Control Messages

[D4nte]

In the waku-relay specs, it is stated that it does not support the gossipsub control messages.

However, I can see reference to them in the nim-waku logs, e.g.:

TRC 2021-03-16 13:47:50.058+11:00 sending pubsub message to peer             topics="libp2p pubsub" tid=3258658 file=pubsub.nim:125 peer=Qme*gCasUM msg="(subscriptions: @[(subscribe: true, topic: \"/waku/2/default-waku/proto\")], messages: @[], control: (ihave: @[], iwant: @[], graft: @[], prune: @[]))"

Can you please clarify the current status/stance?

[D4nte]

Also, the gossipsub specs read as follow:

In order to do so, gossipsub peers form an overlay mesh, in which each peer forwards messages to a subset of its peers, rather than all known peers in a topic. The mesh is constructed by peers as they join a pubsub topic, and it is maintained over time by the exchange of control messages.

The mesh mechanism is core to gossipsub message propagation. As waku does not support control messages, it cannot maintain a mesh. What logic does waku follows in order to determine to which peers messages should be sent?

[oskarth]

Sorry for the late reply, missed this one somehow. I think this sentence "WakuRelay does not currently use the ControlMessage defined in GossipSub. However, later versions will add likely add this capability." is misleading, and IIRC it refers to a previous idea where store/filter functionality would be provided for with 1-1 req-resp messages.

Adding to https://github.com/vacp2p/specs/issues/266