Combines five dep-and-build changes that all flow from the libp2p v2.0.0
upgrade and the move to the extracted libp2p_mix / mix-rln plugin stack:
waku.nimble:
* libp2p: ff8d51857 -> c43199378 (release/v2.0.0 tip; sha-pinned until
vacp2p cuts a v2.0.0 tag).
* Drop the bare `zlib < 0.2` cap — no longer needed by the upgraded
libp2p.
* websock: bare ">= 0.4.0" — replaces the d4cd68b URL+SHA workaround
that pinned through a libp2p commit-specific websock SHA.
* nim-json-rpc: switch to chaitanyaprem/nim-json-rpc#f05fad25 — relaxes
websock cap to allow >=0.4.0. TODO: revert to status-im/nim-json-rpc
once status-im/nim-json-rpc#277 merges and a tag is cut.
* lsquic: bare ">= 0.4.1" (drops URL form).
* Add mix-rln-spam-protection-plugin pin (23b278b4) and nim-libp2p-mix
pin (50c4ab4f — PR #14 HEAD); the plugin pins the same libp2p_mix
SHA so the diamond dep collapses to a single source.
waku/factory/waku.nim:
* Explicit HPService.setup(switch) / AutonatService.setup(switch)
calls. libp2p v2.0.0's Service lifecycle refactor (libp2p#2462)
removed switch.start's auto-setup loop, so any caller that assigns
directly to switch.services (we do) is responsible for calling
setup() themselves. Without it, AutonatService.addressMapper stays
nil and peerInfo.expandAddrs SIGSEGVs during start(). Wrapped in
try/except for ServiceSetupError so a setup failure surfaces as a
logged error rather than a crash.
Build / scripts:
* scripts/build_rln_mix.sh removed and Makefile simplified — librln
is now a single shared archive built from zerokit's `stateless`
features (no separate librln_mix archive).
* simulations/mixnet/build_setup.sh + setup_credentials.nim updated
to use librln_v2.0.2.a directly and run RLN keystore setup before
nodes start.
Validated:
* Cold local-cache nimble setup --localdeps -y.
* wakunode2 and chat2mix link cleanly.
* Mixnet roundtrip sim: [PASS] bob received message from alice.
* RLN proof generation + verification on every in-path mix node:
5 gen_called == 5 verified, 0 SPAM_PROOF_* errors.
Examples
Compile
Make all examples.
make example2
Waku API
Uses the simplified Waku API to create and start a node, you need an RPC endpoint for Linea Sepolia for RLN:
./build/waku_api --ethRpcEndpoint=https://linea-sepolia.infura.io/v3/<your key>
If you can't be bothered but still want to see some action, just run the binary and it will use a non-RLN network:
./build/waku_api
## publisher/subscriber
Within examples/ you can find a publisher and a subscriber. The first one publishes messages to the default pubsub topic on a given content topic, and the second one runs forever listening to that pubsub topic and printing the content it receives.
Some notes:
- These examples are meant to work even if you are behind a firewall and you can't be discovered by discv5.
- You only need to provide a reachable bootstrap peer (see our fleets)
- The examples are meant to work out of the box.
- Note that both services wait for some time until a given minimum amount of connections are reached. This is to ensure messages are gossiped.
Run:
Wait until the subscriber is ready.
./build/subscriber
And run a publisher
./build/publisher
See how the subscriber received the messages published by the publisher. Feel free to experiment from different machines in different locations.
resource-restricted publisher/subscriber (lightpush/filter)
To illustrate publishing and receiving messages on a resource-restricted client,
examples/v2 also provides a lightpush_publisher and a filter_subscriber.
The lightpush_publisher continually publishes messages via a lightpush service node
to the default pubsub topic on a given content topic.
The filter_subscriber subscribes via a filter service node
to the same pubsub and content topic.
It runs forever, maintaining this subscription
and printing the content it receives.
Run Start the filter subscriber.
./build/filter_subscriber
And run a lightpush publisher
./build/lightpush_publisher
See how the filter subscriber receives messages published by the lightpush publisher.
Neither the publisher nor the subscriber participates in relay,
but instead make use of service nodes to save resources.
Feel free to experiment from different machines in different locations.