Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GossipSub 1.2] IDONTWANT control message #548

Merged
merged 11 commits into from
May 15, 2024

Conversation

Nashatyrev
Copy link
Contributor

@Nashatyrev Nashatyrev commented May 30, 2023

This PR introduces a new GossipSub version 1.2

Co-authored with @Menduist

New messages

The new IDONTWANT control message is added which notifies mesh peers to suspend sending back the full publish message based on its messageId

Simulation results

Various simulations demonstrated ~30% traffic reduction and ~3-5% message delivery latency reduction

Related work

Relates to #413

@Nashatyrev Nashatyrev marked this pull request as draft May 30, 2023 06:51
@vyzo
Copy link
Contributor

vyzo commented May 30, 2023

That seems very reasonable; I like IDONTWANT more for the name.

@AgeManning any thoughts?

@vyzo
Copy link
Contributor

vyzo commented May 30, 2023

Actually, this might make some sense to implement with IHAVE, assuming we keep track of peer IHAVEs and avoid sending those messages to the peer.

However, this will conflate with heartbeat generated IHAVEs.
So overall, i think it is better to implement with an IDONTWANT message.

We can also effect some positive scoring on this action (if it pertains to messages we have seen or see shortly after)

Another consideration: if we sending the message to the peer already, would that be useful?
It is kind of implicit.

PS:
@Nashatyrev do you want to join our episub group in telegram?


| Parameter | Description | Reasonable Default |
|-------------------------|------------------------------------------------------------------|--------------|
| `max_dontsend_messages` | The maximum number of `DONTSEND` messages per heartbeat per peer | ??? |
Copy link
Contributor

@Menduist Menduist May 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that necessary? We can just descore peer if they send duplicate DONTSENDs, or we don't eventually see the message id
GossipSub already has too many parameters

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or we don't eventually see the message id

Sounds like a good idea 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or we don't eventually see the message id

Considering DONTSEND is allowed to be sent before validation, a peer can be downscored if a message DONTSEND has been sent for appears to be invalid

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have numbers on how much we can gain by allowing to send DONTSENDs before validation? (ie, how long the validation is in practice)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can avoid the downscoring by keeping a bounded cache, that gets overfilled to /dev/null.

We probably dont need a parameter for this, each peer can configure appropriately according to the expected message rate.

If we do want to downscore excessive rates of IDONTWANT, then we should validate first or else we open the door for a spam attack.

Copy link
Contributor

@vyzo vyzo May 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that validation in some networks can be slow, so there is real benefit by sending early.

@vyzo
Copy link
Contributor

vyzo commented May 30, 2023

Thinking a bit more about this, I am not entirely convinved we need any of this.

We can simply start keep tracking messages we have received from a mesh peer recently; if they have send us a message, we should supress it. Otherwise we just send the message and the IDONTWANT is implicit/redundant.

@Menduist
Copy link
Contributor

@vyzo the DONTSEND becomes useful when the messages get big enough that it actually takes time to transmit them

ie, a 0.5mb message over a 25mbps line will take 160ms to be sent to 8 peers, so sending a small DONTSEND before sending the full message gives us 160 ms more to avoid duplicates
Also, when more sophisticated relaying technique are used (for instance, sending to one peer after the other), this becomes even more useful

@vyzo
Copy link
Contributor

vyzo commented May 30, 2023

Ok, fair enough.
We should still do the supress thing however, for interacting with older peers.

@Nashatyrev
Copy link
Contributor Author

Actually, this might make some sense to implement with IHAVE, assuming we keep track of peer IHAVEs and avoid sending those messages to the peer.

However, this will conflate with heartbeat generated IHAVEs. So overall, i think it is better to implement with an IDONTWANT message.

Yes, we discussed that option, and came to agreement that those messages have slightly different semantics which might make the difference under some conditions. For example a peer may send IDONTWANT prior to message validation which would be different from IHAVE as the message may appear to be invalid finally.

I like IDONTWANT more for the name.

Yes I'm voting for IDONTWANT too 👍

Another consideration: if we sending the message to the peer already, would that be useful?

Yes, the basic strategy would be to broadcast corresponding IDONTWANT prior to broadcasting the message

}

