Self-serve UX: name the approval bot in the `link` pending-code reply #80

New issue

Closed

opened 2026-07-11 03:09:27 +00:00 by robocub · 1 comment

robocub commented

2026-07-11 03:09:27 +00:00

Collaborator

Found during #76 manual /bridge approve validation.

Problem

The pending-link reply (handle_link, crates/matrix-rtc/src/mgmt.rs ~1441) tells the requester to run /bridge approve code:NVB-XXXXXX, but does not say which bot to run it on. /bridge is a global slash command registered by one designated bot per deployment, so if a guild contains that command from more than one application (e.g. a prod deployment's #63 opt-out bot plus another instance's approval bot), a Manage-Server user can run approve on the wrong bot.

Impact

Confusing: observed live — /bridge appeared from two bots in the same guild, and the approver picked the wrong one first.
Safe, not dangerous: approval codes live in each instance's in-memory pending map, so a code minted by instance A doesn't exist in instance B -> the wrong bot replies "unknown or expired code". No cross-instance approval / wrong-bridge risk.

Fix

Plumb the configured approval bot ([management] approval_bot_index) name/mention into the pending reply: "...run /bridge approve code:X on @". The bridge already knows the index; the puppet pool needs to expose that bot's display name / id to the management reply path.

Also

Operational: keep prod puppets out of the automated-test guild (what surfaced the double /bridge here).
Docs (#75): state which bot serves /bridge for the hosted instance.

Pre-public-launch polish -- track alongside #77/#78 on the open-registration path (#76 is done + merged, 8f23abf).

**Found during #76 manual `/bridge approve` validation.** ## Problem The pending-link reply (`handle_link`, `crates/matrix-rtc/src/mgmt.rs` ~1441) tells the requester to run `/bridge approve code:NVB-XXXXXX`, but does **not** say *which bot* to run it on. `/bridge` is a **global** slash command registered by one designated bot per deployment, so if a guild contains that command from more than one application (e.g. a prod deployment's #63 opt-out bot plus another instance's approval bot), a Manage-Server user can run `approve` on the **wrong** bot. ## Impact - Confusing: observed live — `/bridge` appeared from two bots in the same guild, and the approver picked the wrong one first. - **Safe, not dangerous**: approval codes live in each instance's in-memory pending map, so a code minted by instance A doesn't exist in instance B -> the wrong bot replies "unknown or expired code". No cross-instance approval / wrong-bridge risk. ## Fix Plumb the configured approval bot (`[management] approval_bot_index`) name/mention into the pending reply: "...run `/bridge approve code:X` on **@<bot name>**". The bridge already knows the index; the puppet pool needs to expose that bot's display name / id to the management reply path. ## Also - Operational: keep prod puppets out of the automated-test guild (what surfaced the double `/bridge` here). - Docs (#75): state which bot serves `/bridge` for the hosted instance. Pre-public-launch polish -- track alongside #77/#78 on the open-registration path (#76 is done + merged, `8f23abf`).

robocub referenced this issue from a commit

2026-07-11 19:18:04 +00:00

feat(mgmt,config): #80 name approval bot + #82 self-serve allowlist tier

robocub commented

2026-07-11 19:51:31 +00:00

Author

Collaborator

Fixed + shipped in v0.3.0-alpha.21 (master a99e337, deployed to prod 2026-07-11). The link pending-code reply now names the approval bot via a new optional [management] approval_bot_name (the mgmt bot cannot learn the approval bot's live Discord username — only logged on the Discord side, no discord→mgmt identity channel, and it would race startup — so the operator supplies it). The reply also now points at the applications.commands scope when /bridge does not appear in the guild, which is the real failure mode (since /bridge is a single global command that auto-resolves to the one registering app). Out of scope: delivering the live username (would need pool-side retention + a new identity channel).

Fixed + shipped in **v0.3.0-alpha.21** (master `a99e337`, deployed to prod 2026-07-11). The `link` pending-code reply now names the approval bot via a new optional `[management] approval_bot_name` (the mgmt bot cannot learn the approval bot's live Discord username — only logged on the Discord side, no discord→mgmt identity channel, and it would race startup — so the operator supplies it). The reply also now points at the `applications.commands` scope when `/bridge` does not appear in the guild, which is the real failure mode (since `/bridge` is a single global command that auto-resolves to the one registering app). Out of scope: delivering the live username (would need pool-side retention + a new identity channel).

robocub closed this issue

2026-07-11 19:51:31 +00:00

robocub referenced this issue

2026-07-11 22:58:49 +00:00

mgmt: greeting + self-serve help should link the instance user guide (docs_url) #92