This would also have the effect of allowing slack to peer more or less normally even if Slack was down (of course bots, search, etc wouldn’t work).
With WebRTC you give up the nice ultra-low-common-denominator "outbound port 443/TCP needs to work" requirement and replace it with "UDP networking generally healthy, possible to establish port mappings, possible to maintain stable port mappings over time, possible to not have mappings go away due to lack of traffic" etc etc
Ironically getting machines connected across the internet with WebRTC has so far been relatively smooth sailing.
Could you expand a bit on why MediaChannels need TURN specifically? Is there some complication that prevents just dumb relaying of the packets ala what you're suggesting?
It's definitely more complex than websockets, but removing STUN servers from the equation does simplify connection initiation a bit.
My own interest comes from many years of building multiplayer games professionally and wanting to make smaller scale multiplayer games for fun without needing to invest too much in infrastructure.
First of all, while WebRTC has its share of complexity when using it for videoconferencing, here we are talking about using the DataChannel, which is really straightforward to use and doesn't need additional infrastructure.
> not forgetting WebRTC still relies on centralized components to coordinate
It needs a centralized component to setup the connection (signaling), if it fails later, your communication channel is still up. And the good thing if you have a websocket-based chat service, is that you can directly use it for the signaling purpose with zero modifications on the back-end side.
> routers in many scenarios hate it and even where they allow it, the combinatorial explosion in possible configurations to support and diagnose between peers is a problem nobody should willingly invite unless they can't achieve a solution any other way
When using the Datachannel, your failure mode is can't establish a connection, not some hard to understand Heisenbug. All you need is to provide a centralized fallback for clients who cannot establish a connection. This fallback will depend on the centralized service being up, but in case of failure you'll keep most of your users without disturbance (at least in the first world, the network is not as WebRTC friendly in other places of the world). And because the DataChannel's API is close to the WebSocket's one, implementing the fallback is straightforward.
Though, in Slack's situation there is a good reason not to use WebRTC: they can have several thousands of people in the same channel (IIRC IBM uses Slack and have most of their employees in a shared channel for official announcements). You won't be able to do that with WebRTC[1] if a user needs to establish a connection with every other users in the channel (there's just not enough ports available). And even worse, back in 2016, Chrome's implementation of the DataChannel was so poor, you could not establish more than a handful of PeerConnection before feeling the browser's becoming sluggish (this wasn't the case in Firefox so maybe Google fixed that since then).
Also, Slack's users are likely to be in some enterprise network, which makes WebRTC more likely to fail than when you customers are home, which reduces the opportunity.
Main takeaway: WebRTC-based chat is probably not a great fit for Slack, but don't be afraid of using it: it's not hard, it combines well with your already existing centralized infrastructure, and can massively reduces the load on it.
[1] unless you want to build some fancy sparse mesh network, but this is likely overengineering.
If you do both STUN and TURN it works on most networks. I've worked at really restricted work sites, and while STUN fails at those if you have a TURN server then it almost always works.
These sort of comments are why people think webRTC is unstable while the same people use slack calls which literally use webRTC.
I might be wrong, but please don't talk about network reliability in webRTC without specifying if you have a working STUN and/or TURN setup.
> If you do both STUN and TURN it works on most networks
TURN requires clean outbound UDP/TCP connectivity which is far from ubiquitous, there are numerous corporate firewalls where "CONNECT <x>:443" is the best that could be hoped for, and even in some of those, where if the resulting connection did not include an obvious SSL handshake the connection would be immediately reset.