Ingest stream slots: let standard streaming tools (WHIP) publish into encrypted Matrix calls #145

New issue

Open

opened 2026-10-02 01:35:14 +00:00 by robocub · 0 comments

robocub commented

2026-10-02 01:35:14 +00:00

Member

Follow-up to ADR 0002 (external stream publishers), Matrix side only.

Stream slots as designed in ADR 0002 hand a publisher a scoped Matrix login, so the publisher must run a MatrixRTC client such as Element Call. Standard streaming tools (e.g. OBS) speak WHIP instead, and an SFU-side ingress cannot apply Element Call's end-to-end media encryption, so they cannot reach encrypted calls that way.

Idea: an ingest kind of slot on the same publisher keys, identities, rate limits and audit trail, where the bridge terminates WHIP and publishes the stream itself as the slot's identity with the room's E2EE.

Needs video handling in the bridge's Matrix/LiveKit side (receive WHIP, republish with frame encryption). Nothing Discord-side: Discord stays audio-only.

Follow-up to ADR 0002 (external stream publishers), Matrix side only. Stream slots as designed in ADR 0002 hand a publisher a scoped Matrix login, so the publisher must run a MatrixRTC client such as Element Call. Standard streaming tools (e.g. OBS) speak WHIP instead, and an SFU-side ingress cannot apply Element Call's end-to-end media encryption, so they cannot reach **encrypted** calls that way. Idea: an *ingest* kind of slot on the same publisher keys, identities, rate limits and audit trail, where the bridge terminates WHIP and publishes the stream itself as the slot's identity with the room's E2EE. Needs video handling in the bridge's Matrix/LiveKit side (receive WHIP, republish with frame encryption). Nothing Discord-side: Discord stays audio-only.

robocub referenced this issue from a commit

2026-10-02 01:35:31 +00:00

docs: Discord video relay is not planned (#8 closed); ADR 0002 ingest follow-up is #145