residual/rechat
Watch
3
0
Fork
You've already forked rechat
 0
Code Issues 12 Pull requests Projects Releases Packages Wiki Activity Actions

Stage 4: Voice channels (design open) #4

New issue
Open
opened 2026-10-16 17:06:29 +00:00 by muse-lantern · 0 comments
muse-lantern commented 2026-10-16 17:06:29 +00:00
Member
Copy link

proj-rechat-voice tier-4-major

P2P voice channels. Design is still open — this issue tracks the decision.

Current direction (2026-10-16)

Zach's call: P2P WebRTC, not server-relayed (Mumble-style). Rationale: avoid forcing all media bitrate through the server.

Proposed topology: host-relayed P2P — first person in the voice channel becomes the "host" (supernode). Other participants connect P2P to the host. Connection info masked for user security (no raw IP leak).

Open questions

  • Host election and failover (what happens when the host leaves?)
  • Signaling transport: IRC (chunked, 512-byte limit pain) vs sidecar HTTP/WebSocket
  • ICE/STUN/TURN requirements for NAT traversal
  • Whether to use Pion (pure Go WebRTC) or a lighter custom approach

Prior art

  • thebanri/limoni-voice: custom full-mesh UDP, CPace PAKE, AES-256-GCM (AGPL-3.0 — study only)
  • Mumble: server-relayed (rejected for bitrate reasons, but the TCP-tunnel fallback idea is worth keeping in mind)

See ~/workspace/your_files/res-chat-voice-evaluation.md for the full WebRTC-vs-custom-UDP analysis (recommends custom UDP, but Zach has directed P2P WebRTC — the evaluation is still useful for the signaling/NAT analysis).

Depends on

  • #1 (signaling transport TBD — may need IRC extensions or sidecar)
proj-rechat-voice tier-4-major P2P voice channels. Design is still open — this issue tracks the decision. ## Current direction (2026-10-16) Zach's call: **P2P WebRTC**, not server-relayed (Mumble-style). Rationale: avoid forcing all media bitrate through the server. Proposed topology: **host-relayed P2P** — first person in the voice channel becomes the "host" (supernode). Other participants connect P2P to the host. Connection info masked for user security (no raw IP leak). ## Open questions - Host election and failover (what happens when the host leaves?) - Signaling transport: IRC (chunked, 512-byte limit pain) vs sidecar HTTP/WebSocket - ICE/STUN/TURN requirements for NAT traversal - Whether to use Pion (pure Go WebRTC) or a lighter custom approach ## Prior art - thebanri/limoni-voice: custom full-mesh UDP, CPace PAKE, AES-256-GCM (AGPL-3.0 — study only) - Mumble: server-relayed (rejected for bitrate reasons, but the TCP-tunnel fallback idea is worth keeping in mind) See `~/workspace/your_files/res-chat-voice-evaluation.md` for the full WebRTC-vs-custom-UDP analysis (recommends custom UDP, but Zach has directed P2P WebRTC — the evaluation is still useful for the signaling/NAT analysis). ## Depends on - #1 (signaling transport TBD — may need IRC extensions or sidecar)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
residual/rechat#4
No description provided.