Local-first-Software

Local-first-Software ist ein Entwurfsansatz, bei dem die maßgebliche Kopie der Daten auf den Geräten der Nutzer liegt und die Anwendung auch ohne Server arbeitet. Geräte gleichen sich untereinander ab, ein Dienst im Netz kann dabei helfen, ist aber nicht die Quelle der Wahrheit.

So funktioniert es

Im Real Life Trust Protocol zeigt sich der Ansatz an der Gruppe. Sie ist ein verschlüsseltes Dokument, das auf dem Gerät jedes Mitglieds liegt und ein eigenes Log führt: wer beigetreten ist, wer gegangen ist, welche Regeln gelten. Die Zugriffsschicht ist für genau dieses Umfeld entworfen, ein Ende-zu-Ende-verschlüsseltes, Local-first-Setting, in dem ein Ausschluss erst ab dem nächsten Schlüsselzeitraum wirkt (siehe Schlüsselepoche). Die Beschreibung des Protokolls nennt den Ursprung des Gedankens: Die Einladung kommt aus Community Organising und Local-first-Software, aus Karten, Camps, Festivals und regionalen Netzen, wo Vertrauen zuerst da ist. Software könne es erinnern und tragen, aber nicht erzeugen.

Die Projektseite fasst die Verbindung so: Aus der Arbeit am Decentralized Trust Graph übernimmt das Protokoll Credentials, Trust Tasks und Transport, aus Local-first replizierte Daten, Gruppenschlüssel und Ereignisprotokolle. Neu sei die Verbindung, Gruppen als Orte, betreten über Vertrauen zwischen Menschen.

Im Vergleich

Das First Person Project nennt den Begriff Local-first nicht. Verwandte Bausteine gibt es: Credentials liegen nur in den Wallets der Inhaber, der Trust Graph soll auf den Geräten oder in der Cloud der Wahl tragbar sein, und das Hybridmodell kombiniert Client-seitige mit Cloud-Agenten. Gemeinsam bearbeitete Daten zwischen mehr als zwei Parteien und deren Konsistenz behandeln die ausgewerteten Quellen nicht. Der Datenaustausch läuft über private Zweierkanäle. Diese Lücke füllt das Real Life Trust Protocol mit seinem Replikationsvertrag (siehe Ports).

Aus der Dezentralität ergibt sich eine Folge, die die Personhood-Spezifikation offen ausspricht: Zwei Prüfer mit unterschiedlichen Replikaten können dasselbe Prädikat verschieden auswerten, „inherent to local-first“. Eine benannte Schnappschuss-Kennung macht die Auswertungen vergleichbar. Zur Einordnung klassischer Synchronisation nennt der Replikationsvertrag Automerge und ähnliche Local-first-Sync-Engines als den Grundfall der fünften Tür, des beglaubigten Konvergenzziels: Ohne dieses Overlay entsteht nur ein unbeglaubigtes Profil, das Seiten liefert und nie „reached“ meldet. Kein Kandidat gilt heute als konformer Adapter, und ein Replikationsadapter ist nicht spezifiziert. Ich sehe darin die ehrlichste Stelle des Protokolls: Es sagt, wo Local-first allein nicht reicht.

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