Add WebRTC Fallback?

[cblgh]

@sammacbeth had the following tip:

I found that discovery-swarm-webrtc (with a turn server) works better for difficult networks, and as a bonus it can use ipv6.

if we want to go down this TURN-server approach, since it seems implausible that regular clients with unconfigured firewalls and random NATs will be holepunchable in a significant amount of cases, (and cjdns sadly does not magically solve this problem either) maybe the following approach could work:

long-lived cabal peers become TURN servers, and they broadcast their existence on a predefined hyperswarm topic. newly started clients (with internet) that cannot connect (or: have not historically connected) to anyone on a given cabal key within <timeout> proceed to query the hyperswarm TURN topic to find a TURN-server. since the TURN server does not know the cabal key, the contents that are being ferried through it are not readable by it.

for peers to deterministically end up at the same TURN server, the cabal key is used, somehow.

so, the long-lived super peers (i.e. peers which others can connect to) of one cabal help peers of cabals without super peers by ferrying encrypted traffic for them (i.e. becoming TURN servers, but maybe another technique is possible using the same idea)

peers should be able to turn off the automatic usage of TURN-after-timeout.

[okdistribute]

Will the operator of the TURN server be able to read the contents of messages? Perhaps we could consider e2e encryption before turning this on?

[cblgh]

i was thinking we could just pass the multifeed replication stream (which is encrypted with the cabal key, and unknown to the TURN server), but that might be trickier than anticipated ^^

[dwblair]

Wow, this seems super coooool ...

I've wondered why it is that Web RTC applications seems to be able to connect more often than cabal is able to, in my experience; if the reason for that is how TURN servers work, then gosh, supplementing hyperswarm with a TURN backup seems like a great idea!

If guaranteeing e2e encryption of messages involves a lot of additional work, it occurs to me that the TURN server could still come in handy, even if implemented minimally, when generating network connectivity diagnostics, as per cabal-cli #171 -- i.e.if a client is able to connect to a TURN server, but not via 'regular' hyperswarm, then maybe that provides useful network information to the client already, even before any messages are exchanged ... ?

[hackergrrl]

Hey @cblgh, maybe I've misunderstood the problem statement, but isn't every peer is already a relay (via hypercore replication)? Won't having a peer relay my hypercore data to another peer be redundant?

[cblgh]

@noffle this idea is about sharing super peers across cabals, essentially. the TURN thing was just a mechanism for that, based off of sam's experience with them

@dwblair and yeah, we definitely would benefit from some minimal diagnostic commands! whether in this shape or another (we've recently been debugging hyperswarm with its cli tool