Hacker News Reader

Comment by Matthias247 | Hacker News Reader

Even if quic would bring along an unreliable stream option: The browsers Api still only expose http semantics via xhr and fetch. So those would need to get extended too.

View on HN

I would imagine it as something like an option on websockets, so it wouldn't take much API work.

Actually doesn't webRTC already have unreliable channels?

Sure there are possibilities, but they all require additional standardization (which takes time and effort).

WebRTC has unreliable data channels, but they are based on sctp/dtls/udp. Making them work over quic streams might be possible, but also requires a new standardization effort.

If someone does it I would actually prefer an API outside of webrtc, since that one carries a lot of complexity for signaling and requires again a few extra protocols (ice, stun, turn, etc). An unreliable/unordered client to server protocol and api could potentially be much simpler.

There is a WebRTC over QUIC experiment, the standard document can be found here: https://w3c.github.io/webrtc-quic/ It is currently not a work item of the W3C WebRTC WG, but we hear about it every time we meet.

The current focus right now is to deliver WebRTC 1.0, when this is done, we may reconsider it.

That's cool to hear! Thanks for sharing the info and link.

At TPAC last week the WebRTC WG decided to adopt the spec, although it needs to be verified on the mailing list, as there were some members present not in favor of adopting it.

(I'm an editor of the document and am in favor of it).

https://w3c.github.io/webrtc-quic/ is "outside" of webrtc in the sense that it doesn't use PeerConnection and doesn't require signaling. But it currently doesn't require some form of ICE (not stun or turn, but ICE lite on a server). But we're considering adding support for an ICE-less version, and I've already started a pull request to add that.

Reply on news.ycombinator.com