←back to thread

816 points tosh | 5 comments | | HN request time: 0.716s | source
Show context
netsec_burn ◴[] No.41276529[source]
I've used wormhole once to move a 70 GB file. Couldn't possibly do that before. And yes, I know I used the bandwidth of the relay server, I donated to Debian immediately afterwards (they run the relay for the version in the apt package).
replies(3): >>41276736 #>>41276769 #>>41277271 #
AtlasBarfed ◴[] No.41277271[source]
It took this far down in the comments to get to some inkling of the meat of this.

It relys on some singular or small set of donated servers?

NAT <-> NAT traversal is obviously the biggest motivator, since otherwise you just scp or rsync or sftp if you don't have the dual barrier.

Is the relay server configurable? Seemed to be implied it is somewhat hardcoded.

replies(2): >>41277716 #>>41282023 #
1. lotharrr ◴[] No.41277716[source]
Yes, it relies on two servers, both of which I run. All connections use the "mailbox server", to exchange short messages, which are used to do the cryptographic negotiation, and then trade instructions like "I want to send you a file, please tell me what IP addresses to try".

Then, to send the bulk data, if the two sides can't establish a direct connection, they fall back to the "transit relay helper" server. You only need that one if both sides are behind NAT.

The client has addresses for both servers baked in, so everything works out-of-the-box, but you can override either one with CLI args or environment variables.

Both sides must use the same mailbox server. But they can use different transit relay helpers, since the helper's address just gets included in the "I want to send you a file" conversation. If I use `--transit-helper tcp:helperA.example.com:1234` and use use `--transit-helper tcp:helperB.example.com:1234`, then we'll both try all of:

* my public IP addresses * your public IP addresses * helperA (after a short delay) * helperB (after a short delay)

and the first one to negotiate successfully will get used.

> since otherwise you just scp or rsync or sftp if you don't have the dual barrier

True, but wormhole also means you don't have to set up pubkey ahead of time.

replies(2): >>41278437 #>>41300820 #
2. samstave ◴[] No.41278437[source]
Can you turn the magic wormhole into an API for receiving a JSON payload directly into your magic wormhole ontop of whatever youre running in a fastAPI to route that incoming wormhole listener?
replies(2): >>41278642 #>>41279071 #
3. lotharrr ◴[] No.41278642[source]
There's a `wormhole send --text BLOB`, which doesn't bother with a bulk-data "transit" connection, and just drops a chunk of text on the receiving side's stdout.

You can also import the wormhole library directly and use its API to run whatever protocol you want. That mode uses the same kinds of codes as the file-sending tool, but with a different "application ID" so they aren't competing for the same short code numbers. https://github.com/magic-wormhole/magic-wormhole/blob/master... has details.

4. meejah ◴[] No.41279071[source]
Yes.

A technique like this is used to do "invites" in Magic Folder, and also in Tahoe-LAFS. That is, they speak a custom protocol over just the Mailbox server in order to do some secrets-exchanging. They never set up a "bulk transport" link.

There is also a Haskell implementation, if that's of interest.

I love to learn about "non-file-transfer" use-cases for Magic Wormhole, so please connect via GitHub (or https://meejah.ca/contact)

5. IshKebab ◴[] No.41300820[source]
Both sides behind NAT is surely the most common use case by a mile? Do you keep stats?

I would have thought NAT hole punching was a basic requirement for something like this...