This tiny PR contains a proposed change for the warning related to the exceeded pending incoming connections limit. This warning can't be controlled and causes user confusion. It contains useful technical info but IMHO should be downgraded from `warn` to `debug`.
Pull-Request: #3671.
All we need from the multihash is for it to be a data structure that we pass around. We only ever use the identity "hasher" and the sha256 hasher. Those are easily implemented without depending the (fairly heavy) machinery in `multihash`.
Unfortunately, this patch by itself does not yet lighten our dependency tree because `multiaddr` activates those features unconditionally. I opened a companion PR for this: https://github.com/multiformats/rust-multiaddr/pull/77.
https://github.com/multiformats/rust-multiaddr/pull/77 is another breaking change and we are trying to delay those at the moment. However, it will (hopefully) land eventually which should then be much easier to implement.
Fixes#3276.
Pull-Request: #3514.
With an upgrade to the Rust toolchain, the version of the rustdoc JSON may change. We incorporate the rustc version into the cache key to automatically invalidate the cache in that case. Additionally, we also incorporate the version of the `cargo semver-checks` tool.
Related: https://github.com/obi1kenobi/cargo-semver-checks/issues/415.
Pull-Request: #3664.
`Certificate#fingerprint()` returns `Fingerprint`, but since it's not
public, I was not able to test it in my project. I.e. before this change it was
not possible to do:
```
cert.fingerprint() == Fingerprint::raw([1u8 ...])
```
Pull-Request: #3648.
The check for fanout peer inclusion in `test_join` does not check anything since `new_peers` is always empty.
12b785e94e/protocols/gossipsub/src/behaviour/tests.rs (L611)
I assume the intention was to fill the `new_peers` with the fanout peers. In this MR I do just that.
Pull-Request: #3628.
Currently, banning peers is a first-class feature of `Swarm`. With the new connection management capabilities of `NetworkBehaviour`, we can now implement allow and block lists as a separate module.
We introduce a new crate `libp2p-allow-block-list` and deprecate `Swarm::ban_peer_id` in favor of that.
Related #2824.
Pull-Request: #3590.
In earlier iterations of the design for generic connection management, we removed the `ConnectionId::new` constructor because it would have allowed users to create `ConnectionId`s that are already taken, thus breaking invariants that `NetworkBehaviour`s rely on. Later, we incorporated the creation of `ConnectionId` in `DialOpts` which mitigates this risk altogether.
Thus, it is reasonably safe to introduce a public, non-deprecated constructor for `ConnectionId` that can be used for tests.
Related https://github.com/libp2p/rust-libp2p/pull/3327#issuecomment-1469870307.
Pull-Request: #3652.
We currently expose `libp2p-quic` and `libp2p-webrtc` as submodules from the `libp2p` crate despite those only being "alpha" status. This causes problems because we need to pin those dependencies due to `cargo` automatically upgrading alphas (which are allowed to incur breaking changes as per semver spec). Additionally, exposing these modules practically hides the "alpha" state of those modules, rendering it kind of obsolete.
The "alpha" state is still true for those modules, thus to properly communicate this to users, we deprecate the modules and require users to spell out the dependency and the alpha version in their manifest.
Pull-Request: #3580.
This patch deprecates the existing connection limits within `Swarm` and uses the new `NetworkBehaviour` APIs to implement it as a plugin instead.
Related #2824.
Pull-Request: #3386.
Allows folks like @bajtos to use the crate, see https://github.com/filecoin-station/zinnia/pull/85.
I opted for not exposing the crate through the `libp2p` meta crate as it is a testing tool only. @thomas
let me know if you prefer me to do so.
Pull-Request: #3629.
Implementation of the libp2p perf protocol according to https://github.com/libp2p/specs/pull/478/.
//CC @MarcoPolo as the author of the specification.
**Don't (yet) expect this to produce reliable performance metrics.**
Pull-Request: #3508.
`cargo release` provides multiple steps:
- changes
- version
- replace
- hook
- commit
- publish
- owner
- tag
- push
- config
- help
We only make use of `publish` and `tag`. We explicitly don't want `cargo release` to do `version` or `commit`.
Update the release docs accordingly, namely replace the generic `cargo release` with a two step process `cargo release publish` and `cargo release tag`.
Pull-Request: #3596.
