PubSub protocol versioning


Core Libp2p offers Protocol ID as way to discern traffic and reject connections from nodes not running the same protocol. For direct node-to-node communication this is great.
However, PubSub is built on top of LibP2P and defines its own protocol ID different from the protocol ID that may have been defined by an application. This means that while direct one to one communication is protected against cross-talk across incompatible protocol versions, pub-sub messaging is not. Is that correct?

I would like to update the protocol ID that my application uses so that nodes running the old application software cannot talk to nodes running the updated application software. However, this still would mean that old nodes may talk to new nodes via PubSub since that uses a completely different protocol ID.

Please can you let me know if my understanding is correct and if there are ways to update pubsub protocol ID as well.


PS: I do understand that changing the Public key when application software is updated would prevent cross-talks but I wanted to know if it can be done by just manipulating the protocol id.

@vyzo hey! is here a way to override the protocol IDs used by gossipsub? I found a NewFloodSubWithProtocols constructor, but no equivalent Option or constructor for gossipsub.


The short answer is no.

There is an open pr for specifying protocols in the constructor (see but the code still has logic that checks the gossipsub protocol IDs for peer selection etc. All this pr can do is allow you to turn off floodsub/gsv1.0 backwards compatibility.

– vyzo

thanks for the replies.
In that case, I was thinking of prefixing the pubsub Topic with a unique string for each application update so that nodes on the old version of the application are not even aware of the new topic.
Do you think that will be a good approach to keep nodes from cross-talk?

Yes, that’s the standard approach I think – you could also use topics of the form /your/topic/version and increment the version to avoid the cross talk.

thanks @vyzo. I will run with that approach.