openclaw - 💡(How to fix) Fix [Feature Proposal] Zulip channel extension — topic-based threading for agent workflows [1 participants]

What

A Zulip channel extension for OpenClaw, following the same patterns as the existing Matrix, Mattermost, and IRC extensions. Supports:

• Stream + topic routing — maps Zulip streams/topics to OpenClaw channels, with topic-level thread semantics
• DM support — direct messages to/from the bot
• Long-polling transport — uses Zulip's event queue API (no webhooks needed, works behind NAT)
• Metadata store — lightweight SQLite (node:sqlite) mapping of topic↔channel relationships and bot command state
• Bot commands — /claw prefix commands for topic management within Zulip

Why

Zulip's topic-based threading model is a natural fit for agent workflows:

1. Structured conversations — every message belongs to a topic within a stream, giving agents clear conversational boundaries without the noise of flat channels
2. Persistent topics — unlike ephemeral Discord threads, Zulip topics are first-class and long-lived, suitable for ongoing agent tasks
3. Open-source & forkable — fully open-source (Apache 2.0), allowing deep integration and self-hosting
4. Growing adoption — used by Rust, Lean, LLVM, and other technical communities; strong API documentation

Technical Details

Zero external dependencies — uses only:

• node:https / node:http for Zulip API calls
• node:sqlite for the metadata store (Node 22+)
• @openclaw/plugin-sdk (workspace dependency)

Follows existing patterns:

• openclaw.plugin.json with channelEnvVars for ZULIP_REALM, ZULIP_EMAIL, ZULIP_API_KEY
• Standard normalize → inbound → gateway pipeline
• Probe endpoint for connection health checks

Test coverage:

• 93 unit tests across 12 test files covering client, normalize, inbound, gateway, probe, threading, and metadata subsystems
• E2E validation against Zulip Cloud (all P0 scenarios passing)

Structure:

extensions/zulip/
├── src/
│   ├── client.ts          # Zulip API client (REST + long-polling)
│   ├── normalize.ts       # Message normalization
│   ├── inbound.ts         # Inbound message handling
│   ├── gateway.ts         # Gateway integration
│   ├── probe.ts           # Health check endpoint
│   └── metadata/          # Topic↔channel mapping + bot commands
├── tests/                 # 12 test files, 93 tests
├── openclaw.plugin.json
└── tsconfig.json

Scope

Included in the proposed PR:

• Full extensions/zulip/ directory (source + tests + config)
• docs/channels/zulip.md — setup guide with configuration examples
• Metadata subsystem (self-contained, SQLite-based, no external deps)

Not included (potential follow-ups):

• Attachment/file upload support
• Reaction sync
• Stream management commands

Questions for Maintainers

1. Metadata inclusion — The metadata subsystem (~7 source files + 4 test files) manages topic↔channel mappings via SQLite. It's self-contained within metadata/. Should this ship in the initial PR, or would you prefer it as a follow-up?

2. Test runner config — Tests run fine with npx vitest run extensions/zulip but pnpm test:extension zulip returns 0 files, likely due to the vitest workspace glob pattern. Happy to fix the config or adjust test file structure to match.

3. node:sqlite minimum Node version — The metadata store uses node:sqlite which requires Node 22+. OpenClaw already targets Node 22+, but wanted to confirm this is acceptable.

Prior Art

• Matrix extension — closest pattern match (also uses long-polling)
• Mattermost extension — similar REST API + websocket approach
• IRC extension — simpler but same plugin structure

Implementation

Working implementation is available in my fork: kagura-agent/openclaw@feat/zulip-extension. Happy to open the PR once there's maintainer interest.

The full research evaluation (including comparisons with Rocket.Chat, Revolt, and Matrix) is at kagura-agent/chat-infra.