Waku v2 store node retention boundaries and offline delivery guarantees

Answer

Waku v2 store nodes do not provide a protocol-wide mailbox guarantee. Retention is operator-configured, message expiry is optional, and delivery to an offline recipient is best-effort. If no store node is reachable while the recipient is disconnected, the message may be dropped without notification, and the protocol defines no retry or fallback path.

Confirmed facts

• A Waku v2 store node is optional and retains store-and-forward messages for a period set by the node operator.
• The protocol does not mandate a minimum or maximum retention window.
• A message may carry an optional expiry timestamp; once that time passes, the node must drop the message even if the recipient has not reconnected.
• If no expiry is set, the node's own retention policy alone controls message lifetime.
• The protocol specifies no acknowledgment, retry, backoff, or cross-node failover when a store node is unreachable or drops a message under operator policy.

Likely explanation

Store-and-forward in Waku v2 is a routing convenience, not a durable message queue. Operators can choose short windows, disable retention, or restart nodes, so a published message can vanish before the recipient comes back online. Applications should treat a store node as an unreliable intermediary: it may improve delivery odds, but it cannot be modeled as a guaranteed mailbox without an application-layer acknowledgment and retry mechanism.

Steps for this case

1. Check the retention window and expiry enforcement rules on every store node your publisher can reach.
2. If your application can tolerate lost messages, use store-and-forward as-is and treat non-delivery as normal.
3. If offline delivery must be reliable, implement an acknowledgment on a dedicated reply topic and republish unacknowledged messages after a backoff interval.
4. Set an explicit expiry on messages so stale messages are removed rather than redelivered indefinitely.

Missing diagnostic detail

Do you require guaranteed delivery to offline recipients, or is best-effort acceptable? This determines whether a custom acknowledgment layer is required or optional.

Verification

Inspect the store node configuration to confirm the configured retention period and whether message expiry is enforced. Publish a test message with a known expiry to a content topic, keep the recipient offline past the retention window, then reconnect and confirm whether the message arrives. Repeat against each store node, because each operator applies its own policy. Assumption: behavior follows the Waku v2 spec; actual retention depends on the operator's deployed version and config, which must be verified against current node documentation before changing production behavior.