Configure Waku Relay for Store‑and‑Forward Messaging

Desired outcome

Set up a Waku Relay node that stores incoming messages and forwards them when offline peers reconnect, guaranteeing delivery after a temporary network loss.

Prerequisites

• NimWaku (or GoWaku) version 0.30 or newer installed and available in $PATH.
• A libp2p‑enabled environment with UDP/TCP connectivity.
• Open inbound ports: 30303 for discv5 discovery and 63421 for Waku Relay traffic (adjust if you use a different port).
• Persistent storage with sufficient free space (SSD recommended) – e.g., a directory /var/lib/waku/store that the node user can write to.
• Basic familiarity with the wakucli command‑line tool.

Procedure

1. Create the storage directory and ensure the node process can write to it:

   sudo mkdir -p /var/lib/waku/store
   sudo chown $(whoami):$(whoami) /var/lib/waku/store

2. Start the relay with store‑and‑forward enabled. Adjust the listen address if you need a specific interface:

   nimwaku node \\n  --listen-address /ip4/0.0.0.0/tcp/30303 \\n  --discv5 \\n  --store \\n  --message-retention 72h \\n  --datastore-path /var/lib/waku/store \\n  --log-level info

3. Verify the node is running and has peers:

   wakucli peer list

   You should see one or more peer IDs.
4. Publish a test message on a topic of your choice:

   wakucli publish --topic /my-app/1.0/proto --payload \"hello store\"

5. Simulate an offline subscriber: stop a subscriber process or disconnect its network interface.
6. Wait at least 30 seconds (or longer than your network latency) to let the relay hold the message.
7. Restore the subscriber’s connection or restart it and subscribe to the same topic:

   wakucli subscribe --topic /my-app/1.0/proto

   Check the subscriber’s output for the previously published payload.

Expected checks

• Relay log lines containing Stored message when a publish is received and later Forwarded to peer when the subscriber reconnects.
• Subscriber log shows Received message with the original payload after reconnection.
• The directory /var/lib/waku/store grows as messages are stored; after the retention period (72 h in the example) old entries are removed, keeping size roughly stable.
• Disk usage stays below the capacity you provisioned; monitor with df -h or a monitoring tool.

Recovery options

• If the relay process crashes, restart it with the same --datastore-path; the node will reload the persisted store and continue forwarding any retained messages.
• If the store directory becomes corrupted (e.g., I/O errors), stop the node, remove or rename the directory, then start the relay again with an empty store. Messages that were not yet forwarded will be lost, but new incoming messages will be stored normally.
• Set an alert on storage utilization (e.g., >80 % of the allocated disk) to avoid out‑of‑space conditions that would halt the store.