Der Local-First Peer-to-Peer Stack

Vorbereitende Buchhaltung, local-first: Bank- und Krypto-Transaktionen mit Belegen abgeglichen, am Ende ein monatliches DATEV-Paket — die eigentliche Kontierung passiert woanders, und die Bücher verlassen dein Gerät nie.

• Der Passkey ist Identität und Schlüssel: Er meldet dich an, und alles ist mit Schlüsseln versiegelt, die aus ihm abgeleitet werden. Es gibt keinen Benutzernamen, kein Passwort und keine Kopie bei irgendwem.
• Eine Bridge für das, was ein Browser nicht kann: Ein kleiner Dienst auf 127.0.0.1 spricht mit Hibiscus, dem Buchhaltungspostfach, Kundenportalen, Börsen und Wallets — und mit deinem eigenen Sprachmodell, das Belege geschwärzt liest, und nur auf Klick.
• Das Abgleichen ist die eigene Arbeit der App: Ein Score über Betrag, Rechnungsnummer, Lieferant, IBAN und Datum verknüpft Belege mit Zahlungen, lernt aus deinen Korrekturen und folgt eigenen Umbuchungen über Konten, Chains und Bridges hinweg.
• Geräte werden Peers: Dieselben Bücher auf Telefon und Rechner nach einem Passkey-Beweis — über öffentliche Relays, einen Relay in der eigenen Bridge oder per QR ganz ohne Relay.
• Zur Tür hinaus als DATEV: SKR 03, BU-Schlüssel, ein monatliches EXTF-ZIP für deine Buchhaltungssoftware samt Belegen — und Rechnungen kommen über UCEP aus der Rechnungs-App herein.

→ Vorbereitende Buchhaltung für ein kleines Unternehmen — der Stack trägt die Aufzeichnungen, die eine Firma wirklich führen muss

Ein Ordner auf diesem Gerät, der derselbe bleibt wie ein Ordner auf einem anderen — hinzugefügte, geänderte und gelöschte Dateien — ohne Konto und ohne irgendetwas dazwischen.

• Einmal per Code gekoppelt, danach Peers: Zwei Geräte scannen je einen Code vom Bildschirm des anderen — einmal in jede Richtung, und nur beim Koppeln — über libp2p-webrtc-qr. Danach reisen die Bytes direkt, und kein Server hält sie je.
• Der Index ist ein CRDT, die Bytes sind es nicht: Yjs trägt eine Karte aus Pfaden und Inhalts-Adressen; die Dateien selbst gehen über Bitswap. Dateiinhalte in ein CRDT zu legen ist genau der Fehler, den das hier vermeidet.
• Beide Fassungen überleben einen Konflikt: Haben zwei Geräte dieselbe Datei geändert, bleiben beide erhalten — wie bei Dropbox. Der gerettete Name kommt aus der Inhalts-Adresse, zwei Geräte mit identischen Bytes landen also bei einem Eintrag statt bei zweien.
• Ein echter Ordner unter Chromium: Ordner auswählen, und genau der wird abgeglichen — inklusive Änderungen, die außerhalb der App passieren. Sonst dient der private Speicher des Browsers, den jede Engine hat.
• Öffnet sich ohne Netz: installierbar, und der Ordner ist da, wenn das Internet es nicht ist.

→ Ein Ordner zwischen zwei Geräten — der Stack angewandt auf das Schlichteste, was man von ihm will

Kursbuchung für Yogastudios mit mehreren Standorten — gebaut, um zu zeigen, was der Stack leistet, wenn eine Anwendung tatsächlich davon abhängt.

• Ganz ohne Relay: Geräte finden sich per gescanntem QR-Code oder Einladungslink — libp2p-webrtc-qr als einziger Transport, und damit der laufende Beweis, dass der kostenlose Weg genügt.
• Kein Konto, kein Passwort: Ein Passkey ist die Identität, ein zweites Gerät wird vom ersten freigegeben.
• Karten sind ein Append-only-Log: Das Guthaben wird aus den Ereignissen gefaltet und nie gespeichert — zwei Theken an verschiedenen Orten können verkaufen und entwerten, ohne jemanden um Erlaubnis zu fragen.
• Wo es unbequem wird, steht geschrieben: Das Handbuch hat ein Kapitel darüber, was die App nicht kann, und das Repository dokumentiert die Grenzen, an die sie gestoßen ist, statt der Funktionen, die man sich erhofft hatte.

