Der Local-First Peer-to-Peer Stack

Q: What does "local-first" mean?

The term was coined by Ink & Switch (Kleppmann et al.) and describes software that follows seven ideals: • No spinners — fast, because it works with local data • Multi-device — seamless sync across all your devices • Offline — full read/write functionality without internet access • Collaboration — real-time collaborative editing for multiple users • Longevity — access and edit your data for decades, outliving any server • Privacy — encrypted data that service providers cannot read • User control — full ownership: copy, modify, delete

Q: What does "local-first peer-to-peer" mean at Le-Space?

We take local-first one step further: there is no hosting server at all. The app itself is a static JavaScript/HTML bundle, published as a PWA on IPFS — it starts on any desktop or mobile device even entirely without a server: via an IPFS gateway, as a download, or from a USB stick. Sync happens browser-to-browser via libp2p. Relays are optional, replaceable infrastructure started on demand — they are never the app's backend. You can cut out the gateway entirely. Loading this page over a domain like local-first.le-space.de still routes the request through a public IPFS gateway, and that gateway's operator sees your IP address and which pages you fetch — exactly the log a conventional web server would keep. Run your own IPFS node instead (IPFS Desktop or Kubo) and add the IPFS Companion browser extension: it detects the local node and serves IPFS addresses from it, so no request reaches the gateway at all. To be precise about what this buys you: no single operator holds a log of your visits any more. Your node still talks to other peers to fetch the content, and those peers can see which CIDs you ask for — so this is a real gain in privacy over a hosting provider, not anonymity.

Q: Is my OrbitDB data encrypted?

In transit: yes. All libp2p connections are encrypted (noise protocol) — relays and networks only forward ciphertext streams. At rest: not by default. Oplog entries stored on relays or pinning services are readable unless payload encryption is enabled. Payload encryption works today with orbitdb/simple-encryption: entries are encrypted while replication keeps working. Our prototype de2do went further and derived the encryption key from a passkey via WebAuthn PRF — no password, key never stored (currently being revived). Encrypted backups are on the storacha-bridge roadmap.

Q: What metadata does the network see?

Peer-to-peer doesn't mean invisible. Depending on your setup, the following metadata exists: PeerIDs (pseudonymous public keys), database addresses and pubsub topics (visible to peers on the same topics), and IP addresses (visible to the relays you connect to — as with any internet connection). How we minimize it: run your own relay (then no third party sees your IPs), start relays on demand and stop them after use, and enable payload encryption so relays only ever see ciphertext. Content of direct browser-to-browser connections is end-to-end encrypted anyway.

Q: Are you locked into Aleph Cloud?

No. Aleph Cloud is our first deployment target, not the only one. akash-deploy-pwa already runs relay-button-style deployments on Akash Network, and support for further providers is planned — decentralized as well as deliberately centralized ones, because provider independence includes the freedom to choose centralized hosting. Making the deployment layer fully platform-agnostic (an abstract provider interface in @le-space/core) is a core work package of our funding roadmap. The principle: the app never depends on a specific provider — infrastructure is replaceable.

Q: How secure are Aleph Cloud instances? Who could read the data on a relay?

Aleph Cloud VMs run on Compute Resource Nodes operated by independent node operators. As with any hosting — centralized or decentralized — the operator of the physical machine could in principle inspect the memory and disk of a regular VM. The difference to a classic cloud: it isn't one corporation, but many independent operators, and you can choose or run the node yourself. Why this matters less in our architecture: a relay is forwarding and pinning infrastructure, not a data custodian. Transport is end-to-end encrypted (libp2p/noise), keys live in the users' browsers and authenticators — never on the VM. With payload encryption enabled (see the encryption question), a relay only ever stores and forwards ciphertext; a curious node operator sees nothing usable. For deployments where even that isn't enough, there are Confidential VMs (TEE): Aleph Cloud supports confidential computing based on AMD SEV — the VM's memory is hardware-encrypted, so even the node operator cannot inspect it. Evaluating TEE-backed relays for sensitive use cases is on our roadmap.

Q: What happens when all peers are offline?

Nothing is lost: your data lives on your device and every app keeps working offline. If collaborators are offline at the same time, changes simply sync the next time any two peers meet. For teams that want availability around the clock, a relay with pinning (like orbitdb-relay) keeps the shared database online while everyone sleeps — and for data that must outlive devices and relays, the archive layer (Storacha/Filecoin) provides durable backups.

Q: Who "owns" a database? Who is allowed to write?

Every OrbitDB database has an access controller: a list of cryptographic identities that are allowed to write. Writes are signed; every peer verifies signatures independently — no server decides. With our WebAuthn identity provider, that identity is your passkey (Face ID, Touch ID, security key) — no account, no password. Reading is governed by replication and, if enabled, payload encryption.

Q: How is this different from a blockchain?

No tokens, no mining, no global consensus. OrbitDB is a local-first database: each database belongs to the people using it, replicates only between their peers, and merges concurrent changes (CRDT-based op-log) instead of requiring the whole world to agree on one chain. That makes it fast, free to use and private by scope. We do use adjacent decentralized networks where they help: IPFS for app distribution, Filecoin for archival, and decentralized compute (Aleph, Akash) for relays — but your data never sits on a public chain.

Q: What does a relay cost — and who pays for it?

A relay is a small VM — on decentralized compute (Aleph, Akash) typically a few euros per month, and with on-demand deployments you only pay while it runs. Stop it, and the apps keep working; they just lose the always-on meeting point. Crucially, anyone can sponsor a relay: the app developer, a community, a university, a company — or you yourself for your own devices. The relay is replaceable infrastructure, not a vendor's backend.

Question 1

Answer

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

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

Question 2

Answer

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 Infrastruktur auf Knopfdruck — 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.

Question 3

Answer

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: 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.

Question 4

Answer

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.

Question 5

Answer

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.

Question 6

Answer

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.

Question 7

Answer

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.

Question 8

Answer

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.

Question 9

Answer

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.

Question 10

Answer

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.

Der Local-First Peer-to-Peer Stack

Der Local-First-Stack

Projekte

Relay Button

Simple Todo

Universal Connectivity

UCAN Store

OrbitDB WebAuthn DID

libp2p WebRTC over QR

OrbitDB Relay

p2pass

Akash Deploy PWA

Orbit Blog

OrbitDB ⇄ Storacha Bridge

FAQ