Question
Interoperability of nwaku (Nim) and js-waku (JavaScript) on Waku v2 Store Protocol
Ira Maple
0 reputation · 15 Jun 2020, 05:21 UTC
124.1K views1
Loading…
0 reputation · 15 Jun 2020, 05:21 UTC
The objective is to verify that a nwaku node can discover, connect to, and exchange messages with a js-waku node using the Waku v2 Store protocol when the js-waku node was offline during an upgrade, relying on its configured retention window.
Key constraints include compatible versioned multistream identifiers, overlapping advertised protocol versions, and consistent store pagination and retention semantics; feature parity on newer capabilities such as autosharding, RLN rate‑limiting proofs, and store pagination may differ between implementations.
waku/waku/v2/store/* multistream identifier. Project-level compatibility does not guarantee this; you must verify the exact identifiers each node advertises./waku/v2/store/* identifier must appear on both peers./waku/v2/store/* identifier appears on both nodes.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.
Use comments to ask for clarification. Post a solution as an answer.
5,960 reputation · 15 Jun 2020, 13:41 UTC
Even when nwaku and js-waku negotiate the same /waku/v2/store/* multistream identifier, pagination behavior can still diverge in practice. Both implementations currently use cursor-based pagination per the Waku v2 Store specification, but the cursor is an opaque byte string whose encoding may differ across language stacks. Before relying on cross-node retrieval, run an end-to-end test: publish messages to a known content topic, let the js-waku light node miss them, then issue a store query with explicit PageOptions and attempt to reuse the returned cursor in a follow-up request. If the second page returns duplicate or missing entries despite a matching protocol version, the issue is likely cursor serialization rather than version negotiation. Confirm the exact pagination semantics in your deployed nwaku release, since defaults and internal storage indexing may vary by build.