Spirobel
References:
https://x.com/spirobel/status/1672479215512588288
https://github.com/busyboredom/acceptxmr/issues/64
https://x.com/spirobel/status/1595949928634667008
https://github.com/spirobel/monero-discourse-subscriptions
https://x.com/spirobel/status/1596299822516285440
https://github.com/spirobel/monerochan-merchant-rpc
https://www.youtube.com/watch?app=desktop&v=4DLcsQ45zoE
Contact: twitter.com/spirobel
Result: A robust and modular wallet-rpc library, implemented in Rust with WebAssembly (WASM) as the primary target. This library aims to provide a flexible foundation for Monero wallet functionality. The deliverable for this proposal will be:
list of initial tasks:
this task list is not exhaustive and subject to change
As discussed as far back as two years ago: https://github.com/seraphis-migration/strategy/issues/2 The wallet2 Monero library is a 15k lines CPP file. The official monero repo does not contain a deliverable that is easily linkable from other programs. Every project that is a wallet or contains wallet-like functionality (payment processors, hardware wallets, point of sale terminals) needs to implement its own wrapper to expose a C ABI.
This results in collectively wasted hours and headaches. It increases supply chain risk and makes building things with Monero harder. As a result, projects get more expensive, take longer or don't happen at all.
This library aims to counteract the issues and limitations of wallet2.cpp by directly targeting wasm. Using wasm as the main target means that this library is forced to be implemented in a way that meets the expectations outlined here: https://github.com/seraphis-migration/strategy/issues/1
The benefits of this approach:
WASM is a very constrained target. There is no garbage collection and multi threading. Getting code to run there means having to write it in a way that is easy to interact with from any language and in any environment.
The current monero wallet-rpc is at times unresponsive, because its concurrency mixes the responses of the local rpc with the network interacting with the node. More details in the monero-playground repository. The WASM target constraints ensure that this library decouples the concurrency and networking from the wallet code. The result will be more robust.
Wallet code deals with the most sensitive data. It should not have unnecessary dependencies or bloat. To give a practical example: monero currently vendors a 4000 lines of code logging library that introduces a dependency on signals. The WASM target constraint means that things like that can't and wont be introduced into this library.
value commitment:
The 3 deliverables outlined in the What section are the promised outcome of this proposal. Any time left over from the time commitment will be used to further advance the road map. The value commitment is due for the milestone of the second month.
time commitment:
The next step on the road map is to add transaction building and signing functionality to the library and migrate the browser wallet to it.
My endgame is to remove all friction from the privacy enabled web shopping experience. Currently most Monero shoppers have to copy and paste addresses from the tor browser into their wallets. This opens the door to unnecessary opsec failures, as it is easy to get confused and intimidated by long strings of random numbers.
A core part of staying private and safe online is to compartmentalize identities. Qubes OS made some advancements in improving the UX of this activity by coloring different windows that are tied to different identities in a unique way.
The reality is, that installing a different operating system is a large ask for the average person. At the same time we need to onboard as many people as possible to these habits, so we can operate safely in the crowd.
The other venue of attack is using the browser for compartimentalization. And before anybody complains: no this does not involve untrusted javascript frontend code.
There is a big difference between a browser wallet and web wallet. A web wallet is a flawed experiment that is borderline custodial, as it runs wallet code inside the context of a website. This is not to be confused with a browser wallet. A browser wallet runs trusted code as a compartmentalized, constrained program inside of a sandbox.
There is a massive opportunity here to reduce friction by making it easy to separate online identities. The TOR browser currently enables the use of one separate TOR circuit for each tab. Imagine we have one monero address per tab that is used for login and to send and receive payments. It makes it much harder to mess up.
One last concern that comes up is that there might be zero day exploits in the browser, as it exposes a potentially larger attack surface. This can be mitigated by making the wallet a multisignature wallet and using a second device like an android phone or a monero seedsigner to authorize every transaction. This means two devices need to be compromised to capture funds, which is unlikely.