4 ms·

Nifty.. I'll look at the network side of that, maybe we can steal some ideas. At the moment magic-wormhole depends upon one of: * at least one side has a publi

Nifty.. I'll look at the network side of that, maybe we can steal some ideas. At the moment magic-wormhole depends upon one of: * at least one side has a public IP address * both sides are on the same (private) LAN * a TURN-like "Transit Relay" server that I run That transit server hasn't gotten a worrysome amount of traffic yet, but it's a potential scaling problem. (Fortunately the two sides can offer their own transit servers, and they negotiate the one to use, so it's also not a difficult scaling problem to address). In the long run I'm hoping to get some NAT-hole-punching tools, maybe WebRTC, to reduce the need for the transit relay somewhat. Also in the long run, if both sides are using Tor, then one of then can run an onion service, which gets you the NAT-punching for free.

schoen 9y ago
If I remember correctly, ncp only works on LANs (using local segment broadcast), so it doesn't require either side to have any Internet connectivity at all. Your approach would be a lot more flexible, but I bet people would also appreciate it if you could figure out a LAN-only mode -- for better privacy, and when the Internet connection is down. Maybe you could start with an ncp-style segment broadcast and then fall back to the transit relay server if nothing on the segment answers and begins negotiation?
- lotharrr 9y ago
  Yeah, also the two sides can exchange (encrypted) notes about their apparent network environment (including their public IP address, as reported by the rendezvous server), which might give them a clue that they're on the same LAN. Also see https://github.com/warner/magic-wormhole/issues/48 https://github.com/warner/magic-wormhole/issues/48 for some discussion about making things work when you're connected to each other but not to the internet, e.g. an ad-hoc wifi network. It doesn't work at all now, but it totally should.
samstave 9y ago
Uh... just an idea: can you leverage the cloud flare infra challenge for the transit server piece?
Ferofluid 9y ago
Why don't you piggy back on Mainline DHT or try using PEX? Or maybe Local Peer Discovery( to multicast group 239.192.152.143:6771)?
rakoo 9y ago
If you're willing to go the webrtc route for the transport, you might as well look into webtorreny that does everything for you already.

schoen 9y ago

If I remember correctly, ncp only works on LANs (using local segment broadcast), so it doesn't require either side to have any Internet connectivity at all. Your approach would be a lot more flexible, but I bet people would also appreciate it if you could figure out a LAN-only mode -- for better privacy, and when the Internet connection is down. Maybe you could start with an ncp-style segment broadcast and then fall back to the transit relay server if nothing on the segment answers and begins negotiation?

lotharrr 9y ago
Yeah, also the two sides can exchange (encrypted) notes about their apparent network environment (including their public IP address, as reported by the rendezvous server), which might give them a clue that they're on the same LAN. Also see https://github.com/warner/magic-wormhole/issues/48 https://github.com/warner/magic-wormhole/issues/48 for some discussion about making things work when you're connected to each other but not to the internet, e.g. an ad-hoc wifi network. It doesn't work at all now, but it totally should.

samstave 9y ago

Uh... just an idea: can you leverage the cloud flare infra challenge for the transit server piece?

Ferofluid 9y ago

Why don't you piggy back on Mainline DHT or try using PEX? Or maybe Local Peer Discovery( to multicast group 239.192.152.143:6771)?

rakoo 9y ago

If you're willing to go the webrtc route for the transport, you might as well look into webtorreny that does everything for you already.