Adding upstream as a second remote was meant to make updates viewable as a diff. The
first measurement contradicted what this document has claimed since August: diffing
v1.12.17 against the import commit yields 783 files, 115 of which exist only on our
side and 62 only in the tag.
The telling ones are MVVM files - TextualBodyViewModel.tsx and RovingTabIndex.tsx -
absent from the v1.12.17 tag, present in v1.12.26 and present in our import. The
changelog stops at 1.12.17 because it is only written at release time. So the base is
a develop state after the 1.12.17 release, not the tag.
That matters for the plan rather than for the code: grafting onto v1.12.17 would build
every future merge on an invented ancestry. Finding the real ancestor means searching
develop history, which a shallow tag fetch cannot do.
The remote is local configuration, so the setup is written down here instead of
committed.
Nothing in this repo said where @sorb/threadnet-call-embedded comes from. It
worked only because pnpm-lock.yaml carries the full tarball URL and CI installs
with --frozen-lockfile; the first version bump drops that cover. Today that ends
in a 404 because the name is still free on npmjs - which makes our only
protection the fact that nobody has claimed @sorb there. Claim it and the same
command resolves silently against a stranger's package, in the exact moment a
fresh download looks normal.
The checked-in .npmrc closes the wrong path instead of documenting it. It holds a
URL and no secret: read access to the registry is anonymous.
Upstream's .gitignore ignores /.npmrc - reasonable where the file holds tokens,
and it would have swallowed this fix without a word. The negation is explicit and
carries the reason, so the next merge does not quietly restore the hole.
Verified in an isolated tree, not assumed: without the file pnpm resolves to
npmjs and fails; with it the scope resolves to rohana at the same integrity hash
the repo lockfile already carries; with rohana unreachable the install fails
outright rather than falling back to npmjs. pnpm install --frozen-lockfile still
passes and leaves the lockfile untouched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Meine Aussage "ClamAV kostet mehr als das gesamte Branding zusammen" war so nicht haltbar: gemessen sind es ~130 zu ~104 Zeilen, der groesste Einzelpatch ist sogar Branding (HelpUserSettingsTab.tsx, 71 Zeilen).
Der Unterschied liegt woanders: Branding-Patches stehen am Rand und sind nach einem Umbau wiederfindbar, ClamAV-Patches stehen mitten in Entschluesselungs- und Fehlerpfaden. Dazu der eigentliche Haken - verschiebt Upstream die viewmodels/-Dateien, entsteht kein Konflikt, die Zeilen sind schlicht weg und Git meldet nichts. Deshalb ist dort ein Funktionstest maszgeblich, nicht die Merge-Ausgabe.
Refs axion1337.chat/ThreadNet-Web#7
Der wichtigste Befund ist die Grundlage, nicht die Liste: das Repo enthaelt KEINE Upstream-Historie. Element Web 1.12.17 kam am 2026-05-10 als kompletter Baum herein, im selben Commit wie das erste eigene Feature. Es gibt also keinen gemeinsamen Vorfahren mit element-hq/element-web - ein git merge ist nicht moeglich, ein Update heisst neu auftragen.
Gemessen statt geschaetzt: 102 geaenderte Dateien, davon nur 12 Upstream-Quellcode. Fuenf davon Branding (flach, isolierbar), sieben ClamAV in der Medien-Pipeline - und genau dort baut Upstream gerade auf MVVM um. Das Update wird an ClamAV mehr kosten als am gesamten Branding.
Refs axion1337.chat/ThreadNet-Web#7
Thore Cimbal
