This PR implements `Transport` for WebTransport for browsers by using web-sys.
Related: #3846.
Resolves: #3825.
Pull-Request: #4015.
Co-Authored-By: Yiannis Marangos <yiannis@eiger.co>
Co-Authored-By: Maciej Zwoliński <mac.zwolinski@gmail.com>
Co-Authored-By: Yiannis Marangos <psyberbits@gmail.com>
Using workspace inheritance breaks `cargo release` because it cannot resolve that the dev-dependencies should only use a `path` and not a version.
Pull-Request: #4097.
Co-Authored-By: Thomas Eizinger <thomas@eizinger.io>
The extension for WebTransport certhashes was added and can be configured via `Config::with_webtransport_certhashes`.
In case of initiator, these certhashes will be used to validate the ones reported by responder. In case of responder, these certhashes will be reported to initiator.
Resolves#3988.
Pull-Request: #3991.
Implement `Transport::dial_as_listener` for QUIC as specified by the [DCUtR spec](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md).
To facilitate hole punching in QUIC, one side needs to send random UDP packets to establish a mapping in the routing table of the NAT device. If successful, our listener will emit a new inbound connection. This connection needs to then be sent to the dialing task. We achieve this by storing a `HashMap` of hole punch attempts indexed by the remote's `SocketAddr`. A matching incoming connection is then sent via a oneshot channel to the dialing task which continues with upgrading the connection.
Related #2883.
Pull-Request: #3964.
This option is the only reason we pull in a dependency on the shared `zlib` library. Unfortunately, we cannot use a pure Rust backend here because that one does not support configuring the window bits of the deflate algorithm which is used in the deflate websocket extension.
Using websockets in libp2p is already crazy inefficient because you end up with double encryption when using `/wss` (which is enforced by browsers if your website is served via https). A good encryption algorithm like noise or TLS produces an output that looks completely random. Any attempt in compressing this is pretty much wasted CPU power.
Thus, I think removing this configuration option does not really hurt and allows us to remove the dependency on the `zlib` shared library.
Pull-Request: #3949.
Previously, the associated types on `NetworkBehaviour` and `ConnectionHandler` carried generic names like `InEvent` and `OutEvent`. These names are _correct_ in that `OutEvent`s are passed out and `InEvent`s are passed in but they don't help users understand how these types are used.
In theory, a `ConnectionHandler` could be used separately from `NetworkBehaviour`s but that is highly unlikely. Thus, we rename these associated types to indicate, where the message is going to be sent to:
- `NetworkBehaviour::OutEvent` is renamed to `ToSwarm`: It describes the message(s) a `NetworkBehaviour` can emit to the `Swarm`. The user is going to receive those in `SwarmEvent::Behaviour`.
- `ConnectionHandler::InEvent` is renamed to `FromBehaviour`: It describes the message(s) a `ConnectionHandler` can receive from its behaviour via `ConnectionHandler::on_swarm_event`. The `NetworkBehaviour` can send it via the `ToSwarm::NotifyHandler` command.
- `ConnectionHandler::OutEvent` is renamed to `ToBehaviour`: It describes the message(s) a `ConnectionHandler` can send back to the behaviour via the now also renamed `ConnectionHandlerEvent::NotifyBehaviour` (previously `ConnectionHandlerEvent::Custom`)
Resolves: #2854.
Pull-Request: #3848.
`Transport::listen_on` is an asynchronous operation. It returns immediately but the actual process of establishing a listening socket happens as part of `Transport::poll` which will return one or more `TransportEvent`s related to a particular `listen_on` call.
Currently, `listen_on` returns a `ListenerId` which allows the user of the `Transport` interface to correlate the events with a particular `listen_on` call. This "user" is the `Swarm` runtime. Currently, a user of libp2p establishes a new listening socket by talking to the `Swarm::listen_on` interface and it is not possible to do the same thing via the `NetworkBehaviour` trait.
Within the `NetworkBehaviour` trait, we emit _commands_ to the `Swarm` like `ToSwarm::Dial`. These commands don't have a "return value" like a synchronous function does and thus, if we were to add a `ToSwarm::ListenOn` command, it could not receive the `ListenerId` from the `Transport`.
To fix this and to be consistent with our [coding guidelines](https://github.com/libp2p/rust-libp2p/blob/master/docs/coding-guidelines.md#allow-correlating-asynchronous-responses-to-their-requests) we change the interface of `Transport::listen_on` to require the user to pass in a `ListenerId`. This will allow us to construct a command in a `NetworkBehaviour` that remembers this ID which enables precise tracking of which events containing a `ListenerId` correlate which a particular `listen_on` command.
This is especially important in the context of listening on wildcard addresses like `0.0.0.0` because we end up binding to multiple network interfaces and thus emit multiple events for a single `listen_on` call.
Pull-Request: #3567.
I noticed that we also still leak that dependency in several crates by providing a `From` impl so I've removed that one as well.
Resolves#3534.
Pull-Request: #3894.
This patch removes all deprecated legacy code from `libp2p-noise` and attempts to collapse all the abstraction layers into something a lot simpler.
Pull-Request: #3511.
With all crates have received a release since https://github.com/libp2p/rust-libp2p/issues/3024, building the baseline rustdoc no longer required `protoc` and we can thus remove it from our CI entirely.
Resolves#3539.
Pull-Request: #3858.
`Keypair` and `Publickey` are rendered opaque:
- `Keypair` is replaced by a private `KeyPairInner` enum that is encapsulated inside the `Keypair` `pub struct`
- `Publickey` is replaced by a private `PublickeyInner` enum that is encapsulated inside the `Publickey` `pub struct`
Resolves#3860.
Pull-Request: #3866.
