From 0ce1339f8e69713478b62e9b94390b0a61ca4f4c Mon Sep 17 00:00:00 2001 From: Russell Ballestrini Date: Sat, 6 Jun 2026 14:37:18 -0400 Subject: [PATCH] zebra-spaces: prefix-match in flushSfuStreams (kill silent fedora-chrome listener) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fox 2026-06-06: "fedora chrome is flawless besides not able to hear any mics it was working a few days back and nothing was changed on the system, only thing we changed was our zebra codes." The race: on a listener joining a room with existing speakers, the SFU sub PC ontrack can fire BEFORE the signal-server peer-joined event populates `members`. handleRemoteSfuTrack already does prefix resolution at line ~4640: let pubHex = pubHex16; for (const [, mm] of members){ if (fh.startsWith(pubHex16)){ pubHex = fh; break; } } When the roster is empty, the loop finds nothing, pubHex stays the 16-char streamID prefix, and sfuStreamsByPubHex.set(pubHex, stream) caches under that short key. peer-joined arrives later, flushSfuStreams runs to attach what was cached — but its inner match was strict ===: if (mm.pubkey && hex(unb64(mm.pubkey)) === pubHex){ mm.pubkey decodes to the FULL 64-char hex; pubHex from the cache is the 16-char prefix; === never matches; listener stays permanently silent for every speaker who was already in the room. Pre-cascade this defect was masked: the old guard `!remoteAudio.has(uuid)` was always true for worklet listeners (remoteAudio is the