1b25e5c327
waku-sys was a thin -sys crate that only re-exported the generated FFI sources via #[path] and carried the build. It sat between waku-bindings and the generated crate for no real benefit -- the generated crate is the actual -sys equivalent, and its own build.rs cannot build logos-delivery (bare `nim c`, one link directive). So the wrapper is folded in: - The build (make liblogosdelivery + the 13 link directives, librln discovery, cmd.c) moves into waku-bindings/build.rs. - waku-bindings pulls the generated ffi/types/api modules directly by #[path] into the vendor submodule, which moves from waku-sys/vendor to the repo root (vendor/). - ciborium/flume and the cc build-dep move over; the waku-sys path dependency is dropped. Consumers are unaffected -- they always depended only on waku-bindings. This is one crate and one layer fewer. build.rs now also removes a stale build/liblogosdelivery.dylib after the static build: the generated ffi.rs declares `#[link(name = "logosdelivery")]` with no kind, so a dylib left by a non-STATIC make would be linked dynamically over the static archive. Full suite passes (4 tests + doctest, 1 ignored) and all three examples build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Waku Rust bindings
Rust api on top of waku-sys bindgen bindings to c ffi bindings.
Usage
Add this to your Cargo.toml:
[dependencies]
waku-bindings = "0.1.0"
About Waku
Waku is the communication layer for Web3. Decentralized communication that scales.
Private. Secure. Runs anywhere.
What is Waku?
Waku is a suite of privacy-preserving, peer-to-peer messaging protocols.
Waku removes centralized third parties from messaging, enabling private, secure, censorship-free communication with no single point of failure.
Waku provides privacy-preserving capabilities, such as sender anonymity,metadata protection and unlinkability to personally identifiable information.
Waku is designed for generalized messaging, enabling human-to-human, machine-to-machine or hybrid communication.
Waku runs everywhere: desktop, server, including resource-restricted devices, such as mobile devices and browsers. How does it work?
The first version of Waku had its origins in the Whisper protocol, with optimizations for scalability and usability. Waku v2 is a complete rewrite. Its relay protocol implements pub/sub over libp2p, and also introduces additional capabilities:
- Retrieving historical messages for mostly-offline devices.
- Adaptive nodes, allowing for heterogeneous nodes to contribute.
- Bandwidth preservation for light nodes.
This makes it ideal for running a p2p protocol on mobile, or in other similarly resource-restricted environments.
Read the Waku docs