[ohhhlol]

> The wormhole library requires a "Rendezvous Server": a simple WebSocket-based relay that delivers messages from one client to another. This allows the wormhole codes to omit IP addresses and port numbers. The URL of a public server is baked into the library for use as a default, and will be freely available until volume or abuse makes it infeasible to support.

why not make use of https://docs.syncthing.net/users/strelaysrv.html ? lots of servers http://relays.syncthing.net/

[lotharrr]

Interesting.. I'll take a look at it. My first thought is that magic-wormhole needs a canonical way to allocate "nameplates" (the numeric channel identifier at the start of the wormhole code), and that's tricky to do in a DHT (I'm assuming syncthing's relay server behaves like a DHT).

We've got a ticket open (https://github.com/warner/magic-wormhole/issues/72) about distributing this rendezvous server.. I'll add a note to check out syncthing.

[hiq]

Why would I use magic worm-hole instead of Syncthing or Signal? They are both user-friendly and easy to install for the person I want to send the file to. The only shortcomings I can imagine:

_AFAIR Signal has a size limit on the file you can send

_you need a phone number and a smartphone to use Signal

_The Synching key you have to share is complicated, but sending it via email and making sure you add the hosts quickly on both sides would provide enough security guarantees for most people. If you have a secure messenger then you can simply share the key through this channel. And overall I find it easier to explain how to

1) install Signal

2) install Syncthing and share the keys

rather than install magic-wormhole and use some passphrase.

[lotharrr]

Signal and Syncthing are great. magic-wormhole is more about setting up that initial connection: when two humans know each other, but their computers haven't met yet (i.e. know each others pubkeys).

In Signal, the security of the initial message exchange depends upon the phone network (did somebody spoof caller-id to claim Alice's phone number?) and the Signal servers (did they report the correct key for Alice's phone number)? Once you've verified keys in person, those concerns go away. In magic-wormhole, the security of the initial message exchange depends just upon the wormhole code.

For Syncthing, if I remember right, you have to exchange "Device IDs", which are like public keys. You can send them over email, but the security depends upon the email servers (did any of the servers along the path replace that DeviceID with a false one?). The window of opportunity for that attacker is basically the same as it would be for a wormhole code sent via email. And Syncthing gets you long-term/repeated sharing of a folder, whereas magic-wormhole is one-shot.

My goal for magic-wormhole is to offer it as a provisioning protocol for other tools (with better UI and more functionality). Imagine if Syncthing had an "Invite A New Device" button, and pushing it gave you a wormhole code, and the other Syncthing instance had an "Accept Invitation" button where you type in that code. Then you could get all the nice UI and workflow of Syncthing, but you wouldn't have to transcribe the large Device ID (pubkey), and you could do it over something safer than email (like a phone call or just speaking the code to the coworker sitting next to you).

[hiq]

Thanks a lot for the reply! Indeed I was thinking that the main use case that would make sense is the integration of your tool in other more complicated protocols, as a simple first step. As you mentioned, the Syncthing "device id" is 56 characters long that are pseudo-random and thus nigh impossible to remember. Having magic-wormhole as a first step in the handshake would make everything easier.

P.S.: some have mentioned that using apt to install dependencies and then pip to install Magic-Wormhole itself is complicated. You should probably replace these instructions for Debian by "sudo apt install magic-wormhole", as it is included in Debian as of Stretch (stable). It should be the recommended option anyway.

[ComodoHacker]

> In magic-wormhole, the security of the initial message exchange depends just upon the wormhole code

...and upon third-party rendezvous/relay server, doesn't it?

[codefined]

You don't trust that third-party server with any information, it simply makes the initial link between the two parties, like a DNS, that it needs to send the encrypted information to.

An evil relay server could not send the information, or send information to the wrong server, but neither would cause data to be lost because of the encryption.

[ComodoHacker]

You can also fallback to Tox or other existing public P2P network.

[ohhhlol]

see also- https://docs.syncthing.net/specs/relay-v1.html

[BrandiATMuhkuh]

You can also use https://ondevice.io for that. But in that case it let's you ssh into the remote device even if it changes location/ip-address. I use it for some IoT tinkering I do.