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
Research a solution for dynamically loading remote modules.
Rationale
For the multi-protocol / multi-blockchain project we need to support different blockchains and wallet modules. It would not scale to ship all those with the core application.
We need a model to load on demand what the user is interested to use. E.g. user choose to trade Zcash. The Zcash wallet and blockchain module is loaded and the user needs to connect it to their local Zcash wallet or install it. The local wallet installation will not be handled by Bisq only the interface module(s) which enables to talk to it (e.g. a rpc based interface).
Criteria for delivery
A summary of the research and possible options
A description of the proposed solution
A prototype demonstrating the use case, the verification steps can be omitted for that
Optional: RFC like specification. Can be reduced to the critical parts like the cryto used for verification
Measures of success
The provided results are considered sufficient to be used as base for implementing the feature.
Risks
No solution found
No sufficient progress
Quality of investigation insufficient
Solution does not fit goals or constraints of overall project
Tasks
Investigate and research options
Design architecture
Demonstrate with a prototype basic use case
Write up proposed solution
Optional: Write RFC
Estimates
This investigation should be scoped from effort and time. I think teh scope of 2 weeks for 1 contributor should not be exceeded. According to that the contributor should post their expected compensation.
Notes
The downloaded module need to be verified similar as we do the in-app download in Bisq using pgp keys and verifying the signatures. Pgp keys are shipped in the app so even if one manages to hack out Github accounts and change the keys there it would be detected. Only for first time users that would not help.
The download for the Bisq updates are not routed over Tor as Github does not support that and it would add a new burden to host ourself those binaries and would decrease security, download speed and reliability (Github is better suited to deal with it). I would suggest to keep that limitation and not take anonymous access for the download as a requirement (all what Github learns is that the user on that IP uses Bisq).
The solution should work with a min. set of dependencies and those dependencies should carry low risk. Techniques which might add security risks should be avoided.
Downloading the remote module is one task. How to start it from an running process is another open challenge and not clear yet if it is a requirement (requiring a restart can be ok, if on the fly integration is too difficult or comes with security risks). So that aspect should be clearified in the investigation as well.
There should be also the option to download (and verify) the modules manually.
I posted an update on my Java Modules JPMS investigation here. The conclusion about JPMS is that it will not work for a project with dependencies that cannot be modularized (like grpc). And we will have to manage version conflicts and version mis-alignment as best we can without JPMS or OSGi.
Description
Research a solution for dynamically loading remote modules.
Rationale
For the multi-protocol / multi-blockchain project we need to support different blockchains and wallet modules. It would not scale to ship all those with the core application.
We need a model to load on demand what the user is interested to use. E.g. user choose to trade Zcash. The Zcash wallet and blockchain module is loaded and the user needs to connect it to their local Zcash wallet or install it. The local wallet installation will not be handled by Bisq only the interface module(s) which enables to talk to it (e.g. a rpc based interface).
Criteria for delivery
Measures of success
The provided results are considered sufficient to be used as base for implementing the feature.
Risks
Tasks
Estimates
This investigation should be scoped from effort and time. I think teh scope of 2 weeks for 1 contributor should not be exceeded. According to that the contributor should post their expected compensation.
Notes
The downloaded module need to be verified similar as we do the in-app download in Bisq using pgp keys and verifying the signatures. Pgp keys are shipped in the app so even if one manages to hack out Github accounts and change the keys there it would be detected. Only for first time users that would not help.
The download for the Bisq updates are not routed over Tor as Github does not support that and it would add a new burden to host ourself those binaries and would decrease security, download speed and reliability (Github is better suited to deal with it). I would suggest to keep that limitation and not take anonymous access for the download as a requirement (all what Github learns is that the user on that IP uses Bisq).
The solution should work with a min. set of dependencies and those dependencies should carry low risk. Techniques which might add security risks should be avoided.
Downloading the remote module is one task. How to start it from an running process is another open challenge and not clear yet if it is a requirement (requiring a restart can be ok, if on the fly integration is too difficult or comes with security risks). So that aspect should be clearified in the investigation as well.
There should be also the option to download (and verify) the modules manually.
There was an old project with an automated update process from the author of BitcoinJ: https://github.com/vinumeris/updatefx
Maybe there are useful ideas.
The text was updated successfully, but these errors were encountered: