feat: give Data a Discord channel - #4
Conversation
Data's Discord channel is the thin socket that lets people in Discord talk to Data. It holds the Gateway connection as the Data application, and forwards each admitted mention to Data's own HTTP ingress (`POST http://127.0.0.1:8788/ask`) instead of calling a model itself, so Data's brain and session memory stay in one place and this process stays a transport. Admission is fail-closed and mirrors Computer's policy: mention the bot, in an allowlisted guild, from an author holding an allowlisted role or on the owner list. It answers nothing else, and never DMs. Also: - `scripts/zo-deploy.ts` gains `--expect-ready`, so one deploy script can wait for each service's own readiness line, and knows both Data lines. - `.github/workflows/deploy.yml` deploys both services in sequence inside one job, because both fast-forward the same live checkout. - `services/discord.md` records the service and the two prerequisites that live outside this repository.
|
This pull request introduces Data's Discord channel, enabling users to interact with Data directly from Discord. It establishes a thin Gateway socket for the Data application, forwarding admitted mentions to Data's HTTP ingress to ensure Data's brain and session memory remain centralized.
Reviewers should begin by examining |
1 similar comment
|
This pull request introduces Data's Discord channel, enabling users to interact with Data directly from Discord. It establishes a thin Gateway socket for the Data application, forwarding admitted mentions to Data's HTTP ingress to ensure Data's brain and session memory remain centralized.
Reviewers should begin by examining |
Data's Discord channel is the thin socket that lets people in Discord talk to Data. It holds the Gateway connection as the Data application and forwards each admitted mention to Data's own HTTP ingress (
POST http://127.0.0.1:8788/ask), so Data's brain and session memory stay in one place and this process stays a transport.Admission is fail-closed and mirrors Computer's policy: mention the bot, in an allowlisted guild, from an author holding an allowlisted role or on the owner list. It answers nothing else, and never DMs.
Also in this PR
scripts/zo-deploy.tsgains--expect-ready, so one deploy script waits for each service's own readiness line; it knowsready: data-httpandready: data-discord..github/workflows/deploy.ymldeploys both services in sequence inside one job, because both fast-forward the same live checkout.services/discord.mdrecords the service and the two prerequisites that live outside this repository.Verified
data-http→ reply loop was proven against a stub Gateway, a stub Discord REST API, and a stubdata-http: the bridge identified, read a mention from a role-holding author, asked the ingress withsession=discord:<channel>, posted the answer back as a reply, and showed a typing indicator while it worked.4014close (Message Content Intent missing) is reported with the exact fix and retried every five minutes instead of hot-looping.Not yet live
botscope. Until then the bridge deploys and waits. No guild, channel, role, or application identifier is committed: the repository is public, and those live in the service definition and/root/.zo_secrets.