Der Local-First Peer-to-Peer Stack

Der Begriff stammt von Ink & Switch (Kleppmann et al.) und beschreibt Software, die sieben Idealen folgt:

1. No spinners — schnell, weil mit lokalen Daten gearbeitet wird
2. Multi-device — nahtloser Sync über alle Geräte
3. Offline — voller Lese- und Schreibzugriff ohne Internet
4. Collaboration — Echtzeit-Zusammenarbeit mehrerer Nutzer
5. Longevity — Daten bleiben über Jahrzehnte nutzbar und überleben jeden Server
6. Privacy — verschlüsselte Daten, die Service-Provider nicht lesen können
7. User control — volle Datenhoheit: kopieren, ändern, löschen

Wir gehen einen Schritt weiter: Es gibt gar keinen Hosting-Server. Die App selbst ist ein statisches JavaScript/HTML-Bundle, als PWA auf IPFS publiziert — sie startet auf jedem Desktop- oder Mobilgerät auch ganz ohne Server: über ein IPFS-Gateway, als Download oder vom USB-Stick.

Der Sync läuft Browser-zu-Browser über libp2p. Relays sind optionale, austauschbare Peers, die jeder starten kann — nie das Backend der App.

Das Gateway lässt sich ganz weglassen. Wer diese Seite über eine Domain wie local-first.le-space.de aufruft, läuft weiterhin über ein öffentliches IPFS-Gateway — dessen Betreiber sieht deine IP-Adresse und welche Seiten du abrufst, also genau das Protokoll, das auch ein herkömmlicher Webserver führt. Wer stattdessen einen eigenen IPFS-Node betreibt (IPFS Desktop oder Kubo) und die Browser-Erweiterung IPFS Companion installiert, bekommt IPFS-Adressen direkt vom lokalen Node ausgeliefert — beim Gateway landet gar keine Anfrage mehr.

Damit klar ist, was das genau bringt: Es gibt keinen Betreiber mehr, bei dem ein Protokoll deiner Besuche zusammenläuft. Dein Node spricht aber weiterhin mit anderen Peers, um die Inhalte zu holen, und die sehen, welche CIDs du anfragst — ein echter Gewinn an Privatsphäre gegenüber einem Hosting-Anbieter also, aber keine Anonymität.

Ja. Beim ersten Start steht auf dem Consent-Screen eine Checkbox: „Mit dem öffentlichen libp2p-Relay-Netz verbinden“. Nimmst du das Häkchen raus, baut der Browser gar keine Verbindung nach außen auf — kein Bootstrap, kein Relay. Nichts kündigt dich an, niemand kann dich finden, und kein fremder Knoten pinnt deine Daten.

Verbinden kannst du dich trotzdem, nur bewusst statt automatisch: per QR-Code direkt zwischen zwei Geräten, oder indem du dir einen eigenen Relay startest, dem nur deine Geräte vertrauen.

Davon unabhängig ist die Frage, wo die Daten liegen: Das bestimmt der Storage-Typ in der IPFS/OrbitDB-Konfiguration. LevelDB bzw. IndexedDB schreibt sie auf die Platte deines Geräts, Memory-Storage hält sie nur im Arbeitsspeicher. Die Simple-Todo-Demo läuft derzeit mit Memory-Storage, ein Reload beginnt also von vorn.

Beim Transport: ja. Alle libp2p-Verbindungen sind verschlüsselt (Noise-Protokoll) — Relays und Netze leiten nur Ciphertext weiter.

At rest: standardmäßig nein. Oplog-Einträge auf Relays oder Pinning-Diensten sind lesbar, solange keine Payload-Verschlüsselung aktiviert ist.

Payload-Verschlüsselung geht heute schon mit orbitdb/simple-encryption (Stand 0.0.2 — früh, aber funktionsfähig): Einträge werden verschlüsselt, die Replikation funktioniert weiter. Unser Prototyp de2do ging weiter und leitete den Schlüssel per WebAuthn PRF aus einem Passkey ab — kein Passwort, Schlüssel wird nie gespeichert (wird derzeit wiederbelebt). Verschlüsselte Backups stehen auf der Roadmap der storacha-bridge.

