# 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?