Geräteübergreifend synchronisieren

Auf deiner eigenen Instanz ist openplate standardmäßig eine lokale App: Dein Tagebuch liegt in der IndexedDB des Browsers auf dem Gerät, das du nutzt, und nichts verlässt es, bis du die App auf einen Core-Server verweist. Dieses Tagebuch zwischen Geräten zu übertragen ist das Einzige, was ein Konto erfordert, daher liegt es in einem separaten Dienst, openplate-core, mit eigenem Image, eigener Datenbank und eigenen Secrets.

Auf deiner eigenen Instanz ist die Synchronisierung optional. Nicht gesetzt, verliert openplate keine Funktion. Auf dem gehosteten Dienst synchronisiert jedes Konto, daher hat das Tagebuch auch eine verschlüsselte Kopie auf dem Server.

Was zwischen deinen Geräten übertragen wird

Alles, was die Sync-Engine als Entität bezeichnet, wird zeilenweise zusammengeführt. Eine Änderung auf einem Gerät erreicht also die anderen, und ein Löschvorgang auf einem Gerät entfernt die Zeile auf den anderen. Ab dieser Version sind das deine persönlichen Lebensmittel, dein Ernährungsprotokoll, deine Gewichtseinträge, dein Profil und deine Ziele, deine Fastenzeiten, deine Vorratskammer, deine Fastenroutine sowie die Aktivitätsmarkierungen und Auszeichnungen hinter der Serie. Deine gespeicherten Mahlzeiten werden ebenfalls übertragen, allerdings als vollständige Liste statt zeilenweise. Das ist der letzte Teil des Tagebuchs, der noch auf eine zeilenweise Zusammenführung wartet.

Deine Freigabe- und Forschungsschlüssel reisen ebenfalls mit, in einem versiegelten Teil des Blobs, den deine eigenen Geräte öffnen können, und ebenso ein Betreiber, der deinen Wiederherstellungsschlüssel besitzt (siehe Verschlüsselung und was der Betreiber hält). Eine medizinische Fachkraft, der du ein Tagebuch freigibst, kann ihn nicht lesen.

Drei Dinge werden niemals übertragen, unabhängig von deinen Einstellungen:

• Tellerfotos. Sie liegen in einer separaten Datenbank auf dem Gerät, das sie aufgenommen hat, sind von der Sync-Nutzlast sowie aus jeder Sicherungsdatei ausgeschlossen und löschen sich nach einem von dir festgelegten Zeitplan selbst.
• Dein Schlüssel für den KI-Anbieter. Er liegt in einer eigenen Datenbank auf dem Gerät, auf dem du ihn eingegeben hast, und wird an niemanden außer den von dir gewählten Anbieter übermittelt.
• Das Protokoll deiner Löschungen. Dein Gerät protokolliert die durchgeführten Löschungen, um nachweisen zu können, dass sie beabsichtigt waren. Diese Liste bleibt auf dem Gerät. Die Löschungen selbst werden übertragen, die Liste nicht.

Was dafür nötig ist

• Eine laufende openplate-core-Instanz: entweder die gehostete, deine eigene oder ein Drittanbieter-Server, der das Protokoll implementiert. Um deine eigene zu betreiben, nutze docker/topologies/compose.core.yml: siehe self-hosting.md und topologies.md.
• CORE_URL muss für die App gesetzt sein und auf diesen Dienst verweisen.
• Eine sichere Seite. Bei der Anmeldung werden deine Schlüssel mit der Web Crypto API des Browsers abgeleitet, die Browser nur über https:// oder auf localhost anbieten. Siehe self-hosting.md.
• Ein Konto. Auf deiner eigenen Instanz erfolgt die Registrierung auf Einladung, es sei denn, du setzt OPEN_SIGNUP=true, also erstellst du das erste selbst: self-hosting.md.

Aktivierung

CORE_URL dient als einziger Schalter.

• Nicht gesetzt (Standardeinstellung): Es wird nirgends eine Synchronisierungsoberfläche gerendert und keine Synchronisierungsanfrage verlässt jemals die App.
• Gesetzt: Die Sync-Bildschirme erscheinen und kommunizieren mit dieser URL. Ihre Origin wird automatisch zur connect-src der Produktions-CSP hinzugefügt: Du benötigst dafür kein CSP_CONNECT_EXTRA.

Starte die App nach Änderungen neu. Nimmst du den Wert wieder heraus, verschwinden die Synchronisierungsmasken und die App stellt keine Anfragen mehr. Dein lokales Tagebuch bleibt in beiden Fällen unberührt.

Ein zweites Gerät hinzufügen: Richte sie auf dieselbe CORE_URL aus und melde dich mit derselben E-Mail-Adresse und demselben Passwort an, die du auf dem ersten Gerät verwendet hast. Das ist bereits der gesamte Vorgang, vom ersten Gerät muss nichts kopiert werden.

Es muss eine Adresse sein, die ein Browser erreichen kann. Der Sync-Client läuft auf der Seite, daher funktioniert ein Compose-Hostname wie http://core:3000 nicht: Verwende die öffentliche URL, die die Geräte deiner Nutzenden auflösen. Ein fehlerhafter Wert stoppt den Start absichtlich, damit ein Tippfehler nicht wie „Sync ist stillschweigend aus“ wirkt.

Die Forschungskonsole (/study)

Die App enthält immer eine Route /study, und auf einer gewöhnlichen Instanz bleibt sie inaktiv. Sie erwacht nur dann zum Leben, wenn der Core-Server, mit dem sie spricht, SYNC_RESEARCH=true hat, was standardmäßig deaktiviert ist: Eine Instanz, die du aufsetzt, ohne dieses Flag anzufassen, führt keine Studie durch, speichert keinen Studiengraphen und bietet nichts an, wofür man sich anmelden könnte. Lies openplate-core von .env.example, bevor du es aktivierst: Dadurch speichert der Server gesundheitsnahe personenbezogene Daten, was ein anderes Unterfangen ist als das Speichern eines verschlüsselten Tagebuchs.

