Signaling through TURN
This one is an epic.
I was thinking about #22945 (comment 2823413) and #40164 and came up with an interesting idea.
How about we do signaling through a WebRTC peer connection itself? In order to avoid leaking the peers' private data, let's establish the peer connection through a TURN relay initially (with the help of iceTransportPolicy: "relay"
WebRTC option), then set iceTransportPolicy
to "all"
(enabling STUN and true P2P) and restartIce()
and continue signaling (ICE trickling).
Where do we get a TURN server, you might ask? Let's host it along with the broker, I say. Of course we'll probably need some gatekeeping for it (like limiting bandwidth, connection duration, only allowing peers that have communicated with the broker, rotating passwords) so that it doesn't get overloaded by outsiders. Conveniently, Pion also offers a powerful TURN library (example).
Biggest problem - looks like the client has to tunnel the TURN traffic through a domain-fronting HTTPS (WSS?) tunnel (or some other censorship-resistant thing (#25594 )?) because the TURN server might be blocked. I'm not sure how hard it is to achieve, but here's an example of traffic manipulation in Pion, so I guess it shouldn't be super hard.
So Pros:
- Solves #22945
- Practically Solves #40164
- Solves the verification part of #40165 (closed) because it's not two different connections, it's the same one.
- Makes the broker more future-proof because it doesn't have to process data that the proxy and the client want to exchange, it simply passes it along.
- Can allow faster bootstrapping by relaying (non-signaling) proxy-to-client data initially, before true P2P has been established.
- (maybe, need to verify) better DPI resistance due to handshake being performed in a secure (domain-fronted) channel (see tpo/anti-censorship/censorship-analysis#40030 (closed)).
Cons:
- The broker codebase needs a major overhaul.
Some chat logs (nothing particularly important).