Peer-to-peer heißt nicht unsichtbar. Je nach Setup fallen an: PeerIDs (pseudonyme öffentliche Schlüssel), Datenbank-Adressen und Pubsub-Topics (sichtbar für Peers in denselben Topics) sowie IP-Adressen (sichtbar für die Relays, mit denen du dich verbindest — wie bei jeder Internetverbindung).

So minimieren wir sie: eigenen Relay betreiben (dann sieht kein Dritter deine IPs), Relays on demand starten und danach stoppen, und Payload-Verschlüsselung aktivieren, sodass Relays nur Ciphertext sehen. Direkte Browser-zu-Browser-Verbindungen sind ohnehin Ende-zu-Ende verschlüsselt.

Nein. Aleph Cloud ist unser erstes Deployment-Target, nicht das einzige. akash-deploy-pwa macht Relay-Button-artige Deployments bereits auf dem Akash Network, und weitere Anbieter sind geplant — dezentrale ebenso wie bewusst zentrale, denn Provider-Unabhängigkeit schließt die Freiheit ein, zentrales Hosting zu wählen.

Die vollständige Plattform-Abstraktion des Deployment-Layers (abstraktes Provider-Interface in @le-space/core) ist ein Kern-Arbeitspaket unserer Funding-Roadmap. Das Prinzip: Die App hängt nie von einem bestimmten Anbieter ab — Infrastruktur ist austauschbar.

Aleph-Cloud-VMs laufen auf Compute Resource Nodes, die von unabhängigen Node-Betreibern betrieben werden. Wie bei jedem Hosting — zentral oder dezentral — könnte der Betreiber der physischen Maschine bei einer normalen VM prinzipiell Arbeitsspeicher und Disk einsehen. Der Unterschied zur klassischen Cloud: Es ist nicht ein Konzern, sondern viele unabhängige Betreiber — und man kann den Node wählen oder selbst betreiben.

Warum das in unserer Architektur weniger wiegt: Ein Relay ist Weiterleitungs- und Pinning-Infrastruktur, kein Daten-Treuhänder. Der Transport ist Ende-zu-Ende verschlüsselt (libp2p/Noise), Schlüssel leben in den Browsern und Authenticatoren der Nutzer — nie auf der VM. Mit aktivierter Payload-Verschlüsselung (siehe Verschlüsselungs-Frage) speichert und leitet ein Relay ausschließlich Ciphertext weiter — ein neugieriger Node-Betreiber sieht nichts Verwertbares.

Für Deployments, denen selbst das nicht genügt, gibt es Confidential VMs (TEE): Aleph Cloud unterstützt Confidential Computing auf Basis von AMD SEV — der Arbeitsspeicher der VM ist hardwareverschlüsselt, sodass selbst der Node-Betreiber nicht hineinschauen kann. Die Evaluierung TEE-gestützter Relays für sensible Anwendungsfälle steht auf unserer Roadmap.

Nichts geht verloren: Deine Daten liegen auf deinem Gerät, und jede App funktioniert offline weiter. Sind Kollaborateure gleichzeitig offline, synchronisieren sich Änderungen einfach beim nächsten Treffen zweier Peers.

Teams, die Verfügbarkeit rund um die Uhr wollen, halten die gemeinsame Datenbank mit einem Relay samt Pinning (z. B. orbitdb-relay) online, während alle schlafen — und für Daten, die Geräte und Relays überleben sollen, gibt es die Archiv-Schicht (Storacha/Filecoin) mit dauerhaften Backups.

Jede OrbitDB-Datenbank hat einen Access Controller: eine Liste kryptografischer Identitäten, die schreiben dürfen. Schreibzugriffe sind signiert; jeder Peer prüft die Signaturen selbst — kein Server entscheidet.

