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
Updating MASQ to a new version is currently a fairly complicated process. We'd like to simplify that process, if it's not prohibitive for us.
Look at what's available for doing self-updating under Rust. A couple of public crates to investigate are patchify and autoupdater; there are probably others.
Decide which of the available options would be best. We'll need both client functionality in the Node and server functionality in some cloud-server setup somewhere--possibly in GitHub. For each set of functionality, write up a list of cards describing what will be necessary. Especially for the server functionality, do some calculations to get an idea of what providing updates will cost.
Keep in mind that whatever updating happens will need to be able to be done through the MASQ network. If the updating library takes control of the network stack at too low a level, this might be impossible. In such a case, that library should be discarded in favor of something that allows MASQ proxying, even if it's harder to use.
The text was updated successfully, but these errors were encountered:
Current MASQNode does not have any notification or automatic way to instruct a user to update their Node version when releases are done.
There are Rust crates that offer auto-updater functionality, which may provide a solution for this:
Updating MASQ to a new version is currently a fairly complicated process. We'd like to simplify that process, if it's not prohibitive for us.
Look at what's available for doing self-updating under Rust. A couple of public crates to investigate are
patchify
andautoupdater
; there are probably others.Decide which of the available options would be best. We'll need both client functionality in the Node and server functionality in some cloud-server setup somewhere--possibly in GitHub. For each set of functionality, write up a list of cards describing what will be necessary. Especially for the server functionality, do some calculations to get an idea of what providing updates will cost.
Keep in mind that whatever updating happens will need to be able to be done through the MASQ network. If the updating library takes control of the network stack at too low a level, this might be impossible. In such a case, that library should be discarded in favor of something that allows MASQ proxying, even if it's harder to use.
The text was updated successfully, but these errors were encountered: