search

vacp2p / nim-libp2p

libp2p implementation in Nim
https://vacp2p.github.io/nim-libp2p/docs/
MIT License
240 stars 52 forks source link

feat(gossipsub): support version 1.2.0 #1106

Closed diegomrsantos closed 2 weeks ago

diegomrsantos commented 1 month ago

closes https://github.com/vacp2p/nim-libp2p/issues/1102

kaiserd commented 3 weeks ago

addresses issue https://github.com/vacp2p/nim-libp2p/issues/1102

diegomrsantos commented 3 weeks ago

This PR depends on this being fixed https://github.com/vacp2p/nim-libp2p/issues/1115, if we want to send idontwant only to peers that support 1.2.

diegomrsantos commented 3 weeks ago

This will be moved to a new PR cause of https://github.com/vacp2p/nim-libp2p/issues/1115.

lchenut commented 3 weeks ago

I'm not an expert on GS by any means, but I'm expecting something like if GossipSubCodec_12 in g.codecs: # do something GS1.2 related. From what I understand, we just add the codecs (which needed to be done) but there's no difference between GossipSubCodec_10, GossipSubCodec_11 and GossipSubCodec_12.

diegomrsantos commented 3 weeks ago

I'm not an expert on GS by any means, but I'm expecting something like if GossipSubCodec_12 in g.codecs: # do something GS1.2 related. From what I understand, we just add the codecs (which needed to be done) but there's no difference between GossipSubCodec_10, GossipSubCodec_11 and GossipSubCodec_12.

I believe g.codecs are the versions supported by the current code, instead of the one negotiated with the peer - pubsubpeer.codec. Behaving like 1.2 - sending idontwant - will be implemented in a new PR as mentioned here: https://github.com/vacp2p/nim-libp2p/pull/1106#issuecomment-2149411500.

It seems that our current code can negotiate 1.0 but will still behave like 1.1, as there's no check on how the protocol should behave depending on the version negotiated with a remote peer.