* chore: drop rate-limit stage from reliable channel send pipeline Collapses the outgoing pipeline to `segmentation -> sds -> encryption -> dispatch` by folding the encrypt-and-dispatch tail of `onReadyToSend` directly into `send()`. Removes the `RateLimitManager` field, its constructor param, the `ReadyToSendEvent` listener, and the `awaitingDispatch` accounting that only existed to bridge the event-bus hop between `send()` and `onReadyToSend`. The `rate_limit_manager.nim` module itself is untouched — it will be relocated to the messaging layer (co-located with RLN) in a follow-up commit, where per-epoch admission actually belongs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore: relocate RateLimitManager to messaging layer Moves rate_limit_manager.nim from `logos_delivery/channels/` to `logos_delivery/messaging/rate_limit_manager/` — the correct owner now that admission sits alongside RLN in the messaging layer instead of being fanned out to per-channel event listeners. The API surface changes: - `enqueueToSend` + `ReadyToSendEvent` (broker-based fan-out to a ReliableChannel listener) is replaced by `admit(msg): Future[Result[ void, RateLimitError]]`. Callers now branch directly on the result instead of subscribing to an event. - `channelId`, `SdsChannelID` and the SDS import are dropped — the messaging layer has no notion of channels; SDS was a channels-layer concern that only survived on this type because of the old broker fan-out. - `brokerCtx` is dropped for the same reason. Epoch config (`epochPeriodSec`), the wall-clock `currentEpochStart`, `queue`, `dequeueReady`, and `resetEpoch` are preserved exactly as the original owner designed them — this refactor is intentionally scoped to the API surface, not the epoch mechanism. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat: meter SendService transmissions through RateLimitManager Wires the relocated RateLimitManager into the messaging layer at the transmission stage rather than the API entry point: - MessagingClientConf gains a rateLimit: RateLimitConfig field (defaulting to DefaultEpochPeriodSec / DefaultMessagesPerEpoch), and MessagingClient.new hands the constructed manager to SendService. - SendService consults admit() before the first transmission of a task, both in send() and in the retry loop. Re-publishes of an already-propagated message (firstPropagatedTime set) skip admission: they resend the same bytes, which reuse the same RLN proof/nullifier and consume no fresh epoch slot. - An over-budget task parks in the task cache as NextRoundRetry; the service loop re-admits it as the epoch budget frees up. The skeleton admit() is a pass-through, so behaviour is unchanged today. Gating transmissions instead of MessagingClient.send keeps SDS repair rebroadcasts free of API-entry rejection (SDS decides that a repair is needed; the transmission scheduler decides when it fits the budget) while every wire transmission still draws from one node-wide budget -- which network-side RLN enforcement applies to repairs regardless of any local bypass. It is also where RLN proof attachment must happen, since proofs bind to the epoch current at transmission time. Adds tests/messaging/test_rate_limit_manager.nim covering the current disabled + enabled pass-through behaviour, wired into all_tests_waku.nim. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix: make MessagingClientConf.rateLimit reachable, warn on dead channel knobs Addresses two review findings on the move PR: - `rateLimit` was a plain `RateLimitConfig`, but `merge` only copies `Opt` fields (`when oField is Opt`), so every override path (`LogosDeliveryConf.init`, JSON `messagingOverrides`) silently dropped it and the field was always taken from `base` — unsettable by any caller. Make it `Opt[RateLimitConfig]` like every other field; `MessagingClient.new` falls back to `DefaultRateLimitConfig` (new const, rate limiting disabled) when unset. Adds a merge test. - The channel-level knobs (`rateLimitEnabled` / `rateLimitEpochPeriodSec` / `rateLimitMessagesPerEpoch`) are still parsed but unread since rate limiting moved to the messaging client, so setting them was silently ignored. `ReliableChannelManager.new` now logs a deprecation warning when any is set. Full removal remains a follow-up API decision. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Logos Messaging Nim
Introduction
This repository implements a set of libp2p protocols aimed to bring private communications.
- Nim implementation of these specs.
- C library that exposes the implemented protocols.
- CLI application that allows you to run a logos-delivery node.
- Examples.
- Various tests of above.
For more details see the source code
How to Build & Run ( Linux, MacOS & WSL )
These instructions are generic. For more detailed instructions, see the source code above.
Recommended and tested toolchain versions (these are installed when you follow the build instructions below):
- Nim 2.2.4
- Nimble 0.22.3
Prerequisites
The standard developer tools, including a C compiler, GNU Make, Bash, and Git.
In some distributions (Fedora linux for example), you may need to install
whichutility separately. Nimbus build system is relying on it.
You'll also need an installation of Rust and its toolchain (specifically rustc and cargo).
The easiest way to install these, is using rustup:
Rust:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Wakunode
# The first `make` invocation will initialize the local dependency state.
make wakunode2
# Build with custom compilation flags. Do not use NIM_PARAMS unless you know what you are doing.
# Replace with your own flags
make wakunode2 NIMFLAGS="-d:chronicles_colors:none -d:disableMarchNative"
# Run with DNS bootstrapping
./build/wakunode2 --dns-discovery --dns-discovery-url=DNS_BOOTSTRAP_NODE_URL
# Run with the QUIC transport enabled
./build/wakunode2 --quic-support=true
# See available command line options
./build/wakunode2 --help
To join the network, you need to know the address of at least one bootstrap node. Please refer to the Waku README for more information.
For more on how to run wakunode2, refer to:
Issues
WSL
If you encounter difficulties building the project on WSL, consider placing the project within WSL's filesystem, avoiding the /mnt/ directory.
How to Build & Run ( Windows )
Windows Build Instructions
1. Install Required Tools
- Git Bash Terminal: Download and install from https://git-scm.com/download/win
- MSYS2:
a. Download installer from https://www.msys2.org
b. Install at "C:" (default location). Remove/rename the msys folder in case of previous installation. c. Use the mingw64 terminal from msys64 directory for package installation.
2. Install Dependencies
Open MSYS2 mingw64 terminal and run the following one-by-one :
pacman -Syu --noconfirm
pacman -S --noconfirm --needed mingw-w64-x86_64-toolchain
pacman -S --noconfirm --needed base-devel make cmake upx
pacman -S --noconfirm --needed mingw-w64-x86_64-rust
pacman -S --noconfirm --needed mingw-w64-x86_64-postgresql
pacman -S --noconfirm --needed mingw-w64-x86_64-gcc
pacman -S --noconfirm --needed mingw-w64-x86_64-gcc-libs
pacman -S --noconfirm --needed mingw-w64-x86_64-libwinpthread-git
pacman -S --noconfirm --needed mingw-w64-x86_64-zlib
pacman -S --noconfirm --needed mingw-w64-x86_64-openssl
pacman -S --noconfirm --needed mingw-w64-x86_64-python
3. Build Wakunode
- Open Git Bash as administrator
- clone nwaku and cd nwaku
- Execute:
./scripts/build_windows.sh
4. Troubleshooting
If wakunode2.exe isn't generated:
- Missing Dependencies: Verify with:
which make cmake gcc g++ rustc cargo python3 upx
If missing, revisit Step 2 or ensure MSYS2 is atC:\ - Installation Conflicts: Remove existing MinGW/MSYS2/Git Bash installations and perform fresh install
Developing
Nim Runtime
This repository is bundled with a Nim runtime that includes the necessary dependencies for the project.
Before you can utilize the runtime you'll need to build the project, as detailed in a previous section.
This will generate a nimbledeps/pkgs2 directory containing various dependencies.
If everything went well, you should see your prompt suffixed with [SuccessX]. Now you can run nim commands as usual.
Test Suite
# Run all the Waku tests
make test
# Run a specific test file
make test <test_file_path>
# e.g. : make test tests/wakunode2/test_all.nim
# Run a specific test name from a specific test file
make test <test_file_path> <test_name>
# e.g. : make test tests/wakunode2/test_all.nim "node setup is successful with default configuration"
Building single test files
During development it is helpful to build and run a single test file. To support this make has a specific target:
targets:
build/<relative path to your test file.nim>test/<relative path to your test file.nim>
Binary will be created as <path to your test file.nim>.bin under the build directory .
# Build and run your test file separately
make test/tests/common/test_enr_builder.nim
Testing against js-waku
Refer to logos-delivery-js repo for instructions.
Formatting
Nim files are expected to be formatted using the nph version present in vendor/nph.
You can easily format file with the make nph/<relative path to nim> file command.
For example:
make nph/waku/waku_core.nim
A convenient git hook is provided to automatically format file at commit time. Run the following command to install it:
make install-nph
Examples
Examples can be found in the examples folder. This includes a fully featured chat example.
Tools
Different tools and their corresponding how-to guides can be found in the tools folder.
Bugs, Questions & Features
For an inquiry, or if you would like to propose new features, feel free to open a general issue.
For bug reports, please tag your issue with the bug label.
If you believe the reported issue requires critical attention, please use the critical label to assist with triaging.
To get help, or participate in the conversation, join the Logos Discord server.