Gossipsub partial messages #577

jxs · 2025-09-16T18:47:13Z

Description

This is a draft implementation of partial messages for gossipsub following the spec PR and based on the Go implementation. Still WIP but should give a good idea of the direction we're heading.

…sipsub-partial-messages

MarcoPolo · 2025-09-16T21:33:16Z

protocols/gossipsub/src/behaviour.rs

+        {
+            // Return err if trying to publish the same partial message state we currently have.
+            if existing.available_parts() == partial_message.available_parts() {
+                return Err(PublishError::Duplicate);


I don't think this is correct.

Imagine you have parts 1,2,3.

You tell your peers about those parts.

A peer comes back and says I want part 2.

You republish with the same parts in order to respond.

You get this error and fail to respond.

thanks for explaining Marco, updated as we spoke

MarcoPolo · 2025-09-16T21:33:54Z

protocols/gossipsub/src/behaviour.rs

    data_transform: D,

+    /// Partial messages received.
+    partial_messages: HashMap<TopicHash, HashMap<Vec<u8>, P>>,


Do you need to store P here? I think it's better if P is owned solely by the application.

yup, you are right, thanks Marco!

MarcoPolo · 2025-09-16T21:35:51Z

protocols/gossipsub/src/types.rs

+pub(crate) struct PartialData {
+    pub(crate) ihave: Vec<u8>,
+    pub(crate) iwant: Vec<u8>,
+    pub(crate) message: Vec<u8>,


Is it useful to store the message here? It seems like wasted space, you only use it to check if the peer is sending you a duplicate.

Might be simpler to let the application handle dupes.

thanks Marco, I only left wanted and has wanted to avoid sending the same message and has to avoid notifying the application layer of duplicates.
Thanks!

and create a paralel list for the partial_only topics.

dknopik

Some thoughts and some nitpicks.

dknopik · 2025-10-09T14:23:08Z

protocols/gossipsub/src/types.rs

 #[derive(Debug)]
 pub enum RpcOut {
-    /// Publish a Gossipsub message on network.`timeout` limits the duration the message
+    /// PublishV a Gossipsub message on network.`timeout` limits the duration the message


Accidental change

thanks, updated!

dknopik · 2025-10-09T14:25:06Z

protocols/gossipsub/src/partial.rs

+
+    /// Returns metadata describing which parts of the message are available and which parts we want.
+    ///
+    /// This metadata is application-defined and should encode information about


Partial sentence

thanks Daniel, updated

dknopik · 2025-10-09T14:34:14Z

protocols/gossipsub/src/behaviour.rs

+    // If partial set, filter out peers who only want partial messages for the topic.
+    fn get_publish_peers(&mut self, topic_hash: &TopicHash, partial: bool) -> HashSet<PeerId> {


The fact that partial being true causes the filtering is confusing, as this is set to true on non-partial messages and vice-versa. I'd either call this filter_partial or invert the condition.

yup, agreed and updated. Thanks Daniel!

dknopik · 2025-10-09T14:44:55Z

protocols/gossipsub/src/partial.rs

+    /// - Optional remaining metadata if more parts are still available after this one
+    fn partial_message_bytes_from_metadata(
+        &self,
+        metadata: Option<impl AsRef<[u8]>>,


It is unclear to me what the expected behaviour is if metadata is None. I guess usually send everything we have to the peer?

For Ethereum this is the case where we still haven't received a peer's metadata and could maybe eager push data to them. There are, at a high level, 3 options:

Don't return anything.

Return everything (probably not what we want to do)

Return cells we didn't have locally (cells that we got from the network, not getBlobs).

dknopik · 2025-10-09T14:47:06Z

protocols/gossipsub/src/partial.rs

+    fn partial_message_bytes_from_metadata(
+        &self,
+        metadata: Option<impl AsRef<[u8]>>,
+    ) -> Result<(impl AsRef<[u8]>, Option<impl AsRef<[u8]>>), PartialMessageError>;


If I understand correctly, if we have nothing to send to the peer, we return Ok((vec![], metadata)). This seems unintuitive and potentially inefficient to me, as we have to clone metadata and publish_partial has to compare it to the previous value. Maybe change it to allow returning Ok(None) to signal this?

dknopik · 2025-10-09T14:51:25Z

protocols/gossipsub/src/behaviour.rs

-                    timeout: Delay::new(self.config.publish_queue_duration()),
+                RpcOut::PartialMessage {
+                    message: message_data,
+                    metadata: partial_message.parts_metadata().as_ref().to_vec(),


Maybe get partial_message.parts_metadata() before the loop to avoid useless re-encoding (in case the implementation encodes ad-hoc)?

yeah nice catch, before each peer had its own metadata so this was not possible. Updated!

dknopik · 2025-10-09T15:16:34Z

protocols/gossipsub/src/partial.rs

+    ///
+    /// Returns `Ok(())` if the data was successfully integrated, or `Err`,
+    /// if the data was invalid or couldn't be processed.
+    fn extend_from_encoded_partial_message(


This is unused as far as I can tell. Yes, something like this is likely needed by the application, but as the behaviour does not need to access this, we can leave the exact interface up to the application (as maybe some external info is needed to extend the partial message).

yup, good point. Removed it

dknopik · 2025-10-10T11:27:00Z

protocols/gossipsub/src/behaviour.rs

        self.leave(&topic_hash);
+        #[cfg(feature = "partial_messages")]
+        {
+            self.partial_only_topics.insert(topic_hash.clone());


I think this should be remove?

dknopik · 2025-10-10T14:15:20Z

protocols/gossipsub/src/types.rs

+pub(crate) struct PartialData {
+    /// The current peer partial metadata.
+    pub(crate) metadata: Option<Vec<u8>>,
+    /// The remaining heartbeats for this message to be deleted.


I think this should not be Option. I can't think of a meaningful case where we have None associated with a peer instead of no entry at all.

Nevermind, we can represent that we sent all data with None.

MarcoPolo · 2025-10-10T20:21:15Z

My review comments as a patch: https://notes.marcopolo.io/view/d804e35e05fa79cfc1ed38e920aa01f1

Import review commit locally:

curl https://notes.marcopolo.io/raw/d804e35e05fa79cfc1ed38e920aa01f1 | git am

Feel free to respond inline with a new patch or quote relevant sections here and respond.

(I'm experimenting with alternative code-review processes, this is a rough prototype of reviews as separate commits. Feedback welcome)

jxs added 8 commits September 9, 2025 10:48

feat(gossipsub): implement gossipsub 1.3

6313068

implement test extesion

53cc7e8

Add PartialMessage trait implementation

4249ccb

implement sending and receiving partial messages at te protocol level

9aa7ead

add partial_publish method

bc45d3e

update trait extend method to receive slice instead

8b1c086

implement Partial message handling and publishing at the behaviour level

b1b8dbe

Merge branch 'sigp-gossipsub' of github.com:sigp/rust-libp2p into gos…

e7250f5

…sipsub-partial-messages

MarcoPolo reviewed Sep 16, 2025

View reviewed changes

address Marco's review

6370514

jxs force-pushed the gossipsub-partial-messages branch 5 times, most recently from cb0e925 to e6f1ae4 Compare September 26, 2025 11:35

jxs added 3 commits September 26, 2025 15:23

feature gate partial messages

909a68f

remove PartialIDONWANT from proto to follow spec

046ad47

update trait return types and remove non used impl

69c2d95

jxs force-pushed the gossipsub-partial-messages branch from e6f1ae4 to 69c2d95 Compare September 26, 2025 14:24

jxs added 10 commits September 26, 2025 15:29

fixup! feature gate partial messages

45c2bc1

update to spec changes

85b92f3

update extension message priority to highest

b6478d5

add missing proto field SubOpts partial

5e98f1a

implement subscription options partial

f77490c

publish only full messages to partial false peers

1bfbc55

revert to only using TopicHash,

33783bd

and create a paralel list for the partial_only topics.

add partial option to subscribe and unsubscribe methods

438a297

polish PR

6cb5244

push publish method above for smaller diff

bc3d7ba

dknopik reviewed Oct 9, 2025

View reviewed changes

This comment was marked as duplicate.

Sign in to view

dknopik reviewed Oct 10, 2025

View reviewed changes

address Daniel's review

4321429

dknopik reviewed Oct 10, 2025

View reviewed changes

enum return value for partial_message_bytes_from_metadata

c3aa3e4

		// If partial set, filter out peers who only want partial messages for the topic.
		fn get_publish_peers(&mut self, topic_hash: &TopicHash, partial: bool) -> HashSet<PeerId> {

Gossipsub partial messages #577

Are you sure you want to change the base?

Gossipsub partial messages #577

Uh oh!

Conversation

jxs commented Sep 16, 2025

Description

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dknopik left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dknopik Oct 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as duplicate.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MarcoPolo commented Oct 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

dknopik Oct 9, 2025 •

edited

Loading