aade2ed4d8
The channel test only checked that create/send/close returned values, so it passed while every send failed downstream: channel_send returns a request id immediately and reports the outcome asynchronously, and with no listener on onChannelMessageError there was nothing to notice. Asking the question properly -- two nodes, one channel, does the payload arrive -- surfaced three things, none of them caused by the nim-ffi migration. Encryption was never installed, so no segment could ever be sent; that is fixed in the vendor by naming the mechanism at channel creation. Autosharding could not be switched on from here at all. A channel's shard is derived from its content topic, so without it the send cannot even auto-subscribe. num-shards-in-network exists on the kernel conf but WakuNodeConfig never exposed it, so it is added here. Ingress is still dropped below this layer, so channel_message_reaches_peer is #[ignore]d with the evidence in its doc comment rather than deleted or weakened into a test that cannot fail. The single-node test keeps its narrow scope and now says why it asserts nothing about arrival. The error listeners stay: a send that fails silently is exactly how this went unnoticed, and they turn a timeout into a diagnosis. 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