Solving the Offline Recipient Problem with Waku Store Nodes

The Gap in Real-Time Gossip

In a standard gossip-based network, messages are ephemerals. If a node is offline when a message is broadcast to a topic, that data is gone. For decentralized applications (dApps) like encrypted messengers or notification systems, this creates a critical failure: users cannot receive messages sent while their device was asleep or disconnected from the network.

Waku solves this through the Store mechanism. Instead of relying solely on real-time propagation, Waku allows specific nodes to act as temporary buffers, holding messages for a defined period so that offline peers can catch up upon reconnection.

How Store Nodes Decouple Time from Delivery

In a typical Waku setup, nodes communicate via topics. When a message is published to a topic, it spreads from peer to peer. A Store node is a specialized peer that doesn’t just forward the message, but persists it in a local database.

This architecture shifts the communication model from purely synchronous (push) to a hybrid model. The sender pushes the message to the network, and the recipient can later pull missed messages from a Store node using a time-range query. This prevents the need for a centralized database while maintaining the censorship resistance of a P2P network.

Implementing a Store Query

To retrieve missed messages, a node must query a Store node for all messages on a specific topic within a specific time window. This is typically handled via the getStoreMessages request.

Example Configuration and Logic

Assuming you are using the Waku JavaScript SDK (v0.x), the logic for retrieving missed messages follows this pattern:

// Run this on the client node that was previously offline
const topic = "my-app-notifications";
const startTime = Date.now() - (1000 * 60 * 60); // 1 hour ago
const endTime = Date.now();

// Request messages from the network's store nodes
const messages = await waku.getStoreMessages({
  topic: topic,
  startTime: startTime,
  endTime: endTime
});

console.log(`Retrieved ${messages.length} missed messages.`);

Execution Details:

• Permissions: No special permissions are required to query public store nodes, though some nodes may require a small payment or a specific API key in production environments to prevent abuse.
• Placeholders: Replace "my-app-notifications" with your specific application topic.
• Expected Result: An array of message objects containing the payload and the timestamp of when they were stored.

Trade-offs: TTL and Storage Limits

The Store mechanism is not a permanent archive. It is governed by a TTL (Time to Live). If a message’s TTL is set to 24 hours, and a user stays offline for 25 hours, the message is purged from all Store nodes and is permanently lost.

Furthermore, Store nodes are susceptible to resource exhaustion. To prevent Denial-of-Service (DoS) attacks, most Store nodes implement strict limits on:

• Message Volume: The maximum number of messages stored per topic.
• Query Frequency: Rate limiting on how often a single peer can request historical data.
• Payload Size: Maximum bytes per message to prevent memory bloating.

Verifying Store Functionality

To verify that your implementation is correctly utilizing Store nodes rather than just real-time gossip, perform the following test:

1. Start Node A and Node B. Subscribe both to a test topic.
2. Shut down Node B (simulate going offline).
3. Use Node A to send a message to the topic.
4. Wait a few seconds for the message to propagate to a Store node.
5. Restart Node B and execute a getStoreMessages call for the time window covering the period Node B was offline.
6. If the message is returned, the Store mechanism is functioning. If the message only arrives when Node A sends a new message, you are relying on real-time gossip only.