Verschlüsselung und was der Betreiber hält

Dein Passwort verlässt deinen Browser nie. Es wird mit Argon2id gestreckt und durch HKDF in unabhängige Zweige aufgeteilt. Zwei Zweige bleiben auf dem Gerät, um den Datenschlüssel und deine privaten Einstellungen zu entschlüsseln. Ein dritter Zweig geht als Anmeldedaten an den Dienst. Es sind kryptografische Geschwister, nicht Elternteil und Kind; wer einen Zweig besitzt, erfährt daher nichts über die anderen. Dein Tagebuch wird vor dem Hochladen auf dem Gerät verschlüsselt und bleibt bei der Übertragung verschlüsselt; der Dienst speichert opaken Geheimtext, und außer diesem sieht er nur eine E-Mail-Adresse sowie Größe und Zeitpunkt deiner Uploads.

Der Betreiber hält einen Wiederherstellungsschlüssel. Bei der Registrierung erzeugt die App einen Wiederherstellungscode, verschlüsselt deinen Datenschlüssel damit und sendet den Code an den Server, der ihn unter einem eigenen Geheimnis versiegelt aufbewahrt. Das sorgt dafür, dass "Passwort vergessen" dein Tagebuch zurückbringt und kein leeres Benutzerkonto: Der Reset-Link (per Mail gesendet oder auf einer Instanz ohne Mail vom Betreiber übergeben) gibt den Code an deinen Browser zurück, der ihn verwendet, um den Datenschlüssel zu entschlüsseln und ihn unter dem neuen Passwort erneut zu verschlüsseln.

Klar ausgedrückt, weil dies der Kompromiss dieses Entwurfs ist: Der Betreiber einer Instanz kann ein Tagebuch darauf wiederherstellen und daher im Prinzip auch lesen. Auf einer Instanz, die du selbst hostest, bist du dieser Betreiber. Auf einer Instanz, die eine Organisation für dich betreibt, sieht diese ohnehin jedes Tellerfoto, das ihren KI-Proxy passiert; das ändert das Versprechen also weniger, als es aussieht, und ermöglicht ein Zurücksetzen des Passworts, ohne deine Daten zu verlieren.

Vor M192 gab es kein Treuhandverfahren, und der Preis war genau umgekehrt: Ein vergessenes Passwort samt verlorenem Wiederherstellungscode bedeutete, dass die Daten verloren waren, für uns und für dich, und die App musste den Code einmal anzeigen und jemanden bitten, ihn für immer aufzubewahren. Niemand tut das.

Tellerfotos sind niemals Teil einer Synchronisierungs-Nutzlast. Sie bleiben auf dem Gerät, das sie aufgenommen hat, sie sind von JSON-Exporten ausgenommen, und auf einer verwalteten Instanz wird die Kopie, die den KI-Proxy erreicht, einmal gelesen und vom Proxy nicht gespeichert. Ein Foto, das zusammen mit einer Meldung über eine falsche Schätzung gesendet wird, bewahrt der Betreiber für eine begrenzte Zeit auf.

Ein Tagebuch für einen Behandler freigeben

Auf einer Instanz, deren Core-Server SYNC_SHARING=true setzt, kann eine Person eine Fachkraft wie etwa eine Ernährungsberatung ihr Tagebuch lesen lassen. Die Fachkraft sendet der Person einen Connect-Link. Die Person öffnet ihn und tippt die zwölf Zeichen ein, die die Fachkraft vorliest, damit ein falscher Schlüssel bemerkt wird, bevor Daten geteilt werden. Die Person gibt die Freigabe dann unter Einstellungen → Freigabe frei: Die App packt den Datenschlüssel ein weiteres Mal ein, mit dem öffentlichen Schlüssel der Fachkraft, und lädt diese verpackte Kopie hoch. Der Browser der Fachkraft entpackt sie und zeigt das Tagebuch unter /shared an. Der Server speichert die verpackte Kopie und zu keinem Zeitpunkt den zugehörigen Schlüssel. Eine Freigabe lässt sich jederzeit widerrufen. Ein privater Bereich des Tagebuchs speichert die eigenen Freigabe- und Forschungsschlüssel der Person, und eine Fachkraft kann ihn niemals öffnen. Diese Schlüssel befinden sich auch im JSON-Export, unverschlüsselt, damit ein wiederhergestelltes Gerät weiterhin öffnen kann, was mit ihm geteilt wurde; self-hosting.md erklärt, was das für die Datei bedeutet.

Derselbe Bildschirm enthält den Schalter für den Puls, eine optionale instanzweite Zählung von Mahlzeiten und Scans; architecture.md beschreibt, was er sendet.

Was sich früher hier befand: das Gateway

Bis M192 konnte eine Person über denselben Einladungslink einem separaten KI-Gateway beitreten, und diese Verbindung wanderte mit dem Konto im versiegelten Bereich mit. Es gibt kein Gateway mehr: Der Core-Server hat den KI-Proxy übernommen. Auf einer von einer Organisation betriebenen Instanz scannt ein angemeldetes Konto mit einem Kontingent also über den einen Server, mit dem es ohnehin spricht, und es gibt keinen Verbindungsschritt mehr, den man irgendwohin mitnehmen müsste. Eine Instanz, die du selbst hostest, bleibt unverändert: Ein Schlüssel, den du einrichtest, bleibt auf dem Gerät, auf dem du ihn eingerichtet hast.