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

▲

devttyeu 17 hours ago | parent | next [-]

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)

▲

focusgroup0 13 hours ago | parent | prev | next [-]

My understanding is that wide adoption of WebTransport is currently blocked by WebKit:

https://caniuse.com/webtransport

However, there have been some recent pull requests indicating gradual progress:

https://github.com/WebKit/WebKit/pulls?q=is%3Apr+is%3Aclosed...

▲

embedding-shape 18 hours ago | parent | prev [-]

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 17 hours ago \| parent \| next [-]
		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 18 hours ago \| parent \| prev [-]
		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.