The Local-First Peer-to-Peer Stack

Local-first pre-accounting: bank and crypto transactions matched with receipts, and a monthly DATEV package at the end — the posting itself happens elsewhere, and the books never leave your device.

• The passkey is the identity and the key: it signs you in and everything is sealed with keys derived from it. There is no username, no password, and no copy with anyone else.
• A bridge for what a browser cannot do: a small service on 127.0.0.1 talks to Hibiscus, the accounting mailbox, customer portals, exchanges and wallets — and to your own language model, which reads receipts redacted and only on a click.
• Matching is the app's own work: a score over amount, invoice number, vendor, IBAN and date links receipts to payments, learns from your corrections, and follows own transfers across accounts, chains and bridges.
• Devices become peers: the same books on phone and computer after a passkey proof — over public relays, a relay in your own bridge, or by QR with no relay at all.
• Out the door as DATEV: SKR 03, BU keys, a monthly EXTF ZIP for your bookkeeping software, with the receipts attached — and invoices come in from the invoicing app over UCEP.

→ Pre-accounting for a small business — the stack carrying the records a company actually has to keep

A folder on this device that stays the same as a folder on another one — files added, changed and deleted — with no account and nothing in the middle.

• Paired by a code, then peers: two devices scan a code off each other's screen — once in each direction, and only at pairing — over libp2p-webrtc-qr. After that the bytes travel directly and no server ever holds them.
• The index is a CRDT, the bytes are not: Yjs carries a map of paths and content addresses; the files themselves move over bitswap. Putting file content in a CRDT is the mistake this is built to avoid.
• Both copies survive a conflict: two devices that changed the same file keep both, Dropbox's way — and the rescued name comes from the content address, so two devices that diverged to the same bytes converge on one entry rather than two.
• A real folder on Chromium: pick a directory and it syncs that, noticing edits made outside the app. Elsewhere it uses the browser's private storage, which every engine has.
• Opens without a network: installable, and the folder is there when the internet is not.

→ A folder shared between two devices — the stack applied to the plainest thing people want from it

Class booking for yoga studios with more than one location, built to show what the stack does when an application actually depends on it.

• No relay at all: devices meet by scanning a QR code or opening an invite link — libp2p-webrtc-qr as the only transport, which makes it the working proof that the free path is enough.
• No account, no password: a passkey is the identity, and a second device is approved by the first.
• Passes are an append-only log: the balance is folded from the events and never stored, so two counters in different places can sell and redeem without asking anyone for permission.
• Where it stops being comfortable is written down: the handbook has a chapter on what the app cannot do, and the repository documents the limits it ran into rather than the features it hoped for.

→ Showcase for OrbitDB and WebRTC over QR — a real application, not a demo

Invoices in your own peer-to-peer store, not on somebody's server — as plain JavaScript modules, each with its own spec. A record is frozen by issuing it and corrected by Storno, never edited; number series run per identity; the letter comes from a Markdown template the reader owns; the PDF carries a payment code — EPC GiroCode for a SEPA transfer, BIP-21 for Bitcoin, EIP-681 for an EVM chain. An invoice in another currency states the VAT in euros with the rate, its source and its day. Continues the invoice01 chapter of Simple Todo, with its history.

→ The counterpart to Le Space Belege over UCEP: create-eigenbeleg and record-payment are the first extension calls with authorization

Decentralised blogging that replicates between browsers — publish without a hosting provider.

Back up, restore and replicate OrbitDB databases through pluggable storage backends (Aleph, Pinata, Lighthouse), with hashes and identities preserved — and bring a database back on a device that has nothing, with a WebAuthn passkey on a security key alone.

→ Formerly the OrbitDB Storacha Bridge: Storacha's uploads ended in May 2026, and Aleph, Pinata and Lighthouse took their place.

Passkey-based identity for OrbitDB — no extensions, just your browser and a biometric sensor. Every oplog entry has to be signed, so the real question is where the signing key lives:

• Plain keystore (OrbitDB default): the Ed25519 key sits unencrypted in the browser's IndexedDB. Anything that runs script on your origin can copy your identity and write as you — permanently.
• WebAuthn-encrypted keystore: same key, AES-GCM-encrypted at rest, rehydrated into memory only after a WebAuthn unlock (PRF, largeBlob or hmac-secret). One prompt per session, writes stay fast; safe at rest, in memory while the tab is open. The pragmatic default — demo.
• Hardware-backed keys (varsig): no OrbitDB keystore at all. The key is generated inside the authenticator — Secure Enclave, TPM, security key — and never leaves it. One passkey prompt per write, and nothing in the browser left to steal — demo.
• Why varsig: an authenticator never hands you a plain signature over your payload — it signs its own authenticatorData + clientDataJSON-hash structure. The algorithm varies on top of that: Apple, Android and Windows platform authenticators sign with ES256 (P-256), while EdDSA/Ed25519 (COSE -8) is in the spec and works on a handful of security keys — so a passkey DID cannot assume either curve. Varsig is the self-describing envelope carrying structure and algorithm together, so the assertion verifies as an OrbitDB oplog signature and, via toUcantoSigner(), as a UCAN delegation signature. Without it a hardware key cannot be the signer of either, whichever curve it happens to use.
• Recovery on an empty device: the same passkey yields the same DID on hardware that has stored nothing, and a restored identity signs again — a list came back onto a reset phone with nothing but a YubiKey on 21 September 2026.
• One passkey, also a wallet: the same credential signs 32-byte challenges for a P-256 smart account, in the WebAuthn shape that Calibur accounts verify on-chain — which is how the escrow01 chapter pays on Sepolia: one passkey, OrbitDB identity and on-chain account together.

