generated from ben/template
42 lines
1.5 KiB
Org Mode
42 lines
1.5 KiB
Org Mode
#+title: Zulip Bot Constraints and Auth Model
|
|
#+created: [2026-04-14 Tue 15:25]
|
|
#+updated: [2026-04-14 Tue 15:25]
|
|
|
|
* 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.
|