← Back to context

Comment by jauntywundrkind

6 hours ago

I hope some day the browser's webtransport also gets p2p support.

It seemed like there was such a good exciting start, but the spec has been dormant for years. https://github.com/w3c/p2p-webtransport

5 comments

jauntywundrkind

Reply
devttyeu  4 hours ago

It is halfway there arguably, and libp2p does make use of it - https://docs.libp2p.io/concepts/transports/webtransport/

Unlike websockets you can supply "cert hash" which makes it possible for the browser to establish a TLS connection with a client that doesn't have a certificate signed by a traditional PKI provider or even have a domain name. This property is immensely useful because it makes it possible for browsers to establish connections to any known non-browser node on the internet, including from secure contexts (i.e. from an https page where e.g. you can't establish a ws:// connection, only wss:// is allowed but you need a 'real' tls cert for that)

embedding-shape  5 hours ago

Someone correct me if I'm wrong, but I think p2p-webtransport was superseded by "webtransport" (https://github.com/w3c/webtransport). Supposedly, the webtransport design should be flexible enough to support p2p even though focus is the traditional server<>client.

  • vasilvv  3 hours ago

    The story here is a bit complicated. WebTransport is, in some sense, an evolution of RTCQuicTransport API, which was originally meant to solve the issues people had with SCTP/DTLS stack used by RTCDataChannel. At some point, the focus switched to client-server use cases, with an agreement that we can come back to the P2P scenario after we solve the client-server one.

  • jauntywundrkind  4 hours ago

    Superceded? No. Webtransport already was well on its way to approval when p2p-webtransport was created.

    Webtransport as a protocol certainly could be used for p2p, but the browser APIs aren't there: hence p2p-webtransport was created, to allow its use beyond traditional server<->client.