4 ms·

> The core issue is that WebRTC is not a protocol; it’s a monolith. > The WebRTC media stack is designed for conferencing and does an amazing job at it. The pr

> The core issue is that WebRTC is not a protocol; it’s a monolith. > The WebRTC media stack is designed for conferencing and does an amazing job at it. The problems start when you try to use it for anything else. The main problem with WebRTC is that it's designed to be overcomplicated and garbage on purpose. A way to leverage UDP for video streaming without any possibility for anyone to ever send an actual UDP packet... so that it's not possible to turn every mildly popular website into a god tier DDOS botnet. WebRTC is what we get when we can't have nice things.

englishm 3y ago
I very much disagree with the characterization of WebRTC being "designed to be overcomplicated and garbage on purpose" but I do think your point about needing to not open the door to DDoS botnet capabilities is something worth highlighting. There are a number of very challenging constraints placed on the design of browser APIs and this is one of them that is often grappled with when trying to expose more powerful networking capabilities. Another that's particularly challenging to deal with in the media space is the need to avoid adding too much additional fingerprinting surface area. For each, the appropriate balance can be very difficult to strike and often requires a fair bit of creativity that can look like "complication" without the context of the constraints being solved for.
jallmann 3y ago
When WebRTC was being developed, a lot of the underlying protocols were derived from existing standards (RTP, SDP, etc), ostensibly with the intent of making it easier to bridge to legacy video-conference systems that may have been running SIP or similar. Beyond that, there is a ton of stuff to accommodate different device capabilities, network conditions, realities of the Internet, etc. WebRTC has tried to be a "nice thing" for developers from an API perspective for the use-case of streaming realtime video to the browser, but of course all those knobs under the hood make it seem like a hodgepodge, rightly or not. Would a clean-slate design with more tightly scoped goals fare better? Probably. But the underlying complexity needs to be handled somewhere and there are always trade-offs between control and ease-of-use.
rizky05 3y ago
[dead]

englishm 3y ago

I very much disagree with the characterization of WebRTC being "designed to be overcomplicated and garbage on purpose" but I do think your point about needing to not open the door to DDoS botnet capabilities is something worth highlighting. There are a number of very challenging constraints placed on the design of browser APIs and this is one of them that is often grappled with when trying to expose more powerful networking capabilities. Another that's particularly challenging to deal with in the media space is the need to avoid adding too much additional fingerprinting surface area. For each, the appropriate balance can be very difficult to strike and often requires a fair bit of creativity that can look like "complication" without the context of the constraints being solved for.

jallmann 3y ago

When WebRTC was being developed, a lot of the underlying protocols were derived from existing standards (RTP, SDP, etc), ostensibly with the intent of making it easier to bridge to legacy video-conference systems that may have been running SIP or similar. Beyond that, there is a ton of stuff to accommodate different device capabilities, network conditions, realities of the Internet, etc. WebRTC has tried to be a "nice thing" for developers from an API perspective for the use-case of streaming realtime video to the browser, but of course all those knobs under the hood make it seem like a hodgepodge, rightly or not. Would a clean-slate design with more tightly scoped goals fare better? Probably. But the underlying complexity needs to be handled somewhere and there are always trade-offs between control and ease-of-use.

rizky05 3y ago

[dead]