generated from ben/template
1.5 KiB
1.5 KiB
Zulip Bot Constraints and Auth Model
initial research and recommendation
Use a Zulip bot user for the bridge.
Why:
- smaller permission surface than a human account
- API access is explicit and automatable
- easier to treat as infrastructure than as a person
Zulip messages can be sent as stream messages with a fixed topic using the API. Inbound updates can be read through Zulip's real-time events API via an event queue.
Relevant API shape:
- send message: type = stream, to = channel, topic = fixed topic
- receive events: register an event queue, then long-poll get-events
Bot API key access is restricted to the bot owner and organization administrators.
minimal zulip constraints
| area | constraint |
|---|---|
| identity | use a bot user, not a normal user account |
| auth | bot API key needed; owner/admin can access it |
| outbound | stream message + fixed topic |
| inbound | event queue + long-poll events API |
| scope | one stream/topic pair for v0 |
| formatting | plain text is enough for the bridge |
what this means for v0
- the Zulip side is not a general client UI problem
- it is a bot that reads events and sends stream messages
- no need for fancy topic routing yet
- one fixed topic is enough to keep the bridge simple
summary
Bot user + event queue + fixed stream/topic is the clean v0 path.
It keeps Zulip acting like a relay endpoint, not a second full chat client.