[Backlog] Investigate native voice/video/text chat in Quest Board #127

New issue

Open

opened 2026-07-14 19:57:37 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-07-14 19:57:37 +00:00

Contributor

Context / Motivation

Research-only issue: the deliverable is a written investigation with a go/no-go recommendation. No code.

Quest Board's hard dependency today is Discord: voice capture happens in the bot (bot/questboard_bot/cogs/recording.py, per-user PCM buffers via the sink in services/recording_status.py), announcements and reminders flow through Discord channels. If a table could gather, talk, and record entirely inside Quest Board, that dependency becomes optional — and the recording pipeline could capture in-browser (synergy with the roadmap's live in-browser recording idea), with consent/announcement mechanics simplified to "you joined the room, the banner says it's recorded."

Investigation scope

Transport architecture: embedding a self-hosted SFU (LiveKit OSS, Jitsi Videobridge) vs raw WebRTC mesh for ≤8 participants. The "minimal resources" goal is a hard constraint — mesh may win at table sizes (no media server CPU), but weigh NAT traversal (still need TURN), simulcast absence, and upstream bandwidth per client at 6-8 peers.
Resource cost on a small VPS: idle and in-call CPU/RAM for each option; container count and images added to the compose stack. Success criterion: idle cost ≈ zero, one-container deployment.
Per-speaker track capture for the existing pipeline: LiveKit egress (per-track recordings) vs client-side capture (GM's browser records per-peer streams) vs SFU-side tap. The pipeline consumes per-speaker WAVs + speakers.json from the audio_temp volume (process_audio, webapp/backend/app/tasks/reminder_tasks.py:1461/:1519) — whichever option can produce that contract wins; map identity from room auth instead of PlatformLink Discord ids.
Text chat scope: NOT rebuilding Discord — likely session-scoped ephemeral chat only (during a live room), no persistent guild-style channels. Identify the scope-creep line explicitly.
Bot coexistence: Discord remains first-class; native rooms are an alternative capture/gathering path, not a replacement. How do announcements/reminders behave for a campaign using native rooms (in-app notifications vs Discord)?
Auth: session cookie → short-lived room token (JWT for LiveKit; roll-your-own for mesh signaling over an authenticated WebSocket).
Cross-reference: Matrix/Element parity (#17) — an Element Call / Matrix bridge might deliver part of this (federated rooms, existing clients) at different cost; compare explicitly.

Go criteria

Per-speaker recording achievable into the existing pipeline contract
Idle cost ≈ zero on a small VPS
One-container (or zero-additional-container for mesh) deployment

Out of scope

Any implementation, prototype beyond a throwaway spike, or UI design.
Persistent chat/community features.

Deliverable

A written report (issue comment or docs/ page) covering the seven points, a resource-cost table, and a go/no-go with the recommended architecture if "go".

References

bot/questboard_bot/cogs/recording.py, bot/questboard_bot/services/recording_status.py:10 (current capture + speaker tracking)
webapp/backend/app/tasks/reminder_tasks.py:1461/:1519 (pipeline contract: per-speaker WAVs + speakers.json)
Issue #17 (Matrix/Element parity — overlapping alternative)

Filed from the July 2026 full-project review.

## Context / Motivation **Research-only issue: the deliverable is a written investigation with a go/no-go recommendation. No code.** Quest Board's hard dependency today is Discord: voice capture happens in the bot (`bot/questboard_bot/cogs/recording.py`, per-user PCM buffers via the sink in `services/recording_status.py`), announcements and reminders flow through Discord channels. If a table could gather, talk, and record **entirely inside Quest Board**, that dependency becomes optional — and the recording pipeline could capture in-browser (synergy with the roadmap's live in-browser recording idea), with consent/announcement mechanics simplified to "you joined the room, the banner says it's recorded." ## Investigation scope 1. **Transport architecture**: embedding a self-hosted SFU (LiveKit OSS, Jitsi Videobridge) vs raw WebRTC mesh for ≤8 participants. The **"minimal resources" goal is a hard constraint** — mesh may win at table sizes (no media server CPU), but weigh NAT traversal (still need TURN), simulcast absence, and upstream bandwidth per client at 6-8 peers. 2. **Resource cost on a small VPS**: idle and in-call CPU/RAM for each option; container count and images added to the compose stack. Success criterion: idle cost ≈ zero, one-container deployment. 3. **Per-speaker track capture** for the existing pipeline: LiveKit egress (per-track recordings) vs client-side capture (GM's browser records per-peer streams) vs SFU-side tap. The pipeline consumes per-speaker WAVs + `speakers.json` from the audio_temp volume (`process_audio`, `webapp/backend/app/tasks/reminder_tasks.py:1461/:1519`) — whichever option can produce that contract wins; map identity from room auth instead of `PlatformLink` Discord ids. 4. **Text chat scope**: NOT rebuilding Discord — likely session-scoped ephemeral chat only (during a live room), no persistent guild-style channels. Identify the scope-creep line explicitly. 5. **Bot coexistence**: Discord remains first-class; native rooms are an alternative capture/gathering path, not a replacement. How do announcements/reminders behave for a campaign using native rooms (in-app notifications vs Discord)? 6. **Auth**: session cookie → short-lived room token (JWT for LiveKit; roll-your-own for mesh signaling over an authenticated WebSocket). 7. **Cross-reference**: Matrix/Element parity (#17) — an Element Call / Matrix bridge might deliver part of this (federated rooms, existing clients) at different cost; compare explicitly. ## Go criteria - Per-speaker recording achievable into the existing pipeline contract - Idle cost ≈ zero on a small VPS - One-container (or zero-additional-container for mesh) deployment ## Out of scope - Any implementation, prototype beyond a throwaway spike, or UI design. - Persistent chat/community features. ## Deliverable A written report (issue comment or docs/ page) covering the seven points, a resource-cost table, and a go/no-go with the recommended architecture if "go". ## References - `bot/questboard_bot/cogs/recording.py`, `bot/questboard_bot/services/recording_status.py:10` (current capture + speaker tracking) - `webapp/backend/app/tasks/reminder_tasks.py:1461/:1519` (pipeline contract: per-speaker WAVs + `speakers.json`) - Issue #17 (Matrix/Element parity — overlapping alternative) _Filed from the July 2026 full-project review._

claude-bot added the

backend

enhancement

frontend

labels

2026-07-14 19:57:45 +00:00

claude-bot added this to the Backlog - Speculative / Long-Term milestone

2026-07-14 19:57:46 +00:00