Ivan FB 430ebc0bda
feat!: expose the generated bindings, drop the hand-written FFI tier
The generated crate already provides what this tier existed to build:
CBOR marshalling, the callback dance, and a typed method per proc. So
macros.rs (trampoline, handle_ffi_call) and libwaku_response.rs
(RET_OK/RET_ERR, LibwakuResponse) are deleted rather than ported, and
node/events.rs goes with them -- its WakuEvent enum is now one generated
payload struct per event, which is what the typed listeners hand back.

What survives is what the generated crate does not give us: the domain
layer (WakuMessage, WakuContentTopic, MessageHash, pubsubtopic) and
WakuNodeConfig, which still serialises to the JSON create_node takes --
that JSON is unchanged, only its transport moved to CBOR.

BREAKING CHANGE: WakuNodeHandle and its Initialized/Running typestate,
waku_new, and waku_destroy are gone; callers use LogosDeliveryCtx::create
and let Drop tear the node down. set_event_callback is gone too: events
are per-name now, so a whole-stream callback has no equivalent -- use the
typed add_on_*_listener methods, which deliver a payload struct instead
of a JSON string to match on.

Tests and the example move with the API. The event handling gets shorter
rather than longer: no from_str, no matching five variants, no panicking
on Unrecognized -- a listener only receives the event it registered for.
Callers now base64-decode payloads themselves, since that was WakuMessage's
serde doing it before.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 01:08:23 +02:00
..

Description

This is a very simplistic example where two waku nodes are instantiated within the same Rust app.

What it does

  1. Instantiates two Waku nodes
  2. Each node registers an event callback (waku message event, connection change event, etc.)
  3. Each node starts
  4. Each node perform relay subscription
  5. "node1" publishes a waku message
  6. Both nodes are stopped

How to run

From within the examples/basic/ foder run:

cargo run