🪰👁️ Cicadian: A Cyclic Waku Broadcaster Bot for P2P Feeds


Hey everyone, I’d like to introduce something I’ve been working on recently. Cicadian, a modular, minimalist Waku bot that wakes in cycles, like its namesake, to chirp the latest updates from across the decentralised and centralised web.

From RSS, Twitter, and GitHub releases to Ethereum logs and DAO proposals, Cicadian translates real-world and on-chain events into structured WakuFeedBroadcast messages, relayed over Waku topics you define.

Check out the repo here https://github.com/status-im/cicadian


:dna: Why Cicadian?

Cicadian is designed with privacy in mind. It gives users a clean, modular way to bridge feeds and updates into their own decentralised communication channels.

If you have information you want to share with your friends over peer-to-peer networks, but you want to stay air-gapped from centralised services, Cicadian gives you that pathway.

It works across both Web2 and Web3 sources without relying on centralised platforms, proprietary bots, or third-party webhooks.

It’s built for:

  • Decentralisation-first broadcasting using Waku
  • High modularity for composing your own feed logic
  • Minimal surface area: no middlemen, just peer-to-peer messaging
  • Integration potential with chat clients like Status

Whether you want to plug in RSS, Ethereum logs, or DAO votes, Cicadian gives you the tools to translate any signal into a timely, verifiable broadcast.

:satellite: Waku as a Privacy Buffer

There’s a strong tendency to pile on more and more HTTP calls when building plugin or widget systems. It’s easy and familiar. But every HTTP call is a direct privacy exposure:

  • IP address leakage
  • Timing metadata
  • Potential device or identity fingerprints

This is where Waku broadcasts shine. They allow us to air-gap the user from the outside world: a bot (like Cicadian) can pull from RSS or other sources, then publish over Waku. The user subscribes passively and never initiates the HTTP call.

It’s a subtle but powerful shift. Instead of the user fetching, the network delivers.

This lets us build ambient, decentralised experiences without leaking metadata upstream, a pattern worth preserving and promoting.

:sparkles: Key Features

Cicadian is designed to be simple to configure, easy to extend, and highly customisable. Whether you’re looking to stream Twitter updates into a group chat, track on-chain contract events, or follow your favourite newsletter feed over Waku, these features make it possible without centralised services or fragile webhooks.

  • :stopwatch: User-defined poll intervals
  • :helicopter: Web + Web3 feed support: RSS / Atom, Twitter/X, GitHub Releases, Ethereum Contract Events, Snapshot DAO
    • Proposals (with Reddit, Farcaster, Bluesky, Lens coming soon)
  • :globe_with_meridians: Decentralised message relaying via Waku
  • :framed_picture: Image embedding in payloads
  • :wrench: Composable architecture
  • :closed_lock_with_key: Signature support (on the roadmap)

:seedling: My Inspiration. Local Bots & Widget Plugins

@fryorcraken recently shared a vision for making Status app bots that feel like local extensions: sandboxed, installable agents that interact with chat via a clearly defined API.

I really appreciate the vision behind this “local bot” concept. The model is clean and privacy-preserving: bots as extensions that run locally within Status, optionally triggered via messages (e.g. tagged ones in group chats), without needing any hosted infrastructure or external service dependencies. It’s aligned with the kind of trust-minimised design we should be pushing for.

The idea of having bots register with a scoped API (display, alarms, wallet, etc.) introduces modularity and flexibility, especially when paired with user-consent-driven permissions. It’s reminiscent of the browser extension security model, but with a peer-to-peer flavour.

Architecturally, these bots diverge from Cicadian in that they do not use Waku. They operate entirely on the local client. That means they can function in a pseudo-1:1 or fully offline context. Even when bots do require network access (like fetching RSS feeds), the model allows for HTTP access to be explicitly scoped and user-controlled. This opens the door for a permission regime like mobile OSes use, further reducing metadata exposure.

One architectural piece that we’ll likely need for both local and broadcast bots is a defined listener protocol. This could be as simple as defining a “local bot type” like listener.

Currently I’m working on the spec for how the Status app manages and connects to Cicadian-style broadcasts. It builds on Flexsurfer’s (@andrey) “timeline” model, where users can “claim” their own content topics and use them as personalised broadcast channels. The Cicadian listener would passively subscribe to those claimed timelines and render feed updates accordingly.

This architecture unifies the flexibility of local agents with the reach of Waku-powered broadcasts. Whether a bot listens, speaks, or both, everything can stay local and composable by design.


:round_pushpin: Where It’s Headed

Cicadian is still in its early days, but its path forward is clearly kind of mapped. You can check out the evolving roadmap here. The core vision is to enable composable, trust-minimised broadcasting infrastructure that integrates natively with peer-to-peer apps like Status.

The near-term focus is on stability, feed diversity, and developer tooling. We’re refining how feeds are configured, improving support for media, and making it easier to test and extend new data sources.

The broader trajectory is about listener integration, building out the logic inside the Status app that can subscribe to, filter, and render these broadcasts directly in chat timelines. This ties into the “timeline” feature pioneered by @andrey, where users “claim” a topic and effectively turn it into a personal or project feed. Cicadian becomes the tool for publishing into those spaces.

Further down the line, we’re exploring dynamic content topic routing, bot registration metadata, signature verification flows, and privacy features like ephemeral caching or scoped access policies.

The roadmap includes:

  • :white_check_mark: Caching & deduplication
  • :white_check_mark: Dynamic topic routing
  • :white_check_mark: CLI config overrides
  • :hammer_and_wrench: Listener integration for app UX
  • :broom: UI dashboards and feed inspection
  • :lock: Privacy enhancements (rate limits, ephemeral topics, HTTP policies)
  • :speech_balloon: Farcaster, Lens, Reddit, Bluesky integration
  • :hook: Plugin architecture to support bots as apps

:handshake: Join the Chorus

Whether you’re:

  • A protocol dev with a new feed in mind,
  • A power user who wants fine-grained control over updates,
  • Or a builder interested in bot/plugin convergence -

Cicadian is here to help your signal get out.

:point_right: GitHub
:point_right: Open an issue
:point_right: Or chirp back here in the comments ( so many cicada puns :see_no_evil: )

2 Likes

Just dropping this issue in here because it raises some good points why build on top of waku instead of status(-backend) · Issue #1 · status-im/cicadian · GitHub

TLDR:

Q: “Why not use Status?”
A: We will need to.


Edit: I got too into Excalidraw and made a better version


Added another chart detailing how Cicadian can be used to hook into the Status chat ecosystem.

Very exciting work. A couple of comments:

(1) At this point in time, the Waku API is not refined enough; meaning that one can “abuse” Waku and hold too high expectations on it (e.g use it as a CDN). I know you are well aware of the issues. Hence, it is best if a proper RFC comes with this feature/V2 so we (Waku team) can pinpoint any potential scalability, security or privacy issue (I believe you already said you’ll do a spec, awesome).

Do note that with the Messaging API milestone, and RLN, we should reach a stage where Waku API will enable a more adapted use of Waku by developers, and prevent some a usage that would impact scalability etc.

(2) The go-waku implementation is currently barely maintained, only bug fixes; I suggest you either implement this new piece of software in nim, or at least try out the nwaku Golang wrapper.

1 Like