4 Commits

Include renames

Author	SHA1	Message	Date
Lotus CIandClaude Opus 5.5	d3f389cab1	feat(voice-limit-guard): enforce the limit at connect time too (#25) ... The limit was only checked at token issue, and lk-jwt tokens last an hour, so a token fetched while there was space could be used to connect once the room was full. The reconcile loop now compares each limited room's distinct Matrix users with max_users and RemoveParticipants the people who arrived since the previous sweep, newest first, until it is back within the limit. People already in the call are never removed (lowering a limit mid-call kicks nobody); extra devices of one person never count twice. Fixes #25 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5	2026-10-19 23:30:15 -04:00
Lotus CIandClaude Opus 5.5	fa0351084b	fix(voice-limit-guard): two simultaneous joins can no longer both pass a full room (#25) ... The limit was checked against participants LiveKit already had, so tokens issued but not yet connected were not counted: two users pressing Join together could both get into a 1-person channel. Serialise the check per room and give each admitted user a 30 s reservation, counted like a present user until LiveKit lists them or it expires. Refs #25 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5	2026-10-18 15:24:27 -04:00
jaredandClaude Opus 5	ee5f78b71e	voice-limit-guard: live revoke never fired — LiveKit's JSON uses snake_case permissions ... livekit-server (verified on 1.13.7) serialises ParticipantPermission as can_publish / can_publish_sources; the reconciler read canPublish / canPublishSources, saw 'publishes nothing' for everyone and never called UpdateParticipant, so turning Allow Screen Sharing off did not stop an in-progress share. Normalise the permission keys before deciding. Verified on a local Synapse + LiveKit + guard stack: share track gone from the SFU 2 s after the policy flip. Tests added (44 pass). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA	2026-09-18 22:10:14 -04:00
jaredandClaude Opus 4.8	a06f2c662a	feat(livekit-guard): enforce per-room call permissions (screenshare/camera) ... Extend voice-limit-guard to enforce a per-room publish-source policy (io.lotus.room_quality allow_screenshare/allow_camera) for ALL Matrix clients, alongside the existing participant limit. - At token issue, re-sign the LiveKit JWT's canPublishSources to drop forbidden sources (microphone always kept). Verifies our own secret signed the token first and fails open on mismatch, so a secret drift can never mint a token the SFU rejects. Limit check and source policy are independent (one's outage can't skip the other). - Live (mid-call) enforcement: a background reconcile loop calls LiveKit UpdateParticipant to revoke a forbidden source from participants who joined before the policy changed -- which unpublishes their in-progress screenshare/camera server-side within ~3s and blocks re-publish. Only removes sources (never grants), preserves other permission flags, fails open, and runs as a daemon thread that cannot crash or block token issuance. - Endpoint-specific room-id extraction (/get_token->room_id, /sfu/get->room) so a client sending both keys can't get a different room's policy applied. - Auto-deploy the guard on LXC 151 (py_compile-gated, backup + rollback). - Unit tests: JWT re-sign/verify + tamper, secret-mismatch, source narrowing, reconcile (never-grant / preserve-flags / disable-on-empty), fail-open. Numeric bitrate/fps caps are NOT server-enforceable on an SFU (LiveKit forwards, never transcodes) and remain a Lotus-client-cooperative setting; the screenshare/camera permission is the hard cross-client lever. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-30 22:34:34 -04:00