Waku Relay best-effort delivery limits for alert deduplication

Assumptions and facts for idempotent alerting on Waku

Duplicate delivery: Waku Relay (GossipSub v1.1) is best‑effort; mesh redundancy and peer reconnections can cause the same message to be delivered multiple times. No protocol‑level duplicate suppression or sequence numbers exist.

Message ordering: Relay hops do not preserve order; timestamps are sender‑generated and untrusted. For alert ordering you must embed a monotonic sequence or logical clock in the payload.

Application‑level deduplication: Use a stable identifier (e.g., hash of payload + timestamp + nonce + sender public key) and keep a local seen‑set with a TTL longer than the expected propagation latency (typically <30 s in a stable mesh).

Store retention impact: Waku Store retention, pruning policy and capacity are set by each node operator (via --store‑capacity, --store‑retention, --prune‑policy). There is no network‑wide minimum, so the availability of alert history for a given content topic is probabilistic and varies per queried node.

Content‑topic and payload‑filter granularity: Content topics are arbitrary UTF‑8 strings; the protocol matches the full string exactly (no wildcards or regex). You can make topics as narrow as needed (e.g., /myapp/1/alerts/critical). Payload filters are optional extensions (RLN proof, bloom filters) but they do not impose volume caps; RLN provides per‑identity rate limiting, not per‑topic limits. The default GossipSub payload size limit is 1 MiB, though operators may lower it.

Steps to bound inbound alert volume and build idempotent alerts

1. Choose a narrow content topic per alert type/severity (e.g., /myapp/1/alerts/warning).
2. If the network enforces RLN, join the RLN group to limit message rate per identity.
3. Before forwarding an alert to users, validate the payload locally (JSON schema, severity thresholds) and discard unwanted messages.
4. Generate a deduplication key: SHA256(payload ∥ timestamp ∥ nonce ∥ senderPubKey) and keep it in a local seen‑set with TTL > 30 s.
5. If alert ordering matters, include a monotonically increasing sequence number or logical clock in the payload and sort locally after deduplication.
6. When you need historic alerts, query Waku Store on multiple nodes; compare results to fill gaps. Note that history is only available as long as each node’s retention policy has not pruned the messages.

Missing diagnostic detail: To determine whether Store‑based history will be usable for your use case, you need to know the configured store retention time and pruning policy on the nodes you plan to query. If retention is shorter than the alert window you require, you cannot rely on Store for history and must depend on local buffering or alternative storage.