Thanks for that site, bookmarked. However, I'd counter this. As someone whose company has been using WebRTC for years, WebRTC is just too complicated, trying t

Thanks for that site, bookmarked. However, I'd counter this. As someone whose company has been using WebRTC for years, WebRTC is just too complicated, trying to do everything, and as a result bad for its main use case: a comms interface that works. In practice it inevitably doesn't work for some subset of users/platforms, and fixing it is an exercise in yak shaving because there are so many combinations of networks, codecs and signals, and JS makes it easy to bug out with race conditions. Weird problems under load are common on exotic hardware like VR headsets. If you don't have UDP support, like many typical web deployments these days, then you are also signing yourself up for maintaining a separate server. The most technically appealing aspect of WebRTC is that it can be P2P, but even then, projects quickly realize that n^2 independent connections is not actually performant, which is why most run star topologies through a central server, neutering this most appealing aspect. Companies like Discord have implemented great products on WebRTC with custom hacks/subsets, but for the average developer it's a beast of complexity you probably didn't ask for or want. WebRTC frameworks (like mediasoup) help a lot but they are leaky abstractions in a production project. Doing WebRTC comms (IMO) means mostly throwing away WebRTC networking and leveraging the only parts that provide enormous value, which is the codecs! Thankfully that is being broken out into the WebCodecs standard: https://www.w3.org/TR/webcodecs/ https://www.w3.org/TR/webcodecs/ With WebCodecs, you can use your own sane transport like a websocket while still getting acceleration and efficiency.