ae16db4898
Use local musiclink flake input with Go 1.24. Add matterbridge patch, routing docs, and deploy check script.
51 lines
3 KiB
Markdown
51 lines
3 KiB
Markdown
# MusicLink Room Routing: Stakeholder Summary
|
||
|
||
## Executive Summary
|
||
We identified unintended cross-posting of Slack/Matrix messages caused by Matterbridge’s gateway fan-out behavior. Messages posted in one monitored Slack room can appear in other Matrix portal rooms (including DMs), creating a privacy and trust risk. This is expected Matterbridge behavior when multiple rooms share a single gateway. We must route everything through **one Slack login/token**, which limits per-room identity options.
|
||
|
||
**Immediate recommendation:** isolate rooms by using **one gateway per room** to prevent cross-posting. This can be done in a single Matterbridge process with multiple gateway blocks.
|
||
|
||
## Current Situation (What’s Happening)
|
||
- Slack messages in a monitored room are bridged into the Matrix portal room by mautrix-slack.
|
||
- Matterbridge treats all `inout` rooms in one gateway as a **fan-out bus** and broadcasts messages to every other room in that gateway.
|
||
- Result: messages from public rooms can appear in private DMs (and vice versa).
|
||
|
||
## Impact
|
||
- **Privacy risk:** DM or private room content can leak into other rooms.
|
||
- **Trust risk:** users see unexpected reposts attributed to MusicLink.
|
||
- **Operational risk:** unclear routing makes debugging and auditing harder.
|
||
|
||
## Constraints
|
||
- Only **one Slack login/token** is available for all rooms. No per-room Slack identities.
|
||
|
||
## Options Overview
|
||
|
||
### Option A — Keep Current Fan-Out
|
||
- **Pros:** Lowest effort.
|
||
- **Cons:** Cross-posting continues; privacy risk remains. Not acceptable for production.
|
||
|
||
### Option B — One Gateway per Room (Recommended)
|
||
- **What it means:** Split rooms into separate gateways so messages only stay within their originating room.
|
||
- **Pros:** Stops cross-posting; isolates failures; preserves current MusicLink deployment model.
|
||
- **Cons:** More configuration; needs templating/automation; may require multiple MusicLink instances or distinct API targets (ports/tokens) per gateway.
|
||
- **Note:** Can still run in a single Matterbridge process; does not require multiple systemd units unless desired.
|
||
|
||
### Option C — Native Matrix Support (Longer-Term)
|
||
- **What it means:** MusicLink becomes a native Matrix bot, posting replies only in the originating room.
|
||
- **Pros:** Simplifies architecture; eliminates Matterbridge fan-out issues; clearer routing.
|
||
- **Cons:** Requires code changes and Matrix client management; higher effort.
|
||
|
||
### Option D — Matterbridge Routing Extensions (Longer-Term)
|
||
- **What it means:** Patch or extend Matterbridge to support per-room routing rules.
|
||
- **Pros:** Could preserve single gateway.
|
||
- **Cons:** Uncertain feasibility; upstream changes required.
|
||
|
||
## Recommendation
|
||
- **Immediate:** Implement **Option B** to eliminate privacy leakage and restore predictable routing.
|
||
- **Long-term:** Evaluate **Option C** for a simpler, more reliable architecture.
|
||
|
||
## Open Questions
|
||
- How many Slack rooms require MusicLink coverage in the near term?
|
||
- Should we run multiple MusicLink instances or add per-gateway API targets?
|
||
- What level of monitoring and alerting is required per room/gateway?
|