Der Local-First Peer-to-Peer Stack

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 Sicherheitsschlüssel.

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

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.

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

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.

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

Zwei Browser 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.

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

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.

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

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.

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

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

Eine Komponente zum Einsetzen, die einer Anwendung eine Passkey-Identität über mehrere Geräte hinweg gibt — auf Basis unseres WebAuthn-Identity-Providers. Kein Credential verlässt je das Gerät, auf dem es entstanden ist:

• Jedes Gerät bringt seinen eigenen Passkey und seine eigene OrbitDB-Identität mit. Ein zweites Gerät zu verbinden heißt, dass das erste ihm namentlich Schreibrechte in einem OrbitDBAccessController erteilt — keine Wildcards, kein geteiltes Geheimnis, kein kopiertes Credential.
• Das Pairing läuft über libp2p, nicht über einen Server: Gerät zwei wählt Gerät eins über ein eigenes Protokoll an, ein Mensch bestätigt die Anfrage, und erst danach kommt die Registry-Adresse zurück.
• Wiederherstellung ohne zweites Gerät: Aus dem PRF-Output des Passkeys entsteht ein IPNS-Schlüssel, der ein Manifest auflöst, das auf das Ed25519-Archiv zeigt — verschlüsselt, auf IPFS. Browser-Speicher gelöscht, und dieselbe Identität kommt über ein öffentliches Gateway zurück, ganz ohne Anmeldung.
• Wo es noch nicht fertig ist, steht geschrieben: Die Pairing-Anfrage ist noch nicht signiert, und der Weg dort heraus — zusammen mit dem Umstieg auf libp2p 3, Helia 7 und OrbitDB 4 — wird offen nachgehalten.

→ entwickelt mit @asabya — Upstream unter github.com/asabya/p2pass

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

→ Konsolidierung mit Relay Button geplant

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