Mit unserem WebAuthn-Identity-Provider ist diese Identität dein Passkey (Face ID, Touch ID, Security Key) — kein Account, kein Passwort. Lesen regelt die Replikation und, falls aktiviert, die Payload-Verschlüsselung.

Zum Ausprobieren: Das Tutorial-Kapitel acl01 legt eine Liste an, die nur dem Owner gehört, teilt sie per Adresse und vergibt zur Laufzeit Schreibrecht an eine zweite DID — die Adresse bleibt dabei gleich.

Keine Tokens, kein Mining, kein globaler Konsens. OrbitDB ist eine Local-First-Datenbank: Jede Datenbank gehört den Menschen, die sie nutzen, repliziert nur zwischen deren Peers und führt parallele Änderungen zusammen (CRDT-basierter Oplog) — statt dass sich die ganze Welt auf eine Kette einigen muss.

Das macht sie schnell, kostenlos nutzbar und privat im Geltungsbereich. Benachbarte dezentrale Netze nutzen wir dort, wo sie helfen: IPFS für die App-Verteilung, Filecoin fürs Archiv, dezentrales Compute (Aleph, Akash) für Relays — aber deine Daten liegen nie auf einer öffentlichen Chain.

Ja — und der Betrieb kostet nichts. Mit libp2p-webrtc-qr tauschen zwei Geräte den WebRTC-Handshake selbst aus: als gescannten QR-Code, wenn sie im selben Raum sind, oder als Einladungslink über einen beliebigen Messenger. Steht die Verbindung, ist sie eine ganz normale libp2p-Verbindung — gossipsub bildet sein Mesh darüber, OrbitDB repliziert darüber, und ein drittes Gerät, das sich mit einem beliebigen Mitglied verbindet, ist im selben Mesh.

Der Handshake steht im Fragment des Links, dem Teil hinter dem #, den Browser grundsätzlich nicht an einen Server schicken. Kein Signalisierungsserver sieht ihn — es gibt auch keinen, der ihn sehen könnte.

Damit ist es zweierlei zugleich. Es ist der kostenlose Normalfall: Eine App kann ohne jede Infrastruktur ausgeliefert werden und Menschen trotzdem zusammenarbeiten lassen. Und es ist der Rückfallweg, der trägt, wenn jedes Relay ausfällt, unerreichbar oder blockiert ist — weil nichts mehr an einer festen Adresse steht, das man blockieren könnte. Stören müsste man einen QR-Code, den jemand vor eine Kamera hält.

Verlangt wird dafür ein menschlicher Moment. Jemand scannt oder verschickt einen Link, die andere Seite öffnet ihn. Ein Relay erspart genau das: Es ist rund um die Uhr erreichbar, und Peers finden einander, ohne dass jemand etwas tut. Besteht ein Mesh erst einmal, lässt sich eine abgerissene Verbindung über die verbliebenen Peers wiederherstellen — die erste Vorstellung macht aber immer ein Mensch.

Zwei ehrliche Grenzen. Geräte in verschiedenen Netzen brauchen weiterhin STUN, um ihre eigene öffentliche Adresse zu erfahren; das ist eine einzelne UDP-Frage an einen öffentlichen Server, transportiert keine Daten und lässt sich abschalten, wenn beide Geräte im selben Netz sind. Und ein QR-Code fasst eine begrenzte Menge, weshalb ein Handshake mit vielen Kandidaten als animierte Folge statt als einzelnes Standbild läuft.

Ein Relay ist eine kleine VM — auf dezentralem Compute (Aleph, Akash) typischerweise wenige Euro pro Monat, und bei On-Demand-Deployments zahlst du nur, solange er läuft. Stoppst du ihn, funktionieren die Apps weiter; es fehlt nur der immer erreichbare Treffpunkt.

Entscheidend: Jeder kann einen Relay sponsern — der App-Entwickler, eine Community, eine Universität, eine Firma — oder du selbst für deine eigenen Geräte. Der Relay ist austauschbare Infrastruktur, nicht das Backend eines Anbieters.