BYOK-Vault — der Verein sieht den Klartext nicht
Für sensible Inhalte gibt es einen Zero-Knowledge-Modus: der Verschlüsselungs-Schlüssel liegt nur auf den Geräten der Nutzerin, der Server speichert ausschließlich Chiffretext. Auch wir können den Inhalt dann nicht entschlüsseln.
Es gibt einen einfachen Gradmesser für Daten-Souveränität: kann der Anbieter, wenn er wollte, den Inhalt sehen? Wenn ja, dann ist das, was zwischen ihm und dem Klartext steht, Vertrauen — eine Datenschutz- Erklärung, eine Compliance-Abteilung, ein Audit. Vertrauen ist gut. Es ist nur weniger gut als das technische Unvermögen.
Der Vault-Modus ist unsere Antwort darauf. Für sensible Inhalte —
private Notizen, intime Listen, vertrauliche Sprachaufnahmen — gibt es
einen Schaltmodus, in dem der Verschlüsselungs-Schlüssel ausschließlich
auf den Geräten der Nutzerin existiert. Wir verschlüsseln im Client,
schicken Chiffretext an sync2, und der Server speichert ihn, ohne ihn
lesen zu können. Auf dem nächsten Gerät, das mit demselben Schlüssel
gekoppelt ist, entschlüsseln wir wieder.
Das ist nicht das gleiche wie „server-side encryption at rest”. Es ist auch nicht das gleiche wie das, was die meisten kommerziellen Anbieter „Ende-zu-Ende-Verschlüsselung” nennen — weil wir nicht im Besitz des Schlüssels sind. Es heißt: wenn ein Gericht uns zwingen würde, alles herauszugeben, was wir über eine Person haben, wäre das Ergebnis ein Berg unbrauchbarer Chiffretext-Zellen. Nicht weil wir es kompliziert gemacht haben, sondern weil der Schlüssel woanders ist.
Das hat eine harte Kehrseite. Wenn alle gekoppelten Geräte verloren gehen, sind die Inhalte unwiderruflich verloren. Wir können nicht helfen. Das ist nicht ein Versäumnis, das ist die Bedingung dafür, dass wir vorher auch nicht helfen können. Wir kommunizieren das offen, weil das einzige Schlimmere als kein Vault ein Vault wäre, dem man den Schlüssel-Auffang heimlich hinten anbaut.
Wie genau das funktioniert
- AES-GCM-256 als Verschlüsselungs-Verfahren, Schlüssel-Erzeugung client-seitig (Web Crypto API / Apple CryptoKit).
- Master-Key liegt in der Keychain / im IndexedDB-Vault des Endgeräts, geräte-übergreifend nur via QR-Code-Kopplung oder explizitem Export.
- Events werden vor dem Schreiben in `sync2` verschlüsselt — der Server sieht Akteur, Zeitstempel und Schema-Hash, aber nicht den Inhalt.
- Such-Indizes sind clientseitig (lokales SQLite/IndexedDB), keine serverseitige Volltextsuche über verschlüsselten Inhalt.
- Beim Verlust aller gekoppelten Geräte ist der Inhalt *unwiderruflich* verloren. Das ist die ehrliche Kehrseite, kein Bug.
Was uns das kostet
Jeder Lösung hat einen Preis. Diese hier zahlen wir bewusst — weil das, was wir damit erreichen, mit nachgelagerten Tricks nicht ehrlich zu bauen ist.
- Schlüsselverlust ist Daten-Verlust. Wir können nicht „helfen, wieder reinzukommen" — der Preis dafür, dass wir nicht reinkönnen.
- Cross-App-Suggestions, KI-Empfehlungen über alle Daten hinweg und Server-seitige Volltextsuche werden im Vault-Modus funktionell eingeschränkt oder rein lokal ausgeführt.
- Geräte-Kopplung ist ein UX-Bottleneck. Wir arbeiten daran, aber sie wird nie so reibungslos sein wie „Login mit Passwort irgendwo".
Wo es im Code/in der Doku steht
Welche Probleme dieser Lösung adressiert
Diagnose ohne Antwort ist Lamentation; Antwort ohne Diagnose ist Ingenieurs-Spielerei. Hier verbindet sich beides.
- Daten-Monetarisierung — du bist nicht die Kundin, du bist die WareWenn das Produkt kostenlos ist, ist nicht selten dein Verhalten das eigentliche Produkt — und dein Profil wird in Echtzeit versteigert.
- Enshittification — Software wird über Zeit schlechterWenn Wachstum, Werbung und Aktionärsrendite den Takt geben, verschlechtert sich jedes erfolgreiche Software-Produkt zwangsläufig.
Welche Grundsätze er trägt
Was diesen Lösung weiterbaut
- Bald BYOK-Vault MVP für Memoro und Mukke Der Lösung „BYOK-Vault, Zero-Knowledge" ist als Konzept beschlossen. Erster Konsument soll Memoro werden (Audio-Transkripte) und Mukke (Vocal- Stems) — beide Daten-Typen, die wir bewusst nie unverschlüsselt sehen wollen.
- Idee Local-First + Login-Optional — Sieben-Phasen-Plan ausrollen Playbook LOCAL_FIRST_LOGIN_OPTIONAL.md beschreibt vier neue Konventionen (event-sync anon, byok-vault, swift-event-sync, public-feed-standard) und sieben Rollout-Phasen. Heute noch nicht implementiert — könnte aber das glaubwürdigste Datensouveränitäts-Statement werden.
Offene Punkte
- Geräte-Kopplung per QR ist implementiert, aber nicht in allen Apps einheitlich. Ziel ist ein gemeinsamer Flow über `@mana/byok-vault`.
- Recovery-Codes als optionaler dritter Pfad neben Geräte-Kopplung — bewusst opt-in, weil sie das Bedrohungs-Modell ändern.
Weitere Lösungen dieser Art
Wie Geräte und Apps sich verständigen.
Lösungen sind die strukturellen Antworten des Vereins. Werte sagen, wonach wir uns ausrichten; Probleme sagen, wogegen; Lösungen sagen, was wir daraus baulich machen.