Summary
Apologies, if this is hashed out somewhere else, but I couldn't find any discussion on this.
The pubsub spec says
The seqno field (optional) is a 64-bit big-endian uint that is a linearly increasing number that is unique among messages originating from each given peer
Right now the implementation in this repo uses a random number per message: https://github.com/libp2p/rust-libp2p/blob/master/protocols/gossipsub/src/lib.rs#L50
The Go implementation starts with the current nano timestamp, then increments from there: https://github.com/libp2p/go-libp2p-pubsub/blob/master/pubsub.go#L296
I don't believe the current go implementation relies on an increasing sequence number, but I could imagine an optimization where it does (e.g. instead of keeping a map of all message IDs seen, we only keep the highest ID seen and discard anything lower).
I'm guessing the reason to pick a random number is to not rely on the current time.
The risk of relying on the current time is if you reboot your node and start with a an earlier time, you may be reusing IDs. However, I'd counter that argument by saying many other things would break in this scenario (including any TLS encryption). In practice, it hasn't seemed to be a problem in the Go implementation.
Summary
Apologies, if this is hashed out somewhere else, but I couldn't find any discussion on this.
The pubsub spec says
Right now the implementation in this repo uses a random number per message: https://github.com/libp2p/rust-libp2p/blob/master/protocols/gossipsub/src/lib.rs#L50
The Go implementation starts with the current nano timestamp, then increments from there: https://github.com/libp2p/go-libp2p-pubsub/blob/master/pubsub.go#L296
I don't believe the current go implementation relies on an increasing sequence number, but I could imagine an optimization where it does (e.g. instead of keeping a map of all message IDs seen, we only keep the highest ID seen and discard anything lower).
I'm guessing the reason to pick a random number is to not rely on the current time.
The risk of relying on the current time is if you reboot your node and start with a an earlier time, you may be reusing IDs. However, I'd counter that argument by saying many other things would break in this scenario (including any TLS encryption). In practice, it hasn't seemed to be a problem in the Go implementation.