Consider webrtc<-->webrtc vs webrtc<-->websocket for the browser proxy
webrtc <-->websocket is the current situation, which works. webrtc <--> webrtc would take a bit more work.
\
Quoting @yawning,
What are your plans for actually getting the server side to scale well? Since you're using cgo you will run into Really Interesting behavior wrt OS threads as you try to increase concurrency.
https://lists.torproject.org/pipermail/tor-dev/2016-January/010311.html
\
Yes, that does complicate the potential of using a second WebRTC connection to the relay...
The benefit of WebRTC on both sides should be performance / latency, whereas right now the websocket connection to the relay is most likely bottlenecking the first WebRTC data channel from the client.
But maybe it's actually not, at least significantly. It's quite possible the typical latency of the network is already most of what the user experiences compared to the websocket relay, in which case the benefit of the 2nd WebRTC would be negligible with respect to the effort of making it happen.... maybe we need to measure this (I haven't found any obvious latency numbers on metrics.torproject.org), or we could just decide not to bother and close this.
\ Migrated from https://github.com/keroserene/snowflake/issues/8