Yeah, I have a project where WebTransport would be a huge improvement, but not being able to support Safari is a dealbreaker.

I don't know the timeline, but Apple has committed [1] to adding WebTransport support to WebKit.

[1]: https://github.com/WebKit/standards-positions/issues/18#issu...

Eric Kinnear (linked post; Apple) is the author of the HTTP/2 fallback for WebTransport, so it's safe to say that WebTransport will be available in WebKit at some point.

Great news! It looks like Google GRPC team is probably waiting for Safari Webtransport support to implement grpc over the web in WT. Even though Chrome has had it for 2 years they have kept saying they’ll wait until it becomes GA.

Google Chrome never implemented trailers, so no gRPC. Every browser is guilty.

> I spent almost two years building/optimizing a partial WebRTC stack @ Twitch using pion. Our use-case was quite custom and we ultimately scrapped it, but your millage may vary.

So many words about protocols. Protocols aren't hard or interesting. QA is hard. libwebrtc has an insurmountable lead on QA. None of these ad-hoc things, nor WebRTC implementations like Pion, will ever catch up, let alone be deployed in Mobile Safari.

I am not at Twitch anymore so can't speak to what the state of the things today are.

WebRTC was deployed and is in use. For twitch.tv you have Guest Star [0]

You can use that same back-end via IVS Stages[1]. I always call it 'White-label Twitch', but it is more nuanced then that! Some pretty big/interesting customers were using it.

[0] https://help.twitch.tv/s/article/guest-star?language=en_US

[1] https://docs.aws.amazon.com/ivs/latest/RealTimeUserGuide/wha...

I agree with the general thrust of this, but libwebrtc has a tendency to have Google convenient defaults which are distinctly non obvious, such as the quality vs framerate tradeoffs being tied to what Hangouts needs to implement as opposed to useful general purpose hooks. (I hope they have updated that API since I last looked). Once you know how to poke it to make it do what you want, which tends to require reading the C++ source, it's definitely got a massive head start, especially around areas like low level hardware integration. Even bolting on ML inference and so on is not hard. The huge point though is everyone knows everyone has to talk to libwebrtc at some point, so it is the de facto implementation of SDP etc.

Curiously I was working on a webrtc project for about 18 months which also hit the wall, however, since then I have learned of several high profile data only libwebrtc deployments, which really just use it in the way classic libjingle was intended to be used, P2P, NAT punching etc. I'd go so far as to say if you don't have a P2P aspect to what you're doing with libwebrtc you're missing the point.

The big picture though is there seems to be a general denial of the fact that web style CDNs and multidirectional media streaming graphs are two totally different beasts.

Yeah, if you're using WebRTC only for data channels, then 100% you should switch to WebTransport with all due haste. Once Safari adds support of course.

This is what I profoundly disagree about, and I am referring to native code, not in browsers.

The whole P2P, STUN/TURN/ICE integration has value far beyond just media streaming, especially for large amounts of real time data where the central node doesn't want to be handling the data itself.

There are definite oddities to it but having the P2P setup and negotiation working (and QAed, as pointed out) is huge.

I think they'll catch up because libwebrtc is huge and can't take advantage of most of the existing browser protocol stack. WebTransport is a pretty thin layer over HTTP3, which already gets used much more often than WebRTC's SCTP-over-DTLS ever will. Not to mention the fact that it takes like two orders of magnitude less code to implement WebTransport than the whole WebRTC stack.

It's being worked on now: https://github.com/WebKit/WebKit/pull/17320

And Firefox hasn't implemented WebCodecs yet. At this moment, the WebTransport+WebCodecs solution is a no-go unless you only intend to serve Chromium.

Fortunately, Mozilla is working on WebCodecs and Apple is working on WebTransport, so these problems will probably disappear in the future.