This is just an initial proposal, and probably will reduce down to one with developer feedback and implementation experience, which is normal for API development.
Whether it's one shape or the other doesn't take affect the network protocol underneath.
If you have constructive ideas of how to simplify the protocol underneath or the API, you can share them with the authors. The people that work on that APIs are always looking for constructive feedback
WebRTC (with p2p) was done within the W3C, as was a p2p QuicTransport. And this new API is similar to the open screen APIs that have been done in the W3C.
So I'm pretty sure work like this can be done in the W3C.
I was one of the original authors of the p2p QuicTansport API and the WebTransport API which is based on it.
I've also recently discussed this new local p2p API with the authors. And I'm in the favor of it, at least in principle.
The difference is that local p2p does not require signaling like, say the p2p done by ICE, WebRTC, or p2p QuicTransport. So for some uses cases, this would be better. And, if done right, this would fit well into a cohesive set of APIs that cover both kinds of p2p.
I'm also in favor of making APIs low level, but I'm not sure if raw sockets is going to work. Keeping congestion control working is pretty important.
The article's information about WebRTC is not accurate. You can do client/server WebRTC without a "signaling server". Just make the server do the signaling. It takes a few extra round trips, but it doesn't need to be an extra server. And WebRTC data channels work quite well as a replacement for WebSockets or SSE, especially if you want to avoid head-of-line blocking. And there are many libraries that will do pretty much all of the work for you, like Pion or str0m.
I also think calling the WebTransport API complex is overblown. If you don't want the more advanced things, you can ignore them. If you want to use it like a WebSocket, just open one bidirectional stream and you're basically done. If you want to avoid head-of-line blocking, just open a stream for every message. It's a little more complex, but it's not the kind of thing you need a library for. Github Copilot will probably write the code for you. It's true there aren't as many server libraries out there yet, since WebTransport is still maturing. And we're waiting for Safari to add support.
From a server or a native client, you can send whatever RTP packets you want, but you cannot send whatever RTP packets you want from a web client, and you cannot have access to the RTP packets from a web client and do whatever you want with them, at least not very easily. We are working on an extension to WebRTC called RtpTransport that would allow for just that, but it's in early stages of design and standardization.
It's shame it looks like web clients won't be able to connect to each other p2p. If it supported the use of ICE+DTLS+SCTP or even ICE+QUIC, then it web clients could join in.
It started in the W3C and the IETF group was added later. But thank you for pointing out that a lot of effort is put into making these standards a joint effort across the industry.
(I was one of the original authors in the W3C but left shortly after the BoF happened).
There's nothing stopping QUIC from being p2p. In fact, the original version of WebTransport was called QuicTransport and was p2p, but there was more interest in client/server use cases, so we switched focus to that.
(I'm one of the original authors of the WebTransort spec and when I worked at Google years ago, some excellent engineers on my team shipped the original QuicTransport behind a field trial).
Live streaming was a motivating example for both of those, as you can tell from the video. And both of them grew out of our efforts to make WebRTC better for live streaming.
Hey, I'm the author of the Signal blog post about SFUs. I have a few questions/comments:
1. I don't think there are many good open source SFUs to choose from. I know of 2, maybe 3 (including our new one). There may be many, but few have good rate control. But maybe I just don't know about them? I'd be happy to learn of more good ones.
2. Echo cancellation is certainly a hard problem, but it doesn't conflict with E2EE unless you do it on the server, which isn't necessary. So perhaps it may be a somewhat harder problem because you close off one possible approach (doing it server-side), but many (most?) echo cancellation solutions are done client-side.
3. You may not be completely dependent on WebRTC's echo cancellation any more because of
the new MediaStreamTrackProcessor and MediaStreamTrackGenerator APIs. I don't know if it will work for echo cancellation, but it might.
If you're main focus is to mostly receive 1-2 video streams while sending 0, then, yeah, I guess bundle vs non-bundle doesn't matter much. I'm pleasantly surprised to hear that 25 PeerConnections work well for you.
About simulcast: why would a sender not support simulcast? Something to do with VP8 hardware encoders?
I'm still interested to hear what you have learned about AQM and the like.