90fa5fa91f
* remove --mode from the CLI * move WakuMode to the messaging layer * expose store backend (db url, max connections) and a remote store node on the messaging surface * wakunode2 with no flags now runs as a full service node (store still opt-in) * add rateLimitMessagesPerEpoch * channel rate-limiting auto-enables if epochPeriodSec or messagesPerEpoch is set * fix JSON conf parser to be generic (works over all config types) * messaging config = mode + preset + messagingOverrides + channelsOverrides * add full messaging plus selective kernel config options to MessagingClientConf * mode (Core/Edge) expands to kernel protocol flags in the messaging layer * create_node parses the messaging config, drops the flat WakuNodeConf JSON entrypoint * wire channelsOverrides (segmentation/SDS/rate-limit) into channel creation * fix liblogosdelivery.h comments and README for the new config shape * messaging conf tests: switch names, reject-unknown, set-twice, field->kernel * add kernel log-level, log-format, nodekey to the messaging surface * Port 0 (ephemeral) default for messaging entry points * KernelConf alias for WakuNodeConf * rewrite the FFI examples to the new config shape * C/C++ examples use preset status.prod * drop operator-only confs from the examples * remove duplicate tests & misc test fixes * Delete p2pReliability from Kernel (Waku) resolver and config (keep preset definition) * Delete NodeConfig API (deprecation completed by p2pReliability removal from kernel) * Rename test_messaging_conf.nim to test_conf.nim (tests Logos Delivery config in general) * Rename messaging_conf_json.nim to logos_delivery_conf_json.nim * Add logos_delivery_conf.nim (defines LogosDeliveryConf aggregate) * misc docs/comments cleanups
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.