My friend and former colleague has built a bunch of stuff over magic-wormhole like fowl[0], shwim[1] and so on. There is a lot of nice work on "dilated" wormhole.
And its lesser known component, the mailbox server used for signaling to connect the two computers. If you’ve ever installed and used magic wormhole, you’ve likely used the default public mailbox server unless you configured and set up your own.
Debian was kind enough to configure their distribution's copy with a distinct hostname for the transit relay helper (the bit that forwards bulk encrypted traffic when both parties are behind NAT). "magic-wormhole-transit.debian.net" is currently a CNAME for "transit.magic-wormhole.io" (which is what the upstream source uses), so all this currently costs them is some DNS maintenance. Both sides exchange transit server hostnames, so they don't need to use the same one, but Debian does this so we could switch Debian-based clients off to a different server if/when my costs of running transit.magic-wormhole.io grow too large.
The "mailbox relay server" for all mutually-communicating clients must be the same. Both upstream and Debian (and most of the other distributions I've seen) use "relay.magic-wormhole.io". The mailbox server helps the clients exchange tiny key-exchange and setup messages, so its costs are trivial.
Note that it's less clear how secure croc is. Magic Wormhole would be the reference there, I think. I have seen issues on the croc repository regarding security, not sure what the state is today.
Granted croc supports resuming transfers, which magic wormhole doesn't.
coc is also available on android which maked it really useful. Although kde connect works very well at least for smallish files, it requires pairing devices you might not want to pair permanently.
This project made me learn about and attempt to implement the SPAKE2 protocol and HKDF as an exercise.
It's quite fascinating. It lets you upgrade a short password to a long key, but requires trusting a server to rate limit attempts on brute-forcing that short password. It seems difficult to find a practical use case for it tho. Because it's only relevant when it is impractical to send a long key. But if you think for a second, lets say you are transferring from a desktop to a phone, you can show a QR code and scan in with your phones camera, thus achieving a secure handshake bypassing the need for SPAKE2 all together. Maybe it would defeat the simplicity of the tool, but if it also provided a long string of words for the key, a user could optionally send all the words instead of just the first few and get themselves a secure key without needing to trust the server.
> requires trusting a server to rate limit attempts on brute-forcing that short password
This isn't true. Particularly, if an attacker attempts to connect with the wrong password, this will be seen by the client, which then aborts the connection. So an attacker can only try one password. You can test this yourself:
A: $ wormhole send foobar
A: Wormhole code is 1-whimsical-klaxon
B: $ wormhole receive 1-klaxon-whimsical # wrong password
B: ERROR: Key confirmation failed. Either you or your correspondent
B: typed the code wrong, or a would-be man-in-the-middle attacker guessed
B: incorrectly. Try sending the file again.
B: <exit>
A: ERROR: Key confirmation failed. Either you or your correspondent
A: typed the code wrong, or a would-be man-in-the-middle attacker guessed
A: incorrectly. Try sending the file again.
A: <exit>
So if you receive this error (potentially repeatedly), you learn that there is an attacker trying to guess passwords. You can then choose to increase code length or simply stop using that channel.
The CLI also has an option to further mitigate MITM attacks with the `--verify` flag -- this shows to both clients a hash of the transcript, which can be verbally verified before proceeding with the transfer. This allows detecting an attack even if the attacker gets the password right on the first try (which has probability 1/65536).
Does that mean if 100 people send files over a server, and out of the 100 recipients a single one spells the code wrong, all 100 transfers get cancelled?
No, the key negotiation occurs between two clients.
In the Magic Wormhole protocol, the number at the beginning of the Magic Wormhole phrase specifies a "nameplate" used to negotiate the "mailbox" which both clients (sender and receiver) use. If a recipient specifies a _matching_ nameplate but a _non-matching_ key phrase, the file transfer transaction between the sender and receiver with a matching nameplate will fail (since they cannot correctly produce a shared key), but nobody else is affected in any way.
An evil attacker could DoS the magic-wormhole mailbox server by spamming mailbox nameplates with bad keys, since there isn't much entropy at all there, but they would affect only single transactions at a time.
That's all nice and dandy, but what about sending data the other way, from a phone to a desktop? Meticulously typing in long strings of text with no mistakes is not really a practical solution for the vast majority of users.
Localsend, if you're on the same wifi network. Works decently for sending files between Android/iOS/Desktop (sometimes on iOS the app must be closed and reopened a couple of times before non iOS devices can detect it, for some reason).
I use magic wormhole everywhere else, servers, vms, etc.
You can still generate the QR code in the desktop and scan it with your phone camera. The device receiving the file does not have to be the device that scans the code.
Maybe if your camera is broken? Or you are using one of those phones built without a camera (like the ones issued to people who work at secure government sites)?
I use this all the time when trying to get files between devices that need multiple hops to get to. Way easier then remembering what scp or rsync combo I need to jump through a host
> Because of firewall network address translation (NAT) issues, rendezvous protocols generally require that there be at least one unblocked and un-NATed server that lets the peers locate each other and initiate concurrent packets at each other.
So probably cant help with a VPC unless you pierce a hole for it.
I guess this makes sense, since by design this shouldn't be possible.
The point of the intermediate server is so that you can NAT hole punch, otherwise it has little point (except maybe as a relay, which is a bad solution).
We're making good progress on hole-punching, but it isn't available yet. Once complete, that should take some pressure/cost off the transit relay machine.
Note that the transit relay only sees ciphertext (for bulk data transfers). Even the mailbox server only sees ciphertext or SPAKE key-exchange messages. No server sees plaintext ever.
There exists winden.app which is a magic wormhole webapp. They use their own mailbox and relay so you need to use the right options in the wormhole CLI.
I prefer https://localsend.org/ nowadays. Nice cross-platform GUI, "just works". Requires being on the same lan, but discovery of other devices is automatic and there are no alphanumeric codes that have to be shared. It's a good QoL improvement to have "airdrop" between Android and Linux
I've had better luck with https://drop.lol/ - it allows local discovery but can also share a link (drop.lol/XXXXX) to invite a device to the "network". There have been a number of times/networks local peer discovery doesn't work for me, but maybe that's because I haven't installed the localsend app.
You need to be sure to use a sufficiently strong password/passphrase for PGP symmetric encryption. For GPG I would use at least 4 diceware words. The thing being discussed here only requires a digit and 2 words due to the use of a PAKE.
It would be nice if things like GPG would generate an appropriate passphrase for you by default.
I guess if you are only going to send one file the difference is not really all that significant. Otherwise the experience after exchanging email addresses and fingerprints would probably be better with encrypted email.
I’ve used this and localsend, both are great, but has anyone finally solved the problem of making one of these things that can use a GUI (for phones and tablets) and also a CLI (for when I’m SSHed into my home computer and need to send a video to get processed by something)?
I need iOS and iPadOS. Although ideally there’d be a GUI that could work on all of the “mainstream” OSes, since most of my problem here is that I frequently need to move files between devices in different walled or unwalled gardens.
For desktop PCs, Rymdport (formerly wormhole-gui) may be suitable. It's cross-platform with pre-built binaries for FreeBSD, Linux, macOS and Windows on x86-64 and arm64:
If you don't mind unencryption or are okay with encrypting/decrypting things yourself via standard tools (don't worry you could probably create a shell alias to do that for you in ssh)
Personally I don't really mind the unencryption as I mean I just use it to pass videos or any software and I don't really think that there are any security concerns but its also really easy to encrypt / decrypt as well so I genuinely recommend it
It can actually work out of the browser and in the ssh server by using curl / maybe even wget but no guarantees. Both standard tools.
No CLI yet but mobile & desktop support (yes, including Linux), LAN & online: https://payload.app/
Focused on speed, so good for video. (If your transfers don’t saturate the network I treat that as a failure and a bug to be fixed - please report if speed is ever lacking)
Folks at Coder authored a p2p file transfer tool using Tailscale (no account needed, the setup is entirely ephemeral, and the code apparently runs a Headscale control server in-memory): https://github.com/coder/wush
Unsure how Tailscale rate limits, if at all, such traffic flowing through its public relays ("DERP"), as a tool like this is just ripe for abuse?
A simple encrypted channel for file transfer. A great way to send a file to a stranger who is near you but shares nothing with you, e.g. at a conference.
/* A modern version should, of course, work in a browser, so that there'd be no Python packages to install. But the browser security model does not allow listening, so a signaling server would be needed to create a WebRTC connection. It could run on one of the devices involved, but still can't be a pure web app. */
> A modern version should, of course, work in a browser, so that there'd be no Python packages to install
Now, only uv needs to be installed (two self-contained binaries). Then you can do `uvx magic-wormhole --help` and it will quickly create a transient environment with the required packages. You don't even need to install Python (uv will do a transient install of Python as well).
There are Rust and Haskell implementations too (not quite as feature-full as the Python code yet, though) as well.
In principal WebRTC communication could be added to magic-wormhole, but that work has not been done yet. There is WebSocket support in the relay (including "cross-protocol" so one client can be WebSocket and the other TCP). This is only deployed on the Winden.app servers (tcp://relay.mw.leastauthority.com:4001 and wss://relay.mw.leastauthority.com for the relay).
You'd need to use the Winden.app relay server if you want https://winden.app users to reach your Python CLI (e.g. via "wormhole --relay-url wss://mailbox.mw.leastauthority.com/v1 send" for example)
They don't have to be near you, they can be over the internet. Relatedly, the Magic Wormhole CLI also depends on a signaling server (referred to in the documentation as the "mailbox"), so I don't think it's doing anything you couldn't do with WebRTC.
"Near you" physically only matters in coordination, not the network. I can beside someone and it will still go towers and space before we establish a connection.
Been using it from time to time to transfer secrets; out of curiosity, when I'm sending something to some via this tool, do you known what machines is it relayed through? I am sure it's not peer-to-peer; would not be as reliable!
Both sides connect to the "mailbox relay server" to perform key exchange and setup. That's a host named "relay.magic-wormhole.io".
If either side has a public IP address, the encrypted data is transferred directly (they exchange IP addresses through the encrypted pipe, and attempt to connect to all of them, so this also covers two peers on the same LAN). If neither do, they both connect to a public "transit helper" relay named "transit.magic-wormhole.io" which acts like a TURN server to get the encrypted bytes from one connection to the other. I run both services.
I did use it some time ago, but I remember the user experience being somewhat confusing, since there are multiple similarly named tools around, which don't seem to be interoperable. Still, a cool concept.
1. i wish syncthing also would implement this
2. is it already postquantum secure?
(to all the quantum-computer-will-never-come-people: i like to be prepared in CASE it comes, otherwise no one will prepare and users are in the dust, once it is there)
I am not a cryptographer, but can explain that Magic Wormhole uses SPAKE2 to negotiate a shared secret (RFC9382 claims equivalent to gap Diffie-Hellman), and then uses NaCl SecretBox to symmetrically encrypt all data between the peers.
(If using the newer Dilation protocol -- which is true for many of the non-file-transfer tools like ShWiM, Git-WithMe or Fowl -- peer traffic uses this shared secret with Noise, specifically "Noise_NNpsk0_25519_ChaChaPoly_BLAKE2s")
Strong recommend. When I’m bouncing around getting onboarded on new client/customer machines that disallow syncing (justifiably), magic wormhole is a fabulous way to get my dot files and local env set up in a jiffy. Works well for secure transfer of _large_ files ad hoc, too, so a great fit for db dumps.
I’m glad to see that there are mobile apps and web applications that work on/use Magic Wormhole for peer to peer file transfers. The mobile app and web applications seem to be limited (number of files is one at a time, size of file allowed, etc.) due to limitations on mobile platforms and due to choices by the developer/server host.
- NAT Traversal: WireGuard typically requires at least one publicly-reachable endpoint. Magic Wormhole's relay server handles NAT traversal for initial rendezvous, then attempts direct connection.
- Configuration: WireGuard needs config files with public keys and endpoints. Magic Wormhole just needs a temporary code.
- Layer: WireGuard operates at network layer (creates virtual interface, routes IP traffic). Magic Wormhole is application-level.
[1] Based on a conversation with Claude 4.5, distilled and lightly edited. This information matches my experience with them.
I use magic wormhole when I first install a computer to send an SSH key. At that point, I have ssh. Also if you use a mesh VPN, your devices are already connected and there are several ways to transfer files.
I like to use it more. What is your use case for this?
FYI, there's a subcommand just for this use case: `wormhole ssh invite` / `accept`, which will read the SSH pubkey on one end and append it to authorized_keys on the other.
If you’re launching machines from a prebaked image or template, it may not be possible to inject/generate something unique for each one, or doing so is finicky to the point that using something like wormhole may be simpler than fighting with your provisioning tool.
I use this very specifically for setting up new machines. It's one of those where I don't use it much, but when I do it has saved me a whole lot of time, and it's worked well every time.
My friend and former colleague has built a bunch of stuff over magic-wormhole like fowl[0], shwim[1] and so on. There is a lot of nice work on "dilated" wormhole.
[0] <https://github.com/meejah/fowl>
[1] <https://github.com/meejah/shwim>
...and also "Git-WithMe" for peer-to-peer, one-off Git usage: https://sr.ht/~meejah/git-withme/
And its lesser known component, the mailbox server used for signaling to connect the two computers. If you’ve ever installed and used magic wormhole, you’ve likely used the default public mailbox server unless you configured and set up your own.
https://github.com/magic-wormhole/magic-wormhole-mailbox-ser...
I usually use the Debian one and never had problems.
(magic-wormhole author here)
Debian was kind enough to configure their distribution's copy with a distinct hostname for the transit relay helper (the bit that forwards bulk encrypted traffic when both parties are behind NAT). "magic-wormhole-transit.debian.net" is currently a CNAME for "transit.magic-wormhole.io" (which is what the upstream source uses), so all this currently costs them is some DNS maintenance. Both sides exchange transit server hostnames, so they don't need to use the same one, but Debian does this so we could switch Debian-based clients off to a different server if/when my costs of running transit.magic-wormhole.io grow too large.
The "mailbox relay server" for all mutually-communicating clients must be the same. Both upstream and Debian (and most of the other distributions I've seen) use "relay.magic-wormhole.io". The mailbox server helps the clients exchange tiny key-exchange and setup messages, so its costs are trivial.
For sending files between my phone (Android) and my son's iPad, I use:
Wormhole William (Android): https://github.com/psanford/wormhole-william-mobile
Destiny (iOS): https://github.com/LeastAuthority/destiny
For interoperability, don't use Destiny's default servers. After you install Destiny, change the config to the standard Magic Wormhole servers:
Mailbox: ws://relay.magic-wormhole.io:4000/v1
Transit Relay: tcp://transit.magic-wormhole.io:4001
Thanks for posting. This was good timing for me!
croc[1] has worked better for me. It supports resuming transfers, which is a must. It is very wormhole like and written in Go.
[1] https://github.com/schollz/croc
Note that it's less clear how secure croc is. Magic Wormhole would be the reference there, I think. I have seen issues on the croc repository regarding security, not sure what the state is today.
Granted croc supports resuming transfers, which magic wormhole doesn't.
I've used croc extensively and had no issues.
100% endorse croc, you can use croc in any GPU renting service (e.g Runpod).
coc is also available on android which maked it really useful. Although kde connect works very well at least for smallish files, it requires pairing devices you might not want to pair permanently.
Isn't there an Android app supporting magic wormhole?
Yes, there are several alternative clients including several for Android: https://magic-wormhole.readthedocs.io/en/latest/ecosystem.ht...
There is Destiny https://leastauthority.com/community-matters/destiny/. Although there hasn't been much activity lately.
croc's throughput was also a lot better for me. I think this is due to them using multiplexed TCP streams.
This project made me learn about and attempt to implement the SPAKE2 protocol and HKDF as an exercise. It's quite fascinating. It lets you upgrade a short password to a long key, but requires trusting a server to rate limit attempts on brute-forcing that short password. It seems difficult to find a practical use case for it tho. Because it's only relevant when it is impractical to send a long key. But if you think for a second, lets say you are transferring from a desktop to a phone, you can show a QR code and scan in with your phones camera, thus achieving a secure handshake bypassing the need for SPAKE2 all together. Maybe it would defeat the simplicity of the tool, but if it also provided a long string of words for the key, a user could optionally send all the words instead of just the first few and get themselves a secure key without needing to trust the server.
> requires trusting a server to rate limit attempts on brute-forcing that short password
This isn't true. Particularly, if an attacker attempts to connect with the wrong password, this will be seen by the client, which then aborts the connection. So an attacker can only try one password. You can test this yourself:
So if you receive this error (potentially repeatedly), you learn that there is an attacker trying to guess passwords. You can then choose to increase code length or simply stop using that channel.The CLI also has an option to further mitigate MITM attacks with the `--verify` flag -- this shows to both clients a hash of the transcript, which can be verbally verified before proceeding with the transfer. This allows detecting an attack even if the attacker gets the password right on the first try (which has probability 1/65536).
Does that mean if 100 people send files over a server, and out of the 100 recipients a single one spells the code wrong, all 100 transfers get cancelled?
No, the key negotiation occurs between two clients.
In the Magic Wormhole protocol, the number at the beginning of the Magic Wormhole phrase specifies a "nameplate" used to negotiate the "mailbox" which both clients (sender and receiver) use. If a recipient specifies a _matching_ nameplate but a _non-matching_ key phrase, the file transfer transaction between the sender and receiver with a matching nameplate will fail (since they cannot correctly produce a shared key), but nobody else is affected in any way.
An evil attacker could DoS the magic-wormhole mailbox server by spamming mailbox nameplates with bad keys, since there isn't much entropy at all there, but they would affect only single transactions at a time.
That's all nice and dandy, but what about sending data the other way, from a phone to a desktop? Meticulously typing in long strings of text with no mistakes is not really a practical solution for the vast majority of users.
The moderately technical solution is a single-file webserver on the computer that supports file uploads, like https://github.com/sigoden/dufs.
Once it is running all you need to type on the phone is the IP:port.
Localsend, if you're on the same wifi network. Works decently for sending files between Android/iOS/Desktop (sometimes on iOS the app must be closed and reopened a couple of times before non iOS devices can detect it, for some reason).
I use magic wormhole everywhere else, servers, vms, etc.
LANDrop
https://landrop.app/
There are some forks since the software was originally opensource but then closed it.
Start web server on desktop, show QR on desktop, scan with phone, phone posts key to route in QR code
QR codes?
Not all desktops have cameras.
The vast majority of desktops do not have a camera.
You can still generate the QR code in the desktop and scan it with your phone camera. The device receiving the file does not have to be the device that scans the code.
I was reading about MW yesterday and had the same question about the short password. Here's a doc I found about it: https://magic-wormhole.readthedocs.io/en/latest/attacks.html...
Me too! A few years back I ported magic-wormhole to Haskell and wrote a few posts about what I learned (https://jml.io/posts/spake2-begins/, https://jml.io/posts/what-is-spake2/). The good folk at Least Authority took over the Haskell implementation: https://github.com/leastauthority/haskell-magic-wormhole
Maybe if your camera is broken? Or you are using one of those phones built without a camera (like the ones issued to people who work at secure government sites)?
https://gist.github.com/SMUsamaShah/fd6e275e44009b72f64d0570... List of p2p file sharing tools including this one. Most in the list are browser based.
I use this all the time when trying to get files between devices that need multiple hops to get to. Way easier then remembering what scp or rsync combo I need to jump through a host
Hmm how does this negotiate the hops or does it assume internet access? E.g. what if the last hop is inside a VPC.
It uses a rendezvous server to handle connecting.
Googled.
> Because of firewall network address translation (NAT) issues, rendezvous protocols generally require that there be at least one unblocked and un-NATed server that lets the peers locate each other and initiate concurrent packets at each other.
So probably cant help with a VPC unless you pierce a hole for it.
I guess this makes sense, since by design this shouldn't be possible.
The point of the intermediate server is so that you can NAT hole punch, otherwise it has little point (except maybe as a relay, which is a bad solution).
We're making good progress on hole-punching, but it isn't available yet. Once complete, that should take some pressure/cost off the transit relay machine.
Note that the transit relay only sees ciphertext (for bulk data transfers). Even the mailbox server only sees ciphertext or SPAKE key-exchange messages. No server sees plaintext ever.
Well it allows you to customize the rendezvous server, so if you're on a network with no internet access you can host the server there.
AFAIK, Web Wormhole is the only one of those tools that can be used both as a command-line tool and from a browser. It looks like the site is down at the moment though. https://github.com/saljam/webwormhole https://webwormhole.io/
Their TURN and STUN servers are down too.
There exists winden.app which is a magic wormhole webapp. They use their own mailbox and relay so you need to use the right options in the wormhole CLI.
The website doesn’t work on my phone.
I prefer https://localsend.org/ nowadays. Nice cross-platform GUI, "just works". Requires being on the same lan, but discovery of other devices is automatic and there are no alphanumeric codes that have to be shared. It's a good QoL improvement to have "airdrop" between Android and Linux
The main reason one would use Magic Wormhole is that the devices do not need to be on the same LAN...
If two Magic Wormhole clients _are_ on the same LAN they should communicate directly that way (i.e. no relay required).
I've had better luck with https://drop.lol/ - it allows local discovery but can also share a link (drop.lol/XXXXX) to invite a device to the "network". There have been a number of times/networks local peer discovery doesn't work for me, but maybe that's because I haven't installed the localsend app.
Thank you for this link. Looks awesome.
>Copying files through encrypted email requires bootstrapping a GPG key as well as an email address.
Do people realize that GPG supports symmetric encryption?
You need to be sure to use a sufficiently strong password/passphrase for PGP symmetric encryption. For GPG I would use at least 4 diceware words. The thing being discussed here only requires a digit and 2 words due to the use of a PAKE.
It would be nice if things like GPG would generate an appropriate passphrase for you by default.
I guess if you are only going to send one file the difference is not really all that significant. Otherwise the experience after exchanging email addresses and fingerprints would probably be better with encrypted email.
One of the best tools I've ever used. I adore it. I use it everywhere. It's supremely handy when migrating data between servers in a hurry.
I’ve used this and localsend, both are great, but has anyone finally solved the problem of making one of these things that can use a GUI (for phones and tablets) and also a CLI (for when I’m SSHed into my home computer and need to send a video to get processed by something)?
Wormhole William is available for Android devices:
https://play.google.com/store/apps/details?id=io.sanford.wor...
I need iOS and iPadOS. Although ideally there’d be a GUI that could work on all of the “mainstream” OSes, since most of my problem here is that I frequently need to move files between devices in different walled or unwalled gardens.
For desktop PCs, Rymdport (formerly wormhole-gui) may be suitable. It's cross-platform with pre-built binaries for FreeBSD, Linux, macOS and Windows on x86-64 and arm64:
https://github.com/Jacalz/rymdport
If you don't mind unencryption or are okay with encrypting/decrypting things yourself via standard tools (don't worry you could probably create a shell alias to do that for you in ssh)
Then I genuinely recommend piping-server https://github.com/nwtgck/piping-server
Personally I don't really mind the unencryption as I mean I just use it to pass videos or any software and I don't really think that there are any security concerns but its also really easy to encrypt / decrypt as well so I genuinely recommend it
It can actually work out of the browser and in the ssh server by using curl / maybe even wget but no guarantees. Both standard tools.
https://piping-ui.org/ There is this website which has a better ui
And you can self host the server as well and these ui's are just static pages which you can view the source code of
https://github.com/nwtgck/piping-server
There are several different clients available for Magic Wormhole, including GUIs and phone apps: https://magic-wormhole.readthedocs.io/en/latest/ecosystem.ht...
No CLI yet but mobile & desktop support (yes, including Linux), LAN & online: https://payload.app/
Focused on speed, so good for video. (If your transfers don’t saturate the network I treat that as a failure and a bug to be fixed - please report if speed is ever lacking)
Disclaimer: I’m the creator.
Folks at Coder authored a p2p file transfer tool using Tailscale (no account needed, the setup is entirely ephemeral, and the code apparently runs a Headscale control server in-memory): https://github.com/coder/wush
Unsure how Tailscale rate limits, if at all, such traffic flowing through its public relays ("DERP"), as a tool like this is just ripe for abuse?
A simple encrypted channel for file transfer. A great way to send a file to a stranger who is near you but shares nothing with you, e.g. at a conference.
/* A modern version should, of course, work in a browser, so that there'd be no Python packages to install. But the browser security model does not allow listening, so a signaling server would be needed to create a WebRTC connection. It could run on one of the devices involved, but still can't be a pure web app. */
> A modern version should, of course, work in a browser, so that there'd be no Python packages to install
Now, only uv needs to be installed (two self-contained binaries). Then you can do `uvx magic-wormhole --help` and it will quickly create a transient environment with the required packages. You don't even need to install Python (uv will do a transient install of Python as well).
There are Rust and Haskell implementations too (not quite as feature-full as the Python code yet, though) as well.
In principal WebRTC communication could be added to magic-wormhole, but that work has not been done yet. There is WebSocket support in the relay (including "cross-protocol" so one client can be WebSocket and the other TCP). This is only deployed on the Winden.app servers (tcp://relay.mw.leastauthority.com:4001 and wss://relay.mw.leastauthority.com for the relay).
You'd need to use the Winden.app relay server if you want https://winden.app users to reach your Python CLI (e.g. via "wormhole --relay-url wss://mailbox.mw.leastauthority.com/v1 send" for example)
They don't have to be near you, they can be over the internet. Relatedly, the Magic Wormhole CLI also depends on a signaling server (referred to in the documentation as the "mailbox"), so I don't think it's doing anything you couldn't do with WebRTC.
"Near you" physically only matters in coordination, not the network. I can beside someone and it will still go towers and space before we establish a connection.
Been using it from time to time to transfer secrets; out of curiosity, when I'm sending something to some via this tool, do you known what machines is it relayed through? I am sure it's not peer-to-peer; would not be as reliable!
(author here)
Both sides connect to the "mailbox relay server" to perform key exchange and setup. That's a host named "relay.magic-wormhole.io".
If either side has a public IP address, the encrypted data is transferred directly (they exchange IP addresses through the encrypted pipe, and attempt to connect to all of them, so this also covers two peers on the same LAN). If neither do, they both connect to a public "transit helper" relay named "transit.magic-wormhole.io" which acts like a TURN server to get the encrypted bytes from one connection to the other. I run both services.
Note, too, that you may run your own "transit helper" (code: https://github.com/magic-wormhole/magic-wormhole-transit-rel... ) and then specify this via "wormhole --transit-helper tcp:<your host>:<port>" when doing a transfer.
You do need to run the helper on a public IP address, like a rented VPS for example.
So if I understand correctly, even if I use your relay, the relay relays encrypted data, never learning what I am sending?
Correct.
It does learn some metadata: the endpoints of the messages (unless you use Tor) and the number of bytes in those messages.
It attempts to communicate peer-to-peer but falls back to a relay if necessary.
I did use it some time ago, but I remember the user experience being somewhat confusing, since there are multiple similarly named tools around, which don't seem to be interoperable. Still, a cool concept.
1. i wish syncthing also would implement this 2. is it already postquantum secure?
(to all the quantum-computer-will-never-come-people: i like to be prepared in CASE it comes, otherwise no one will prepare and users are in the dust, once it is there)
I am not a cryptographer, but can explain that Magic Wormhole uses SPAKE2 to negotiate a shared secret (RFC9382 claims equivalent to gap Diffie-Hellman), and then uses NaCl SecretBox to symmetrically encrypt all data between the peers.
(If using the newer Dilation protocol -- which is true for many of the non-file-transfer tools like ShWiM, Git-WithMe or Fowl -- peer traffic uses this shared secret with Noise, specifically "Noise_NNpsk0_25519_ChaChaPoly_BLAKE2s")
One tool that does now use Magic Wormhole for "introduction" like this is EtherSync: https://ethersync.github.io/ethersync/
Strong recommend. When I’m bouncing around getting onboarded on new client/customer machines that disallow syncing (justifiably), magic wormhole is a fabulous way to get my dot files and local env set up in a jiffy. Works well for secure transfer of _large_ files ad hoc, too, so a great fit for db dumps.
I’m glad to see that there are mobile apps and web applications that work on/use Magic Wormhole for peer to peer file transfers. The mobile app and web applications seem to be limited (number of files is one at a time, size of file allowed, etc.) due to limitations on mobile platforms and due to choices by the developer/server host.
Recently learnt about tailscale funnel, and I love it, I would use for everything.
tailscale funnel --set-path <secret> <DIRECTORY>
(The path is needed because there are lots of bots who scan tailscale hostnames).
This works if the sender is tech savvy (and a tailscale user) but not in the other direction.
Maybe I’m missing something but has this been largely superseded by wireguard these days?
Very different use case. It's for one-off secure file transfers.
Ah. I missed the “one off” part.
You might even use Magic Wormhole to securely transfer WireGuard keys!
Nerdsnipe accomplished :)
To summarize some of the key differences [1]:
- Purpose/Scope: WireGuard creates persistent VPN tunnels for ongoing network connectivity. Magic Wormhole handles ephemeral file transfers.
- NAT Traversal: WireGuard typically requires at least one publicly-reachable endpoint. Magic Wormhole's relay server handles NAT traversal for initial rendezvous, then attempts direct connection.
- Configuration: WireGuard needs config files with public keys and endpoints. Magic Wormhole just needs a temporary code.
- Layer: WireGuard operates at network layer (creates virtual interface, routes IP traffic). Magic Wormhole is application-level.
[1] Based on a conversation with Claude 4.5, distilled and lightly edited. This information matches my experience with them.
I use magic wormhole when I first install a computer to send an SSH key. At that point, I have ssh. Also if you use a mesh VPN, your devices are already connected and there are several ways to transfer files.
I like to use it more. What is your use case for this?
BTW, I haven’t found a good iOS app.
FYI, there's a subcommand just for this use case: `wormhole ssh invite` / `accept`, which will read the SSH pubkey on one end and append it to authorized_keys on the other.
I think you should create a new ssh key for every computer so you only have to share the public key .
If you’re launching machines from a prebaked image or template, it may not be possible to inject/generate something unique for each one, or doing so is finicky to the point that using something like wormhole may be simpler than fighting with your provisioning tool.
I use this very specifically for setting up new machines. It's one of those where I don't use it much, but when I do it has saved me a whole lot of time, and it's worked well every time.
Don't want to crash my friend's server, but he made a Mac app with this: https://www.viawormhole.xyz/
Any screenshots or further reading? "Download this zip with no description" is tough to recommend.
I use Piknik: https://github.com/jedisct1/piknik
I use it all the time. this tool is so great
Another simple solution works on LAN https://pairdrop.net/
It just works.
Great tool.
Very minor web page issue report: please add a replay to the video. Thanks.
can Magic Wormhole help me place a directory of a terabyte of files onto multiple hosts in a datacenter ?
You should probably first test and ensure that you're sending "directly" instead of via the relay -- but if that's true then yes.
How better than Syncthing is it?
Syncthing is for storing files across different endpoints. Magic wormhole sends a file to a computer.
One use-case could be for SyncThing to actually _use_ magic-wormhole as a way to introduce / join another endpoint to a SyncThing folder.
Another cool solution: Copyparty – Turn almost any device into a file server https://news.ycombinator.com/item?id=44711519
[dead]
[flagged]