if (v === null) settings[key] = undefined; only removes the key from the fork's sticky settings — applyToRoom then skips patching that sender. The maxBitrate/maxFramerate previously written via sender.setParameters() is still live on the RTCRtpSender and stays there for the life of the publication. The cinny-side JSDoc explicitly documents "A field set to null clears that cap", so the host and fork disagree: once a user lowers screenshare quality, raising it back to "auto" leaves them capped until they republish.
How to trigger
setQuality({screenshareMaxBitrate: 500000}), then setQuality({screenshareMaxBitrate: null}). Screenshare stays at 500 kbps.
Suggested fix
On clear, actively write maxBitrate: undefined / maxFramerate: undefined into every encoding and call setParameters (track which keys were ever set so you only clear your own), instead of skipping the patch.
Filed from the September 2026 audit (branch lotus).
**Severity:** medium · **Type:** bug · **Confidence:** high
**Location:** `src/lotus/lotusQuality.ts:147-155`, `57-78`; host doc `/root/code/cinny/src/app/plugins/call/CallControl.ts:479-486`
### Problem
`if (v === null) settings[key] = undefined;` only removes the key from the fork's sticky settings — `applyToRoom` then *skips* patching that sender. The `maxBitrate`/`maxFramerate` previously written via `sender.setParameters()` is still live on the RTCRtpSender and stays there for the life of the publication. The cinny-side JSDoc explicitly documents "A field set to `null` clears that cap", so the host and fork disagree: once a user lowers screenshare quality, raising it back to "auto" leaves them capped until they republish.
### How to trigger
`setQuality({screenshareMaxBitrate: 500000})`, then `setQuality({screenshareMaxBitrate: null})`. Screenshare stays at 500 kbps.
### Suggested fix
On clear, actively write `maxBitrate: undefined` / `maxFramerate: undefined` into every encoding and call `setParameters` (track which keys were ever set so you only clear your own), instead of skipping the patch.
---
_Filed from the September 2026 audit (branch `lotus`)._
jared
added this to the EC fork audit 2026-09 · Medium & Low milestone 2026-09-12 02:13:02 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: medium · Type: bug · Confidence: high
Location:
src/lotus/lotusQuality.ts:147-155,57-78; host doc/root/code/cinny/src/app/plugins/call/CallControl.ts:479-486Problem
if (v === null) settings[key] = undefined;only removes the key from the fork's sticky settings —applyToRoomthen skips patching that sender. ThemaxBitrate/maxFrameratepreviously written viasender.setParameters()is still live on the RTCRtpSender and stays there for the life of the publication. The cinny-side JSDoc explicitly documents "A field set tonullclears that cap", so the host and fork disagree: once a user lowers screenshare quality, raising it back to "auto" leaves them capped until they republish.How to trigger
setQuality({screenshareMaxBitrate: 500000}), thensetQuality({screenshareMaxBitrate: null}). Screenshare stays at 500 kbps.Suggested fix
On clear, actively write
maxBitrate: undefined/maxFramerate: undefinedinto every encoding and callsetParameters(track which keys were ever set so you only clear your own), instead of skipping the patch.Filed from the September 2026 audit (branch
lotus).Fixed in
cbd42bf9, shipped in0.25.0-lotus.1(published by CI from tag v0.25.0-lotus.1) and consumed by cinny at 9a85a487.