DanielFGray / DanielFGray/rfchat
Voice channel architecture and signaling
- Dominant language
- Elixir
- Stars
- 2
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
## Summary
Define and implement the product architecture and signaling layer for voice channels, deferring hard media transport details to follow-up work.
## Scope
- Define voice-channel join/leave semantics, speaking state, mute/deafen state, and participant presence.
- Define signaling messages and authoritative server state for voice sessions.
- Support channel occupancy and basic voice presence in the product UI.
- Establish the contract future media transport work will plug into.
## Acceptance Criteria
- [ ] Users can join and leave voice channels with correct visible occupancy state.
- [ ] Voice signaling state is authoritative and recovers correctly after reconnects.
- [ ] Mute/deafen and speaking-related states have a clear source of truth.
- [ ] The signaling model cleanly supports future media transport and moderation features.
## Operational Notes
- This issue should not depend on shipping full voice/video transport immediately.
- Self-hosted operators need a design that remains understandable when debugging live voice problems.
Contributor guide
No contributing guide indexed for this repository
Research direction
No files, tests, or entry points are named in the issue. Begin by locating the current channel and reconnect handling, then trace how presence and state reach the product UI. Done means the join/leave, occupancy, reconnect, mute/deafen, and speaking-state contracts satisfy the listed acceptance criteria without requiring media transport.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- elixir
- Domain
- audio-video-rtc, backend-api-design, frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100