The tap-anywhere-to-resume queue was a regression — users saw a "tap
anywhere to start" message and tapping often did nothing, with no
feedback about why. Replace with the obvious-in-hindsight approach:
seize the user gesture from the entry button click itself.
primeAudioOnGesture() plays a 1-frame silent WAV through a hidden
<audio> element inside the entry click handler. Mobile Firefox /
Safari treat that as gesture-driven audio playback and grant the
page audio permission for the session. It also resumes any
suspended AudioContext (meter / chime path) the same way.
By the time auto-enrolment into DJ mode runs (async hops after
entry), the page already has audio permission — dynamic <audio>
elements created later play() without further user interaction.
No "tap anywhere", no queue, no flip-flop on stalled.
Bound to btn-enter click + rdv-code Enter key. Tap-to-resume queue
and pendingAutoplay/installTapResume helpers removed.
Tests green (83 fsm + 16 zebra-spaces).
When stream autoplay was blocked and the listener tapped to resume,
the retry called a.play() on a <audio> that had already been left in
error state by the browser-aborted prior load. play() on a stuck
element silently no-ops — listener saw the 'tap anywhere' message but
got no audio and no feedback.
Three fixes:
- call a.load() inside the gesture handler before a.play() to
restart the fetch from a clean state
- add 'click' to the listened events alongside pointerdown/
touchstart — Firefox Android only grants gesture activation on
click in some configurations
- log retry result: 'stream resumed after tap' on success,
'stream tap-retry failed: <msg>' on rejection, so we can see
what's happening instead of silent failure
Tests green (83 fsm + 16 zebra-spaces).
Mobile Firefox/Safari refuse audio.play() when the gesture activation
window has expired between the entry-button tap and auto-enrolment
into DJ mode. Previously this surfaced as "autoplay blocked" in the
log and the listener was silently stuck on WebRTC.
Now: when play() rejects, the <audio> element goes into a
pendingAutoplay set and one global pointerdown/touchstart listener
on document retries every queued element. Once they all play the
listener self-uninstalls. Idempotent install — adding more elements
during the pending window just enqueues them.
Listener sees: 'stream for <pubhex> — tap anywhere to start (msg)'
in the log; one tap later, every queued stream resumes and the
log fills with 'stream on for ...' lines.
WebRTC stays unmuted during the wait so the listener still hears
the live (possibly choppy) audio — they're not left in silence
between the autoplay block and their tap.
Fox saw repeated "stream stalled" and "autoplay blocked: aborted at
user's request" log lines on both auto-enrolled mobile listeners and
host self-monitor clicks. Three coupled causes:
1. applySinkTo() was called sync-fire-and-forget right before setting
.src and calling .play(). setSinkId() can re-init the media
pipeline; when it landed during the in-flight load it aborted the
request — Firefox surfaces that as
"The fetching process for the media resource was aborted by the
user agent at the user's request." on the play() promise. We
wrongly logged that as autoplay-blocked. Fix: await applySinkTo()
BEFORE assigning .src.
2. The 'stalled' event handler called unmuteWebRtcOnFail every time
it fired. 'stalled' fires constantly during normal mobile-cellular
buffering and isn't a terminal failure. Each fire ping-ponged the
audio path between WebRTC (unmuted) and the still-loading HTTP
stream. Drop the handler — only 'error' and a rejected play()
promise indicate real failure.
3. A second toggle-on for the same pubHex (auto-enroll race when
peer-joined fires during initial enrol) reassigned .src on the
same <audio> element, aborting the prior load with the same abort
error. Make startStream idempotent: if the element already has
our wantUrl and no .error, return immediately.
Plus two cheap mobile-friendly attrs on the dynamic <audio>:
- preload="auto" so buffering starts before play() (gives the
user-gesture window time to last past the initial fill)
- playsInline so iOS/Safari doesn't escalate to a fullscreen player
startStream is now async — callers (toggleStreamFor,
autoEnableDjModeForListener) fire-and-forget the returned promise,
which is fine since all error paths are already caught inside.
Tests green (83 fsm + 16 zebra-spaces).
Page-side companion to proxy.unturf.com 90a5e96.
- modMute(uuid): signs + sends {type:"mute",target,epoch,sig}.
- Mute button on speaker / cohost rows (host always; cohost can
mute speakers only). Lives in .acts-primary beside the role
transitions; kick/ban stay on the .acts-removal row below.
- On peer-force-muted from server:
- If I'm the target: disable my mic tracks, set muted=true,
persist to sessionStorage, broadcast new mic-state, show
"you were muted by X. Click unmute to talk again." Banner —
the unmute button is the user's own action, not locked.
- For others: mark the target visually muted right away so
the roster reflects state without waiting on a mic-state
broadcast.
The .stream-toggle CSS class and `strm` grid column were already in
place but the JS still appended the button into .acts-primary —
which lives in the bottom-row mod-actions stack. That meant every
speaker row (including self-monitor on non-mod rows) grew a third
sub-row just to host the single ◉ glyph, adding scroll height.
Render it as a sibling of micEl in the row so it lands in the `strm`
grid column on the TOP row, alongside the mic icon. Single character
text (○ / ◉) keeps the column tight, and the .stream-toggle styles
already shipped pick it up.
For rows that don't qualify (listeners, non-host-viewers on other
speakers), the streamEl is null → not appended → strm column
collapses to its 1.4rem track width. No row-height penalty.
The mod-actions stack stays as-is for actual mod actions (mic-invite,
role transitions, kick, ban). Self rows and non-mod self-monitor rows
no longer carry an empty mod-actions row at all.
Fox: 'the buttons should be horizontall not vertical on invite and
kick and ban etc.' The previous grid template
`repeat(auto-fit, max-content)` was treated by browsers as a single
column when no fixed sizing function was provided, so every button
ended up on its own row.
Swap to the older inline-block + margin pattern: .acts-primary and
.acts-removal are block-level rows, their <button> children flow
horizontally and naturally wrap to a second line only when the
panel is too narrow to hold them. No flex.
Fox 2026-06-03: 'the listener phone doesn't hear anything since your last
push.' startStream() was muting the WebRTC <audio> for the speaker BEFORE
calling .play() on the fresh HTTP <audio>. On mobile the fresh <audio>'s
autoplay was often blocked (the entry-button gesture had aged out for
freshly-created elements), so the failure mode was: WebRTC silenced +
HTTP not playing = total silence.
Now WebRTC stays unmuted until the HTTP <audio> fires 'playing'. Any
autoplay/error/stalled path unmutes WebRTC and surfaces the reason in
the log, so we fall back to live WebRTC instead of going dead.
play() promise rejections are also logged now (were silenced) so next
session we can tell exactly which speakers' streams failed to start.
Per fox: 'lock them into DJ mode unconditionally.' Stream button is
no longer rendered on listener rows for any other peer. Visibility
rule reverts to {self|host} — same as the post-kick/ban gating —
and listeners get auto-enrolled into the HTTP Ogg/Opus path without
any escape hatch. Host can still flip individual speakers room-wide,
and every speaker still has their self-monitor button.
Fox: 'I want the sound to be epic and to fucking choppy ever.'
Two changes that compose:
1. Default-on DJ mode for listeners. On role landing (or transition
INTO listener), auto-flip every speaker's playback path off the
WebRTC subscribe and onto the existing HTTP Ogg/Opus tap from
the SFU. The browser's <audio> element keeps a deep media buffer
(~30s in Chrome) that absorbs glitches WebRTC can't. Speakers
stay on WebRTC for low-latency conversational audio. Listener
can still opt-out per-speaker via the stream button — gating
expanded from {self|host} to {self|host|listener}.
Auto-enrol triggers at:
- onRoleEntered (initial join as listener)
- peer-joined (new speaker arrives while we're listening)
- role-change of OTHER peer (they became speaker)
- onRoleChanged self speaker → listener
Auto-disable: onRoleChanged self listener → speaker
(cannot afford 2s+ buffer when you have to talk back).
2. RECV_PLAYOUT_DELAY_SEC 2.0 → 4.0 on both mesh and SFU receive
paths. Conversational latency is now ~4s for speakers; this is
the cheap-but-real win against chop on the WebRTC path for
everyone who still uses it. Music/DJ rooms generally don't care
about 4s — the room's already committed to a stream-mode 2s+.
Four corrections in one pass — all from fox's live-room session
2026-06-03 after the kick/ban + heartbeat ship:
1. Stream button visibility was too generous. A speaker viewing
the host's row got a stream button — they shouldn't. New rule:
SELF row always (self-monitor), OTHER rows only when myRole
=== 'host'. Cohost gets self-only too; lift the gate to
isMod(myRole) if room-wide cohost stream control is wanted.
2. .acts-removal's grid-column:1/-1 collapsed the parent auto-fit
grid down to a single column on a row with both primary +
removal actions, so EVERY button stacked vertically. Refactor:
.mod-actions is now a row-stack of sibling groups
(.acts-primary + .acts-removal), each its own horizontal auto-
fit grid. Primary still wraps inside itself when the panel is
narrow; kick + ban are forced to a fresh line by the parent
grid-auto-rows.
3. playoutDelayHint bumped 0.7 → 2.0 (RECV_PLAYOUT_DELAY_SEC) on
both mesh + SFU receive paths. Conversational latency goes up
but the stream/HTTP-pull DJ mode already commits to ~2s, so
matching the WebRTC path makes the room consistent. Persistent
chop survived every SDP-side dial-back fox tried; this is the
last knob left at the receiver.
4. pagehide-bye now skips bfcache (event.persisted=true). Without
this guard, a phone going to lock screen / app-switch /
minimise fired bye → server evicted SFU PCs → page resumed but
audio stayed silent. Aliveness of a bfcached page is already
handled by the server-side aliveTTL (heartbeat stops during
bfcache → server arms hiccup grace at 45s).
Destructive controls shouldn't share a row with role-transition buttons —
the muscle-memory misclick where 'ban' sat next to '→ speaker' is exactly
the kind of mod ergonomics fox flagged. Kick + ban now render inside
a nested .acts-removal grid that spans the parent auto-fit row, so they
always wrap to a fresh line below stream / → cohost / → speaker /
→ listener regardless of available width.
The room-member mod-actions row was hardcoded
grid-auto-flow: column; grid-auto-columns: max-content;
which forces every button onto one non-wrapping line. After adding
the per-speaker "stream" toggle the strip got long enough
(stream + → cohost + → listener + kick + ban) to overflow the side
panel on common widths — kicked the page into horizontal scroll.
Swap to
grid-template-columns: repeat(auto-fit, max-content);
so buttons flow onto a second row when the panel is narrow. Still
grid (no flex per project rule). Doesn't change appearance on wide
panels — only kicks in when the button strip wouldn't fit on one line.
Drop the m.uuid !== myUUID guard on the per-speaker stream toggle so
the DJ can preview what listeners are actually hearing of their own
mic. Self-stream URL hits the SFU pulling our own pubkey — the ~2s
delayed playback is the cue we want to confirm the broadcast works.
Title attr warns about feedback risk on open speakers (closed
headphones like WH-1000XM5 are fine — earcups don't bleed into the
headset mic enough to feedback).
Mod buttons (kick/ban/promote/demote) still self-exclude — different
guard, kept intact.
For each speaker (other than self) the member row now carries an
"○ stream" / "◉ stream" button. Toggling it:
- Mutes the WebRTC remote audio for that uuid (so they don't
double-play through both paths)
- Attaches a parallel <audio src="SFU/stream?room=R&pub=PUBHEX">
that pulls the SFU's new Ogg/Opus broadcast tap as plain HTTP
- Routes through setSinkId so the speaker-output picker still
applies
Trade-off: WebRTC path is ~700ms latency but glitch-prone under
network loss / mixed-browser NACK gaps. The HTTP stream path is
~1.5–3s latency but bulletproof — the browser's <audio> jitter
buffer absorbs everything WebRTC can't. The sub.fm-style DJ
listening UX.
State is keyed by pubHex (not uuid) so it survives session-uuid
churn on rejoin. Cleanup hooks into tearPeer so peer-left tears
down the HTTP pull and the SFU stops fanning Ogg pages to a dead
client.
Requires the matching SFU change in proxy.unturf.com main
(GET /zebra-spaces-sfu/stream endpoint).
Choppy persisted after every other dial-back (NACK off → 510k→320k →
maxptime off). The only remaining new Chrome-publisher param was the
"fullband pin" (maxplaybackrate=48000, sprop-maxcapturerate=48000,
cbr=0). Drop those too and step bitrate back to the known-good 256k.
Chrome publisher's SDP now identical to pre-feature shape:
stereo=1; sprop-stereo=1; maxaveragebitrate=256000;
useinbandfec=1; usedtx=0
Kept:
- Firefox SDP regex fix — Firefox publishers now actually get the
music-mode params applied (was silently no-op before).
- UA-gated NACK — Chrome publishers advertise it (responder support);
Firefox publishers omit (no responder). "audio NACK as sender" log
confirms which side we're on per session.
- Speaker output picker (setSinkId UI).
Comment warns against re-adding fullband pins without re-verifying.
Three coupled changes after still-choppy reports on UA-gated NACK build:
1. 510k → 320k Opus everywhere in music mode. 320k is the transparent
listening-test threshold (Audible masters at this). 510k is spec
ceiling but real-world uploads can't sustain it alongside concurrent
screen 6M + camera 4M without dropping audio packets. Choppy at 510k
persisted after NACK rollback, so bitrate is the next dial.
2. Drop a=maxptime:120 advertisement. Tried to give Opus larger encode
windows for cleaner music at same bitrate. Chrome publishers may have
actually honored it and packed at higher ptime, which the receiver
side handled poorly (jitter buffer + playoutDelayHint=0.7 weren't
tuned for >20ms packetization). Default 20ms stays.
3. Fix preferStereoOpus regex no-op on Firefox publishers. Previous
matcher anchored on minptime=10 which Chrome emits but Firefox does
not — so for years, Firefox-published mic SDPs went out unmunged:
no stereo=1, no maxaveragebitrate cap, no fullband pin, no NACK gate.
Now: scan rtpmap for all opus/48000/2 PTs, update existing fmtp lines
in place, or insert a fresh fmtp if none exists (Firefox's case).
This is why fox saw "audio NACK as sender" diagnostic never fire on
Firefox publish — the function early-returned before reaching it.
Kept: fullband pins (no bandwidth cost), UA-gated NACK code (honest
per-browser advertisement), speaker output picker, 700ms playoutDelayHint.
Audio NACK is an asymmetric feature — the SENDER has to respond to
retransmit requests. Chrome implements both directions; Firefox
implements neither for audio. Blanket-advertising NACK in offers from
Firefox publishers caused Chrome receivers to wait for retransmits
that never arrived and skip audibly.
Solution: each browser advertises only what it can back up. Probe via
RTCRtpSender.getCapabilities('audio') and look for nack in Opus's
rtcpFeedback list. Chrome → true → advertise. Firefox → false → omit.
Cached after first call (capabilities are static per UA).
Chrome → Chrome: NACK advertised, both sides honor it ✓
Chrome → Firefox: NACK advertised, Firefox ignores (no NACK requests) ✓
Firefox → Chrome: NACK omitted, Chrome never NACK-waits → no skip ✓
Firefox → Firefox: NACK omitted, both sides ignore ✓
No LCD across mixed rooms — each side gets the best contract its own
browser can honor. Logs "audio NACK as sender: on|off" once per session
for diagnostic.
Audio NACK was advertised in preferStereoOpus(). Chrome receivers will
request retransmits when they see rtcp-fb:nack on the Opus PT, but
Firefox senders never reply (Mozilla never shipped the responder side).
Chrome's jitter buffer waits for recovery that never arrives, then
skips — audibly choppy in mixed Firefox→Chrome rooms.
useinbandfec + 700ms playoutDelayHint already cover the loss case
without protocol churn. Comment block warns future code not to re-add
audio NACK without verifying both sides actually implement it for the
negotiated PT.
Keeps: 510k Opus ceiling, fullband pin, cbr=0, maxptime=120, speaker
picker — none of those are the choppy source.
Codec headroom (Tier 1):
- Opus 256 kbps → 510 kbps (spec ceiling) at every music-mode site:
mic publish (SFU + mesh), screen audio, game-share audio. Both
SDP maxaveragebitrate and RTP-level encodings[0].maxBitrate raised.
- Pin Opus fullband: maxplaybackrate=48000, sprop-maxcapturerate=48000
so BWE pressure can't opportunistically narrow to 16/24 kHz.
- cbr=0 explicit (VBR — Opus only spends what it needs).
Loss resilience (Tier 2):
- Audio NACK feedback (a=rtcp-fb:<opus_pt> nack) injected after Opus
rtpmap. Reactive packet recovery, near-zero overhead, ignored by
browsers that don't honor it.
- a=maxptime:120 in music mode advertises tolerance for larger frames
from peers (more encode context = cleaner music at same bitrate).
Playback chain (Tier 3):
- New speaker output selector (setSinkId) so listeners can route peer
audio to studio monitors / external DAC. Hidden on Safari (no
setSinkId on HTMLMediaElement). Persists to localStorage; applied
to every remote <audio> on creation and on user switch.
Live sessions need leave+enter to pick up the new SDP (per CLAUDE.md —
existing RTCPeerConnections are locked to whatever was negotiated at
creation time).
make stamp updates web/zebra-spaces.html footer date + hashes.
Server-side counterpart to proxy.unturf.com edb1009. Page sends
{type:"alive"} every 15s via setInterval on the signal WS; backgrounded
tabs throttle this timer hard (1Hz Android, ~1/minute iOS) so a
truly frozen tab reliably misses 3 heartbeats and the server's
aliveTTL=45s fires.
Pairs with the just-shipped pagehide-bye for the two distinct
failure modes:
- clean tab-close → pagehide fires bye → instant strong-leave
- dirty close / OS-backgrounded → JS heartbeat stops → server
aliveTTL fires after ~45s → standard hiccup grace → peer-left.
Two moderation actions, two buttons:
- kick : evict the session, allow rejoin
- ban : evict + block the pubkey (old 'boot' semantics)
Renders 'X was kicked by Y' vs 'X was banned by Y' off the new
peer-booted.action field. Self-notice text follows the same split.
pagehide / beforeunload now sends a synchronous 'bye' so a closed
tab counts as a strong-leave (peer-left + SFU evict immediately)
instead of waiting 8s for the hiccup grace. Fox 2026-06-03 —
"will closed tab on phone but the audio kept playing until i
kicked him out". With the new bye on pagehide his tab-close will
trigger the same fast-path the leave button does.
beforeunload kept as a fallback for older desktop browsers that
fire it before pagehide; pagehide is the cross-mobile primary.
Live-room defect (2026-06-03): Will refreshed his browser; the
supplant fired a SECOND ontrack for kind=camera pub=Will at +16s.
The page swapped srcObject on the existing <video>, called play(),
got 'fetching process for the media resource was aborted by the
user agent at the user's request' — browser refused to start a new
playback session on the same element after its autoplay grant had
already been consumed. Tile sat black on the moderator's screen.
Fix: swapFreshVideoElement() — on supplant, replace the <video>
with a freshly-built one carrying the same attrs. A brand-new
<video> is eligible for muted-autoplay even when the prior one had
its play() rejected, so the supplant lands cleanly without needing
a tap. Applied to both the thumbnail and the spotlight tile.
Mesh test harness extracts the helper so renderVideoTile still
runs end-to-end under the sandbox.
- moderation: 'boot' button onclick now .catch'es and logs server
errors. Server now returns 'boot target not found (stale uuid?)'
instead of silently no-op'ing when the page's member roster lagged
the room — the moderator was clicking 'boot' and seeing nothing
happen because their page held a stale uuid.
- diagnostic: watchFirstFrame logs 'still black after 2500ms — no
keyframe?' on any fresh SFU video track (screen/camera/game) whose
decoder never unmutes. Pairs with the SFU's extended kfBurst so we
can tell next session which path actually broke when a camera tile
renders black.
multi-peer-mesh test harness extracts the new fn alongside
watchVideoTrackForRemoval so handleRemoteSfuTrack still runs end-to-end
in the headless sandbox.
Stamp date refresh on the other pages (no behavior change).
Telemetry showed Willdabeast's mesh PC (peer edc257b4...) failing every
~20s in a perfect loop for 4+ minutes — the old 1.5s flat retry was
firing connectToPeer over and over against a NAT we couldn't traverse.
Each cycle ate CPU, network, signaling churn, and contributed to the
robot-voice + lost-mic noise we've been chasing.
New behavior:
- 2s -> 4s -> 8s -> 16s backoff (capped) between attempts
- Hard cap at PEER_MESH_MAX_RETRIES = 4 attempts. After that,
peerMeshGiveUp.add(uuid): connectToPeer becomes a no-op for that
uuid and audio rides on SFU permanently.
- Successful 'connected' transition resets the retry counter so a
much-later transient blip gets a fresh budget.
- peer-left / peer-booted clear all retry state via
clearMeshRetryState() so a rejoin from the same uuid starts over.
Log lines surface the decision so the next pathological mesh peer
shows up in CLIENT_LOG as 'mesh failed Nx — giving up, audio stays
on SFU' rather than a wall of identical 'failed — reconnecting' lines.
Side benefit: less mesh churn means the SFU mic fallback path (the
2f1e481 + 441c086 fix) gets to settle and stay settled, so receivers
don't keep flipping their audio elements between mesh and SFU
streams under a failing peer.
Were in the right column inside .controls, which on mobile cramped the
latency rows and squeezed the share URL. Now they sit as siblings of
sec-log below the .page grid — full viewport width everywhere. Order
top-to-bottom under .page:
latency
link
log
Same DOM whether the controls panel is shown or hidden, so the
mobile + hide-panel layout no longer needs the cameras column to
absorb them awkwardly.
The role-change notices (you-are-now-a-speaker / stepped-down / moved-
to-listener / promoted-to-cohost / now-the-host) sat above the room
list — top-of-page real estate for what's actually a personal status
update. Move sec-notice to sit BELOW sec-listener-actions so the
message reads in the same gaze as the controls it affects.
Was: leave button cleared MUTE_STATE_KEY, so a rejoin via bless-reclaim
came back unmuted regardless of prior choice. Fox: 'when I leave and
rejoin the mic state is unmuted.'
Now: keep MUTE_STATE_KEY in sessionStorage on leave (same tab, same
identity → same preference). Next promotion or bless-reclaim restores
via applyMuteState, matching the hard-refresh path's behavior. The
local in-page `muted` variable still syncs to whatever's in storage
so the dormant-tab state is consistent.
Two more Web Audio tones, completing the doorman set:
- playToneLeave: E5 -> C5 descending major third (mirror of join's
C5 -> E5 ascending). Fires on peer-left (any role leaves the
room post hiccup-grace) and peer-booted (mod kicks someone),
skipping self on the boot case.
- playToneStepDown: single G4 low sine blip — softer than the
arrival/departure pair. Fires on role-change for OTHER peers
when canSpeak(prev) && !canSpeak(next): they're still in the
room, just lost mic privileges.
Full notification ladder:
C5 -> E5 guest arrived
A5 (triangle) hand raised
G4 speaker stepped down (still here)
E5 -> C5 guest left / was kicked
Was: tones skipped when document.hidden. That's wrong for the doorman
cohost use case fox flagged — the whole point is to know a guest just
arrived without watching the tab.
Remove the document.hidden gate. Also defensively resume() the
AudioContext if it slipped to 'suspended' (some mobile browsers
suspend on tab-hide) — keeps the timeline alive so the scheduled tone
actually fires.
Reports of robot-voice artifacts from a peer on a different Wi-Fi —
classic symptom of jitter-buffer under-runs (Opus PLC kicks in,
generates synthetic samples that sound vocoder-y). 400ms was tight
enough that bursty inter-arrival on cross-AP / cellular hand-off
networks would exhaust the cushion.
700ms costs barely-audible end-to-end latency (well under the 1s
people perceive as 'walkie talkie'), well above typical Wi-Fi peak
jitter, and matches both the SFU subscribe path and mesh peer path
so the room sounds consistent regardless of how the audio is being
delivered.
Bitrate / FEC / DTX settings unchanged — adding bandwidth would
make a lossy link worse, not better.
Two Web Audio synthesised tones, no asset shipping required:
- playToneJoin: C5 -> E5 ascending major-third chime (~340ms total),
fires on every peer-joined. Server broadcasts peer-joined to
everyone except the joiner via broadcastExcept, so existing members
always hear it for new arrivals only.
- playToneRaise: single A5 triangle blip (~260ms), fires on
hand-raised UNLESS it's the raiser's own hand (server broadcasts
hand-raised to all so we filter on m.uuid !== myUUID).
Tones share a lazily-instantiated AudioContext (the user already
gestured to enter the room, autoplay policy is satisfied). Skipped
when document.hidden so background tabs stay quiet. Short
exponential attack + decay envelope avoids click artifacts.
Two new logLine calls in the SFU mic ontrack handler:
- 'sfu mic skipped for <uuid> — mesh peer connected' when the mesh is
serving (expected silence)
- 'sfu mic taking over for <uuid> — mesh state=<failed|disconnected|
closed|...>' when SFU stream attaches over a dying mesh PC
Makes the 'why don't I hear them' question one grep away in CLIENT_LOG
next time the cascade happens.
CLIENT_LOG telemetry showed the phone re-promoted to speaker, published
to SFU successfully, but neither the host nor the other speaker heard
them. Cause: the page's ontrack handler skipped attaching SFU mic
whenever peers.has(uuid) — even if that peer's mesh PC was in
'failed' or 'disconnected' state from an earlier role-change cycle.
Fix two paths:
1. ontrack-side: only skip SFU mic when peers.get(uuid).connectionState
is actually 'connected'. A stale entry or a failing PC no longer
blocks the SFU fallback; receiver hears the publisher via SFU until
mesh actually delivers.
2. mesh-fails-side: when an existing mesh PC transitions to 'failed',
the audio element was bound to the dying mesh stream. Reach into
sfuStreamsByPubHex and re-attach the cached SFU stream so the
listener hears continuous audio while the mesh reconnect runs in
the background, instead of a silent gap.
Mesh stays the preferred path when it's actually working — only
takes over the audio binding via its own ontrack when 'connected'.
Bug surfaced in CLIENT_LOG telemetry from a real session: when the
host's screen publish PC hit ICE failure, the watchPublishPC auto-
rebuilder called sfuPublishScreen() which immediately failed with
'getDisplayMedia requires transient activation from a user gesture.'
The auto-call path has no click, so getDisplayMedia can never succeed
from there.
Match the game-share pattern: on 'failed' tear down the dead PC + log
a clear 'tap share screen to re-share' message + clear state via
sfuUnpublishScreen(). User clicks the share button → picker opens (the
click IS the gesture) → fresh publish PC.
Mic + camera keep their auto-rebuild because getUserMedia honors the
persisted permission grant, no gesture needed.
Boot is the noisier sibling of demote — booted users can't publish
either, so their video tiles must come down immediately. The SFU-side
eviction (server /internal/block + OnConnectionStateChange) propagates
'ended' eventually but lags enough that a kicked speaker's camera tile
stayed visible after the boot. Authoritative removal by pubkey, same
pattern as the role-change-demote fix from 1e94fa6.
Was: when a speaker was bounced to listener their tiles froze on every
other peer until either the SFU's removePublisher path finally fired
'ended' on the subscriber's tracks or the 60s/120s mute window reaped
them. Pion's OnConnectionStateChange can lag and SSE renegotiation can
race, leaving visibly-frozen tiles for tens of seconds.
Authoritative removal: when role-change strips speak rights from
peer X (canSpeak(prev) && !canSpeak(next)), drop every kind of X's
video tile on the receiver side immediately. The demoted user can't
publish anymore by definition, so the tiles are guaranteed-stale —
no need to wait for the data-plane path to catch up.
Mirrors the existing peer-left handler which removes by pubkey.
Three-layer defense for the mic-state channel:
1. Authenticity: send signs over 'mic-state|' + room_id + payload
with the identity ed25519 key. Receivers verify against the
member's roster pubkey (which the server tied to me.uuid at join
time). Missing or invalid sig -> drop the message + log err line
to telemetry.
2. Freshness: payload carries a wall-clock timestamp. Receivers reject
anything older than 30s in either direction (covers clock drift).
3. Monotonicity: each peer's last-accepted timestamp is tracked on
mm._micT; an old or equal-timestamp message is silently dropped,
so a replay of a previously-valid mic-state can't reset state to
a stale value.
Pairs with signal 59ad814.
Pairs with signal 33dcabf. Fixes the 'host refreshed and now sees
everyone as unmuted' UX gap. Two paths:
- On welcome (any rejoin): send mic-state-req; every speaker in the
room responds with their current mic-state.
- On peer-joined for anyone else: if I'm a speaker with a live mic,
re-broadcast my own state so the new arrival sees it without
having to ping.
Both are bounded: only speakers respond, and the message is the same
E2E-encrypted blob used for normal mic toggles, so no extra privacy
surface beyond what already exists.
Reverts 35908cf's resume banner. The browser security model makes
getDisplayMedia ALWAYS show the picker — selection can't be remembered
across reload — so a resume banner adds an extra click without saving
the user from anything. Single 'share screen' button stays the canonical
path.
Add picker hints on getDisplayMedia that Chrome honors (Firefox / Safari
silently ignore — no behavior change):
surfaceSwitching: 'include' — show the in-stream switcher widget
selfBrowserSurface: 'include' — let the user pick this tab if useful
systemAudio: 'include' — surface the tab-audio toggle by default
Net result: same gesture flow as before the resume experiment, slightly
friendlier picker on Chrome, no extra UI.
Camera silently auto-resumes on refresh (getUserMedia keeps the
permission grant); screen-share couldn't because getDisplayMedia
requires transient activation — a fresh user gesture. The previous
attempt fired in a setTimeout after welcome, which has no gesture, so
the browser instantly returned NotAllowedError. We then dropped
screen-state tracking entirely.
This time: track ACTIVE_SCREEN_KEY in sessionStorage when sfuPublishScreen
succeeds; on welcome, if the user can speak AND the key is set,
unhide #sec-screen-resume — a banner with a single 'resume screen
share' button. The button click is the gesture; its handler calls
sfuPublishScreen() synchronously, and getDisplayMedia is the first
await inside, so the transient-activation flag is preserved through
the chain (same shape as the regular 'share screen' button, which
proves the mechanic works every day).
UX:
- Camera: silent resume on welcome (unchanged)
- Screen: banner appears, user taps once, picker opens
- Mobile: getDisplayMedia missing — the resume button rejects with a
logLine error and self-clears the key (handled by .catch on the
resume click)
Key clears on explicit unshare + on demote to listener + on rejection,
so the banner doesn't linger after the underlying state changes.
Listener -> speaker/cohost/host transition is a fresh mic grab — no
hot-mic surprise. Set muted=true + persist to sessionStorage BEFORE
ensureMicAndUI runs, so applyMuteState picks it up cleanly when the
mic track is acquired. User can click 'unmute' when ready.
Doesn't affect bless-reclaim rejoin (welcome path), where the user's
previously-saved mute state is restored — they come back in the same
mute state they last chose.
Receive-side mesh state machine (the bit that decides which peer gets
which tile) was buried inside an anonymous pc.ontrack callback inside
sfuSubscribe(). Extracted into a named top-level function
handleRemoteSfuTrack so tests can drive it directly with synthetic
RTCTrackEvents — no real RTCPeerConnection, no real SFU.
test/multi-peer-mesh.test.js pins fox's stated invariant:
'whatever one device shares all should see, and when unshared none
should see.'
Eight scenarios across 2-3 fake browser sandboxes, each holding the
shipped handleRemoteSfuTrack + renderVideoTile + removeVideoTile +
watchVideoTrackForRemoval + the maps they own:
- one peer publishes camera -> every other peer ends with that pubHex
in cameraStreams + a tile entry
- one peer unshares (track ended) -> every other peer drops that pubHex
- one peer unshares mid-flow (mute past window) -> drops correctly
- hiccup supplant (same pubkey, new track) -> tile preserved AND
pointed at the new stream object (this is the MSID-supplant fix from
d5e9e4e — fresh MediaStream per track means the video element binds
to the new RTP cleanly)
- hiccup supplant + the OLD track's stream-identity guard prevents the
NEW tile from being reaped
- supplant + sustained mute past window on the NEW track -> reaped
correctly
- echo guard: a peer's own publish never enters their own cameraStreams
- three publishers fan-out: A B C all publish, every peer ends with
exactly the other two
Wired into Makefile as test-mesh + added to test-all. Pure Node, no
browser or proxy server needed. Will catch the regressions where one
peer's publish/unpublish silently desyncs another peer's view.
Diagnostic-only: logLine fires on every share/stop button click with
the current sfuXPC/sfuXStream truthiness so the telemetry channel
shows whether (a) the click reached the JS at all, (b) the unpublish
function bailed at its 'nothing to do' early return, or (c) it
actually entered the close path. Helps diagnose the 'stop sharing
doesn't work' report without copy-pasting.
Pairs with signal commit 3aebd67. Every logLine call after the local
render also fires a WS message to the signal server, which writes a
CLIENT_LOG line into /var/log/zebra-spaces-signal.log. Lets us debug
WebRTC cascades across multiple peers from a single grep instead of
asking each user to copy-paste their tab's log column.
Real cause of 'host can't see laptop's camera on rejoin' (and the phone-
camera analogue): SFU's TrackLocalStaticRTP uses the same streamID
(shortPub-kind) for every publish of a given (pubkey, kind). When a
publisher supplants themselves the new track's MSID matches the old
one. Per WebRTC spec the browser merges it into the SAME MediaStream
object — ev.streams[0] is the same instance as before, containing
BOTH the dead old track AND the new live one. Setting
video.srcObject = ev.streams[0] doesn't switch the source; the video
element keeps showing the old track's last frame, reports muted, and
the 60s mute-window then reaps a tile that was never going to come
back on its own.
Fix: construct a fresh MediaStream from just ev.track. The video
element binds to the new RTP cleanly and the receive-side state
machine sees a real unmute as soon as packets arrive.
Repro: host shares camera, laptop sees it fine, phone (FF Android on
cellular) reaped the tile at 15s even though the publisher was alive
and well. The laptop's subscribe path doesn't see the same RTP jitter
the phone does — 15s was too tight for mobile networks. 60s sits
above the typical NACK/transport-cc recovery window and Pion's ICE
timeout: a path that's really broken fires renegotiation + 'ended'
within that window anyway, so the only difference is fewer false
reaps on jittery mobile paths.
Screen + game window stays at 120s — static content needs the longer
fuse.
Matches signal commit 0547b4c. The leave button now sends a 'bye'
message before closing the WS — the server distinguishes a strong
leave from a hiccup, and we want the strong-leave path here. Without
the bye, an explicit leave would defer peer-left for 8s and other
peers would see the user's tiles + mesh PCs linger.
Screen shares and game shares can sit static for long stretches — a still
desktop, a paused video, a code editor with no caret movement. The
encoder genuinely stops emitting RTP, the subscriber's track goes muted,
and the 15s camera window would falsely reap the live tile.
watchVideoTrackForRemoval now takes a per-call windowMs; the sub-PC
ontrack handler passes VIDEO_REMOVE_MUTE_WINDOW_SCREEN_MS (120s) for
screen + game and VIDEO_REMOVE_MUTE_WINDOW_MS (15s) for camera. A
genuine unshare still resolves through the 'ended' path within a
frame, so the longer window only affects the slow-failure case.
Tests bumped to 18: new screen-window assertions + invalid-windowMs
fallback to the default rather than disabling removal entirely.
