feat: Add WebTransport protocol based on BiagioFesta/wtransport

[dgarus]

related to #2993

spec
https://github.com/libp2p/specs/tree/master/webtransport

[dgarus]

@jxs @thomaseizinger @dariusc93
Hi! Please review.

Thanks!

[elenaf9]

Hi @dgarus, thank you for your PR, it's much appreciated!

I'll try to give this a review as soon as possible, but it might take some days until I get to it.

[elenaf9]

Thank your for this great effort and sorry for the delay. I started reviewing it, but didn't look into the certification logic yet.

This PR differs in some aspects from the previous webtransport PR #5564. In particular it:

• now builds on the wtransport crate, instead of h3-webtransport
• doesn't extend libp2p_quic anymore but instead is a separate crate

Could you briefly elaborate what motivated these changes? In particular for latter, because now the webtransport::GenTransport duplicates a lot of quic::GenTransport.

[dgarus]

Thank your for this great effort and sorry for the delay. I started reviewing it, but didn't look into the certification logic yet.

This PR differs in some aspects from the previous webtransport PR #5564. In particular it:

• now builds on the wtransport crate, instead of h3-webtransport
• doesn't extend libp2p_quic anymore but instead is a separate crate

Could you briefly elaborate what motivated these changes? In particular for latter, because now the webtransport::GenTransport duplicates a lot of quic::GenTransport.

Hi!
We discussed these changes with @jxs on the Slack chat:

And as the result, it is here 🙂

With webtrasport and quic together in the single transport implementation, it's difficult (at least for me) to keep the whole picture in mind. So, the main motivation is to make things simpler and more transparent.
The second one is wtransport has a client part, which is used in a smoke test.

Additionally, if a user wants to use pure webtransport, but it is a part of quic transport, it can perform some unnecessary extra things related to a dialer feature.

[dgarus]

@elenaf9 thank you for review!
@thomaseizinger and I discussed certificates here, this link could be useful for you.

[elenaf9]

outbound stream != outbound connection

I think on an already established connection, both sides should be able to open a new stream, no?

[elenaf9]

With webtrasport and quic together in the single transport implementation, it's difficult (at least for me) to keep the whole picture in mind. So, the main motivation is to make things simpler and more transparent.
The second one is wtransport has a client part, which is used in a smoke test.

Additionally, if a user wants to use pure webtransport, but it is a part of quic transport, it can perform some unnecessary extra things related to a dialer feature.

I understand, and I agree that having both in one module with a lot of if/else branches is a bit confusing.
Still, right now a large majority of Stream, Connection, Listener, and Transport is just copy-past from libp2p-quic, which I don't think is ideal.

Do you think that it would be possible to extract the shared quic code into one transport that is then generic over the two different variants (plain quic and webtransport), like this:

trait QuicTransport {
    type Endpoint;
    type Connection;
    type Connecting;
    type SendStream;
    type RecvStream;
    ...

    fn new_server_endpoint(addr: Multiaddr, config: &Config) -> Result<Self::Endpoint, Error>;
    fn new_client_endpoint(addr: Multiaddr, config: &Config) -> Result<Self::Endpoint, Error>;
    fn open_stream(connection: &mut Self::Connection) -> BoxFuture<_, Result<(Self::SendStream, Self::RecvStream), Error>>;
    fn accept_stream(connection: &mut Self::Connection) -> BoxFuture<_, Result<(Self::SendStream, Self::RecvStream), Error>>;
    ...
}

struct Transport<QuicTransport = PlainQuic>;

impl QuicTransport for PlainQuic {
     ...
}

impl QuicTransport for WebTransport {
     ...
}

That way the webtransport and normal quic transport specific logic would be separated, but (hopefully) not much code duplicated.

[dgarus]

With webtrasport and quic together in the single transport implementation, it's difficult (at least for me) to keep the whole picture in mind. So, the main motivation is to make things simpler and more transparent.
The second one is wtransport has a client part, which is used in a smoke test.
Additionally, if a user wants to use pure webtransport, but it is a part of quic transport, it can perform some unnecessary extra things related to a dialer feature.

I understand, and I agree that having both in one module with a lot of if/else branches is a bit confusing. Still, right now a large majority of Stream, Connection, Listener, and Transport is just copy-past from libp2p-quic, which I don't think is ideal.

Do you think that it would be possible to extract the shared quic code into one transport that is then generic over the two different variants (plain quic and webtransport), like this:

trait QuicTransport {
    type Endpoint;
    type Connection;
    type Connecting;
    type SendStream;
    type RecvStream;
    ...

    fn new_server_endpoint(addr: Multiaddr, config: &Config) -> Result<Self::Endpoint, Error>;
    fn new_client_endpoint(addr: Multiaddr, config: &Config) -> Result<Self::Endpoint, Error>;
    fn open_stream(connection: &mut Self::Connection) -> BoxFuture<_, Result<(Self::SendStream, Self::RecvStream), Error>>;
    fn accept_stream(connection: &mut Self::Connection) -> BoxFuture<_, Result<(Self::SendStream, Self::RecvStream), Error>>;
    ...
}

struct Transport<QuicTransport = PlainQuic>;

impl QuicTransport for PlainQuic {
     ...
}

impl QuicTransport for WebTransport {
     ...
}

That way the webtransport and normal quic transport specific logic would be separated, but (hopefully) not much code duplicated.

If you are bothering about code duplication, I could return to #5564.
WDYT?

[elenaf9]

If you are bothering about code duplication, I could return to #5564.
WDYT?

And use h3-webtransport, or change that PR to use wtransport?

[dgarus]

If you are bothering about code duplication, I could return to #5564.
WDYT?

And use h3-webtransport, or change that PR to use wtransport?

Use h3-webtransport as implementation and client part of wtransport in a smoke test.

[elenaf9]

Use h3-webtransport as implementation and client part of wtransport in a smoke test.

Based on your experience, which one of the two do you think we should use? Is one clearly more mature or easier to integrate?
I think we should first decide which webtransport crate to use before discussing the implementation details in libp2p, and not make one decision depend on the other (unless the crate API dictates it).