Channel Management Through Bot Commands

dark commented

2026-06-15 15:02:37 +00:00

Owner

Instead of needing to configure the channel mapping through a config file, we should be able to use bot commands to add and remove links between matrix and discord channels.

dark added the

enhancement

help wanted

labels

2026-06-15 15:12:29 +00:00

dark added this to the Roadmap project

2026-06-27 16:29:34 +00:00

robocub referenced this issue

2026-06-27 16:46:54 +00:00

Runtime bridge provisioning (supervisor + tenant persistence) #45

robocub referenced this issue from a commit

2026-06-27 16:47:54 +00:00

docs(readme): reframe Future directions around hosted bridging roadmap

robocub referenced this issue from a commit

2026-07-05 18:52:29 +00:00

config: [management] block + tenants.toml edit helpers (#4)

robocub referenced this issue from a commit

2026-07-05 18:52:29 +00:00

matrix-rtc: management bot + supervisor control channel (#4)

robocub referenced this issue from a commit

2026-07-05 18:52:29 +00:00

bridge: wire the management bot + docs (#4)

robocub referenced this issue from a commit

2026-07-05 19:42:40 +00:00

config: [management] block + tenants.toml edit helpers (#4)

robocub referenced this issue from a commit

2026-07-05 19:42:40 +00:00

matrix-rtc: management bot + supervisor control channel (#4)

robocub referenced this issue from a commit

2026-07-05 19:42:40 +00:00

bridge: wire the management bot + docs (#4)

robocub commented

2026-07-05 20:07:45 +00:00

Collaborator

Shipped in v0.3.0-alpha.8 — bridges can now be managed over Matrix DM instead of editing files.

What landed

A new optional [management] config block starts a management bot on the appservice bot account (own device + store, Olm-capable so encrypted DMs work). It auto-joins room invites only from allowlisted operator MXIDs and serves:

link <name> <matrix-room-id> <discord-guild-id> <discord-channel-id> [server]
unlink <name>
list (statics + tenants, with running status)
help

Commands atomically rewrite tenants.toml via toml_edit (operator comments/hand-edits survive) and trigger the same in-process reconcile SIGHUP uses (#45), over a new supervisor control channel with per-request replies — one lifecycle code path no matter who initiates. A rejected reconcile rolls the file back, so the file never lies about the running set. With [management] configured, a zero-[[bridge]] config is a valid boot: a hosted deployment can start empty and be provisioned entirely over DM.

Verified live (2026-07-05, staging on the prod host)

Offline-invite accepted at boot; live invites gated on the allowlist.
6 links + 3 unlinks, zero failures: correct add/remove/unchanged reconcile counts every time, clean teardowns (no force-drops), per-room media-E2EE auto-detect correct (encrypted test room → Olm transport).
Real audio over bot-created tenant bridges; the 4 static bridges served live traffic throughout, untouched.
Deployed to prod same day: 4 statics (device ids reused) + 3 tenant bridges + management bot, zero errors.

Notes

The management room must allow PL-0 users to send messages — the bot joins but cannot reply otherwise (it logs a WARN).
Commit trail: b4407df (config + tenants.toml edit helpers), 37ed0f3 (bot + supervisor control channel), dbb48c9 (wiring + docs).

Remaining multi-tenant auth/hardening (two-sided authority, room-prereq detection, quotas) is #47.

**Shipped in [v0.3.0-alpha.8](https://nether.codes/dark/nether-voicebridge/releases/tag/v0.3.0-alpha.8)** — bridges can now be managed over Matrix DM instead of editing files. ### What landed A new optional `[management]` config block starts a **management bot** on the appservice bot account (own device + store, Olm-capable so encrypted DMs work). It auto-joins room invites **only from allowlisted operator MXIDs** and serves: - `link <name> <matrix-room-id> <discord-guild-id> <discord-channel-id> [server]` - `unlink <name>` - `list` (statics + tenants, with running status) - `help` Commands atomically rewrite `tenants.toml` via `toml_edit` (operator comments/hand-edits survive) and trigger the **same in-process reconcile** SIGHUP uses (#45), over a new supervisor control channel with per-request replies — one lifecycle code path no matter who initiates. A rejected reconcile rolls the file back, so the file never lies about the running set. With `[management]` configured, a zero-`[[bridge]]` config is a valid boot: a hosted deployment can start empty and be provisioned entirely over DM. ### Verified live (2026-07-05, staging on the prod host) - Offline-invite accepted at boot; live invites gated on the allowlist. - 6 links + 3 unlinks, zero failures: correct add/remove/unchanged reconcile counts every time, clean teardowns (no force-drops), per-room media-E2EE auto-detect correct (encrypted test room → Olm transport). - Real audio over bot-created tenant bridges; the 4 static bridges served live traffic throughout, untouched. - Deployed to prod same day: 4 statics (device ids reused) + 3 tenant bridges + management bot, zero errors. ### Notes - The management room must allow PL-0 users to send messages — the bot joins but cannot reply otherwise (it logs a WARN). - Commit trail: `b4407df` (config + tenants.toml edit helpers), `37ed0f3` (bot + supervisor control channel), `dbb48c9` (wiring + docs). Remaining multi-tenant auth/hardening (two-sided authority, room-prereq detection, quotas) is #47.

robocub closed this issue

2026-07-05 20:07:45 +00:00

robocub referenced this issue from a commit

2026-07-05 20:56:59 +00:00

docs: changelog + README for the link preflight (#47)

robocub referenced this issue

2026-07-06 17:41:47 +00:00

Automatic Testing #38

robocub referenced this issue

2026-07-07 03:54:07 +00:00

Wishlist: per-user avatars on voice puppets (platform-blocked — webhook trick is text-only) #65