transport/webtransport: Add WebTransport protocol

[mxinden]

Description

Add a WebTransport Transport implementation according to the WebTransport specification libp2p/specs#404.

Motivation

The most exciting feature for libp2p (other than the numerous performance benefits that QUIC gives us) is that the W3C added a browser API allowing browsers to establish connections to nodes with self-signed certificates, provided they know the hash of the certificate in advance:

See libp2p/specs#404

Are you planning to do it yourself in a pull request?

No

[mxinden]

Status Update

#4015 adds WASM WebTransport support when running in the browser.

[DougAnderson444]

@mxinden just to clarify, #4015 is only the browser side of webtransport in rust-libp2p, and the server side for webtransport in rust still needs to be completed? If this is correct, what server does #4015 connect to, I presume Kubo for the time being?

[thomaseizinger]

If this is correct, what server does #4015 connect to, I presume Kubo for the time being?

In the interop tests, we currently only test against a go-libp2p node.

It will however work with any implementation that follows the libp2p WebTransport spec. Nothing is hardcoded to only work with Kubo :)

[dgarus]

@mxinden
Hello, Max!
I'd like to help you with this issue, I hope you don't mind.

[mxinden]

Great. Thank you @dgarus. Note that you can build on top of #4348.

[dgarus]

@thomaseizinger
Could you please assign this issue to me?

The Assignees feature looks very convenient to understand,
there is anybody working on the issue or not :)
Why do you use it so rare?

[thomaseizinger]

@thomaseizinger Could you please assign this issue to me?

The Assignees feature looks very convenient to understand, there is anybody working on the issue or not :) Why do you use it so rare?

A lot of the work in this repo is still done by Max and myself and we communicate a lot on what we work on so we practically never had an overlap. Speaking of which, I can't recall when we last had duplicated work that could have been avoided by assigning people :)

Usually, we ask for draft-PRs very early on and immediately link them to the corresponding issue so there is visibility about in-progress work!

[dgarus]

@thomaseizinger Could you please assign this issue to me?
The Assignees feature looks very convenient to understand, there is anybody working on the issue or not :) Why do you use it so rare?

A lot of the work in this repo is still done by Max and myself and we communicate a lot on what we work on so we practically never had an overlap. Speaking of which, I can't recall when we last had duplicated work that could have been avoided by assigning people :)

Usually, we ask for draft-PRs very early on and immediately link them to the corresponding issue so there is visibility about in-progress work!

Ok, thanks!

[zvolin]

https://github.com/BiagioFesta/wtransport

Just came across this

[dgarus]

@thomaseizinger @mxinden

Hello guys!
Thoughts about the WebTransport integration. Is it a good idea to wrap libp2p::quic::GenTransport in libp2p::webtransport::Transpot?
In that case, libp2p::webtransport::Transpot will depend on libp2p::quic.
Pros: we won't need to repeat routine code to get a quic connection.
Cons: It can require to violate encapsulation in libp2p::quic structures.
What do you think?