Implementing Store-and-Forward Messaging with Waku Relay Nodes

The Problem: Asynchronous Delivery in P2P Networks

In a pure gossip-based peer-to-peer (P2P) network, messages are transient. If a recipient is offline when a message is broadcast, that data is lost. For applications requiring reliable delivery—such as decentralized messaging or asynchronous notifications—relying on active peer presence is insufficient.

The solution is the Store-and-Forward pattern. By utilizing Waku Relay nodes, developers can ensure that messages persist for a defined duration, allowing offline peers to retrieve missed data upon reconnection.

Architectural Requirements

To implement asynchronous delivery, the system must satisfy three primary constraints:

• Persistence: A subset of nodes (Relays) must commit incoming messages to a local cache rather than just forwarding them.
• Topic Filtering: Nodes must be able to subscribe to specific subjects to avoid processing irrelevant network traffic.
• Payload Privacy: Since Relay nodes are untrusted infrastructure, the transport layer must not have access to the message content.

The Smallest Suitable Design

The most efficient implementation involves three roles: the Publisher, the Relay Node, and the Subscriber.

The Publisher encrypts the payload using a symmetric key shared with the Subscriber. The message is then sent to the Waku network with a specific topic header. The Relay node, acting as a temporary buffer, stores the message in its local database based on the topic and a Time-to-Live (TTL) value. When the Subscriber reconnects, it queries the Relay for all messages associated with its subscribed topic that were published after the Subscriber's last known timestamp.

Data and Trust Boundaries

The design establishes a strict boundary between Transport and Content:

Layer	Responsibility	Trust Level
Relay Node	Message caching, routing, and TTL enforcement	Untrusted (Zero-Knowledge)
Peer Node	Encryption, decryption, and topic management	Trusted (End-to-End)

Because the Relay only sees the encrypted blob and the topic ID, it cannot modify or read the message. Trust is shifted from the infrastructure to the cryptographic keys held by the endpoints.

Operational Implementation

To verify the store-and-forward mechanism, you must deploy a node capable of acting as a relay. Using the Waku SDK, the logic follows this flow:

1. Publisher Configuration

Run this logic on the sending peer. Ensure the payload is encrypted before calling the send method.

// Example conceptual logic for sending a persistent message
const message = encryptPayload(plaintext, sharedSecret);
const topic = "chat-room-123";

// Send to the network with a request for relay storage
await wakuNode.send(topic, message, { persist: true });

2. Subscriber Retrieval

The subscriber does not just listen for live gossip; it must explicitly poll for missed messages upon startup.

// Run on the receiving peer after reconnection
const lastSeenTimestamp = localStorage.getItem('last_sync');
const missedMessages = await wakuNode.getMessagesFromRelay("chat-room-123", lastSeenTimestamp);

missedMessages.forEach(msg => {
  const decrypted = decryptPayload(msg.payload, sharedSecret);
  processMessage(decrypted);
});

Verification Steps

1. Baseline: Start a Relay node and a Publisher.
2. Offline Test: Shut down the Subscriber node.
3. Persistence Test: Use the Publisher to send a message to a specific topic.
4. Recovery Test: Restart the Subscriber and execute the getMessagesFromRelay call.
5. Privacy Check: Use a packet analyzer (e.g., Wireshark) on the Relay node to confirm that the payload field contains ciphertext, not plaintext.

Failure Modes and Constraints

This architecture is subject to specific operational limits:

• Storage Exhaustion: Relay nodes have finite disk space. If a topic receives a high volume of messages, the Relay may drop the oldest messages before the Subscriber reconnects.
• Network Partitioning: If a cluster of nodes becomes isolated from the Relays, they can still gossip among themselves, but store-and-forward capabilities will be unavailable until the partition heals.
• Sybil Pressure: While rate-limiting prevents basic spam, a coordinated attack of fake nodes can attempt to fill Relay caches with junk data to evict legitimate messages.

Design Evolution

The current design should be modified if the following conditions arise:

• High-Frequency Data: If the application requires streaming high-bandwidth data, the store-and-forward model should be replaced with a Pointer-based system, where the Relay stores a URI to a decentralized storage provider (like IPFS) rather than the message itself.
• Strict Ordering: If absolute message ordering is required, a sequence number must be added to the encrypted payload, as P2P gossip does not guarantee delivery order.