Waku Relay best-effort delivery limits for alert deduplication

Designing useful alerts over Waku requires bounding inbound message volume while avoiding notification noise. The core protocol provides topic-based pub/sub via Relay, Filter and Light Push with best-effort delivery and no ordering or delivery guarantees specified at protocol level. Application-level alert throttling, notification deduplication and user-facing noise controls are not defined by the protocol.

Noise reduction is documented as narrowing subscriptions with content topics and optional payload filters. Waku Store enables historical retrieval, but retention duration, pruning policy and storage limits are node-operator controlled and not standardized across the network.

What assumptions can be made about duplicate delivery and message ordering when building idempotent alerting on Relay, Filter and Light Push? What is the documented impact of operator-defined Store retention on availability of alert history? What documented limits exist for content topic and payload filter granularity to bound inbound volume?