Sender verification for the AI filter: after attaching, the fork now checks
that the RTCRtpSender actually carries the processed track and enforces the
swap if LiveKit skipped it silently - the Safari field finding where level
0-100 made no audible difference. The log line states the outcome.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Opens the AI noise suppression gate after the passed two-person acceptance:
checkbox and slider return to the in-call audio settings, clients with the
setting enabled get the filter again. The rollback lever for any regression is
the gate in threadnet-call, not a deployment revert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Way B from #0054: the AI filter attaches to the local microphone track after
publication, with its own AudioContext on just that track - no webAudioMix, no
processor key in the capture defaults in any state. The feature gate stays
closed; a single test client opts in via two localStorage keys. For everyone
else this build behaves identically to .9.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The .8 widget broke unmuting in production (both with the AI filter on and off);
threadnet-call dcc8643 restores the upstream off-path and hard-gates the feature
until the webAudioMix decision. Verified locally end to end: the installed
package carries the model assets, webpack lands them under
webapp/widgets/element-call/assets/dfn3, and the widget index.html references
the .9 bundle (0.19.2-threadnet.9+dcc86431).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Brings the AI noise suppression (ADR-0018) into the widget we actually ship.
The .7 package built and ran fine but carried no model assets, because the
embedded Vite config had publicDir off — the filter would have been dead only
inside the widget, and nowhere else.
Verified the whole chain locally rather than trusting the green build: the
23 MB of model and wasm arrive under webapp/widgets/element-call/assets/dfn3,
which is the path the widget requests at runtime.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Erste Widget-Version mit VITE_PRODUCT_NAME: Fehlermeldungen und die Versionszeile im Entwicklermodus sagen nicht mehr "Element Call".
pnpm-lock.yaml von Hand nachgezogen (Version an 6 Stellen, integrity aus dem veroeffentlichten Tarball berechnet) - auf diesem Mac gibt es kein Node. Faellt beim CI-Schritt pnpm install --frozen-lockfile auf, falls etwas nicht stimmt.
Die uebersprungene .6 liegt kaputt in der Registry, siehe axion1337.chat/threadnet-call#4.
The floating github:matrix-org/matrix-js-sdk#develop reference was
resolved to a stale commit missing src/oidc/authorize.ts (breaking the
webpack build). Investigated moving to the current develop HEAD instead
(191908da) - turned out to be worse, not better: that commit renamed the
entire src/oidc/ module to src/oauth/ with a materially different API
(generateOidcAuthorizationUrl/completeAuthorizationCodeGrant/OidcError
don't exist under those names anymore). Rather than porting our OIDC
login code to the new API sight-unseen, pinned to d19cb751 - the last
develop commit before that rename, verified to have both the file at
the expected path and the exact exports apps/web imports.
Also switched the Element Call embedded widget dependency from
upstream's @element-hq/element-call-embedded to our own published fork
(@sorb/threadnet-call-embedded@0.19.2-threadnet.5) - a full rebuild was
otherwise silently bundling the unmodified upstream widget, discarding
every Element Call customization (Video-tab quality settings, German
translations, codec list fix).
Thore CimbalandClaude Opus 4.8
sorB