What do they mean with WebSockets hole punch on port 443 and Let's Encrypt? The first thing that comes to mind is running a TLS web/WS server on the endpoints, but I didn't think you can do TCP+TLS servers with WebRTC. Or can you?
A new open source server side WebRTC implementation would be very welcome, though this does seem to use some of the old C++ libraries too. I wonder how much exposure of C++ to hostile bits they managed to reduce?
That entire section reads like nonsense to me (and I understand NAT hole punching), seems like some kind of confusion. Why do you need special TLS certs for WebSockets, but not WebRTC? WebRTC is end-to-end encrypted like TLS, using a Diffie-Hellman exchange so that the signaling server doesn't see private keys.
To summarize, you are correct WebRTC is end-to-end encrypted via DTLS and WebRTC handles setting all of this up. WebSockets, however, are not encrypted by default, and when attempting to connect to a WebSocket server from a secure origin, a valid TLS certificate is required. Because each user has their WebSocket server running from their Rainway instance, we need to create unique and valid certificates for each user to avoid having a shared private key. This is how we avoid needing a TURN server and maintain low latency.
I apologize that it wasn't clear in the blog I was describing how we handle WebRTC failing.
A new open source server side WebRTC implementation would be very welcome, though this does seem to use some of the old C++ libraries too. I wonder how much exposure of C++ to hostile bits they managed to reduce?