Deploy libp2p relay nodes on demand — the toolchain at the core of the local-first stack.

• One click, one relay: deploys a libp2p/OrbitDB relay (signaling, bootstrap, IPFS pinning) — run it for a meeting, a project or years, then stop it.
• Full automation: build qcow2 RootFS images, publish to IPFS, manage VM lifecycle & retention via CLI and GitHub Actions.
• Embeddable UI: React & Svelte components — the actual "Relay Button" — for any app.
• Bootstrap discovery: relays register themselves; apps discover them automatically.
• New — remote browser replication: CI spins up a real browser on a fresh VM in another network and verifies true cross-network P2P replication end-to-end — replacing services like testingbot.com for local-first P2P apps.
• Runs on Aleph Cloud: decentralised compute, VMs without a cloud account; further providers — decentralised and centralised — planned.

Relay and pinning service keeping OrbitDB databases available while peers are offline.

Two devices connect directly as libp2p peers — no relay, no signaling server. Each phone scans a code off the other's screen, once in each direction.

• Signaling as a QR code: offer and answer travel out-of-band as signed, deflate-compressed payloads instead of through a circuit relay. Both legs are carried by hand, because there is no server to bring the answer back — a second code, an invite link, a text field, or an audible tone when the answering device has no camera worth using.
• A quarter the size, optionally: a compact payload sends only the fingerprint and the candidates and rebuilds the SDP at both ends — the packing idea from QWBP, with the signature added. ~284 characters against ~995 is the difference between one still code and an animated sequence, and it is what lets a handshake fit carriers a full SDP cannot: a couple of LoRa packets, a few seconds of tone.
• Signed, not just scanned: the SDP carries the DTLS fingerprint, so signing it with the libp2p key binds the WebRTC session to the peer id — the same idea certhash uses in WebRTC-Direct. That is what makes it safe to skip the usual encryption handshake.
• Tampering fails closed: a modified payload is rejected before any dial happens, and a browser refuses its own offer instead of self-dialing.
• Works without infrastructure: useful where there is no relay to reach — the same room, the same LAN, an air-gapped network.

→ Experimental — a QR code removes the signalling server, not everything else a direct connection needs. Browsers and networks often do not provide it: a NAT that allows hole punching, a Wi-Fi where two clients may address each other, a secure origin for the camera. Read the README before building on it.

Browser-based storage with WebAuthn/Passkey DIDs and UCAN delegations — upload to Filecoin (planned) without accounts or passwords.

→ Storacha upload-service fork — UCAN 1.0 upgrade planned

Relay-Button-style deployments on Akash Network — a second decentralised compute target.

→ Consolidation with Relay Button planned

Tutorial for local-first P2P PWAs: WebAuthn/Passkey identity, OrbitDB data, browser-to-browser sync. No server, no accounts, no passwords.

The Universal Connectivity Extension Protocol, written down as a specification: a libp2p peer offers extensions — small services with named commands — that any other peer can discover and call, with no registry or server in between. Discovery rides on libp2p's own identify protocol; every call is one request and one response on a short-lived stream; commands that change state or reveal data require a grant obtained by pairing. A Working Draft (wire revision 2) — and possibly the first time individual local-first peer-to-peer apps call each other with authorization: the invoice extension is specified to connect an invoicing PWA with a pre-accounting app.

→ Based on the winning entry of the libp2p Universal Connectivity Hackathon — the P2P Spreadsheet further down this page

A byte courier for local-first apps over LoRa mesh radios — it works with Meshtastic nodes and carries OrbitDB and Yjs where there is no internet.

• Within the airtime law: payloads are cut into radio-sized frames, retransmitted selectively, and paced to the region’s duty cycle, which the node itself reports.
• Internet first, the mesh when it goes: the todo demonstrator replicates over libp2p and offers to move the list onto the radio once the connection drops — it asks first, because airtime is rationed.
• Measured on hardware: it first crossed the air on 4 September 2026; the evaluation, its run sheet and its findings are on lora.le-space.de.

→ Experimental and GPL-3.0 — research demonstrators, not audited; anyone who can hear the channel may write to a list.

Our fork of the official libp2p project with the Relay Button built in: the cross-language showcase — chat between Go, Rust, TypeScript and Nim peers in the browser — extended so anyone can deploy their own relay on demand.

A peer-to-peer spreadsheet on a Yjs CRDT that offers its capabilities to other apps. The Universal Connectivity Extension Protocol lets libp2p applications announce what they can do and discover each other's extensions directly — no central registry. Discovery rides on libp2p's own identify protocol: every connection already exchanges the list of protocols each side speaks, so an extension announces itself simply by being one. Built in a week for the hackathon run by the libp2p project itself, and judged first of five entries.

→ First place, libp2p Universal Connectivity Hackathon, December 2025