Ivan FB e4c8991727

messaging: drive delivery services through the Waku kernel ...

`SendService`/`RecvService` took a raw `WakuNode` and reached into its
internals (`wakuStoreClient`, `subscriptionManager`, `peerManager`),
which breaks the layering: the messaging layer should depend on the Waku
kernel, not the node.

Widen the Waku api surface with the operations these services need
(`storeQueryToAny`, `isStoreMounted`, `hasStorePeer`, `isContentSubscribed`,
`subscribedContentTopics`) and switch both services to hold `Waku` and
call that surface instead. The send-processor chain still pulls raw
publish handles (relay/lightpush/RLN/peer manager) from `waku.node`,
since the kernel API does not expose publishing primitives yet; this is
isolated to the constructor and flagged with a comment.

Also make `MessagingClient.new` return explicitly.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-26 14:03:26 +02:00

..

api

Move events back into interface-class source files (restore #3975 placement)

2026-06-25 23:07:13 +02:00

channels

adjust nph

2026-06-26 12:43:31 +02:00

messaging

messaging: drive delivery services through the Waku kernel

2026-06-26 14:03:26 +02:00

waku

messaging: drive delivery services through the Waku kernel

2026-06-26 14:03:26 +02:00

logos_delivery.nim

messaging: route api send/subscription through the Waku kernel

2026-06-26 13:40:40 +02:00