[GossipSub 1.2] Allow sending IDONTWANTs when publishing #642
Conversation
|
Hi Vyzo, on our case it's implemented and merged soon to be released, on other implementations I don't know. |
|
ok, lets wait a little for the other implementations to catch up and we merge it |
|
Implemented in JVM-libp2p here: libp2p/jvm-libp2p#386 |
|
@ppopth can confirm, but we should already be doing this in the go-implementation when publishing |
No, go-libp2p-pubsub is not doing this now. It has to be implemented. |
| @@ -56,6 +56,7 @@ This section lists the configuration parameters that needs to agreed on across c | |||
| 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. | |||
| Additionally, on networks where multiple messages share the same messageId, a user may choose to broadcast IDONTWANT when publishing. | |||
There was a problem hiding this comment.
I think it's good to note that the publisher still shouldn't publish the message to the peers that previously sent an IDONTWANT to the publisher.
It's trivial to know this but I'm afraid that some implementers will forget this.
With the introduction of
getBlobsV1for the Cancun upgrade in the Ethereum network, nodes may publish blobs (messages) retrieved from the Execution Layer without receiving them through Gossipsub. In such cases, a node already has the blobs and can conserve download bandwidth by sending out IDONTWANT messages to peers for the blobs it publishes. This prevents the node from receiving the same blobs again through gossip.This PR aims to clarify the behavior at the specification level.
See more here
Thanks!