→ Showcase für OrbitDB und WebRTC über QR — eine echte Anwendung, keine Demo

Rechnungen im eigenen Peer-to-Peer-Store statt auf fremden Servern — als schlichte JavaScript-Module, jedes mit eigener Spezifikation. Ein Rechnungssatz wird durch das Ausstellen eingefroren und per Storno korrigiert, nie editiert; Nummernkreise laufen pro Identität; das Anschreiben kommt aus einer Markdown-Vorlage, die dem Leser gehört; das PDF trägt einen Zahlungscode — EPC-GiroCode für die SEPA-Überweisung, BIP-21 für Bitcoin, EIP-681 für eine EVM-Chain. Eine Rechnung in anderer Währung weist die Umsatzsteuer in Euro aus, mit Kurs, Quelle und Tag. Führt das Kapitel invoice01 von Simple Todo weiter, samt Historie.

→ Das Gegenstück zu Le Space Belege über UCEP: create-eigenbeleg und record-payment sind die ersten Erweiterungsaufrufe mit Autorisierung

Dezentrales Bloggen mit Replikation zwischen Browsern — publizieren ohne Hosting-Anbieter.

Backup, Restore und Replikation von OrbitDB-Datenbanken über austauschbare Storage-Backends (Aleph, Pinata, Lighthouse), mit erhaltenen Hashes und Identitäten — und eine Datenbank auf ein Gerät zurückholen, das nichts hat, allein mit einem WebAuthn-Passkey auf einem Sicherheitsschlüssel.

→ Früher die OrbitDB-Storacha-Bridge: Storachas Uploads endeten im Mai 2026, Aleph, Pinata und Lighthouse traten an ihre Stelle.

Passkey-basierte Identität für OrbitDB — keine Extensions, nur Browser und Biometrie. Jeder Oplog-Eintrag muss signiert werden; die eigentliche Frage ist, wo der Signaturschlüssel liegt:

• Klartext-Keystore (OrbitDB-Default): der Ed25519-Schlüssel liegt unverschlüsselt in der IndexedDB des Browsers. Alles, was auf deinem Origin Skript ausführt, kann die Identität kopieren und dauerhaft in deinem Namen schreiben.
• WebAuthn-verschlüsselter Keystore: derselbe Schlüssel, per AES-GCM at rest verschlüsselt und erst nach einem WebAuthn-Unlock (PRF, largeBlob oder hmac-secret) in den Speicher geholt. Ein Prompt pro Session, Schreibvorgänge bleiben schnell; sicher at rest, im Speicher solange der Tab offen ist. Der pragmatische Default — Demo.
• Hardwaregestützte Schlüssel (Varsig): gar kein OrbitDB-Keystore. Der Schlüssel entsteht im Authenticator — Secure Enclave, TPM, Security Key — und verlässt ihn nie. Ein Passkey-Prompt pro Schreibvorgang, dafür bleibt im Browser nichts zu stehlen — Demo.
• Wozu Varsig: ein Authenticator liefert nie eine schlichte Signatur über deine Payload — er signiert seine eigene Struktur aus authenticatorData + clientDataJSON-Hash. Dazu kommt, dass das Verfahren variiert: die Plattform-Authenticator von Apple, Android und Windows signieren mit ES256 (P-256), während EdDSA/Ed25519 (COSE -8) zwar im Standard steht und auf einigen Security Keys funktioniert — eine Passkey-DID kann also weder die eine noch die andere Kurve voraussetzen. Varsig ist der selbstbeschreibende Envelope, der Struktur und Verfahren gemeinsam transportiert, sodass die Assertion als OrbitDB-Oplog-Signatur und über toUcantoSigner() auch als UCAN-Delegation-Signatur verifizierbar ist. Ohne Varsig kann ein Hardware-Schlüssel für beides nicht der Signierer sein — ganz gleich, welche Kurve er verwendet.
• Wiederherstellung auf leerem Gerät: derselbe Passkey ergibt dieselbe DID auf Hardware, die nichts gespeichert hat, und eine wiederhergestellte Identität signiert wieder — am 21. September 2026 kam eine Liste allein mit einem YubiKey auf ein zurückgesetztes Telefon zurück.
• Ein Passkey, auch ein Wallet: dieselbe Credential signiert 32-Byte-Challenges für ein P-256-Smart-Account, in der WebAuthn-Form, die Calibur-Accounts on-chain verifizieren — so zahlt das Kapitel escrow01 auf Sepolia: ein Passkey, OrbitDB-Identität und On-Chain-Konto zusammen.

