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?

[thomaseizinger]

Could we just add WebTransport functionality to libp2p-quic? I.e. when the user says Swarm::listen_on(..../webtransport), the libp2p-quic module can pick that up and make it happen.

It would be nice we could support listening on /quic and /webtransport on the same port.

[dgarus]

Could we just add WebTransport functionality to libp2p-quic? I.e. when the user says Swarm::listen_on(..../webtransport), the libp2p-quic module can pick that up and make it happen.

It would be nice we could support listening on /quic and /webtransport on the same port.

Good point! I like your proposal.
I'll do it.

[dgarus]

@thomaseizinger @mxinden
Hi!
Here is an attempt to add WebTransport to the quic transport.

I am faced with a few problems here.

1. h3-webtransport doesn't have a client part. Or do I mess something?
2. A lifetime problem with WebTransportSession in webtransport::Connection that isn't obvious to me.

But nevertheless, you can see here the general direction.
Give me, please, feedback.

[thomaseizinger]

h3-webtransport doesn't have a client part. Or do I mess something?

I don't think we need to support dialing WebTransport for now. Given that WebTransport is primarily intended to improve connectivity by browsers, the dialing bit will be implemented in the browser's native code.

If you are actually running rust-libp2p code as a client, you can just establish a QUIC connection. No need to use WebTransport.