p2p-webtransport

Interface to create and manage QUIC streams (by w3c)

P2p-webtransport Alternatives

Similar projects and alternatives to p2p-webtransport

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better p2p-webtransport alternative or higher similarity.

p2p-webtransport reviews and mentions

Posts with mentions or reviews of p2p-webtransport. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-06-06.
  • Video Live Streaming: Notes on RTMP, HLS, and WebRTC
    7 projects | news.ycombinator.com | 6 Jun 2022
    > I just wish WebRTC wasn't so prescriptive of DTLS/SRTP.

    There was a webrtc-webtransport spec, but it got renamed to p2p-webtransport[1]. I'm not sure when the rename happened. Feels like a pretty strong indicator of webrtc being deconstructed, but whose to say this goes anywhere. We'd also need webcodecs.

    It's somewhat scary & also somewhat exciting thinking of the one good, working, browser supported standard being ripped into pieces (p2p-webtransport, webcodecs, more) & being user-implemented. Having the browser & servers have a well-known target is both great but also perhaps confining. If we leave it up to each site/library to DIY their solution, figure out how to balance the p2p feeds, it'll be a long long time before the Rest of the World (other than the very big few) have reasonable tech again. WebRTC is quite capable & a nice even playing field, with lots of well-known rules to enable creative interopation. We'd be throwing away a lot. I'd hoped for webrtc-webtransport, to at least keep some order & regularity, but that seems out, at the moment. But Webrtc-nv is still ultra-formative; anything could happen.

    The rest of the transport stack is also undergoing massive seismic shifts. I feel like we're in for a lot of years of running QUIC or HTTP3 over WebRTC Data-Channels and over WebTransport, so we can explore solutions the new capabilities while not having to ram each & every change through with the browser implementers. It feels like a less visible but far more massive Web Extensibility Manifesto moment, only at sub-HTML levels[2]. The browsers refused to let us play with HTTP Push, never let appdevs know realtime resources had been pushed at the browser, so we're still debating terrible WebSocket vs SSE choices; terrible. I think of gRPC-web & what an abomination that is, how sad & pointless that effort is; all because the browser is a mere glimmer of the underlying transport. I feel like a lot of experimentation & exploration is going to happen if we start exploring QUIC or HTTP3 over WebTransport. Attempts to reimagine alternatives to WebRTC are also possible if we had specs like p2p-webtransport, or just did QUIC over DataChannels. Running modern protocols in the client, not the browser, seems like a semi-cursed future, but necessary, at least for a while, while we don't yet know what we could do. The browsers are super laggy, slow to expose capabilities.

    [1] https://github.com/w3c/p2p-webtransport

    [2] https://github.com/extensibleweb/manifesto

Stats

Basic p2p-webtransport repo stats
1
154
7.0
6 months ago

w3c/p2p-webtransport is an open source project licensed under GNU General Public License v3.0 or later which is an OSI approved license.

The primary programming language of p2p-webtransport is HTML.


Sponsored
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com