Libp2p-Relay-Nodes auf Knopfdruck — die Toolchain im Zentrum des Local-First-Stacks.

• Ein Klick, ein Relay: deployt einen libp2p/OrbitDB-Relay (Signaling, Bootstrap, IPFS-Pinning) — läuft für ein Meeting, ein Projekt oder Jahre, danach wird er gestoppt.
• Volle Automatisierung: qcow2-RootFS-Images bauen, auf IPFS publizieren, VM-Lifecycle & Retention per CLI und GitHub Actions.
• Einbettbare UI: React- & Svelte-Komponenten — der eigentliche „Relay Button" — für jede App.
• Bootstrap-Discovery: Relays registrieren sich selbst; Apps finden sie automatisch.
• Neu — Remote-Browser-Replication: Die CI startet einen echten Browser auf einer frischen VM in einem anderen Netz und verifiziert echte Cross-Network-P2P-Replikation Ende-zu-Ende — ersetzt Dienste wie testingbot.com für Local-First-P2P-Apps.
• Läuft auf Aleph Cloud: dezentrales Compute, VMs ohne Cloud-Account; weitere Anbieter — dezentrale wie zentrale — geplant.

Relay- und Pinning-Service, der OrbitDB-Datenbanken verfügbar hält, während Peers offline sind.

Zwei Geräte verbinden sich direkt als libp2p-Peers — ohne Relay, ohne Signaling-Server. Jedes Handy scannt einen Code vom Bildschirm des anderen — einmal in jede Richtung.

• Signaling als QR-Code: Offer und Answer laufen out-of-band als signierte, deflate-komprimierte Payloads statt über ein Circuit-Relay. Beide Wege werden von Hand getragen, weil kein Server die Answer zurückbringt — ein zweiter Code, ein Einladungslink, ein Textfeld oder ein hörbarer Ton, wenn das antwortende Gerät keine brauchbare Kamera hat.
• Ein Viertel der Größe, wahlweise: eine kompakte Payload überträgt nur Fingerprint und Kandidaten und baut das SDP auf beiden Seiten neu — die Packidee von QWBP, ergänzt um die Signatur. ~284 Zeichen statt ~995 sind der Unterschied zwischen einem stehenden Code und einer animierten Folge — und sie lassen einen Handschlag in Träger passen, in die ein volles SDP nicht hineingeht: zwei LoRa-Pakete, ein paar Sekunden Ton.
• Signiert, nicht nur gescannt: das SDP enthält den DTLS-Fingerprint — wird es mit dem libp2p-Schlüssel signiert, ist die WebRTC-Session an die Peer-ID gebunden. Dasselbe Prinzip wie certhash bei WebRTC-Direct, und genau deshalb darf der übliche Verschlüsselungs-Handshake entfallen.
• Manipulation scheitert sicher: eine veränderte Payload wird vor jedem Verbindungsversuch abgelehnt, und ein Browser verweigert sein eigenes Offer statt sich selbst zu dialen.
• Funktioniert ohne Infrastruktur: nützlich, wo kein Relay erreichbar ist — derselbe Raum, dasselbe LAN, ein abgeschottetes Netz.

