Seeing that a big chunk of the use case is p2p. That’s difficult to do well without a listening API, SO_REUSEPORT and/or UPnP (or other port mapping protocols). If p2p is an explicit use case someone should prototype how that could work and also make it better/simpler than WebRTC before putting a new proposal forward for the entire web.
Since this is meant for high trust anyway, perhaps just shipping the more familiar Node APIs for tcp/udp would be better? That would let people do cool things (including p2p) that actually works, and it’s pretty battletested. Or maybe I’m missing something? It was a while ago I used that.
Another thought: don’t we have too many streaming protocols already? Do we really need SSE, WebSocket, WebTransport and now raw sockets as well? It’s a lot, (but not this project's fault)
What do you find impenetrable about WebRTC? In most cases I have found the complexity necessary. When you find yourself in unique situations it’s a protocol that gives you the knobs.
The moment I open this page, which is ostensibly the first on the way to understanding WebRTC, it slaps me over the head with hundreds of terms I’ve never heard before. More importantly, I don’t understand why I should care about them.
I just want to do Server.serve(5648), and Client.connect(server, 5648) and then pass binary messages back and forth. This is the mental model I already have, and works fine when I’m anywhere other than a browser, and even for websockets (mostly, except no UDP) and whatever website explains WebRTC will first have to explain to me why such a simple thing cannot work.
To me the issue is that any real-world deployment of this is going to want some form of encryption, or you are just leaking the poor user's data to a ton of random people. In addition to encrypting the data, this means you are going to need to build in a key sharing mechanism. Like, this is table stakes: anything less is unacceptable, and is a complexity you don't escape even with a native app. I think you then rapidly discover that just satisfying that one need causes most of the complexity of WebRTC (and to the extent to which it isn't documented well enough to show that that doesn't mean the protocol or even API sucks and should be replaced: it just means we need better documentation for people who don't care enough to learn how it all works and how to bypass the issues).
The oblivious mental model was something like `WebRTC.send("12.34.56.78", "hello world!"); WebRTC.addEventListener("text", function(e){if(e.ip==="12.34.56.78"){ /* do something */ }})` not that I expected it to be that easy (it isn't php) but it turned out to be (ehm) slightly more complicated than that.
Exactly. Having worked with plain tcp/udp sockets, and then trying to understand WebRTC is like trying to run a marathon after winning the 100m sprint.
To be able to accept connections, you would need to have a white IP, configure router to map port, configure firewall to allow connections. Too many things could go wrong.
With BitTorrent plenty of clients can't accept connections but that does not render them unusable.
These things may be a desired use case but as the explainer lays out they were already rejected for being too easy to abuse. This proposal is an attempt to get some basic portion of the functionality that is easier to limit even if there is no way for everyone to agree the rest can be secured too.
Since this is meant for high trust anyway, perhaps just shipping the more familiar Node APIs for tcp/udp would be better? That would let people do cool things (including p2p) that actually works, and it’s pretty battletested. Or maybe I’m missing something? It was a while ago I used that.
Another thought: don’t we have too many streaming protocols already? Do we really need SSE, WebSocket, WebTransport and now raw sockets as well? It’s a lot, (but not this project's fault)