Vertrauensnetze

CRDT

Ein CRDT (Conflict-free Replicated Data Type, konfliktfrei zusammenführbarer Datentyp) ist ein Datentyp, dessen Kopien auf verschiedenen Geräten unabhängig voneinander geändert werden können und sich beim Abgleich ohne Konfliktlösung durch eine zentrale Stelle zum selben Stand vereinigen. Das Real Life Trust Protocol schreibt keinen CRDT vor.

Aktualisiert:

Ein CRDT (Conflict-free Replicated Data Type, konfliktfrei zusammenführbarer Datentyp) ist ein Datentyp, dessen Kopien auf verschiedenen Geräten unabhängig voneinander geändert werden können und sich beim Abgleich ohne Konfliktlösung durch eine zentrale Stelle zum selben Stand vereinigen. Für Local-first-Software ist das der übliche Baustein, weil Geräte offline arbeiten und später zusammenfinden müssen.

So funktioniert es

Das Real Life Trust Protocol schreibt keinen CRDT vor. Seine Replikationsvorgabe sagt es ausdrücklich: Die Spezifikation benennt weder einen Transport noch einen CRDT. Sie legt einen Vertrag fest, der „individually signed, causally linked entries“ idempotent und lückenlos relativ zu einem beglaubigten Ziel zusammenführt, ohne stilles Auseinanderlaufen. Zugesagt wird „convergence over entries, never readability of content“, also Konvergenz über Einträge und keine Lesbarkeit der Inhalte. Alles unterhalb der fünf Türen ist offen: Transport, Topologie, Speicher, Encoding, CRDT oder Log, Push oder Pull.

Die fünf Türen lauten: Einträge sind einzeln signiert und kausal verkettet (signierter kausaler Graph). Durchsetzende Operationen und Epochenwechsel sind atomare Commits. Autorisierung gegenüber Diensten gilt gegen eine vorgelegte, verkettete Ansicht. Nebenläufige Durchsetzung schlägt geschlossen fehl, es gibt keine Gewinnerwahl. Und jede Behauptung von Vollständigkeit läuft über ein beglaubigtes Konvergenzziel. Ein Austausch ohne dieses Ziel sei zulässig und liefere Seiten, „never convergence“. Die Kanonizität werde nie beglaubigt, nur berechnet.

Im Vergleich

Die Spezifikation prüft Kandidaten Tür für Tür und ordnet sie als nativ, Adapter oder ausgeschlossen ein, Stand der Quellen August 2026. p2panda trägt die erste Tür nativ, die übrigen über Adapter, wobei die vierte den gepinnten RLTP-Resolver braucht. Keyhive mit BeeKEM, SECSYNC und NextGraph erhalten jeweils eigene Einträge, bei Keyhive und SECSYNC ist die zweite Tür „excluded today“. Automerge und klassisches Local-first-Sync heißen „the defining case of door 5“: Sie laufen unterhalb des Konvergenzziels und sind ohne es nur ein unbeglaubigtes Profil. Das Urteil der Spezifikation: „None is a conformant adapter today“.

Das Gegenstück im Decentralized Trust Graph fehlt. Die ausgewerteten First-Person-Quellen erwähnen CRDTs und Datenkonsistenz zwischen mehr als zwei Parteien nicht; ihr Datenaustausch läuft über private Zweierkanäle. Ich lese den Vertrag als bewusste Weigerung, sich an eine Datenstruktur zu binden: Wer das Protokoll trägt, soll nachweisen, dass er die Türen hält, und darf dafür einen CRDT wählen.

Einordnung

Diese Erläuterung gehört zu den Fachnotizen über das Real Life Trust Protocol und gibt den Stand der Spezifikationen vom Oktober 2026 wieder.

Quelle

https://trust-protocol.real-life.org/understand/foundations/

https://github.com/real-life-org/trust-protocol

CRDT in drei Sätzen

Ein CRDT (Conflict-free Replicated Data Type, konfliktfrei zusammenführbarer Datentyp) ist ein Datentyp, dessen Kopien auf verschiedenen Geräten unabhängig voneinander geändert werden können und sich beim Abgleich ohne Konfliktlösung durch eine zentrale Stelle zum selben Stand vereinigen. Das Real Life Trust Protocol schreibt keinen CRDT vor.