Waku Store v2.0.0: ContentFilter vs Topic precedence unresolved

Short answer: the spec is silent, so code defensively

None of the three behaviors you describe is mandated by the Waku Store v2.0.0 protocol specification. The reference client's behavior (contentFilter wins, maxAge=0 means no limit, empty list on no match) is the most reasonable reading, but it is a convention, not a contract. If your client must interoperate with arbitrary servers, you cannot rely on any of the three. The practical resolution is to make your requests unambiguous and your response handling tolerant.

1. contentFilter vs. legacy topic precedence

Likely behavior: implementations that understand contentFilter treat it as authoritative and ignore the legacy topic field when both are present. Confirmed: the specification does not require this, so a server is free to do the opposite, merge the two, or reject the request.

The safe pattern is to never send both. If you need granular filtering, send only contentFilter; if you must support pre‑v2.0.0 servers, send only topic and filter content topics client‑side after retrieval. Sending both fields is the one case where behavior is genuinely unpredictable across the network.

To verify what a specific server does, run a scoped test: publish two messages on the same pubsub topic but different content topics, then query with a topic that matches both and a contentFilter that matches only one. If you get one message back, contentFilter won; two messages means topic won.

2. maxAge = 0: no limit or immediate expiration?

The documented intent is that maxAge = 0 means "no age limit" — a sentinel value, not a duration of zero seconds. Implementations that treat it as immediate expiration are applying the numeric comparison naively (age > maxAge is always true when maxAge is 0) instead of special‑casing the sentinel.

Until this is clarified in the spec, avoid relying on the sentinel at all. If you want "no limit", omit maxAge rather than setting it to 0 — omission is unambiguous in every implementation, whereas 0 is not. If you control the server code, check whether the zero case is branched before the age comparison.

Verification is cheap: publish a message, wait a known interval (say, 60 seconds), then query with maxAge = 0. If the message is returned, the server implements the sentinel semantics; if the result is empty, it implements immediate expiration.

3. Empty result set: empty array or 404?

The protocol does not mandate either. Architecturally, an empty array is the better behavior — a successful query that matched nothing is not an error, and a 404 conflates "no data" with "bad endpoint". But since both exist in the wild, your client must accept both:

• Treat HTTP 200 with an empty list and HTTP 404 as equivalent "no messages" outcomes.
• Do not retry on 404 assuming a transient failure — you may hammer a server that is simply reporting an empty result.
• Log which behavior each peer exhibits so you can detect implementation drift after upgrades.

Bottom line

For all three ambiguities the same strategy applies: constrain what you send (one filter field only, omit maxAge instead of zeroing it) and widen what you accept (empty array or 404). If you need guaranteed semantics, pin and test against a specific server implementation rather than coding to the spec's intent. These are draft‑level observations based on documented protocol gaps — confirm against the current specification text and your target implementation's source before shipping interop‑critical code.