docs: add axion1337-fork.md documenting fork-specific changes vs upstream

README.md

@@ -1,5 +1,12 @@
 # Element Call
 
+> **threadnet-call**: this is a fork of Element Call (based on `emmick4/element-call`'s
+> `livekit` branch), customized for the self-hosted
+> [axion1337.chat](https://axion1337.chat) Matrix homeserver. See
+> [docs/axion1337-fork.md](docs/axion1337-fork.md) for everything this fork changes versus
+> upstream (media_quality defaults, the VP9 incident, npm publish process). The rest of this
+> README describes upstream Element Call and is intentionally left as-is.
+
 [![Chat](https://img.shields.io/matrix/webrtc:matrix.org)](https://matrix.to/#/#webrtc:matrix.org)
 [![Localazy](https://img.shields.io/endpoint?url=https%3A%2F%2Fconnect.localazy.com%2Fstatus%2Felement-call%2Fdata%3Fcontent%3Dall%26title%3Dlocalazy%26logo%3Dtrue)](https://localazy.com/p/element-call)
 [![License](https://img.shields.io/github/license/element-hq/element-call)](LICENSE-AGPL-3.0)

docs/axion1337-fork.md

@@ -0,0 +1,61 @@
+# threadnet-call: Fork-Anpassungen für axion1337.chat
+
+Dieses Dokument beschreibt alles, was dieser Fork gegenüber Upstream Element Call ändert. Die
+übrigen Dateien in `docs/` sind unverändertes Upstream-Material.
+
+## 1. Warum Fork von `emmick4/element-call` (Branch `livekit`)?
+
+Nicht direkt von `element-hq/element-call` geforkt, sondern von `emmick4/element-call`s
+`livekit`-Branch, weil dieser bereits den noch nicht upstream gemergten PR
+[element-hq/element-call#3736](https://github.com/element-hq/element-call/pull/3736)
+enthält - config-driven `media_quality`. Ohne diesen PR wäre eigener Custom-Code nötig gewesen,
+um Video-/Audio-Qualitätslimits pro Deployment konfigurierbar zu machen.
+
+## 2. media_quality-Defaults
+
+Konfiguriert in `vite-embedded.config.ts` (im `generateFile`-Plugin-Aufruf, der
+`media_quality` in die zur Build-Zeit gebackene `config.json` des Embedded-Packages schreibt):
+
+- Kamera: **1440p / 60fps / ~8 Mbps** (`video.max_resolution/max_framerate/max_bitrate`)
+- Screen-Share: **1440p / 30fps / ~6 Mbps**
+- 720p-Zwischen-Simulcast-Layer (`video.simulcast_layers`) - ohne diesen fiel die Übertragung
+  bei kleinsten Netzwerkschwankungen direkt von 1440p auf blockiges 360p
+- `video_codec: "h264"` (siehe Incident unten für die Begründung)
+
+Das sind Startwerte, keine harten Limits - Nutzer können in den Call-Settings weiter hochdrehen.
+
+## 3. VP9-Incident (2026-07-28) — ⚠️ nicht ohne Browser-Repro erneut versuchen
+
+Erster Versuch setzte `video_codec: "vp9"` (Commit `83db5224`). Das hat Calls **live komplett
+kaputt gemacht** (kein Bild/Ton), obwohl die LiveKit-SFU-Server-Logs den
+Codec-Regression-Fallback auf VP8 als scheinbar erfolgreich zeigten. Sofort zurückgerollt
+(Commit `f845d81e`). Vermutete Ursache: LiveKit nutzt für VP9/AV1 SVC statt klassischem
+Simulcast, aber `buildPublishOptions()` in diesem Fork setzt immer Simulcast-Layer - ein
+echter Code-Fix wäre nötig, um das aufzulösen. **Root Cause nie abschließend isoliert** (hätte
+einen Browser-Konsolen-/WebRTC-Internals-Repro gebraucht). Danach auf 720p-Zwischen-Layer +
+`h264` (klassisches Simulcast, kein SVC-Risiko, oft hardwarebeschleunigt v.a. auf iOS)
+umgestellt - live verifiziert (7/8 Tracks nativ H.264, 1 sauberer VP8-Fallback).
+
+**Nicht erneut versuchen, ohne vorher einen echten Browser-Repro zu haben.**
+
+## 4. npm-Publish zu Gitea (`@sorb/threadnet-call-embedded`)
+
+Das Embedded-Package (`embedded/web/package.json`, aktuell `0.19.2-threadnet.5`) wird zu
+Gitea's npm-Registry veröffentlicht (`https://rohana.axion1337.de/api/packages/sorb/npm/`,
+Scope `@sorb`). Der obere Versionierungs-Track hier (`0.19.2-threadnet.N`) ist unabhängig von
+den Docker-Image-Tags, unter denen das fertig gebaute Widget im gitops-Repo deployt wird (z.B.
+`v0.2.3-elementcall-h264` als `threadnet-web`-Image-Tag) - zwei getrennte Versionsschemata für
+zwei verschiedene Artefakte (npm-Package vs. Docker-Image).
+
+Der aktuelle Publish-Vorgang läuft manuell/lokal - das committete
+`.github/workflows/publish-embedded-packages.yaml` zielt noch auf `registry.npmjs.org`/
+`@element-hq`-Scope (Upstream-Konfiguration, nicht an die Gitea-Registry angepasst). Registry-
+Zugangsdaten liegen in einer lokalen, **nicht committeten** `.npmrc` - nicht Teil dieses Repos.
+
+## 5. Bewusst keine Server-seitige ML-Rauschunterdrückung
+
+Nur der client-seitige WebRTC-Standardtoggle (Echo/Noise/Gain-Suppression, aus derselben
+Upstream-PR-Linie) wurde übernommen. Bewusst **kein** LiveKit-Agents-basiertes Server-seitiges
+ML-Noise-Cancellation (z.B. selbst gehostetes DTLN/RNNoise) - LiveKits eigene Dokumentation
+beschreibt diesen Baustein als für AI-Voice-Agents gedacht, nicht für Mensch-zu-Mensch-Calls
+(kein unterstützter Weg, bereinigtes Audio an andere Teilnehmer weiterzuleiten).