Ivan FBandClaude Opus 5
a9fc67df3f
Closes the last drift from master's 4a85db1b: the edge was still building
against a vendored, threads-off fork of nim-ffi 0.1.3 while everything else had
moved to 0.3.0.
wasm-deps/ffi is re-vendored from the pinned 0.3.0 with a much smaller patch
than the 0.1.3 one: rather than gating ~20 call sites (and re-gating them on
every bump), ffi_singlethread.nim supplies API-compatible no-ops for
ThreadSignalPtr and Thread, which are what --threads:off actually forbids. The
upstream lifecycle code then compiles untouched. The only behavioural change is
sendRequestToFFIThread, which runs the handler on the caller's chronos loop
instead of enqueuing it for a worker that is never started.
edge_lib.nim moves to the 0.3.0 surface: declareLibrary now takes the library
type, contexts come from the generated <LibType>FFIPool, and genBindings()
closes the file. The five request procs use `{.ffiRaw: "abi = c".}` — the one
annotation that keeps the explicit (ctx, callback, userData, ...cstring) C
signature the browser already calls, so edge_new / edge_lightpush_publish /
edge_filter_subscribe / edge_store_* / edge_stop keep their symbols and arity.
Two things 0.3.0 changes that ARE visible, hence the `!`:
- Request replies are CBOR text strings, not raw bytes. `abi = c` does not
prevent it: ffiRaw expands to registerReqFFI, which pins the codec to CBOR.
Short replies (a hash, "") looked fine; only storeQuery's JSON.parse caught
it. Hosts must strip the 1-5 byte header — the demos and ld-edge.js do, and
fall through for unframed replies so they still work against a 0.1.x binary.
- FFIContext lost eventCallback/eventUserData in favour of a listener registry.
logosdeliveryedge_set_event_callback keeps its exported signature and stores
into a module-level slot instead, so events stay unframed and the JS is
unchanged. A browser edge node has exactly one context.
Request params must be `string`, not `cstring`: the request is CBOR-encoded, so
a cstring field encodes the pointer and the multiaddr arrives empty.
Verified against the Status staging fleet with lion-signet's selftest — 20
passed, 0 failed, 0 skipped: connect, lightpush v3, store query + paging,
byte-identical payload round trip, history decrypt+verify, ns timestamps as
strings, offline invite recovery, clean teardown.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012qDYE5r2t2dMry5XpWWySu
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.