ops-jrz1/docs/musiclink-room-routing-stakeholder-summary.md

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?