Magic Wormhole: Get Things From One Computer to Another, Safely

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)

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).

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>

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).

Granted croc supports resuming transfers, which magic wormhole doesn't.

https://play.google.com/store/apps/details?id=io.sanford.wor...

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

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.

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.

- 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.

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.

(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/