Waku v2: Topic interest behaviour

[oskarth]

Problem

From vacp2p/research#40:

One difference that is worth noting is that the app topics would not be the same as Waku topics. Why? In Waku we currently don't use topics for routing between full nodes, but only for edge/light nodes in the form of topic interest. In FloodSub, these topics are used for routing.

Why can't we use Waku topics for routing directly? PubSub over libp2p isn't built for rare and ephemeral topics, and nodes have to explicitly subscribe to a topic. See topic sharding section for more on this.

[...]
4. Topic interest behavior

While we target full node traffic here, we want to make sure we maintain the existing bandwidth requirements for light nodes that Waku v1 addressed (https://vac.dev/fixing-whisper-with-waku). This means implementing topic-interest in the form of Waku topics. Note that this would be separate from app topics notes above.

In PubSub terms, this would be a form of content based filtering, as opposed to topic based filtering.

Acceptance criteria

Ensure there is optional support for content based routing for edge nodes.

Possible Solution

Currently in Waku v2 raw spec https://specs.vac.dev/specs/waku/waku-v2.html, we have a message type with a data field in it. Since the data field is likely to be encrypted, and light nodes need to query a specific topic, this could be a field in the Message type.

To disambiguate from pubsub topics, which are used for routing, a suggestion is to call this field contentTopic. This also means consumers such as Status would be able to continue mapping Waku v1 topics to contentTopic.

---

This could also be called something like contentFilter

[oskarth]

This issue needs to be amend with another one to make it clear how you express topic interest to another node.

[oskarth]

#160 here is that issue

[oskarth]

I believe this is solved.