# ThreadNet-Web: Fork-Anpassungen für axion1337.chat Dieses Dokument beschreibt alles, was dieser Fork gegenüber Upstream Element Web ändert. Der Rest der `docs/`-Ordner-Dateien und das Root-`README.md` sind unverändertes Upstream-Material und beschreiben absichtlich **nicht** diese Anpassungen - diese Datei ist der zentrale Anlaufpunkt dafür. ## 1. Discord-Style Room-List (Call-Teilnehmer in der Raumliste) Zeigt aktive Call-Teilnehmer direkt in der Raumliste an (ähnlich Discords Voice-Channel-UI), statt nur einen generischen "Call läuft"-Indikator. Betroffene Komponenten: `apps/web/src/room-list/RoomListItemView/RoomListItemView.tsx` und `RoomListItemView.module.css` (vertikale Ausrichtung der Teilnehmer-Avatare). ## 2. Client-seitiges ClamAV-Content-Scanning (Issue #19-Erweiterung) Der Server-seitige Content-Scanner (Synapse-Modul, siehe gitops-Repo [`docs/deployment-guides/06-moderation-content-scanning.md`](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/src/branch/main/docs/deployment-guides/06-moderation-content-scanning.md)) sieht bei Ende-zu-Ende-verschlüsselten Räumen nur Ciphertext - eine strukturelle Grenze, kein Bug. Da dieser Client bereits geforkt wird, scannt er stattdessen selbst, auf beiden Seiten: - **Senden** (`apps/web/src/ContentMessages.ts`, `uploadFile()`): liest die Datei als ArrayBuffer, scannt sie über `scanContent()` **bevor** verschlüsselt/hochgeladen wird - der Upload wird bei Treffer gar nicht erst gestartet. - **Empfangen** (`apps/web/src/utils/DecryptFile.ts`, `decryptFile()`): scannt die entschlüsselten Bytes direkt nach dem Entschlüsseln, bevor das Blob an die UI zurückgegeben wird - schützt auch vor Dateien von unveränderten/fremden Matrix-Clients, die diesen Patch nicht haben. - Gemeinsame Scan-Logik: `apps/web/src/utils/ContentScanner.ts` - ruft den (im gitops-Repo deployten) `clamav-http-scanner`-Dienst per `fetch("/_scan", ...)` auf, mit dem eigenen Matrix-Access-Token als Bearer-Auth. Fail-open bei Netzwerk-/Scanner-Fehlern (blockiert Uploads/Downloads nicht bei einem Ausfall des Scanners). - Neuer Fehlertyp `ContentScanRejectedError`, verdrahtet durch die bestehenden Fehler-Rendering-Pfade in `MImageBody.tsx`, `MAudioBody.tsx`, `VideoBodyViewModel.ts`, `FileBodyViewModel.ts`. - Live getestet inkl. Hostile-Sender-Simulation (Datei per rohem API-Call ohne diesen Patch gesendet, Empfangs-Hook hat trotzdem geblockt). ### ⚠️ Bekannte Lücke: Electron/Desktop (Issue #2) Dieser Fix ist bestätigt nur für den **Web-Client-Build** wirksam. Der Electron-Desktop-Client bekommt ihn aktuell **nicht automatisch** - die CI-Workflow-Kette (`build_ew`-Job) checkt weiterhin `element-hq/element-web` (Upstream) statt diesen Fork aus, und es ist kein GitHub- Actions-Runner für dieses Repo registriert. Der aktuell veröffentlichte Desktop-Build (`desktop-v1.12.17-clientscan` Release) wurde manuell gebaut, nicht automatisiert. Details und Fix-Plan: [Issue #2](https://rohana.axion1337.de/sorb/ThreadNet-Web/issues/2). ## 3. Build-Fixes (historisch, Issue #12) Zwei Bugs blockierten einen vollständigen `docker build` von Grund auf (mussten für den Client-Scanning-Rebuild oben behoben werden): (1) mehrere Shell-Skripte waren mit Modus 644 statt 755 committet (nicht ausführbar); (2) der `matrix-js-sdk#develop`-Git-Ref-Pin in `pnpm-lock.yaml` war veraltet (fehlte `src/oidc/authorize.ts`, das `apps/web` importiert). Beide behoben. ## 4. Merge-Reibung: was ein Upstream-Update wirklich kostet *Arbeitspaket 3 aus ThreadNet-Web#7. Gemessen am 2026-08-06, nicht geschätzt.* ### Die unangenehme Grundlage zuerst **Dieses Repo enthält keine Upstream-Historie.** Element Web 1.12.17 wurde am 2026-05-10 als kompletter Baum importiert — und zwar in `3da3635`, zusammen mit dem ersten eigenen Feature im selben Commit. Davor liegt nur ein `Initial commit` mit zwei Dateien. Daraus folgt das Wesentliche: **es gibt keinen gemeinsamen Vorfahren mit `element-hq/element-web`.** Ein `git merge upstream/develop` ist nicht möglich; mit `--allow-unrelated-histories` erzwungen, kollidiert praktisch jede Datei. Wer „mal eben Upstream nachziehen" sagt, meint in diesem Repo also: neuen Upstream-Stand beschaffen und unsere Änderungen darauf neu auftragen. Das ist der Grund, warum die Zahl unten überhaupt zählt — sie ist der Aufwand jedes Updates. ### Unser Delta: 102 Dateien, davon 12 kritische `git diff --name-only 3da3635..main`: | Menge | Bereich | Konfliktrisiko | |---|---|---| | 46 | CI/Build (`.github/`, `.gitlab-ci.yml`, `dockerbuild/`) | gering — eigene Strecke, Upstreams Workflows brauchen wir nicht | | 22 | Config, Lockfiles, Upstream-Varianten | mittel — `pnpm-lock.yaml` konfliktet immer, wird aber regeneriert | | 13 | Web-Assets (`apps/web/res/`) | gering — meist eigene Dateien | | 4 + 3 | eigene Icons und `apps/desktop/axion1337/` | **keins** — kein Upstream-Pendant | | **12** | **Upstream-Quellcode** | **hier entsteht die Arbeit** | ### Die 12 Dateien, und warum sie angefasst wurden **Branding (5)** — flach, gut isolierbar: - `apps/web/src/SdkConfig.ts` — Defaults für `brand`, `welcome_background_url`, `desktopBuilds` - `apps/web/src/vector/index.html` — ``, Favicon-Link, PWA-Namen - `apps/web/src/async-components/structures/ErrorView.tsx` — Logo der Fehlerseite - `apps/web/src/components/views/settings/tabs/user/HelpUserSettingsTab.tsx` — Attribution + Danksagung - `apps/web/src/i18n/strings/en_EN.json` — einzelne Strings **ClamAV-Client-Scanning (7)** — tief in der Medien-Pipeline: - `apps/web/src/ContentMessages.ts`, `utils/ContentScanner.ts`, `utils/DecryptFile.ts` - `apps/web/src/components/views/messages/MImageBody.tsx`, `MAudioBody.tsx` - `apps/web/src/viewmodels/message-body/FileBodyViewModel.ts`, `VideoBodyViewModel.ts` ### Nicht der Umfang entscheidet, sondern die Art des Eingriffs Gemessen in geänderten Zeilen nehmen sich beide Gruppen wenig: **ClamAV ~130 Zeilen, Branding ~104**. Der größte Einzelpatch ist sogar Branding (`HelpUserSettingsTab.tsx`, 71 Zeilen). Wer nur zählt, hält beide für gleich teuer. Sie sind es nicht, und der Grund ist die Art des Eingriffs: - **Branding-Patches stehen am Rand.** Ein zusätzlicher Default in `SdkConfig.ts`, ein `<link>` im `<head>`, ein `<li>` in einer Settings-Liste. Wird die Datei umgebaut, sieht man sofort, wo das eigene Stück wieder hin muss. - **ClamAV-Patches stehen mittendrin** — in Entschlüsselungs- und Fehlerpfaden der Medien-Pipeline, verschränkt mit Upstream-Logik. Ein geänderter Kontrollfluss bedeutet nicht „Konflikt lösen", sondern „neu verstehen". ⚠️ **Und der eigentliche Haken: `viewmodels/`.** Element baut die Medien-Anzeige gerade auf MVVM um (`docs/MVVM.md`; v1 ist dort bereits als deprecated markiert — der Umbau läuft also schon in zweiter Runde). `FileBodyViewModel.ts` und `VideoBodyViewModel.ts` gab es in älteren Ständen gar nicht. Unsere Änderung darin ist mit je 6 Zeilen winzig — aber wenn Upstream diese Dateien verschiebt, umbenennt oder auflöst, entsteht **kein Konflikt**: die Zeilen sind einfach weg, und Git meldet nichts. Das ist gefährlicher als ein Konflikt, weil es stillschweigend passiert. Praktische Folge: Nach einem Upstream-Update ist an ClamAV nicht die Merge-Ausgabe maßgeblich, sondern ein **Funktionstest** — eine verschlüsselte Datei senden und eine abgelehnte empfangen. Steht so auch in Abschnitt 2. ### Was daraus für künftige Änderungen folgt 1. **Erst prüfen, ob es die Konfiguration schon kann.** Auth-Logo, `logo_link_url` und `brand` liefen ohne Rebuild über die ConfigMap; das Call-Widget wurde vollständig über `VITE_PRODUCT_NAME` umbenannt, ohne eine einzige Quelldatei. Jede so vermiedene Datei ist eine, die beim Update nicht kollidiert. 2. **Eigene Datei schlagen geänderte Datei.** `apps/desktop/axion1337/` und eigene Assets kosten beim Merge nichts. 3. **Wenn Upstream-Code sein muss: einen Kommentar mit `ThreadNet-Fork:` und der Begründung dazu.** Beim Neuauftragen auf einen neuen Stand ist die Frage nie „was steht hier", sondern „warum stand das da" — und die beantwortet sonst niemand mehr. ## Repo-Topologie (seit 2026-07-31) **Kanonisch ist `git.lab/axion1337.chat/ThreadNet-Web`** (Homelab-GitLab, nur im Lab auflösbar) — dort laufen Entwicklung und CI (`.gitlab-ci.yml`). Die Kopie auf `rohana.axion1337.de/sorb/ThreadNet-Web` ist ein **Push-Mirror** (automatisch, GitLab → Gitea) und dient als Lesekopie plus Standort für Issues, Container-Registry und Releases. **Niemals direkt nach rohana pushen** — der Mirror überschreibt divergente Stände. ## Element Call anheben (`@sorb/threadnet-call-embedded`) Das Call-Widget kommt als npm-Paket aus der **Gitea-Registry auf rohana**, nicht von npmjs. `.npmrc` im Wurzelverzeichnis bindet den Scope fest: ``` @sorb:registry=https://rohana.axion1337.de/api/packages/sorb/npm/ ``` Zum Anheben genügt damit der normale Weg — **kein Zusatzschritt, keine Umgebungsvariable**: ```sh # Version in apps/web/package.json setzen, dann: pnpm install --lockfile-only # Lockfile zieht die neue Tarball-URL von rohana pnpm --dir apps/web build # NICHT --filter web: das endet mit exit 0, ohne zu bauen ``` Danach muss die Tarball-URL im `pnpm-lock.yaml` auf `rohana.axion1337.de` zeigen. Tut sie das nicht, ist die `.npmrc` verlorengegangen: **ohne sie löst pnpm gegen npmjs auf**, und das geht heute nur deshalb laut aus (404), weil der Name `@sorb` dort noch frei ist — verlässt man sich darauf, ist es ein *dependency-confusion*-Weg. Siehe management#0055. Vor dem Anheben liegt das Paket erst dann in der Registry, wenn in `threadnet-call` der manuelle Job `publish_npm` gelaufen ist — der ist bewusst manuell und wird von sorb ausgelöst.