message ControlDontSend {
required bytes messageID = 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for discussion, what would be the pros/cons of also including the topic?
I think it's the first time that we reference messages only by their id on the wire, so needs some consideration

I guess the only con of include the topic is more bandwidth usage

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe an optional field?
Agreed about bandwidth usage, we should aim to keep this lean.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IHAVE also has an optional topic field. But it looks like it is utilized by one implementation only (not sure which one exactly). I couldn't find any reasonable usage of topic for IDONTWANT tbh.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If no one is opposed or has any ideas on usage scenarios I would keep it without optional topic field to be more explicit

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If no one is opposed or has any ideas on usage scenarios I would keep it without optional topic field to be more explicit

The usage can be #548 (comment)

@vyzo
Copy link
Contributor

vyzo commented May 30, 2023

@Menduist @mkalinin note the existence of the episub working group in telegram; our little Lair is open, reach out to me in Telegram if you want to join.

pubsub/gossipsub/gossipsub-v1.2.md Outdated Show resolved Hide resolved
pubsub/gossipsub/gossipsub-v1.2.md Outdated Show resolved Hide resolved
@Nashatyrev Nashatyrev changed the title [GossipSub 1.2] DONTSEND control message [GossipSub 1.2] IDONTWANT control message May 31, 2023
@arnetheduck
Copy link
Contributor

Ok, fair enough.

for context, here are two scenarios we're addressing with this upgrade, for large messages in particular:

@ppopth
Copy link
Contributor

ppopth commented Jun 26, 2023

@vyzo Can I also join the episub group? FYI, I am the network person of the EF research and have been working with @Nashatyrev, @Menduist, and others.

@vyzo
Copy link
Contributor

vyzo commented Jun 26, 2023

Of course! Reach out on telegram to add you.

@vyzo vyzo mentioned this pull request Jul 14, 2023
@vyzo
Copy link
Contributor

vyzo commented Jul 14, 2023

Let's target this to #560

@Nashatyrev Nashatyrev changed the base branch from master to gossipsub/v1.2 July 17, 2023 08:22
Copy link
Contributor

@vyzo vyzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a small comment, otherwise lgtm.


When the peer receives the first message instance it immediately broadcasts
(not queue for later piggybacking) `IDONTWANT` with the `messageId` to all its mesh peers.
This could be performed prior to the message validation to further increase the effectiveness of the approach.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concerns about spam attacks triggering amplified IDONTWANT spam?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't look like a feasible attack vector to me:

  • IDONTWANT is primarily intended for larger messages, so the cumulative size of resulting IDONTWANT messages is expected to be significantly smaller than the original message
  • If an attacker is sending invalid messages to initiate IDONTWANT spamming it would be pretty quickly banned due to negative scoring
  • And we have max_idontwant_messages limit as the last resort

…VE and IWANT messages

Co-authored-by: Pop Chunhapanya <haxx.pop@gmail.com>

| Parameter | Description | Reasonable Default |
|--------------------------|------------------------------------------------------------------|--------------|
| `max_idontwant_messages` | The maximum number of `IDONTWANT` messages per heartbeat per peer | ??? |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this probably needs to be per-topic per heartbeat, rather than a total per heartbeat.

It seems it could be tied in with the scoring for mesh message delivery rate. I.e the more messages we are expecting per topic, the more IDONTWANT messages we would expect to receive.

One thought would be to add a behaviour penalty, similar to broken promises, if the number of IDONTWANT messages received from a peer exceeds the mesh message delivery rate.

We intend to implement this fairly soon. Perhaps we can leave the scoring penalty here for a future PR if we dont want to specify it now.

Copy link
Contributor Author

@Nashatyrev Nashatyrev Mar 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tracking IDONTWANT by topics would be perfect, however you don't know a message topic by its ID unless you already received this message.
IDONTWANT message is almost semantically equivalent to IHAVE message, so probably should have a similar anti-spam protection mechanism?
Probably it could make sense to set the 'reasonable default' to maxIHaveLength * maxIHaveMessages ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

however you don't know a message topic by its ID unless you already received this message.

Is it a good reason to include topics to IDONTWANT and not care what IHAVE and IWANT are doing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it a good reason to include topics to IDONTWANT and not care what IHAVE and IWANT are doing?

Including a topic would increase IDONTWANT traffic 2-3 times (messageID is 20 bytes, topic could be up to around 40 bytes). Not sure if it's worth just to enable more advanced spam protection...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also consider that IHAVE is sent on heartbeat with a batch of messages which may be grouped by topics and the topic overhead here could not be that significant.
IDONTWANT on the other hand is intended to be flushed immediately and would most likely contain just a single messageID so the topic overhead would be more significant

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect it might be valuable to specify it - ie effectively, after mcache expires, the message should no longer exist and implementations should be able to rely on them being "resent" if they resurface after that time - this more faithfully keeps the protocol consistent in this aspect

Copy link
Contributor Author

@Nashatyrev Nashatyrev May 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why using a weak hash function for unwanted is a problem.

@ppopth I was meaning this HashDoS attack.
The messageIDs in IDONTWANT are not validated: neither upon receive nor later (as for IHAVE). Thus an adversary may generate and send significant amount of messageIDs which yields the same hashCode in the context of unwanted hash set. That would result in a DoS on the receiver's side.
Actually this attack vector could be addressed on the implementation side pretty easily. I just wanted to add a 'warning note' for implementers into the spec

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Nashatyrev Got it. Thank you so much.

Copy link
Contributor Author

@Nashatyrev Nashatyrev May 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure it's been mentioned, but because the message id:s are not validated

@arnetheduck Good point!
I believe as far as the messageId function is application specific, the validation of a messageId is left for an application responsibility. I believe Ethereum clients should all have such validation

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe Ethereum clients should all have such validation

I'm not convinced this is the case, ie at least in nimbus, we don't validate message id:s (only messages). There's a custom message id generation feature, but this again does not validate message id:s themselves.

This PR represents the first time we receive message id:s that we're expected to store / keep track of - all others are either generated from actual messages or ephemeral.

Co-authored-by: João Oliveira <hello@jxs.pt>
@AgeManning
Copy link
Contributor

Hey all.

We are very interested in testing this. What are our thoughts on merging this. We can do a future PR to handle scoring, or leave it up to implementors to handle their own dos prevention strategies.

We want to start testing on live networks using the 1.2 protocol id. My concern is that if we do this, without this PR being merged and someone decides to change the protobuf, we will have then polluted the protocol-id space with an incompatible version.

We will go with a -beta in the meantime, however it would be good to merge down to get some consensus.

@arnetheduck
Copy link
Contributor

arnetheduck commented May 1, 2024

fwiw, nimbus/nim-libp2p has implemented this as an extension to 1.1: https://github.com/vacp2p/nim-libp2p/blob/2b5319622c997ce1c80bc62c863e30f3349ee0d7/libp2p/protocols/pubsub/gossipsub/behavior.nim#L266 - it would indeed be nice to get this merged and properly give it a version number

Copy link
Contributor

@vyzo vyzo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Soooo, lets merge it?
Any objections?

@vyzo vyzo changed the base branch from gossipsub/v1.2 to master May 15, 2024 11:46
Copy link
Contributor

@arnetheduck arnetheduck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, unless someone wants to edit in the various security recommendations

@vyzo vyzo merged commit e8b3234 into libp2p:master May 15, 2024
vyzo pushed a commit to libp2p/go-libp2p-pubsub that referenced this pull request Aug 16, 2024
## GossipSub v1.2 implementation

Specification: libp2p/specs#548

### Work Summary
Sending IDONTWANT

Implement a smart queue
Add priorities to the smart queue

    Put IDONTWANT packets into the smart priority queue as soon as the node gets the packets

Handling IDONTWANT

Use a map to remember the message ids whose IDONTWANT packets have been received
Implement max_idontwant_messages (ignore the IDONWANT packets if the max is reached)
Clear the message IDs from the cache after 3 heartbeats

    Hash the message IDs before putting them into the cache.

More requested features

    Add a feature test to not send IDONTWANT if the other side doesnt support it

### Commit Summary

* Replace sending channel with the smart rpcQueue

Since we want to implement a priority queue later, we need to replace
the normal sending channels with the new smart structures first.

* Implement UrgentPush in the smart rpcQueue

UrgentPush allows you to push an rpc packet to the front of the queue so
that it will be popped out fast.

* Add IDONTWANT to rpc.proto and trace.proto

* Send IDONTWANT right before validation step

Most importantly, this commit adds a new method called PreValidation to
the interface PubSubRouter, which will be called right before validating
the gossipsub message.

In GossipSubRouter, PreValidation will send the IDONTWANT controll
messages to all the mesh peers of the topics of the received messages.

* Test GossipSub IDONWANT sending

* Send IDONWANT only for large messages

* Handle IDONTWANT control messages

When receiving IDONTWANTs, the host should remember the message ids
contained in IDONTWANTs using a hash map.

When receiving messages with those ids, it shouldn't forward them to the
peers who already sent the IDONTWANTs.

When the maximum number of IDONTWANTs is reached for any particular
peer, the host should ignore any excessive IDONTWANTs from that peer.

* Clear expired message IDs from the IDONTWANT cache

If the messages IDs received from IDONTWANTs are older than 3
heartbeats, they should be removed from the IDONTWANT cache.

* Keep the hashes of IDONTWANT message ids instead

Rather than keeping the raw message ids, keep their hashes instead to
save memory and protect again memory DoS attacks.

* Increase GossipSubMaxIHaveMessages to 1000

* fixup! Clear expired message IDs from the IDONTWANT cache

* Not send IDONTWANT if the receiver doesn't support

* fixup! Replace sending channel with the smart rpcQueue

* Not use pointers in rpcQueue

* Simply rcpQueue by using only one mutex

* Check ctx error in rpc sending worker

Co-authored-by: Steven Allen <steven@stebalien.com>

* fixup! Simply rcpQueue by using only one mutex

* fixup! Keep the hashes of IDONTWANT message ids instead

* Use AfterFunc instead implementing our own

* Fix misc lint errors

* fixup! Fix misc lint errors

* Revert "Increase GossipSubMaxIHaveMessages to 1000"

This reverts commit 6fabcdd.

* Increase GossipSubMaxIDontWantMessages to 1000

* fixup! Handle IDONTWANT control messages

* Skip TestGossipsubConnTagMessageDeliveries

* Skip FuzzAppendOrMergeRPC

* Revert "Skip FuzzAppendOrMergeRPC"

This reverts commit f141e13.

* fixup! Send IDONWANT only for large messages

* fixup! fixup! Keep the hashes of IDONTWANT message ids instead

* fixup! Implement UrgentPush in the smart rpcQueue

* fixup! Use AfterFunc instead implementing our own

---------

Co-authored-by: Steven Allen <steven@stebalien.com>
@vyzo
Copy link
Contributor

vyzo commented Aug 16, 2024

The go implementation in libp2p/go-libp2p-pubsub#553 has merged.

mergify bot pushed a commit to libp2p/rust-libp2p that referenced this pull request Dec 27, 2024
This PR implements gossipsub 1.2 beta bringing changes over from lighthouse
ref PR: sigp/lighthouse#5422

Please include any relevant issues in here, for example:
libp2p/specs#548

Pull-Request: #5697.
jxs pushed a commit to jxs/rust-libp2p that referenced this pull request Jan 6, 2025
This PR implements gossipsub 1.2 beta bringing changes over from lighthouse
ref PR: sigp/lighthouse#5422

Please include any relevant issues in here, for example:
libp2p/specs#548

Pull-Request: libp2p#5697.
mangolas added a commit to mangolas/rust-libp2p that referenced this pull request Jan 28, 2025
* Use newer version for rcgen enable RISC-V builds.

* Fix deprecation warnings for errors due to move to newer rcgen

* Fix rcgen version in webrtc

* chore: parameterise s3 build cache setup (libp2p#5586)

As we're setting up a new cache bucket, we'd like to be able to control
its' configuration via GitHub vars/secrets fully.

FYI, the secrets are not set up yet.

---------

Co-authored-by: João Oliveira <hello@jxs.pt>
Co-authored-by: Guillaume Michel <guillaumemichel@users.noreply.github.com>

* fix(autonat): reject inbound dial request from peer if its not connected (libp2p#5597)

## Description
As discovered and described in the issue below, there are situations
where an incoming AutoNAT dial can come from a non-connected peer.
However `resolve_inbound_request` expects that this situation cannot
occur. This PR adds a check upfront and refuses the incoming dial when
no connected peer is found.

Fixes libp2p#5570.
## Change checklist

- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] A changelog entry has been made in the appropriate crates

Co-authored-by: João Oliveira <hello@jxs.pt>

* chore(ci): only run interop tests on commits to master (libp2p#5604)

## Description

This is done as temporary measure to unblock PR merging as the CI is
currently broken

Co-authored-by: Guillaume Michel <guillaumemichel@users.noreply.github.com>

* fix(ci): address cargo-deny advisories (libp2p#5596)

## Description
by updating:
- `bytes` to 1.7.1, `1.6.0` was
[yanked](https://crates.io/crates/bytes/1.6.0)
- `quinn-proto` to 0.11.8 to address
[RUSTSEC-2024-0373](https://rustsec.org/advisories/RUSTSEC-2024-0373.html)
- thirtyfour-macros to 0.1.11 to remove `proc-macro-error` dependency
and address
[RUSTSEC-2024-0370](https://rustsec.org/advisories/RUSTSEC-2024-0370.html)

* chore(ci): address beta clippy lints (libp2p#5606)

Co-authored-by: Darius Clark <dariusc93@users.noreply.github.com>

* fix(swarm): don't report `NewExternalAddrCandidate` if already confirmed (libp2p#5582)

## Description

Currently, `NewExternalAddrCandidate` events are emitted for every
connections. However, we continue to get this event even when `autonat`
has already confirmed that this address is external. So we should not
continue to advertise the "candidate" event.

## Notes & open questions

We have made the changes in the `swarm` instead of `identify` because it
does not make it necessary to duplicate the `ConfirmedExternalAddr`
vector in the `identify` Behaviour. Moreover, if any future Behaviour
emit `NewExternalAddrCandidate`, the same rule will also be applied.

I had to edit the `autonat_v2` tests which were always expecting a
`NewExternalAddrCandidate` but the address was already confirmed.

## Change checklist

<!-- Please add a Changelog entry in the appropriate crates and bump the
crate versions if needed. See
<https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#development-between-releases>-->

- [x] I have performed a self-review of my own code
- [ ] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] A changelog entry has been made in the appropriate crates

---------

Co-authored-by: Darius Clark <dariusc93@users.noreply.github.com>
Co-authored-by: Guillaume Michel <guillaumemichel@users.noreply.github.com>

* chore(autonat-v2): fix dial_back_to_non_libp2p test (libp2p#5621)

## Description
By avoiding dialing an external address

Co-authored-by: Guillaume Michel <guillaumemichel@users.noreply.github.com>

* chore: update interop test run condition (libp2p#5611)

## Description

Follow up to libp2p#5604. Interop
tests only work on the main `rust-libp2p` repo, and not on forks,
because of the S3 cache (introduced in
libp2p#5586).

The interop tests currently don't run in the PRs, but they run after the
PRs are merged to `master`. This PR is trying to run interop tests in PR
that are branches of the main repo (not forks).

* deps: update metrics example dependencies (libp2p#5617)

## Description

and address cargo-deny
[RUSTSEC-2024-0376](https://rustsec.org/advisories/RUSTSEC-2024-0376.html)

* refactor(examples): use tokio instead of async-std in relay-server (libp2p#5600)

## Description

<!--
Please write a summary of your changes and why you made them.
This section will appear as the commit message after merging.
Please craft it accordingly.
For a quick primer on good commit messages, check out this blog post:
https://cbea.ms/git-commit/

Please include any relevant issues in here, for example:

Related https://github.com/libp2p/rust-libp2p/issues/ABCD.
Fixes https://github.com/libp2p/rust-libp2p/issues/XYZ.
-->
Following on issue libp2p#4449 
refactor: use tokio instead of async-std in the relay-servert example
and remove unnecessary dependencies
## Notes & open questions

<!--
Any notes, remarks or open questions you have to make about the PR which
don't need to go into the final commit message.
-->
Fails on testing with the [whole punch
tutorial](https://docs.rs/libp2p/0.54.1/libp2p/tutorials/hole_punching/index.html)
possibly because of my networking topology. connection established event
registered.

I will publish the logs and testing information as a comment 

## Change checklist
* Removed unnecessary dependencies on examples/relay-server/Cargo.toml
* Updated tokio version  to "1.37.0"
<!-- Please add a Changelog entry in the appropriate crates and bump the
crate versions if needed. See
<https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#development-between-releases>-->

- [ ] I have performed a self-review of my own code
- [ ] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [ ] A changelog entry has been made in the appropriate crates

---------

Co-authored-by: David E. Perez Negron R. <david@nethunters.xyz>
Co-authored-by: Guillaume Michel <guillaumemichel@users.noreply.github.com>
Co-authored-by: João Oliveira <hello@jxs.pt>

* fix(server): removing dependency on libp2p-lookup (libp2p#5610)

## Description

Remove dependency on
[`libp2p-lookup`](https://github.com/mxinden/libp2p-lookup) which is no
longer maintained, and [makes checks
fail](https://github.com/libp2p/rust-libp2p/actions/runs/11016492372/job/30628121728).

## Change checklist

<!-- Please add a Changelog entry in the appropriate crates and bump the
crate versions if needed. See
<https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#development-between-releases>-->

- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] A changelog entry has been made in the appropriate crates

---------

Co-authored-by: João Oliveira <hello@jxs.pt>

* chore: update igd-next to 0.15.1 (libp2p#5625)

## Description

<!--
Please write a summary of your changes and why you made them.
This section will appear as the commit message after merging.
Please craft it accordingly.
For a quick primer on good commit messages, check out this blog post:
https://cbea.ms/git-commit/

Please include any relevant issues in here, for example:

Related https://github.com/libp2p/rust-libp2p/issues/ABCD.
Fixes https://github.com/libp2p/rust-libp2p/issues/XYZ.
-->

Resolves libp2p#5506.

## Notes & open questions

<!--
Any notes, remarks or open questions you have to make about the PR which
don't need to go into the final commit message.
-->

## Change checklist

<!-- Please add a Changelog entry in the appropriate crates and bump the
crate versions if needed. See
<https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#development-between-releases>-->

- [ ] I have performed a self-review of my own code
- [ ] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] A changelog entry has been made in the appropriate crates

* deps: bump Swatinem/rust-cache from 2.7.3 to 2.7.5 (libp2p#5633)

Bumps [Swatinem/rust-cache](https://github.com/swatinem/rust-cache) from
2.7.3 to 2.7.5.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/swatinem/rust-cache/releases">Swatinem/rust-cache's
releases</a>.</em></p>
<blockquote>
<h2>v2.7.5</h2>
<h2>What's Changed</h2>
<ul>
<li>Upgrade checkout action from version 3 to 4 by <a
href="https://github.com/carsten-wenderdel"><code>@​carsten-wenderdel</code></a>
in <a
href="https://github.com/Swatinem/rust-cache/pull/190">Swatinem/rust-cache#190</a></li>
<li>fix: usage of <code>deprecated</code> version of <code>node</code>
by <a href="https://github.com/hamirmahal"><code>@​hamirmahal</code></a>
in <a
href="https://github.com/Swatinem/rust-cache/pull/197">Swatinem/rust-cache#197</a></li>
<li>Only run macOsWorkaround() on macOS by <a
href="https://github.com/heksesang"><code>@​heksesang</code></a> in <a
href="https://github.com/Swatinem/rust-cache/pull/206">Swatinem/rust-cache#206</a></li>
<li>Support Cargo.lock format cargo-lock v4 by <a
href="https://github.com/NobodyXu"><code>@​NobodyXu</code></a> in <a
href="https://github.com/Swatinem/rust-cache/pull/211">Swatinem/rust-cache#211</a></li>
</ul>
<h2>New Contributors</h2>
<ul>
<li><a
href="https://github.com/carsten-wenderdel"><code>@​carsten-wenderdel</code></a>
made their first contribution in <a
href="https://github.com/Swatinem/rust-cache/pull/190">Swatinem/rust-cache#190</a></li>
<li><a
href="https://github.com/hamirmahal"><code>@​hamirmahal</code></a> made
their first contribution in <a
href="https://github.com/Swatinem/rust-cache/pull/197">Swatinem/rust-cache#197</a></li>
<li><a href="https://github.com/heksesang"><code>@​heksesang</code></a>
made their first contribution in <a
href="https://github.com/Swatinem/rust-cache/pull/206">Swatinem/rust-cache#206</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/Swatinem/rust-cache/compare/v2.7.3...v2.7.5">https://github.com/Swatinem/rust-cache/compare/v2.7.3...v2.7.5</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/Swatinem/rust-cache/commit/82a92a6e8fbeee089604da2575dc567ae9ddeaab"><code>82a92a6</code></a>
2.7.5</li>
<li><a
href="https://github.com/Swatinem/rust-cache/commit/598fe25fa107b2fd526fc6471f6e48de7cd12083"><code>598fe25</code></a>
update dependencies, rebuild</li>
<li><a
href="https://github.com/Swatinem/rust-cache/commit/8f842c2d455cfe3d0d5a4b28f53f5389b51b71bf"><code>8f842c2</code></a>
Support Cargo.lock format cargo-lock v4 (<a
href="https://github.com/swatinem/rust-cache/issues/211">#211</a>)</li>
<li><a
href="https://github.com/Swatinem/rust-cache/commit/96a8d65dbafbc7d145a9b2b6c3b12ee335738cd2"><code>96a8d65</code></a>
Only run macOsWorkaround() on macOS (<a
href="https://github.com/swatinem/rust-cache/issues/206">#206</a>)</li>
<li><a
href="https://github.com/Swatinem/rust-cache/commit/9bdad043e88c75890e36ad3bbc8d27f0090dd609"><code>9bdad04</code></a>
fix: usage of <code>deprecated</code> version of <code>node</code> (<a
href="https://github.com/swatinem/rust-cache/issues/197">#197</a>)</li>
<li><a
href="https://github.com/Swatinem/rust-cache/commit/f7a52f691454d93c6ce0dff6666a5cb399b8d06e"><code>f7a52f6</code></a>
&quot;add jsonpath test&quot;</li>
<li><a
href="https://github.com/Swatinem/rust-cache/commit/2bceda39122b2cc71e6e26ad729b92b44d101f4b"><code>2bceda3</code></a>
&quot;update dependencies&quot;</li>
<li><a
href="https://github.com/Swatinem/rust-cache/commit/640a22190e7a783d4c409684cea558f081f92012"><code>640a221</code></a>
Upgrade checkout action from version 3 to 4 (<a
href="https://github.com/swatinem/rust-cache/issues/190">#190</a>)</li>
<li><a
href="https://github.com/Swatinem/rust-cache/commit/158274163087d4d4d49dfcc6a39806493e413240"><code>1582741</code></a>
update dependencies</li>
<li>See full diff in <a
href="https://github.com/swatinem/rust-cache/compare/23bce251a8cd2ffc3c1075eaa2367cf899916d84...82a92a6e8fbeee089604da2575dc567ae9ddeaab">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=Swatinem/rust-cache&package-manager=github_actions&previous-version=2.7.3&new-version=2.7.5)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

You can trigger a rebase of this PR by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)


</details>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* feat: make runtime features optional in swarm-test (libp2p#5551)

## Description

<!--
Please write a summary of your changes and why you made them.
This section will appear as the commit message after merging.
Please craft it accordingly.
For a quick primer on good commit messages, check out this blog post:
https://cbea.ms/git-commit/

Please include any relevant issues in here, for example:

Related https://github.com/libp2p/rust-libp2p/issues/ABCD.
Fixes https://github.com/libp2p/rust-libp2p/issues/XYZ.
-->

Sometimes a test uses custom swarm building logic and doesn't need `fn
new_ephemeral`, and sometimes a test uses `tokio` runtime other than
`async-std`.
This PR adds the `tokio` runtime support and makes both `async-std` and
`tokio` runtimes optional behind features to make it more flexible.

## Notes & open questions

<!--
Any notes, remarks or open questions you have to make about the PR which
don't need to go into the final commit message.
-->

## Change checklist

<!-- Please add a Changelog entry in the appropriate crates and bump the
crate versions if needed. See
<https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#development-between-releases>-->

- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] A changelog entry has been made in the appropriate crates

---------

Co-authored-by: João Oliveira <hello@jxs.pt>

* chore: fix typo in comment (libp2p#5643)

## Description

<!--
Please write a summary of your changes and why you made them.
This section will appear as the commit message after merging.
Please craft it accordingly.
For a quick primer on good commit messages, check out this blog post:
https://cbea.ms/git-commit/

Please include any relevant issues in here, for example:

Related https://github.com/libp2p/rust-libp2p/issues/ABCD.
Fixes https://github.com/libp2p/rust-libp2p/issues/XYZ.
-->

## Notes & open questions

<!--
Any notes, remarks or open questions you have to make about the PR which
don't need to go into the final commit message.
-->

## Change checklist

<!-- Please add a Changelog entry in the appropriate crates and bump the
crate versions if needed. See
<https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#development-between-releases>-->

- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [ ] A changelog entry has been made in the appropriate crates

* deps(ci): update cargo-semver-checks (libp2p#5647)

* fix(swarm-test): set proper version (libp2p#5648)

## Description
To unblock  CI

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* feat(kad): add `Behavior::find_closest_local_peers()` (libp2p#5645)

## Description

Fixes libp2p#5626

## Notes & open questions

This is the nicest way I came up with, I decided to leave
`get_closest_local_peers` as is since it does return all peers, not just
`replication_factor` peers.

Looking at libp2p#2436 it is not
clear if @folex really needed all peers returned or it just happened
that way. I'm also happy to change proposed API to return all peers if
that is preferred by others.

It is very unfortunate that `&mut self` is needed for this, I created
libp2p#5644 that if resolved will
allow to have `&self` instead.

## Change checklist

- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] A changelog entry has been made in the appropriate crates

Co-authored-by: João Oliveira <hello@jxs.pt>

* feat(gossipsub): apply `max_transmit_size` to the published message (libp2p#5642)

## Description

When trying to publish a message using gossipsub's `publish` method,
it should be possible to predict whether it will fit in the limit
defined by
the `max_transmit_size` config option.
If this limit applies to the final protobuf payload, it's not possible
to know
that in advance because the size of the added fields is not fixed.

This change makes the limit apply to the passed message size instead of
the final wire size.

## Notes & open questions

This is a minor version change because it changes the meaning of the
existing config option.
However, for the existing clients the limit will only become more
permissive, so it shouldn't break anything.

## Change checklist

<!-- Please add a Changelog entry in the appropriate crates and bump the
crate versions if needed. See
<https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#development-between-releases>-->

- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] A changelog entry has been made in the appropriate crates

---------

Co-authored-by: Darius Clark <dariusc93@users.noreply.github.com>
Co-authored-by: João Oliveira <hello@jxs.pt>

* chore(ci): address clippy beta lints (libp2p#5649)

Co-authored-by: Darius Clark <dariusc93@users.noreply.github.com>

* feat: refactor distributed-key-value-store example (libp2p#5652)

## Description

ref libp2p#4449 

Refactored distributed-key-value-store example to use `tokio` instead of
`async-std`

## Change checklist

<!-- Please add a Changelog entry in the appropriate crates and bump the
crate versions if needed. See
<https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#development-between-releases>-->

- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation
- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] A changelog entry has been made in the appropriate crates

* chore: refactor ping tests (libp2p#5655)

## Description

ref libp2p#4449 

Refactored ping tests to use `tokio` instead of `async-std`.

## Change checklist

- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation
- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] A changelog entry has been made in the appropriate crates

* fix(websocket): don't dial `/dnsaddr` addresses (libp2p#5613)

## Description

Returns `Error::InvalidMultiaddr` when `parse_ws_dial_addr` is called
with `/dnsaddr`.

As per its specification, `/dnsaddr` domains are not meant to be
directly dialed, instead it should be appended with `_dnsaddr.` and used
for DNS lookups afterwards

Related: libp2p#5529
Fixes: libp2p#5601 

## Notes & open questions

* Is it okay to return an error, or should I perform a DNS lookup and
resolve that DNS afterwards if address has `/dnsaddr`?
* If so, how should I handle that case where DNS lookup returns multiple
multiaddrs?

## Change checklist

- [x] I have performed a self-review of my own code
- [ ] I have made corresponding changes to the documentation
- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] A changelog entry has been made in the appropriate crates

---------

Co-authored-by: Darius Clark <dariusc93@users.noreply.github.com>

* chore: fix some comments (libp2p#5661)

## Description

<!--
Please write a summary of your changes and why you made them.
This section will appear as the commit message after merging.
Please craft it accordingly.
For a quick primer on good commit messages, check out this blog post:
https://cbea.ms/git-commit/

Please include any relevant issues in here, for example:

Related https://github.com/libp2p/rust-libp2p/issues/ABCD.
Fixes https://github.com/libp2p/rust-libp2p/issues/XYZ.
-->

## Notes & open questions

<!--
Any notes, remarks or open questions you have to make about the PR which
don't need to go into the final commit message.
-->

## Change checklist

<!-- Please add a Changelog entry in the appropriate crates and bump the
crate versions if needed. See
<https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#development-between-releases>-->

- [x] I have performed a self-review of my own code
- [ ] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [ ] A changelog entry has been made in the appropriate crates

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* chore: identify::Config fields private (libp2p#5663)

## Description

Closes libp2p#5660 

## Change checklist

- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation
- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] A changelog entry has been made in the appropriate crates

* chore(protocols): fix some typos in comment (libp2p#5665)

## Description

<!--
Please write a summary of your changes and why you made them.
This section will appear as the commit message after merging.
Please craft it accordingly.
For a quick primer on good commit messages, check out this blog post:
https://cbea.ms/git-commit/

Please include any relevant issues in here, for example:

Related https://github.com/libp2p/rust-libp2p/issues/ABCD.
Fixes https://github.com/libp2p/rust-libp2p/issues/XYZ.
-->

fix some typos in comment



## Notes & open questions

<!--
Any notes, remarks or open questions you have to make about the PR which
don't need to go into the final commit message.
-->

## Change checklist

<!-- Please add a Changelog entry in the appropriate crates and bump the
crate versions if needed. See
<https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#development-between-releases>-->

- [ ] I have performed a self-review of my own code
- [ ] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [ ] A changelog entry has been made in the appropriate crates

Signed-off-by: wangjingcun <wangjingcun@aliyun.com>

* chore(ci): fix interop tests region, and run them again on each PR (libp2p#5666)

* chore: deprecate `void` crate (libp2p#5676)

## Description

<!--
Please write a summary of your changes and why you made them.
This section will appear as the commit message after merging.
Please craft it accordingly.
For a quick primer on good commit messages, check out this blog post:
https://cbea.ms/git-commit/

Please include any relevant issues in here, for example:

Related https://github.com/libp2p/rust-libp2p/issues/ABCD.
Fixes https://github.com/libp2p/rust-libp2p/issues/XYZ.
-->

The `void` crate provides a `Void` type that is conceptually equivalent
to the [`never`
type(!)](https://doc.rust-lang.org/std/primitive.never.html). This PR
tries to remove `void` crate from the dependency tree by replacing
`void::Void` with
[`std::convert::Infallible`](https://doc.rust-lang.org/std/convert/enum.Infallible.html)
that will eventually become an alias of the `never` type(!)

> This enum has the same role as [the ! “never”
type](https://doc.rust-lang.org/std/primitive.never.html), which is
unstable in this version of Rust. When ! is stabilized, we plan to make
Infallible a type alias to it:

## Notes & open questions

<!--
Any notes, remarks or open questions you have to make about the PR which
don't need to go into the final commit message.
-->

## Change checklist

<!-- Please add a Changelog entry in the appropriate crates and bump the
crate versions if needed. See
<https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#development-between-releases>-->

- [x] I have performed a self-review of my own code
- [ ] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [ ] A changelog entry has been made in the appropriate crates

* chore: replace async-std with tokio in autonat tests (libp2p#5671)

## Description

ref libp2p#4449 

Refactored `autonat` tests to use `tokio` instead of `async-std`.

* chore: bump crate versions and update changelogs for libp2p#5676 (libp2p#5678)

## Description

<!--
Please write a summary of your changes and why you made them.
This section will appear as the commit message after merging.
Please craft it accordingly.
For a quick primer on good commit messages, check out this blog post:
https://cbea.ms/git-commit/

Please include any relevant issues in here, for example:

Related https://github.com/libp2p/rust-libp2p/issues/ABCD.
Fixes https://github.com/libp2p/rust-libp2p/issues/XYZ.
-->

This PR bumps crate versions and add changelog entries for crates that
are changed in libp2p#5676

Question: When should a crate version bump in the current release
process? Should it be right before or right after publishing? I see most
of current crate versions are published while some are not (e.g.
libp2p-autonat@0.13.1 libp2p-gossisub@0.48.0 and libp2p-perf@0.4.0 etc.)

## Notes & open questions

<!--
Any notes, remarks or open questions you have to make about the PR which
don't need to go into the final commit message.
-->

## Change checklist

<!-- Please add a Changelog entry in the appropriate crates and bump the
crate versions if needed. See
<https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#development-between-releases>-->

- [x] I have performed a self-review of my own code
- [ ] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] A changelog entry has been made in the appropriate crates

---------

Co-authored-by: João Oliveira <hello@jxs.pt>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* chore(ci): add a mergify batch queue for external PRs (libp2p#5668)

and remove the if conditions no longer required as we are running them
again on every PR

---------

Co-authored-by: Guillaume Michel <guillaumemichel@users.noreply.github.com>
Co-authored-by: João Oliveira <jxs>

* chore: refactor dcutr and gossipsub tests to use tokio instead

ref libp2p#4449

Refactored dcutr and gossipsub tests to use `tokio` instead of `async-std`.

Pull-Request: libp2p#5662.

* chore(gossispsub): deprecate futures-ticker

to address [RUSTSEC-2024-0384 ](https://rustsec.org/advisories/RUSTSEC-2024-0384.html). Use `futures-timer` and `Delay` instead

Pull-Request: libp2p#5674.

* chore: update FUNDING.json

I've added addresses to receive Drips donations. This is required for FIL-RetroPGF-2 in the coming days, we should get this into `master` ASAP.

This is a dedicated address controlled by Sigma Prime (including @AgeManning and myself).

Pull-Request: libp2p#5685.

* feat(gossipsub): introduce backpressure

superseeds libp2p#4914 with some changes and improvements, namely:

- introduce a `Delay` for `Forward` and `Publish` messages, messages that take more than the configured delay to be sent are discarded
- introduce scoring and penalize slow peers
- remove control pool
- report slow peers with the number of failed messages

Pull-Request: libp2p#5595.

* chore(deps): upgrade `thiserror` to 2.0

Changes:
- upgrade `thiserror` crate from `1` to `2`
- move `thiserror` to `workspace.dependencies`
- sort `workspace.dependencies`
- ~run `cargo update` to update `Cargo.lock`~
(Skipping changelog as `thiserror` does not present in any public APIs)

Pull-Request: libp2p#5689.

* fix: typos in documentation files

Pull-Request: libp2p#5693.

* fix(gossipsub): fix mesh/fanout inconsistencies

When a peer unsubscribes also remove it from fanout.

Pull-Request: libp2p#5690.

* fix(ci): Clippy Beta

Fixes CI failure in Clippy (Beta)

https://github.com/libp2p/rust-libp2p/actions/runs/12055058396/job/33614543029

Pull-Request: libp2p#5700.

* chore: introduce rustfmt.toml

Pull-Request: libp2p#5695.

* feat(kad): make Distance private field public

make Distance private field (U256) public

So that some `network density` in Distance can be calculated as below:

```rust
let density = U256::MAX / U256::from(estimated_network_size);
let density_distance = Distance(estimated_distance);
```

Pull-Request: libp2p#5705.

* chore: fix some typos in comment

fix some typos in comment

Pull-Request: libp2p#5721.

* fix(libp2p): expose builder phase error

May close libp2p#4829 and libp2p#4824.
Export three error types `BehaviourError`, `TransportError`, `WebsocketError` with rename. Feature gated `WebsocketError`.
Exported at crate root as [suggested](libp2p#4824 (comment)).

Pull-Request: libp2p#5726.

* feat(request-response): Add connection id to behaviour events

Closes libp2p#5716.

Added connection id to the events emitted by a request-response Behaviour and adapted the code accordingly.

Pull-Request: libp2p#5719.

* chore(ci): update Rust stable version

Update Rust stable version in our CI to the latest stable version 1.83.0.

Pull-Request: libp2p#5730.

* chore(roadmap): fix typo

Pull-Request: libp2p#5732.

* chore(deps): upgrade uint to 0.10

This PR upgrade `uint` to `0.10`
https://github.com/paritytech/parity-common/blob/master/uint/CHANGELOG.md#0100---2024-09-11
(Skipping changelog as there's no changes in public APIs)

Pull-Request: libp2p#5699.

* fix: RUSTSEC-2024-0421 by upgrading idna

https://rustsec.org/advisories/RUSTSEC-2024-0421.html

Pull-Request: libp2p#5727.

* deps(metrics-example): update opentelemetry to 0.27

this will help fix the `cargo deny` situation as `opentelemetry-otlp` `0.25` has `tokio` [locked to `~1.38.0`](https://crates.io/crates/opentelemetry-otlp/0.25.0/dependencies) 🤷‍♂️
which then impedes us tfrom updating `netlink-sys`

Pull-Request: libp2p#5735.

* fix: update Cargo.lock

To finally address [RUSTSEC-2024-0384](https://rustsec.org/advisories/RUSTSEC-2024-0384).
Thanks  @hanabi1224 for submitting the [upstream update](rust-netlink/netlink-sys#25) ❤️

Pull-Request: libp2p#5737.

* chore: add Unicode V3 license to deny.toml

Add `Unicode` `v3` License to our `cargo.deny` file.
This is required because of the [`icu_collections`](https://crates.io/crates/icu_collections) dependency which is authored by The Unicode Consortium.
in my ignorance, seems to be safe as the Open Source Initiative [approves it](https://opensource.org/license/unicode-license-v3), and the main `deny.toml` has also [added it](https://github.com/EmbarkStudios/cargo-deny/pull/713/files#diff-1040309c64844eb1b6b63d8fd67938adbf9461f1b3c61f12cf738f064a02d3deR50).

Pull-Request: libp2p#5738.

* chore(core): avoid unused props matching on connection.rs

Pull-Request: libp2p#5734.

* feat(swarm): set default for idle-connection-timeout to 10s (libp2p#4967)

## Description

With the move to a global idle-connection-timeout, connections are being
closed much more aggressively. This causes problems in situations where,
e.g. an application wants to use a connection shortly after an event has
been emitted from the `Swarm`. With a default of 0 seconds, such a
connection is instantly considered idle and therefore closed, despite
the application wanting to use it again just moments later. Whilst it is
possible to structure application code to mitigate this, it is
unnecessarily complicated.

Additionally, connections being closed instantly if not in use is a
foot-gun for newcomers to the library.

From a technical point-of-view, instantly closing idle connections is
nice. In reality, it is an impractical default. Hence, we change this
default to 10s.

10 seconds is considered to be an acceptable default as it strikes a
balance between allowing some pause between network activity, yet frees
up resources that are (supposedly) no longer needed.

Resolves: libp2p#4912.

* chore(deps): bump golang.org/x/crypto from 0.21.0 to 0.31.0 (libp2p#5736)

Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from
0.21.0 to 0.31.0. for the wasm webtransport tests

* fix(identify): validate public key from remote peer

Related libp2p#5706

Discard `Info` messages received from a remote peer that contain a public key that doesn't match their peer ID, and log a warning. Don't emit `identify::Received` events to the swarm containing whatever public key they sent.

Pull-Request: libp2p#5707.

* deps(memory-connection-limits): update sysinfo to 0.33

Pull-Request: libp2p#5739.

* feat(SwarmBuilder): add with_connection_timeout method

Small PR to be able to change the `connection_timeout` value given to the `TransportTimeout` when building the `Swarm` with a `SwarmBuilder`.

Pull-Request: libp2p#5575.

* chore(core): use `matches!` in connection.rs

Pull-Request: libp2p#5740.

* chore: fix format with nightly

Fix formatting with nightly.

Without nightly, some of our `rustfmt.toml` rules aren't applied because they are not stable yet (e.g. our `group_imports` rule).
Our CI didn't catch it yet because it doesn't check fmt on nightly. Will fix that in a follow-up PR.

Pull-Request: libp2p#5742.

* chore(docs): fix typos in documentation

Pull-Request: libp2p#5744.

* chore(ci): check rustfmt with nightly toolchain

Some of our rustfmt rules aren't stable yet. Thus our rustfmt CI check should run on nightly.

Pull-Request: libp2p#5743.

* fix(kad): improve memory allocation when iterating over kbuckets

Proposal to fix libp2p#5712.

I have changed to `ClosestIter` structure to only allocate when `kbucket_size` is higher than `K_VALUE` and only once along the life of `ClosestIter`. I think I did not break anything but I would really like some experienced people with Kademlia to take a look (@guillaumemichel 😉).

Pull-Request: libp2p#5715.

* chore(spellchecker): fix typos in comment

- use spellchecker, and check false positive manually

```
codespell  -L crate,COMIT,comit  -S CHANGELOG.md
```
- maybe we can add typo checker in github action ref: https://github.com/codespell-project/actions-codespell

Pull-Request: libp2p#5750.

* chore: add SQD Network to notable users list

SQD Network uses Libp2p and gossipsub protocol in particular to organize a decentralized network of p2p workers that provide fast access to stored data.

Pull-Request: libp2p#5749.

* feat(mdns): emit `ToSwarm::NewExternalAddrOfPeer` on discovery

fixes libp2p#5104 and superseeds libp2p#5179

Pull-Request: libp2p#5753.

* fix: multiple typos of different importance

This pull request addresses several typos and minor grammatical inconsistencies found across multiple files in the repository. The fixes aim to improve clarity, readability, and maintain consistency in the project's documentation and workflows.

### Key Changes:
- **`.github/ISSUE_TEMPLATE/bug_report.yml`**:
- Fixed grammatical issues in descriptions and labels.
- **`.github/ISSUE_TEMPLATE/enhancement.yml`**:
- Corrected label text and standardized phrasing.
- **`.github/ISSUE_TEMPLATE/feature_request.yml`**:
- Improved label consistency and readability.
- **`.github/pull_request_template.md`**:
- Enhanced phrasing and corrected minor grammatical errors.
- **`.github/workflows/ci.yml`**:
- Adjusted text to ensure consistent phrasing and clarity in workflow steps.

These updates ensure a more professional and coherent presentation across the project documentation and workflows.

Pull-Request: libp2p#5756.

* chore(deps): remove unused deps

Remove unused dependencies

(Not sure how to bump `libp2p-identity` and `libp2p-swarm-derive` versions in a PR)

Pull-Request: libp2p#5747.

* chore(mdns): revert version bump

Revert version bump of libp2p#5753, because libp2p-mdns-0.46.1 isn't released yet.

Pull-Request: libp2p#5762.

* deps(quic): update quinn to 0.11.6

Among other changes, it includes a fix for this issue which often reproduces with libp2p: quinn-rs/quinn#1889

Pull-Request: libp2p#5757.

* chore: introduce `libp2p-test-utils`

Fixes libp2p#4992

Based on the conversation in libp2p#4992.

Pull-Request: libp2p#5725.

* feat(gossipsub): implement gossipsub 1.2 beta

This PR implements gossipsub 1.2 beta bringing changes over from lighthouse
ref PR: sigp/lighthouse#5422

Please include any relevant issues in here, for example:
libp2p/specs#548

Pull-Request: libp2p#5697.

* chore(deps): update Cargo.lock

- run `cargo update`
- lock `webrtc-ice = "=0.10.0"` to not break webrtc smoke tests
- fix `cargo clippy` warnings
- update `deny.toml` accordingly

Pull-Request: libp2p#5755.

* feat(gossipsub): Allow setting a size threshold for IDONTWANT messages

This PR adds configurable parameter that sets minimum message size for which `IDONTWANT` messages would be send. This is an optimisation trick, discussion regarding the same can be found [here](sigp/lighthouse#6437)

Pull-Request: libp2p#5770.

* chore(kad): revert version bump

Revert version bump, because `libp2p-kad-0.47.0` isn't released yet.

Pull-Request: libp2p#5776.

* chore(autonat): revert version bump

Revert version bump, `libp2p-autonat-v0.13.1` isn't released yet.

Pull-Request: libp2p#5777.

* chore(server): revert version bump

Revert version bump, `libp2p-server-v0.12.6` isn't released yet.

Pull-Request: libp2p#5780.

* chore(identify): revert version bump

Revert version bump, `libp2p-identify-v0.46.0` isn't released yet.

Pull-Request: libp2p#5778.

* chore(ci): add Zlib to deny.toml

Similar to libp2p#5738,  [`foldhash`](https://crates.io/crates/foldhash) is the dependency that requires it. It was introduced by `hashbrown` which is dependency of a lot of crates [here](rust-lang/hashbrown#563).
`hashbrown` is MIT, and Zlib is also an Open Source Initiative [approved license](https://opensource.org/license/zlib).

If you prefer we can also do as the upstream `cargo-deny` do and just add `foldhash` [to the exceptions](https://github.com/EmbarkStudios/cargo-deny/pull/618/files#diff-1040309c64844eb1b6b63d8fd67938adbf9461f1b3c61f12cf738f064a02d3deR56) but I can't see any advantage to it.
Cc @hanabi1224

Pull-Request: libp2p#5769.

* chore(allow-block-list): revert version bump

Revert version bump, `libp2p-allow-block-list-v0.4.1` isn't released yet.

Pull-Request: libp2p#5779.

* chore(kad): remove default constructor for ProtocolConfig

Remove items that were deprecated in libp2p#5122.

Pull-Request: libp2p#5774.

* feat: broadcasting `idontwant` for published messages

This PR introduces an optimisation to preemptively broadcast `IDONTWANT` for published messages, preventing redundant downloads of the same message received over gossip. This feature is opt-in and respects the existing `idontwant_message_size_threshold`. By default, `IDONTWANT` messages will only be sent for published messages larger than 1000 bytes.

reference PRs:
[spec](libp2p/specs#642)

Pull-Request: libp2p#5773.

* fix(gossipsub): make sure we have fanout peers when publish

This PR is to submit a fix in Lighthouse. sigp/lighthouse#6738

An `InsufficientPeers` error can occur under a particular condition, even if we have peers subscribed to a topic.

Pull-Request: libp2p#5793.

* feat(request-response): allow custom sizes for `json` and `cbor` codec

resolves libp2p#5791.

Pull-Request: libp2p#5792.

* chore: update MSRV

Pull-Request: libp2p#5650.

* chore: address clippy lints for Rust 1.85.0-beta

Pull-Request: libp2p#5802.

* deps: bump Swatinem/rust-cache from 2.7.5 to 2.7.7

Pull-Request: libp2p#5775.

* refactor: mark {In, Out}boundOpenInfo as deprecated

Mark `{In, Out}boundOpenInfo` as deprecated.
May close libp2p#3268.

Pull-Request: libp2p#5242.

* chore(identify): fix changelog entry

Amendment to libp2p#5778.

Merged CHANGELOG entries of `0.45.1` and `0.46.0`. Version `0.45.1` has been superseded by `0.46.0` before it was released.

Pull-Request: libp2p#5803.

* update webrtc crate

* update CHANGELOG.md

* fix websocket doc

* chore(ci): fix wasm tests

see here rust-lang/compiler-team#607 for more info

Pull-Request: libp2p#5805.

* chore(swarm): append missing changelog

Add missing changelog entry for libp2p#5242.

Pull-Request: libp2p#5806.

* ci(mergify): upgrade configuration to current format

Pull-Request: libp2p#5683.

* fix(tcp): make `TCP_NODELAY` actually the default

Nagle's algorithm is actually disabled by setting `TCP_NODELAY` to _true_. In the current master, it is set to _false_, i.e. Nagle's algorithm is enabled.
This PR sets `TCP_NODELAY` per default to `true` and fixes the description of `tcp::Config::new`.

Fixes libp2p#4890.

Pull-Request: libp2p#5764.

* chore(ci): update mergify script

With libp2p#5683  the automatically merge of `send-it` labeled PR's was lost.
This PR brings it back

Pull-Request: libp2p#5808.

* chore(interop-tests): remove static linking flags for dependency builds

When building the dependencies, we are not linking anything so we don't need to specify the static linking flags.

Pull-Request: libp2p#5121.

* deps(if-watch): update if-watch to v3.2.1

Bumps the `if-watch` version to 3.2.1, aiming to fix libp2p#5628.

Since this [`if-watch` PR](libp2p/if-watch#37), the `system-configuration` version has been updated, which enables compiling for iOS targets.

Pull-Request: libp2p#5758.

* chore(ci): update mergify script

missed this, with this dependabot is not able to merge PR's by itself as it needs the `send-it` label.
also add a clause for the dismiss of stale approvals to not do so when the last commit was done by one of the `rust-libp2p` maintainers, so that we don't dismiss approvals if the last commit was a merge of master into the PR that is necessary before merging the PR.
Latest example of this happening [here](libp2p#5758 (comment))

Pull-Request: libp2p#5809.

* chore(test-utils): revert libp2p#5725

We cannot publish the crates using `libp2p-test-utils`, as cargo seems to required `dev-dependencies` to also be published

Pull-Request: libp2p#5810.

* fix: minor version bump packages affected by libp2p#5676

By switching from `void::Void` to `std::convert::Infallible`, libp2p#5676 changed the output types of some `NetworkBehavior` implementations in different protocols.
This can cause a type mismatch for the user and therefore is a breaking change.

libp2p#5678 (follow-up PR that version-bumped the crates affected by libp2p#5676) only bumped the patch version of the affected crates.
The current PR now changes it to a minor version bump for all crates where types in a `NetworkBehavior` implementation were affected.

It also reverts the version bump and CHANGELOG entry in `libp2p-quic` that was added with libp2p#5678, because that crate was never touched by the original PR.

Pull-Request: libp2p#5811.

* chore: prepare libp2p-webrtc-websys 0.4.0

Pull-Request: libp2p#5807.

* chore(*): prepare release

Bump minor version of all crates that depend on `libp2p-core`, to avoid conflicting versions or `libp2p-core` being pulled in multiple times.

Pull-Request: libp2p#5813.

* chore(ci): fix workspace version enforcing job

Cue due to an [update](https://crates.io/crates/tomlq/0.2.0) to the `tomlq` tool, there's now a mismatch between the `$CRATE_VERSION` and the  `$SPECIFIED_VERSION` variables:
```bash
Package version: 0.43.0
Specified version: "0.43.0"
```
This PR attempts to fix the "Enforce version in `workspace.dependencies` matches the latest version" job by locking to the previous version until (and if) the situation is solved.
Also see cryptaliagy/tomlq#22

Pull-Request: libp2p#5817.

* refactor(gossipsub): remove duplicated call to `inbound_transform`

May close libp2p#4369.

Pull-Request: libp2p#5767.

* chore(ci): update tomlq

and address the version lock introduced on libp2p#5817

Pull-Request: libp2p#5821.

* WIP allow test runs manually

---------

Signed-off-by: dependabot[bot] <support@github.com>
Signed-off-by: wangjingcun <wangjingcun@aliyun.com>
Co-authored-by: haurog <36535774+haurog@users.noreply.github.com>
Co-authored-by: Piotr Galar <piotr.galar@gmail.com>
Co-authored-by: João Oliveira <hello@jxs.pt>
Co-authored-by: Guillaume Michel <guillaumemichel@users.noreply.github.com>
Co-authored-by: Stefan <stefan@novabytes.nl>
Co-authored-by: Darius Clark <dariusc93@users.noreply.github.com>
Co-authored-by: stormshield-frb <144998884+stormshield-frb@users.noreply.github.com>
Co-authored-by: P1R0 <p1r0@nethunters.xyz>
Co-authored-by: David E. Perez Negron R. <david@nethunters.xyz>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: hanabi1224 <harlowmoo@gmail.com>
Co-authored-by: yanziseeker <153156292+AdventureSeeker987@users.noreply.github.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
Co-authored-by: Dzmitry Kalabuk <kalabukdima@gmail.com>
Co-authored-by: Krishang Shah <93703995+kamuik16@users.noreply.github.com>
Co-authored-by: Hamza <hmzkrb@gmail.com>
Co-authored-by: wangjingcun <wangjingcun@aliyun.com>
Co-authored-by: Paul Hauner <paul@paulhauner.com>
Co-authored-by: leopardracer <136604165+leopardracer@users.noreply.github.com>
Co-authored-by: maqi <qi.ma@maidsafe.net>
Co-authored-by: needsure <166317845+needsure@users.noreply.github.com>
Co-authored-by: DrHuangMHT <DrHuangMHT@outlook.com>
Co-authored-by: Bastien Faivre <faivre.bast@gmail.com>
Co-authored-by: Elena Frank <elena.frank@protonmail.com>
Co-authored-by: lfg2 <lfgtwo@proton.me>
Co-authored-by: Sergey Melnychuk <8093171+sergey-melnychuk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: James Hiew <james@hiew.net>
Co-authored-by: X6 <xep-c-6yrpa@proton.me>
Co-authored-by: Tristav <124001124+Pricstas@users.noreply.github.com>
Co-authored-by: argentpapa <argentpapa@proton.me>
Co-authored-by: Dzmitry Kalabuk <d.kalabuk@subsquid.io>
Co-authored-by: hopinheimer <48147533+hopinheimer@users.noreply.github.com>
Co-authored-by: crStiv <cryptostiv7@gmail.com>
Co-authored-by: Akihito Nakano <sora.akatsuki@gmail.com>
Co-authored-by: Breno Teodoro <54450520+brenodt@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.