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 Fable 5