Interoperability of nwaku (Nim) and js-waku (JavaScript) on Waku v2 Store Protocol

Direct Answers

1. Overlapping store protocol versions: Overlap exists only when both installed releases advertise an identical /waku/v2/store/* multistream identifier. Project-level compatibility does not guarantee this; you must verify the exact identifiers each node advertises.
2. Retrieval when js-waku's retention window exceeds nwaku's history: No. The nwaku node's retention window and eviction policy bound what can be retrieved. A longer configured window on the js-waku light node does not extend the full node's stored history.
3. Documented delivery guarantee when only non-store extensions differ: No such guarantee exists. Waku v2 Store is a query/retrieval protocol, not a delivery guarantee. Matching non-store protocols (e.g., relay) does not ensure store interoperability; the store multistream identifier must match.

Confirmed Facts vs. Likely Explanations

Confirmed

• Store sessions are negotiated via libp2p multistream identifiers; at least one identical /waku/v2/store/* identifier must appear on both peers.
• A js-waku light node pulls missed messages from a connected store/full node; it cannot retrieve messages the peer has evicted or never stored.
• Waku v2 Store provides stored-message query/retrieval, not a delivery guarantee.

Likely (based on current architecture)

• Overlapping store versions exist only when the specific releases in use advertise the same store identifier.
• When js-waku's configured retention window is longer than nwaku's stored history, nwaku's eviction time bounds retrieval.
• Non-store extension version differences should not break store queries if the store identifier matches, but no cross-version delivery guarantee is documented.

Verification Steps for Your Case

1. Print exact nwaku and js-waku versions and their advertised libp2p protocols. Verify at least one identical /waku/v2/store/* identifier appears on both nodes.
2. Configure nwaku as a full/store node with retention covering the full js-waku offline upgrade interval. Enable store, restart if required.
3. Reconnect the js-waku light node and issue a store query for the missed content topic and time range using pagination.
4. Compare returned messages against the expected missed interval. If incomplete, inspect nwaku store eviction/query logs and js-waku request filters and cursors before concluding protocol failure.

One Missing Diagnostic That Changes the Recommendation

Provide the exact nwaku and js-waku release versions plus each node's advertised store protocol identifiers (e.g., /waku/v2/store/1.0.0, /waku/v2/store/1.1.0). Without these, version overlap and retention behavior cannot be confirmed.

Cautions

• Relay protocol compatibility does not imply Store protocol compatibility; negotiate and verify store identifiers separately.
• A longer retention window on js-waku does not extend nwaku's stored history; empty results may reflect eviction, content-topic mismatch, or cursor/pagination handling.
• Do not rely on autosharding, RLN rate-limiting, or newer store features unless both releases advertise and implement them; parity may differ.