Allocate a mailbox without a nameplate

[timmc]

I'm developing an application called "breakmancer" where the two parties would like to connect via wormhole but have an existing piece of shared information. Ideally I would just derive a mailbox code from this shared information (by hashing it and converting to a large number) but the Rust implementation does not allow for directly creating a Mailbox object and using it in the rendezvous protocol -- everything has to go through Codes instead.

In practice, supporting this might just involve the following:

• Undeprecate RendezvousServer
• Make Mailbox public
• Applications can then use RendezvousServer.html::open_directly

My workaround has been to generate a nameplate+password (in a similar manner) where the nameplate is deterministically random within 0..i64::MAX. [EDIT: Upper bound.] This makes it very unlikely that there will be a collision with a nameplate already in use. The generated code looks like 2169281208640752923-34d1MHZZDjhn7SHG7. It works, but it would be nice if I could instead target a Mailbox directly, which I believe the Python implementation allows.

One wrinkle here is that the protocol documentation doesn't indicate what range of numeric strings should be accepted by a rendezvous server. I could imagine specifying a minimum range directly in the protocol (my preference), having the server advertise it, or extending the protocol to convert a string deterministically into a mailbox number.

(I might also be able to refactor my application in such a way that it could ask the rendezvous server for a random Code, but it might be non-trivial to do so.)

[timmc]

(A weird thing about my application is that the shared information is not a secret, as breakmancer has a different mechanism for setting up an encrypted channel and only would be using the library as a connectivity option. But the same idea would apply for a shared secret, and that may in fact be something breakmancer supports in the future as well.)

[felinira]

One wrinkle here is that the protocol documentation doesn't indicate what range of numeric strings should be accepted by a rendezvous server

Please follow magic-wormhole/magic-wormhole-protocols#43 for that, and feel free to contribute your ideas. At the moment the requirement on the protocol level is very lax, I would expect that a protocol PR to limit it to "just numbers" would be accepted, and any other limitations would likely not. So the general consensus is probably that "a number, no matter how large" is an acceptable nameplate.

Undeprecate RendezvousServer
Make Mailbox public
Applications can then use RendezvousServer.html::open_directly

That would be a way to go about it. I am wondering if we need RendezvousServer (which we will probably rename to MailboxServer for consistency) for this though. You don't need to send arbitrary messages through the mailbox server, do you? Otherwise we could also just expose the transit protocol directly via some public function or sth.

[meejah]

"In general" sending arbitrary messages through the Mailbox is a valid way to use wormhole (i.e. no Transit or Dilation connection will ever appear). For example, the "invite" flows of Magic Folder and Tahoe-LAFS both do this, exchanging some small JSON messages both ways before shutting down the mailbox.

I think the above thing that @timmc is talking about will look, protocol-wise, exactly like a re-connect to the mailbox: both peers already know a mailbox ID and shared secret, so they connect directly to the mailbox and resume exchanging messages. I don't necessarily want to complicate this PR, but it's definitely related (not sure if there's a ticket for supporting re-connect yet).

[timmc]

I think I don't need to send app-specific messages over the wormhole, although I don't want to rule it out. For example, I've been mulling over whether to exchange some randomness over the wormhole that would then be used in computing the shared transit key; this might be useful in breakmancer's weird situation. But like meejah said, there's also value in a pure-mailbox protocol.

Having looked more into MailboxConnection and RendezvousServer, I see that exposing a mailbox-direct this isn't as straightforward as I thought. MailboxConnection, for example, exposes the Code that was used in creating one -- which wouldn't be possible in the flow I'm envisioning. And I see now how much lower-level RendezvousServer is.

Perhaps the right approach is just to keep doing what I'm doing (deterministically derive a Code from shared information). Maybe that becomes part of magic-wormhole (e.g. MailboxConnection::create_from_shared_secret(...)), maybe it stays in my app.

[timmc]

Oh, for reference, this is what breakmancer currently does to generate a Code from shared info: https://codeberg.org/timmc/breakmancer/src/commit/3ce168283af56ee84ffc0ce41dcb7b8f2982ca1c/src/transport/wormhole.rs#L58 [EDIT: Updated link now that I've made a version that could support a shared secret.]

[felinira]

"In general" sending arbitrary messages through the Mailbox is a valid way to use wormhole (i.e. no Transit or Dilation connection will ever appear). For example, the "invite" flows of Magic Folder and Tahoe-LAFS both do this, exchanging some small JSON messages both ways before shutting down the mailbox.

Yeah that is a fair point. I'd maybe want to clean up the API before making them public again though, it's a good opportunity. I'll put it on the list for later.

[timmc]

Having read more of the server protocol, I think I might need direct Mailbox connection. The main issue is that I have one leader and potentially multiple followers; generating a Code works fine for a single leader/follower pair, but when multiple followers try to use the same Nameplate it's a problem. I think having them all share a Mailbox would work fine, though! I'll do more reading and will hopefully be talking it over with meejah next week as well.