You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Eventually we want to be smarter with portal selection across our SDKs. This means we will need to extend the client model to all of our SDKs so that we can perform the portal selection only once, when initializing the client. Then we want to implement some checks to select the best portal in the absence of user/dev input.
Design
The priority should be:
Prefer user-configured portal (the portal hosting the sky app) (skynet-js only)
Prefer dev-configured portal (option passed to the Client constructor)
Prefer siasky.net
We also may want to factor in locally-running siad instances as well as user configuration (dotfile or a cookie).
We will need to test for missing capabilities (min version, feature support) for each portal picked. We should hit an endpoint like /version (we might want to make this more specific like skynet-capabilities).
This will also catch the case in point 1 where we are running a web app that is not a sky app on a portal.
When initiating a client we may want to assume that it'll fail, so we'll actually ping the:
current portal
dev portal
siasky portal
all at once, and then use the best one that doesn't return an error or a response that indicates missing capabilities.
The text was updated successfully, but these errors were encountered:
Issue by m-cat
Friday Jul 31, 2020 at 11:14 GMT
Originally opened as NebulousLabs/skynet-docs#21
Smart Portal Selection
Eventually we want to be smarter with portal selection across our SDKs. This means we will need to extend the client model to all of our SDKs so that we can perform the portal selection only once, when initializing the client. Then we want to implement some checks to select the best portal in the absence of user/dev input.
Design
The priority should be:
We also may want to factor in locally-running siad instances as well as user configuration (dotfile or a cookie).
We will need to test for missing capabilities (min version, feature support) for each portal picked. We should hit an endpoint like
/version
(we might want to make this more specific likeskynet-capabilities
).This will also catch the case in point 1 where we are running a web app that is not a sky app on a portal.
When initiating a client we may want to assume that it'll fail, so we'll actually ping the:
all at once, and then use the best one that doesn't return an error or a response that indicates missing capabilities.
The text was updated successfully, but these errors were encountered: