Skip to content

docs(bridges): distributed Discord app design spike - #473

Draft
lbangalosbt wants to merge 1 commit into
mainfrom
docs/discord-distributed-app-spike
Draft

lbangalosbt wants to merge 1 commit into
mainfrom
docs/discord-distributed-app-spike

Conversation

@lbangalosbt

@lbangalosbt lbangalosbt commented Sep 15, 2026

Copy link
Copy Markdown
Collaborator

Design and plan only — no implementation. The Discord counterpart to the
distributed Slack app (in flight, #435): a customer clicks Add to Server and
events route to the installing tenant, without anyone pasting a token.

Adds docs/old/bridges/DISCORD_DISTRIBUTED_APP.md. It reuses the messaging-app
machinery (messaging_installs, the signed single-use install state, the
RLS-exempt tenant lookup) and argues only what differs from Slack:

  • One application bot token, not one per install → no per-install
    credential; encrypted_bot_token becomes nullable.
  • Message events arrive over the Gateway, not an HTTP webhook → no public
    inbound surface beyond the OAuth callback; no signature/status-code layer.
  • One bot token forces a single connection that multiplexes every tenant
    the isolation story rests on four guards (per-event scoping, tenant-scoped
    identity, no default tenant, no guild-less routing), each with a test.
  • DMs out of scope for v1, dropped explicitly (no guild_id → not
    tenant-routable).

Open questions flagged in the doc: mention-only vs. full message content
(decides whether Discord app verification is needed for v1), and the Phase-2
self-serve tenant-resolution wrapper.

Intended as a review artifact in the style of #391 / #408 — close after review,
or land later via a follow-up docs(...) PR.

Design and plan only — no implementation. The Discord counterpart to the
distributed Slack app (in flight): a customer installs Switch's own app by
clicking Add to Server, and events route to the installing tenant.

Reuses the messaging-app machinery (messaging_installs, the signed single-use
install state, the RLS-exempt tenant lookup) and argues only what differs from
Slack: one application bot token rather than one per install, so no per-install
credential and a nullable encrypted_bot_token; message events over the Gateway
rather than an HTTP webhook, so no public inbound surface beyond the OAuth
callback; and — because one bot token forces a single connection that
multiplexes every tenant — an isolation story that rests on four guards
(per-event scoping, tenant-scoped identity, no default tenant, no guild-less
routing) with a test each. DMs are out of scope for the first version, dropped
explicitly.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant