ThreadNetWiki/betrieb/element-customization.md

title, description, published, date, tags, editor, dateCreated

title	description	published	date	tags	editor	dateCreated
Element Customization	Themes, Desktop-Apps, Admin	true	2026-08-13T18:04:24.484Z		markdown	2026-08-13T18:04:24.484Z

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

1. Custom Themes (17 Stück)

Theme	Art	Akzent	Grundton
aXion1337 Dark true	dunkel	#ffaf0f	—
Deep Purple	dunkel	#6503b3	#181b21
Discord Dark	dunkel	#747ff4	#36393f
Electric Blue	hell	#3596fc	#ffffff
Everforest dark hard	dunkel	#a7c080	#2b3339
aXion1337 Dark	dunkel	#bd93f9	#282828
aXion1337 Light	hell	#8f3f71	#fbf1c7
Ocean Depths	dunkel	#2ec4b6	#12303f
Sunset Boulevard	dunkel	#ff6b6b	#452133
Forest Canopy	dunkel	#7fb069	#22372b
Modern Minimalist	hell	#3d5a80	#ffffff
Golden Hour	dunkel	#d4a017	#3f2f1f
Arctic Frost	hell	#3b9ec7	#ffffff
Desert Rose	hell	#c08497	#fdfaf9
Tech Innovation	dunkel	#00e5ff	#161d29
Botanical Garden	hell	#4c9a5d	#ffffff
Midnight Galaxy	dunkel	#b388ff	#1c1440

Konfiguration: apps/production/custom-configs/element-values.yaml (Schlüssel setting_defaults.custom_themes — JSON innerhalb der ConfigMap).

Anwendung (User): Settings → Appearance → Colour theme

Hinweise zur Pflege

• aXion1337 Dark ist Gruvbox Dark — Grundtöne, Textfarben und die acht username-colors sind die Gruvbox-Palette. aXion1337 Light ist das exakte helle Gegenstück (Gruvbox Light): gleiche Rollenverteilung, gleiche Akzentfamilie, nur die Helligkeitsachse gespiegelt. Wer eins ändert, sollte das andere mitziehen.
• Die zehn Paletten von Ocean Depths bis Midnight Galaxy nutzen einen einheitlichen Schlüsselsatz (24 Farben inkl. username-colors) und sind dadurch untereinander vergleichbar; ältere Themes haben teils nur 3–16 Schlüssel und erben den Rest vom Element-Default.
• ⚠️ Beim Bearbeiten der ConfigMap niemals die YAML neu serialisieren. Der Themes-Block ist JSON innerhalb von YAML; ein Re-Dump zerstört Formatierung und Kommentare (real passiert am 2026-07-30). Nur textuell ergänzen und danach beides prüfen — YAML parsen und den JSON-Block parsen.
• Nach jeder Änderung muss die ConfigMap-Prüfsumme mitgezogen werden, sonst rotiert der Pod nicht sauber (Fallstrick vom 2026-08-01).

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:

1. config.json erstellen mit configUrl: "https://axion1337.chat/config.json"
2. Element installieren (WinGet / Homebrew / apt/dnf/pacman)
3. 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:

1. 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.
2. 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.
3. 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.