6a954bdec0
Squash of 13 commits from feat/mix-dos-protection-libp2p-v2.0.0 onto the logos_delivery/ folder-restructure base from #3935 (build-messaging-folder). Original commit history (squashed): - d8e6dcef feat(mix): integrate mix protocol with extended kademlia + RLN spam protection - fb72f18d refactor(mix): split DoS-protection self-registration into background retry - d8bbef0c feat(mix): bump libp2p stack to v2.0.0 + adopt stateless RLN spam protection - 2f24448a fix(tests): use HmacDrbgContext.new() instead of crypto.newRng() - 5a21455c fix(ci): regen nimble.lock for v2.0.0 + disambiguate rng in wakucore - 03ef02a2 fix(tests): wrap HmacDrbgContext via newBearSslRng for libp2p v2.0.0 - 167ab1df fix(nix): regenerate deps.nix from updated nimble.lock - 97a27222 fix(tests): wrap or pass Rng correctly for 3-arg PrivateKey.random - 5561fcb5 fix(tests): replace removed newStandardSwitch with SwitchBuilder - ba39ee4a fix(tests): libp2p v2.0.0 API migrations across test suite - 328e11df fix: gitignore test binaries + remove accidentally-committed binary - cc712444 fix(tests): more v2.0.0 API migrations (rng template, PeerId.random, etc.) - 412d97a9 fix(tests): unblock CI — nph, excise orphan waku_noise, complete v2.0.0 Rng migration Conflict resolutions (#3935 → ours): - 11 import-path migrations: waku/X → logos_delivery/waku/X - waku_node/waku_node/relay.nim: dropped our `registerRelayHandler` proc (relocated to subscription_manager.nim by #3935; see cascade fix below) - factory/builder.nim: combined both sides' new imports (net_config + waku_switch) - factory/conf_builder/mix_conf_builder.nim: libp2p_mix package (not libp2p/protocols/mix) - waku_mix/protocol.nim: combined paths + our mix_rln_spam_protection/relay/nimchronos imports - 3 test files: dropped noise_utils import (replicates noise excision from original PR) - 2 UA file moves: option_shims.nim and waku_mix_coordination.nim added at new paths Cascade fixes (#3935 lost our work, restored): - subscription_manager.nim: added `mixHandler` to #3935's `registerRelayHandler`, and added `waku_mix` to its imports. Without this, mix messages were silently dropped from the relay handler chain. - config.nims: option_shims auto-import path migrated to logos_delivery/... Validation: - nph check on all 82 staged .nim files: clean (0 reformats needed) - wakunode2 build: exit 0, 38 MB binary - (sim PASS confirmed in earlier identical-state run: 5/5 mix init, 5 RLN proofs gen/verify, 0 errors) Backup tag at original tip: backup/3931-pre-3935-rebase (412d97a9).
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.