Element Web Customization: Themes, Desktop-Apps, Admin

Status: ✅ Vollständig deployed
Domains: axion1337.chat (Web), /docs/setup (Scripts)

1. Custom Themes (7 Stück)

Theme	Primärfarbe
aXion1337 Dark	`#1a1a1a`
Deep Purple	`#6a4c93`
Discord Dark	`#2c2f33`
Electric Blue	`#0066ff`
Everforest Dark Hard	`#1e2326`
Gruvbox Dark	`#282828`
Wal	`#1e1e1e`

Konfiguration: apps/production/custom-configs/element-values.yaml

Anwendung (User): Settings → Appearance → Colour theme

2. Desktop-Setup-Scripts

System	Datei
Windows	`element-setup-windows.cmd` (Doppelklick)
macOS	`element-setup-macos.command` (Doppelklick)
Linux	`element-setup-linux.sh` (bash)

Was die Scripts tun:

config.json erstellen mit configUrl: "https://axion1337.chat/config.json"
Element installieren (WinGet / Homebrew / apt/dnf/pacman)
Element starten (auto-config laden)

Download: https://axion1337.chat/docs/setup/

3. Element Admin-Panel

URL: https://admin.axion1337.chat

User verwalten
Room durchsuchen
Server-Statistiken

Konfiguration: apps/production/element-server-suite.yaml (ESS Chart)

4. Element Call Fork (Video/Audio-Qualität)

Status: ✅ Deployed (2026-07-28, Closes Issue #8)

Fork: rohana.axion1337.de/sorb/threadnet-call (basiert auf emmick4/element-call:livekit, enthält den noch nicht gemergten Upstream-PR element-hq/element-call#3736 mit config-driven media_quality — kein Custom-Code nötig)
Defaults angehoben: Kamera bis 1440p/60fps (~8 Mbps), Screen-Share 1440p/30fps (~6 Mbps). Das sind Startwerte, keine harten Limits — Nutzer können in Settings weiter hochdrehen.
Incident (2026-07-28): Erster Versuch mit erzwungenem video_codec: vp9 hat Calls komplett kaputt gemacht (kein Bild/Ton). Sofort zurückgerollt. Vermutete Ursache: LiveKit nutzt für vp9/av1 SVC statt klassischem Simulcast, der Fork-Code setzt aber immer Simulcast-Layer — Code-Fix nötig, bevor vp9 erneut versucht wird (Backlog).
720p-Zwischen-Layer ergänzt — ohne eigene simulcast_layers-Definition fiel die Übertragung bei kleinsten Netzwerkschwankungen direkt von 1440p auf blockiges 360p.
H.264 statt VP8 (2026-07-28) — nutzt wie VP8 klassisches Simulcast (kein SVC-Risiko), zusätzlich auf vielen Geräten (v.a. iOS/Safari) hardwarebeschleunigt. Live verifiziert: 7 von 8 Video-Tracks über H.264, 1 sauberer Fallback auf VP8. Deployed als v0.2.3-elementcall-h264.
Rauschunterdrückung: clientseitige WebRTC-Standardtoggles (Echo/Noise/Gain), passend zu LiveKits eigener Empfehlung für Mensch-zu-Mensch-Calls. Bewusst kein server-seitiges ML-Noise-Cancellation (siehe docs/TASKS.md Backlog).
Deployt als rohana.axion1337.de/sorb/threadnet-web:v0.2.0-elementcall-mediaquality — nur der /app/widgets/element-call/-Ordner im bestehenden v0.1.0-Image ausgetauscht, da ThreadNet-Web einen vorbestehenden Build-Bug hat (siehe unten).
Config live prüfbar: https://axion1337.chat/widgets/element-call/config.json

Update 2026-07-28 (Issue #12) — Full-Rebuild-Blocker behoben: Der oben beschriebene Workaround (nur den widgets/element-call/-Ordner patchen) war nötig, weil ThreadNet-Web komplett neu gebaut nicht funktionierte. Drei Bugs gefunden und gefixt:

7 Skripte nicht ausführbar committet (644 statt 755) - docker-link-repos.sh, docker-package.sh + 5 weitere, betraf auch die eigenen GitHub-Actions-Workflows des Forks.
matrix-js-sdk#develop-Pin war auf einen veralteten Commit resolved (fehlte src/oidc/authorize.ts). Der aktuelle develop-HEAD wäre noch schlimmer gewesen - dort wurde der komplette src/oidc/-Ordner zu src/oauth/ umbenannt, mit geänderter API (generateOidcAuthorizationUrl/completeAuthorizationCodeGrant/OidcError existieren so nicht mehr). Stattdessen auf d19cb751 gepinnt - den letzten Commit vor diesem Rename, verifiziert dass Datei+API exakt passen.
Gefunden: package.json/webpack.config.ts referenzierten noch upstream @element-hq/element-call-embedded statt unseres eigenen Forks - ein Full-Rebuild hätte bisher alle Fork-Anpassungen stillschweigend verworfen. Umgestellt auf @sorb/threadnet-call-embedded@0.19.2-threadnet.5.

Verifiziert mit einem echten, vollständigen docker build aus frischem Klon (kein Cache) - erst bei 3.8GB Docker-RAM an OOM gescheitert, nach Erhöhung auf 7.75GB sauber durchgelaufen. Gebautes Image enthält nachweislich unseren Fork (deutsche Übersetzung Kameraqualität im Bundle gefunden). Produktivumgebung bleibt vorerst beim bestehenden Patch-Image - der Full-Rebuild-Prozess ist jetzt nur möglich, nicht automatisch scharf geschaltet.

Update 2026-07-28 (später) — Video-Tab statt Developer-Mode: Kamera-/Screen-Share- Qualitätseinstellungen waren im Upstream-PR #3736 hinter einem "Developer Mode"-Schalter versteckt - in den regulären "Video"-Settings-Tab verschoben, für alle Nutzer sichtbar. Deutsche Übersetzungen ergänzt. Codec-Dropdown auf die tatsächlich von der SFU akzeptierten Codecs beschränkt (VP8/H.264/H.265).

Update 2026-07-29 — VP9/AV1 live getestet, zurückgerollt (Issue #11): SFU-Codec-Freigabe

Dropdown-Wiederfreischaltung getestet. Trotz echter Auswahl auf Safari und Desktop-Firefox (frischer Rejoin) fiel VP9 immer automatisch auf VP8 zurück. SFU-Logs zeigten: die eigene Codec-Freigabe kam serverseitig nie in der aktiven enabledPublishCodecs-Liste an - Ursache nicht abschließend geklärt (möglicher Zusammenhang: sfu.additional ersetzt die Chart-eigene config-overrides.yaml statt sie zu ergänzen). Komplett zurückgerollt. Details: Issue #11.

Dateien

Datei	Ort
Custom Themes	`element-values.yaml` ConfigMap
Setup-Scripts	`element-web-docs-configmap.yaml`
Docs Server	`element-web-docs-server.yaml` (nginx)
Ingress	`apex-ingress.yaml` (`/docs/setup/` route)

Weitere Details: Siehe Kapitel 4.