Reducing Bandwidth Waste with Waku v2 Topic Filtering

The Noise Problem in Decentralized Pub/Sub

In a global peer-to-peer network, the simplest way to ensure a message reaches its destination is to broadcast it to everyone. However, this "gossip" approach creates a massive bandwidth tax. If a node only cares about a specific data stream—such as a specific chat room or a price feed—receiving every single packet flowing through the network is inefficient and costly, especially for mobile clients.

Waku v2 solves this by moving the filtering logic from the end-user's device to the relay nodes. Instead of receiving everything and discarding the irrelevant bits, subscribers tell the network exactly what they want via topic hashes, ensuring only matching payloads are forwarded.

How Topic-Based Routing Works

Waku v2 uses a combination of keccak256 hashing and the libp2p overlay to manage subscriptions. When a node wants to listen for specific data, it doesn't send the raw topic name; it advertises a hash of that topic.

• The Subscription: The subscriber registers their interest in a topic hash with the relay nodes they are connected to.
• The Relay: Relay nodes maintain a mapping of which connected peers are interested in which hashes.
• The Filter: When a message arrives at a relay, the node checks the message's topic hash against its list of subscribers. If there is a match, the payload is forwarded; otherwise, it is dropped for that specific peer.

Crucially, this process preserves privacy. Because the relay only sees the hash and not the plaintext topic or the encrypted message content, the network infrastructure remains agnostic to the actual data being exchanged.

Implementing a Filtered Subscription

To implement this, you typically use a Waku SDK (Go or JS). The following logic represents the configuration required to ensure a node only receives messages for a specific "channel."

// Example using a conceptual Waku JS client
const waku = new WakuClient();

// 1. Define a unique topic string
const topicString = "my-secure-app-channel-01";

// 2. Generate the keccak256 hash (handled internally by most SDKs)
// The network uses this hash to route the message
await waku.subscribe(topicString, (message) => {
  console.log("Received filtered message:", message.payload);
});

// 3. Publish a message to that specific topic
await waku.publish(topicString, "Hello, filtered world!");

Execution Context: These commands are run within your application logic. Ensure your node is connected to a Waku v2 relay. If you are running a self-hosted relay, ensure the relay configuration allows for topic-based forwarding, as some restrictive configurations may default to dropping all non-broadcast traffic.

Trade-offs: False Positives and Relay Trust

Topic filtering is not a perfect surgical tool; it relies on Bloom-filter-inspired selection at the relay level. This introduces a specific technical trade-off: false positives.

Because of how these filters are structured, a relay might occasionally forward a message that doesn't actually match the subscriber's topic. The client-side SDK handles this by performing a final check on the hash before passing the message to the application layer. While this prevents the app from receiving wrong data, it means the bandwidth saving isn't always 100%.

Additionally, the efficiency of this system depends entirely on the relay node. If a relay is misconfigured or overloaded, it may fail to index subscriptions correctly, leading to missed messages (false negatives) or a fallback to broadcasting everything, which spikes bandwidth usage.

Verifying Filter Efficiency

To verify that filtering is actually working and you aren't just receiving a global stream, follow this diagnostic path:

1. Start two nodes: one Subscriber and one Publisher.
2. Subscribe the Subscriber node to Topic_A.
3. Publish a message to Topic_B.
4. Check the Subscriber's network logs. If the payload for Topic_B never reaches the node's network interface, the relay is filtering correctly. If the payload arrives but is discarded by the SDK, the relay is failing to filter, and you are wasting bandwidth.

Warning: Ensure you are using Waku v2. Waku v1 handled topic distribution differently, and attempting to use v2-style filtering on v1 nodes will result in messages not being delivered at all.