In-channel disclosure notice when a bridge link activates #64
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
dark/nether-voicebridge#64
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Part of the #43 ToS follow-ups (Dev Policy §2/§3: make "this channel is relayed off-platform" unmistakable).
Today's disclosure: the
[Matrix]nickname prefix, the Manage-Server approval, and (since the ToS-followups branch) the PUBLIC/bridge approveoutcome in the channel where the command ran. Missing: a notice in the bridged voice channel itself (its text chat), visible to people who join later and never saw the approval.Proposal: when a link activates (and on unlink), the approval bot posts to the voice channel's text chat: "🔗 This voice channel is bridged to a Matrix room — voice is relayed off-platform (live only, never recorded). Approved by . Policy: <privacy_policy_url>." Needs Send Messages permission on the channel; degrade gracefully (log a WARN) without it. Plumbing: the mgmt side owns link lifecycle, the pool owns Discord HTTP — reuse the #47 adapter direction or extend the approval reply path with the channel id.
Link side shipped: merged to master
cfda71b, released in v0.3.0-alpha.12. Leaving this open for the unlink side.On a successful
/bridge approve, the approval bot now posts into the bridged voice channel's text chat: "🔗 This voice channel is now bridged to a Matrix room — voice is relayed off-platform (live only, never recorded). Approved by ." plus theprivacy_policy_urlline. Plumbing: the approval reply oneshot now carriesnvb_config::ApprovalOutcome(text + optional notice channel/message) — the shared type crosses the discord↔matrix-rtc boundary through the binary's adapter untouched; mgmt populates the notice from the pending link'schannel_idon commit success. Missing Send Messages on the voice channel degrades to a WARN plus the public approval record in the invoking channel. Live-verified on staging 2026-07-07 (notice posted with policy link, exact text confirmed).Remaining (why this stays open): the unlink-side notice ("this channel is no longer bridged") has no seam — there is no mgmt→pool push channel, and unlink/reconcile teardown runs without a Discord
Contextin hand. Needs new plumbing (e.g. an mgmt→pool notification mpsc consumed by the command-bot's loop).Unlink side shipped: merged to master
633d27c(v0.3.0-alpha.13) — closing.The missing mgmt→pool seam now exists: a
DiscordNoticempsc (shared type in nvb-config) from the management bot to the pool's command bot, whosereadyspawns a consumer that posts each notice viaChannelId::say(best-effort; missing Send Messages degrades to a WARN, and theArc<Http>REST client survives gateway reconnects).Senders:
unlink: reads the tenant's channel id before removal (newnvb_config::tenant_discord_channel) and posts "🔌 This voice channel is no longer bridged to Matrix — the link was removed." after a successful reconcile.banteardown sweep:remove_tenant_entries_matchingnow returns(name, channel_id)pairs (RemovedTenant); each affected channel gets the same neutral text — the ban itself is deliberately not broadcast in-channel.Live-verified on staging 2026-07-07: link+approve → 🔗 notice,
unlink→ 🔌 notice, both observed in the voice channel's text chat; 0 errors; prod restored (5-bridge baseline). 260 tests + clippy green. The ban-path send shares the same pipe; its channel-id extraction is unit-tested.With this, the full disclosure story is in place: public approval record + link notice + unlink/teardown notice +
[Matrix]-prefixed participants +/bridge optout(#63) + the privacy policy link everywhere.