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
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.
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.
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.
User-defined poll intervals
Web + Web3 feed support: RSS / Atom, Twitter/X, GitHub Releases, Ethereum Contract Events, Snapshot DAO
- Proposals (with Reddit, Farcaster, Bluesky, Lens coming soon)
Decentralised message relaying via Waku
Image embedding in payloads
Composable architecture
Signature support (on the roadmap)
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.
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:
Caching & deduplication- Dynamic topic routing
- CLI config overrides
Listener integration for app UX
UI dashboards and feed inspection
Privacy enhancements (rate limits, ephemeral topics, HTTP policies)
Farcaster, Lens, Reddit, Bluesky integration
Plugin architecture to support bots as apps
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.
GitHub
Open an issue
Or chirp back here in the comments ( so many cicada puns 
)
