magic-wormhole
thinking about magic-nostrhole
Hi, studying magic-wormhole I started figuring out how it could benefit from become compatible with the NOSTR network. Here some info https://nostr.com/ , there is much to explore about it. What I'm thinking about is standardize in a NIP https://github.com/nostr-protocol/nips a way a nostr relay can act as a magic-wormhole-mailbox-server. The most important benefits I'm thinking about if nostr relays would integrate magic-wormhole is:
- A more decentralized network of relays.
- Possibility to not rely on a single hardcoded server; the protocol could be expanded to negotiate what relay to use using web-of-trust in a social-network-like experience where you "add in your friendlist the guy sitting next to you in the conference and having also the info about what relay to use for magic-wormhole".
- Possibility of monetization to prevent spam and make the mailbox-server business model sustainable: nostr relays can leverage bitcoin lightning network instant low-fees micropayments, or even better, cashu https://cashu.space/ chaumian e-cash tokens to be attached during the connection. Most nostr relays are operated for free by various project maintainers, but for who needs a more reliable and premium experience, the micro-payment (sub-cent payments) model is a great new option.
- leveraging NOSTR async crypto and web-of-trust for authentication and discoverability (of machines exchanging files, but also for mail-servers), but this is a non-trivial argument to expand and the possibilities and the complexities are a lot...
My competence for now terminate here, will contunue studying this possibility and what could be the best way to proceed. If you are interested about nostr or about anything dont esitate to question, I'd be happy trying to help!
Hello, thanks for reaching out.
We would really like to get rid of the "single, central server" -- but not at the expense of ease-of-use.
That means that the humans don't have to decide "which server shall we use" and application developers only have to ensure that all their users are on the same server. The codes also need to be easy for humans to transcribe and write down (or remember for short periods). Of course, this is also centralized and a single-point-of-failure (SPoF).
So I'm happy to explore ideas to decentralize this situation. One difficulty being that there must be a "shared mailbox-id address-space" for two clients to communicate. That is, per "app-id" we need a cohesive way to allocate mailbox-ids, associate (and disassociate) nameplates to them, and store (encrypted) messages that both sides can send + receive.
One idea around this, for example, is to sacrifice one of the digits of the nameplate to designate a server to handle that code -- this would allow up to 10 servers, at the expense of always having 2 or more digit codes. That is, a tiny sacrifice in ease-of-use for some gain in decentralization. (This has not been implemented yet, of course, just an idea).
As far as the cryptocurrency ideas, I personally have no interest in incorporating anything related to cryptocurrency -- but there is the "permissions" API now. This has a "hashcash" based implementation, and is intended to support others. See https://github.com/magic-wormhole/magic-wormhole-protocols/blob/01b7c46ffaec4c12866f99bb2596fd4e49db460a/server-protocol.md?plain=1#L155
Those interested in methods beyond hashcash should start here.