The previous commit added no pipeline run: .npmrc is not in the changes list that
triggers one. That file decides which registry dependencies come from, so a change
to it deserves a build rather than a wave-through. This commit touches
.gitlab-ci.yml, which is on the list - so it verifies itself.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nothing in this repo said where @sorb/threadnet-call-embedded comes from. It
worked only because pnpm-lock.yaml carries the full tarball URL and CI installs
with --frozen-lockfile; the first version bump drops that cover. Today that ends
in a 404 because the name is still free on npmjs - which makes our only
protection the fact that nobody has claimed @sorb there. Claim it and the same
command resolves silently against a stranger's package, in the exact moment a
fresh download looks normal.
The checked-in .npmrc closes the wrong path instead of documenting it. It holds a
URL and no secret: read access to the registry is anonymous.
Upstream's .gitignore ignores /.npmrc - reasonable where the file holds tokens,
and it would have swallowed this fix without a word. The negation is explicit and
carries the reason, so the next merge does not quietly restore the hole.
Verified in an isolated tree, not assumed: without the file pnpm resolves to
npmjs and fails; with it the scope resolves to rohana at the same integrity hash
the repo lockfile already carries; with rohana unreachable the install fails
outright rather than falling back to npmjs. pnpm install --frozen-lockfile still
passes and leaves the lockfile untouched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Field test F-011 found four of five components carried no pointer file, so a
session landing here had no path to the group rules at all. CLAUDE.md is the
one-line pointer the check looks for; AGENTS.md links the canonical rules in the
management repo (with the Gitea mirror URL for readers outside the lab) and
otherwise carries only what is specific and easy to get wrong here.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The desktop variant had no bug_report_endpoint_url at all, so the whole section stayed hidden and a desktop user could not produce logs for a report. Setting local shows a Download logs button that writes them to the device and uploads nothing.
Matches what the web client now serves. Takes effect with the next desktop build.
Refs axion1337.chat/ThreadNet-Web#9
Moving a tag retriggers docker_web, which would rebuild a published release from old source against today's base images and dependencies and push it over the existing one. On 2026-08-09 that nearly happened to v0.4.0 while the rewritten tags were force-pushed; it was averted only because the protected registry variables were unavailable in that window, so docker login failed first.
The job now aborts if the target tag already exists in the registry. latest-ci stays overwritable on purpose - it names the newest state, not a version, and carries no promise.
Closesaxion1337.chat/ThreadNet-Web#14
A commit touching only docs/ produced a pipeline with zero jobs, which GitLab marks as failed - pipelines 203 and 204 on 2026-08-06 were both red for nothing. Cause is the needs chain: web is skipped by its changes rule, and desktop_linux/desktop_windows depend on it, which collapses the whole pipeline including the manual jobs.
This matters beyond cosmetics: gitops/CLAUDE.md makes the red pipeline the alarm for the TURN rotation, stating there is no separate reminder. Red that means nothing trains people to stop looking.
The path list is a YAML anchor shared with the web job - two copies would drift. CI_PIPELINE_SOURCE == web stays allowed so the manual maintenance jobs remain reachable via Run pipeline.
Meine Aussage "ClamAV kostet mehr als das gesamte Branding zusammen" war so nicht haltbar: gemessen sind es ~130 zu ~104 Zeilen, der groesste Einzelpatch ist sogar Branding (HelpUserSettingsTab.tsx, 71 Zeilen).
Der Unterschied liegt woanders: Branding-Patches stehen am Rand und sind nach einem Umbau wiederfindbar, ClamAV-Patches stehen mitten in Entschluesselungs- und Fehlerpfaden. Dazu der eigentliche Haken - verschiebt Upstream die viewmodels/-Dateien, entsteht kein Konflikt, die Zeilen sind schlicht weg und Git meldet nichts. Deshalb ist dort ein Funktionstest maszgeblich, nicht die Merge-Ausgabe.
Refs axion1337.chat/ThreadNet-Web#7
Der wichtigste Befund ist die Grundlage, nicht die Liste: das Repo enthaelt KEINE Upstream-Historie. Element Web 1.12.17 kam am 2026-05-10 als kompletter Baum herein, im selben Commit wie das erste eigene Feature. Es gibt also keinen gemeinsamen Vorfahren mit element-hq/element-web - ein git merge ist nicht moeglich, ein Update heisst neu auftragen.
Gemessen statt geschaetzt: 102 geaenderte Dateien, davon nur 12 Upstream-Quellcode. Fuenf davon Branding (flach, isolierbar), sieben ClamAV in der Medien-Pipeline - und genau dort baut Upstream gerade auf MVVM um. Das Update wird an ClamAV mehr kosten als am gesamten Branding.
Refs axion1337.chat/ThreadNet-Web#7
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.
Die heute im Web gesetzten branding-Werte fehlten der Desktop-Config. Ohne sie
faellt AuthHeaderLogo.tsx auf themes/element/img/logos/element-logo.svg zurueck -
die Anmeldemaske des Desktop-Clients haette also weiter Elements gruenes Logo
gezeigt, waehrend der Web-Client bereits die ThreadNet-Marke traegt.
vector-icons/512.png liegt im webapp-Bundle des Desktops (geprueft), der Pfad
loest also auch dort auf.
Chirurgisch eingefuegt, nicht neu serialisiert - die 17 Themes und der
Gedankenstrich in der Beschreibung bleiben unangetastet.
Danach gilt: Web-Konfiguration ist eine echte Teilmenge der Desktop-Konfiguration,
ohne einen einzigen Wertkonflikt (verglichen ueber alle verschachtelten
Schluessel).
Refs ThreadNet-Web#1
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Upstream setzt mac.icon auf build/icon.icon - das Icon-Composer-Bundle von
macOS 26. Dessen Verarbeitung ruft actool auf, das es nur mit dem vollen Xcode
gibt (~10 GB, App-Store-Login). Mit blossen CommandLineTools scheitert damit
JEDER macOS-Build:
⨯ Failed to check actool version. Is Xcode 26 or higher installed?
Die bisherige Diagnose in management#22 war falsch: Dort stand, nur das
DMG-Target brauche actool und das ZIP baue problemlos. Tatsaechlich trifft es
alle macOS-Targets, weil mac.icon fuer alle gilt - das ZIP scheitert genauso.
Der dort empfohlene Ausweg (DMG per hdiutil bauen) haette ein Problem geloest,
das gar nicht am DMG lag.
Loesung: mac.icon und dmg.badgeIcon auf das klassische build/icon.icns. Damit
baut electron-builder ZIP UND DMG selbst, inklusive Blockmap - verifiziert am
2026-08-06, beide Artefakte in Release v0.4.1.
Umgesetzt als Variantenoption statt als Aenderung an Upstreams Defaults: Die
Werte stehen in unserem axion1337/build.json, electron-builder.ts wird nur
additiv um zwei optionale Schluessel erweitert - dieselbe Machart wie das
bereits vorhandene linux.deb.name. Ein Upstream-Merge erzeugt an der
mac.icon-Zeile damit keinen Konflikt.
Preis: kein macOS-26-Icon-Rendering. Ohne Xcode gaebe es ohnehin keinen Build.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
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
Die zehn theme-factory-Themes sind jetzt in beiden Configs identisch (gitops
c47b0a3 + Nachfolger). Ohne das haetten Desktop-Clients weiter meine alte
Interpretation der Paletten gezeigt.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
electron-builder leitet unterschiedliche Dinge aus zwei Feldern ab: productName
bestimmt den App-Namen (macOS .app, Windows Setup.exe), 'name' dagegen den
Linux-Paketnamen, das Binary und den /opt-Pfad. Nach dem Rebrand hiess die App
ueberall ThreadNet - ausser bei .deb und .tar.gz.
Nebenwirkung bewusst in Kauf genommen: apt sieht ein neues Paket, ein
Upgrade-Pfad von element-desktop existiert nicht. Bei einem Rebrand ist das
erwartbar; die appId bleibt unveraendert, damit lokale Daten erhalten bleiben.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Der Rebrand-Commit legte apps/desktop/axion1337/build.json an, aber electron-builder
nutzt eine Variante nur, wenn VARIANT_PATH gesetzt ist. Lokal hatte ich sie per
Umgebungsvariable gesetzt, in der CI fehlte sie - deshalb trugen die Linux- und
Windows-Pakete aus Pipeline 147 weiter den Namen 'element-desktop' bzw.
'Element Setup', obwohl die Icons bereits neu waren.
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
Erster Schritt aus ThreadNet-Web#10 - der Client hiess bisher 'Element' und
zeigte dessen Icon.
- apps/desktop/axion1337/build.json: eigene Build-Variante (VARIANT_PATH), damit
element.io/release/build.json unangetastet bleibt und Upstream-Merges nicht
reiben. productName 'ThreadNet', Beschreibung 'ThreadNet - powered by Element'
als faire Attribution (Element Web ist AGPL, dies ist ein Fork davon).
- appId bleibt bewusst 'im.riot.app': bestehende Installationen behalten ihre
lokalen Daten. Ein appId-Wechsel waere ein Datenschnitt und gehoert in die
Rebranding-Runde, nicht in einen Icon-Commit.
- build/icon.png + icon.icns: ThreadNet-Bildmarke, transparenter Rand entfernt
(das Motiv fuellte im Original nur 54% x 38% - direkt skaliert verschwindet es).
Verifiziert im Build: CFBundleName/CFBundleDisplayName = ThreadNet, eigenes
Icon, alle 17 Themes im webapp.asar.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Die Desktop-Apps laden ihre eigene config.json und haetten die elf neuen Themes
sonst nicht (aXion1337 Light + zehn Paletten). Aus der bereits deployten
Web-Konfiguration uebernommen, damit beide Clients identisch sind.
Chirurgisch eingefuegt (Lehre vom 2026-08-01, als ein Re-Dump dieser Datei 441
Zeilen umformatierte): 0 entfernte / 427 neue Zeilen, JSON validiert.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Aus artifactDownloader.go + binDownload.js verifiziert: Schluessel ist
<release>-<release>, Unterverzeichnis = Namensteil vor dem ersten
Bindestrich (nsis-resources daher unter nsis\). Job 431 traf winCodeSign
im Cache, scheiterte aber am nsis-Miss mit einfachem Namen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
winCodeSign starb an denselben CDN-Resets wie zuvor die Electron-Binary
(Job 424); Prefetch-Skript konsolidiert Electron-Zip + winCodeSign +
NSIS-Pakete mit curl -C - in die persistenten Caches (ELECTRON_CACHE,
ELECTRON_BUILDER_CACHE).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
GitHub-CDN brach den ~120-MB-Download zweimal mitten im Transfer ab
(Jobs 415/416, wsarecv: connection forcibly closed); app-builder kann
nicht fortsetzen. curl -C - in Schleife + persistenter Cache im Gast.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
hak/matrix-seshat/check.ts verlangt auf Windows rustc, perl, patch, nasm,
nmake und python - Job 399 scheiterte an fehlendem rustc. Rust landet
maschinenweit unter C:\Rust (SYSTEM-Dienst sieht kein Benutzerprofil),
Strawberry Perl deckt perl+patch ab, NASM-PATH wie im Upstream-Workflow
explizit nachgezogen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
Vollstaendig durch .gitlab-ci.yml ersetzt (Linux verifiziert gruen, Windows
in Arbeit); Gitea Actions ist fuer dieses Repo deaktiviert, auf GitHub lag
das Repo nie. Die Dateien bleiben als Uebersetzungsreferenz in der
Git-Historie erhalten.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
web laeuft nur noch bei build-relevanten Pfadaenderungen (Doku-Commits
kosten nichts) und immer bei v*-Tags. docker_web und desktop_linux bauen
nur noch bei Release-Tags (Image-Tag = Git-Tag statt sha), desktop_linux
bleibt auf main manuell triggerbar. Windows-/VM-Jobs sind auf main und
Tags manuell verfuegbar. Hintergrund: Deploy ist ohnehin ein bewusster
Tag-Bump im gitops-Repo - Artefakte pro Doku-Commit waren reine
Runner-Verschwendung.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
start/stop_windows_vm steuern die On-Demand-Build-VM vom Linux-Runner aus
(Docker-Socket). desktop_windows (tags: windows, manuell, unsigniert/nsis)
uebersetzt den x64-Pfad des Upstream-Workflows: frozen-lockfile, webapp +
axion-config vor dem asar, VS-DevShell + build:native mit MSVC-Target.
Wartet in der Queue bis der Windows-Runner (lab-windows-1) online ist.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
First CI for the lab GitLab (git.lab): web job builds the webapp with the
lessons from the Gitea attempts baked in (frozen-lockfile instead of
layered.sh, 6GB node heap), docker_web pushes the canonical
apps/web/Dockerfile image to the rohana registry that Flux pulls from,
and two manual jobs cover the desktop path - a dockerbuild build-image
and the Electron Linux build replicating the manually verified flow.
Also tracks the production client config (apps/desktop/axion1337/) that
previously only existed inside the one-off manual desktop build.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
layered.sh clones a branch-matching upstream matrix-js-sdk - on this fork
that would override the deliberately pinned js-sdk from pnpm-lock.yaml
(issue #12) with upstream develop, and it also needs jq which the node:20
job container lacks (the actual CI failure). Plain frozen-lockfile install
matches the production docker build.
Also replace the contains(needs.*.result, ...) gate check with explicit
per-job checks: the object-filter syntax evaluated wrongly on Gitea/act,
letting build-complete report success while build_ew had failed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Root cause found for jobs never starting: runs were created all along
(visible in the Actions UI), but every job requested ubuntu-24.04 while
builder-1 only offers ubuntu-latest, linux-build and win-wine - a label
mismatch means jobs queue forever, invisible via the /actions/tasks API
which only lists picked-up jobs.
Mapped build/prepare/gate jobs to ubuntu-latest and the Linux desktop
build to linux-build (electronuserland/builder image, amd64/static only -
the only variant buildable on the single x86 runner). Removed jobs the
runner cannot serve instead of letting them starve the queue: web+desktop
playwright tests (need Docker-in-job and display setup, tracked as
follow-up in issue #2) and the native-Windows desktop build (workflow
assumes signtool/MSVC/PowerShell; the win-wine label awaits a dedicated
wine-based workflow).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
push + workflow_call in the same on: block doesn't reliably fire push
events on Gitea Actions 1.27 (reproducible upstream, closed as "not
planned" - https://github.com/go-gitea/gitea/issues/33238). Nothing in
this repo invokes build-and-test.yaml via workflow_call anymore after the
workflow cleanup, so removing the trigger is a safe, targeted fix rather
than a workaround.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Removed ~37 workflow files that are unmodified upstream tooling this fork
doesn't use (Netlify, SonarCloud, Localazy, release-drafter/backport,
GitHub issue-triage bots, npm-publish, Cloudflare Pages deploy, Docker
push to ghcr.io/element-hq). Enabling Actions for this repo would have
activated all of them simultaneously against a single-capacity shared
runner - most would just fail loudly and starve the one job slot shared
with other repos.
Kept build-and-test.yaml (the actual comprehensive build+test+desktop
workflow) and its build_desktop_*.yaml sub-workflows. Fixed: push trigger
now targets `main` (was `staging`/`master`, neither of which exist here -
push events never fired at all before), 4 checkout steps now check out
this fork instead of element-hq/element-web, and removed the macOS
desktop build job since the registered runner (builder-1) has no macOS
label and would queue forever instead of failing cleanly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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).
apps/web/Dockerfile invokes scripts/docker-link-repos.sh and
scripts/docker-package.sh directly (no bash prefix) - without +x this
fails immediately on any fresh clone/full rebuild. The same bug also
affects fetchdep.sh, get-version-from-git.sh, layered.sh,
normalize-version.sh, and playwright-common/playwright-screenshots.sh,
all invoked directly the same way by this repo's own GitHub Actions
workflows (build.yml, tests.yml, static_analysis.yaml, docs.yml) - so
this was also silently breaking CI, not just Docker builds.
Thore CimbalandClaude Opus 5