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.
alpenglow.jpg (John Towner, Unsplash) ersetzt lake.jpg als Hintergrund der Login-Seite. Die Unsplash License erlaubt kommerzielle Nutzung und Aenderung ohne Genehmigung und verlangt keine Namensnennung - wir nennen ihn trotzdem, das ist die faire Form.
Die Danksagung ist dabei bewusst nicht uebersetzt: der Schluessel credits|default_cover_photo liegt in 32 Sprachdateien, 31 nennen Elements Fotografen namentlich. Nur en/de anzupassen haette in 29 Sprachen eine falsche Attribution stehen lassen, und diese 29 pflegen wir nicht - sie kommen aus Elements Uebersetzungsdienst.
lake.jpg ist entfernt, weil es durch diese Aenderung unerreichbar wird - 610 KB, die sonst in jedem Image mitfahren.
Nachtrag zu v0.4.0. Meine Icon-Arbeit deckte nur vector-icons/ ab; an vier
weiteren Stellen stand weiterhin Element - sichtbar, nicht im Verborgenen.
<title>Element</title> stand statisch in der index.html. Im Browser-Tab stand
also 'Element', unabhaengig vom Icon daneben. Ebenso application-name und
apple-mobile-web-app-title, die beim Ablegen als PWA greifen.
favicon.ico neu: Browser fragen diesen Pfad automatisch ab, unabhaengig von den
<link rel=icon>-Tags. Bisher kam dort ein 404 mit text/html zurueck - derselbe
Fehler, den wir am 2026-08-02 im Docusaurus-Wiki hatten. Sieben Groessen von 16
bis 256, aus derselben zentrierten Quelle wie alle anderen Icons.
Fehlerseite (ErrorView): zeigte Elements element-app-logo.png mit alt='Element'.
Ausgerechnet die Seite, die man sieht, wenn sonst nichts funktioniert.
Desktop-Hinweis (SdkConfig defaults): trug Elements Logo und verlinkte auf
element.io/get-started - also auf fremde Downloads, obwohl wir eigene Builds
ausliefern. Zeigt jetzt auf unsere Releases.
Die drei Bildverweise gehen alle auf vector-icons/512.png statt auf neue Dateien:
webpack kopiert aus res/ nur themes/** und vector-icons/**, und eine zweite
Logo-Datei koennte von den uebrigen abdriften.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Zwei Haelften desselben Issues, bewusst in einem Commit, weil sie zusammen
gebaut und ausgeliefert werden.
Desktop-Icons: build/icon.png war byte-identisch mit dem alten, unzentrierten
Web-Icon - das Motiv klebte an der Oberkante (Rand oben 3 %, unten 40 %). macOS
und Windows zeigten also dasselbe schiefe Bild wie der Browser-Tab. Alle vier
Artefakte aus der jetzt zentrierten Quelle neu erzeugt: icon.png, icon.ico
(sieben Groessen von 16 bis 256), das Layer-Asset des macOS-Icon-Composers und
icon.icns ueber iconutil (10 Einzelbilder, 16-512 plus @2x). Alle vier gehen auf
dieselbe Datei zurueck, sie koennen also nicht mehr auseinanderlaufen.
About-Attribution: 'ThreadNet - powered by Element' steht jetzt in Einstellungen
-> Hilfe & Info direkt unter der Client-Version, mit Link auf element.io. Das
war der eigentliche Zweck des Issues - bisher stand die Zeile nur in der
Build-Beschreibung des Desktop-Pakets und war im Client nirgends sichtbar.
Zwei bewusste Entscheidungen dabei, beide im Code kommentiert:
- NICHT in getVersionTextToCopy aufgenommen. Der Text dort landet in
Fehlerberichten; die Herkunft des Forks ist da nur Rauschen.
- Ohne _t(). Ein Markenhinweis wird nicht uebersetzt, und jeder zusaetzliche
i18n-Schluessel ist Reibung beim naechsten Upstream-Merge - genau das, was das
Issue mit 'chirurgisch halten' meint.
Das Stylesheet nutzt nur Variablen, die im Projekt bereits verbreitet sind
(--cpd-space-2x in 43, --cpd-color-text-secondary in 28,
--cpd-font-body-sm-regular in 22 Dateien) - kein Blindflug mit erfundenen Tokens.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Die Web-Icons trugen bereits die ThreadNet-Marke - anders als im Issue vermerkt.
Sie waren aber falsch zugeschnitten: Rand oben 3 %, unten 40 %, das Motiv klebte
an der Oberkante. In runden und quadratischen Icon-Slots sitzt es dadurch
sichtbar zu hoch.
Alle sieben Groessen aus dem 1024er neu erzeugt: auf die Motiv-Bounding-Box
beschnitten und bei gleicher Groesse (81 % der Kante) mittig gesetzt - jetzt
21 % Rand oben wie unten. resize() statt thumbnail(), sonst waere nur verkleinert
worden.
theme_color stand auf #76CFA6, Elements Mintgruen. Die Marke ist #ed4f4c
(dominante Farbe des Motivs gemessen, nicht geschaetzt) - das Gruen war ein
Upstream-Rest und faerbte die Browser-/PWA-Leiste falsch ein.
config.sample.json: brand von Element auf aXion1337.Chat, damit die Vorlage
zeigt, was Prod tatsaechlich setzt.
Nicht angefasst: der Favicon-Snapshot-Test - er prueft Canvas-Operationen
(clearRect, Dimensionen), nicht den Bildinhalt, und bleibt gruen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Gestern wurden nur icon.png und icon.icns getauscht; Windows (.ico) und der
Web-Client (res/vector-icons/, manifest.json) trugen weiter das Element-Icon.
Dazu ein echter Fehler behoben: die Icons wurden mit PIL.thumbnail() erzeugt -
das skaliert NUR nach unten. Das 277px-Motiv wurde in 1024er-Icons daher nie
vergroessert und fuellte ueberall bloss 54% x 38% der Flaeche. Jetzt mit resize()
aus dem 1024er-Original: 81% Breite statt 54%.
Ersetzt: web/res/vector-icons/{24,120,144,152,180,512,1024}.png, manifest.json
(name/short_name -> ThreadNet), desktop/build/icon.{png,ico,icns}.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Synapse's own check_media_file_for_spam module can never see E2EE
attachment content - only the client ever holds the decryption key.
Adds two hooks that call a self-hosted scan service
(https://axion1337.chat/_scan, deployed separately in the gitops repo):
- DecryptFile.ts: scans every decrypted attachment (image/audio/video/
file all funnel through this one function via MediaEventHelper)
before returning it as a Blob.
- ContentMessages.ts: scans plaintext before encryption/upload in
uploadFile(), the shared function behind all attachment uploads
(main file, thumbnails, voice messages), regardless of room
encryption state.
New ContentScanRejectedError surfaces through the existing error-
rendering paths (MediaProcessingError, upload failure dialog) using
the same pattern as DecryptError/DownloadError/UploadFailedError.
Live-tested: EICAR blocked pre-upload in encrypted rooms and DMs;
receive-side hook also blocks EICAR sent by an unpatched client
(app.element.io), confirming it isn't just self-protection for our
own uploads. Fails open on scanner errors so an outage can't block
all uploads/downloads.
The earlier script-permission fix (5e3254d) only covered scripts
invoked by apps/web's own Dockerfile/CI at the time. Found 9 more
non-executable scripts (644 instead of 755) while building the
Electron desktop app via apps/desktop/dockerbuild - same root cause,
different invocation paths.
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