[still_grokking]

I don't know about any significant use case of WebRTC in the P2P space. OTOH, like mentioned, libp2p implemented WebTransport. So WT seems to be also adequate for the P2P use case. (No clue about the details there, though. So maybe they had to jump loops to make it happen. But it doesn't look like there would be major show stoppers.)

[jackewiehose]

It looks like STUN/TURN can be integrated with QUIC so you don't need additional ports, but I wouldn't say "the complexity is gone" ;-)

https://w3c.github.io/p2p-webtransport/

> This specification extends the WebRTC [WEBRTC], ORTC [ORTC] and WebTransport [WEBTRANSPORT] APIs to enable peer-to-peer operation using QUIC [RFC9000]. This specification supports the exchange of arbitrary data with remote peers using NAT-traversal technologies such as ICE, STUN, and TURN. As specified in [RFC7983bis], QUIC can be multiplexed on the same port as RTP, RTCP, DTLS, STUN and TURN, allowing the API defined in this specification to be utilized along with the functionality defined in [WEBRTC] and [ORTC] including communication using audio/video media and SCTP data channels.

[still_grokking]

Oh, that's cool! :-D

It implements the missing parts on top of WebTransport. I was especially sad that WT doesn't do client authentication. You can't send credentials with a CONNECT request. But this thingy adds exactly this. Great!

Also having some standardized way to open QUIC Streams through NAT sounds nice. (Even I think the proper fix for this issues would just be IPv6.)

Frankly it's very early days. It's not implemented, and not even considered currently.

> It is not a W3C Standard nor is it on the W3C Standards Track.

But as I'm currently into implementing a WebTransport lib maybe I should try to add the features form this draft. Would be funny to have a P2P ready WT lib. Only that NAT traversal part I would leave out for now, I guess, as I'm not sold on the idea that this complexity is strictly needed. NAT just needs to die finally…