→ Experimentell — ein QR-Code macht den Signalisierungsserver überflüssig, nicht alles andere, was eine direkte Verbindung braucht. Browser und Netze stellen das oft nicht bereit: ein NAT, das Hole Punching zulässt, ein WLAN, in dem zwei Clients einander adressieren dürfen, eine sichere Herkunft für die Kamera. Vor dem Daraufbauen ins README schauen.

Browser basierter Storage mit WebAuthn/Passkey-DIDs und UCAN-Delegationen — Upload nach Filecoin (geplant) ohne Accounts oder Passwörter.

→ Storacha-Upload-Service-Fork — Upgrade auf UCAN 1.0 geplant

Relay-Button-artige Deployments auf dem Akash Network — zweites dezentrales Compute-Target.

→ Konsolidierung mit Relay Button geplant

Tutorial für local-first P2P-PWAs: WebAuthn/Passkey-Identität, OrbitDB-Daten, Browser-zu-Browser-Sync. Kein Server, keine Accounts, keine Passwörter.

Das Universal Connectivity Extension Protocol, als Spezifikation ausgeschrieben: Ein libp2p-Peer bietet Erweiterungen an — kleine Dienste mit benannten Kommandos —, die jeder andere Peer finden und aufrufen kann, ohne Registry oder Server dazwischen. Die Erkennung läuft über libp2ps eigenes Identify; jeder Aufruf ist eine Anfrage und eine Antwort auf einem kurzlebigen Stream; Kommandos, die Zustand ändern oder Daten preisgeben, verlangen einen Grant, den man durch Pairing erhält. Ein Working Draft (Wire-Revision 2) — und womöglich das erste Mal, dass einzelne Local-First-Peer-to-Peer-Apps einander mit Autorisierung aufrufen: Die Invoice-Erweiterung ist dafür spezifiziert, eine Rechnungs-PWA mit einer Belege-App zu verbinden.

→ Basiert auf dem Gewinnerbeitrag des libp2p Universal Connectivity Hackathons — der P2P-Tabellenkalkulation weiter unten auf dieser Seite

Ein Byte-Kurier für Local-first-Apps über LoRa-Mesh-Funk — er arbeitet mit Meshtastic-Knoten und trägt OrbitDB und Yjs dorthin, wo kein Internet ist.

• Im Rahmen der Sendezeit-Regeln: Payloads werden in funkgerechte Frames zerlegt, gezielt wiederholt und im Duty Cycle der Region gesendet, den der Knoten selbst meldet.
• Zuerst das Internet, das Mesh, wenn es wegfällt: der Todo-Demonstrator repliziert über libp2p und bietet an, die Liste auf den Funk zu verlegen, sobald die Verbindung abreißt — erst nach Rückfrage, denn Sendezeit ist rationiert.
• Auf Hardware gemessen: erstmals am 4. September 2026 über die Luft; die Evaluation mit Laufzettel und Befunden steht auf lora.le-space.de.

→ Experimentell und GPL-3.0 — Forschungsdemonstratoren, nicht auditiert; wer den Kanal empfängt, kann in eine Liste schreiben.

Unser Fork des offiziellen libp2p-Projekts mit eingebautem Relay-Button: der Cross-Language-Showcase — Chat zwischen Go-, Rust-, TypeScript- und Nim-Peers im Browser — erweitert, sodass jeder auf Knopfdruck einen eigenen Relay deployen kann.

Eine Peer-to-Peer-Tabellenkalkulation auf einem Yjs-CRDT, die ihre Fähigkeiten anderen Anwendungen anbietet. Das Universal Connectivity Extension Protocol lässt libp2p-Anwendungen ankündigen, was sie können, und die Erweiterungen der anderen direkt finden — ohne zentrale Registrierung. Die Diensterkennung läuft über libp2p-eigenes Identify: Jede Verbindung tauscht ohnehin aus, welche Protokolle beide Seiten sprechen — eine Erweiterung kündigt sich also an, indem sie eines ist. In einer Woche entstanden, beim Hackathon des libp2p-Projekts selbst, erster von fünf Beiträgen.

→ Erster Platz, libp2p Universal Connectivity Hackathon, Dezember 2025