No servers. No accounts. No passwords. Your data lives on your device and travels directly to the people you share it with. Networks run with always-on peers or entirely without them — add one whenever a group wants more reach, and when none is reachable, devices connect directly by scanning a code. Neither mode is the fallback.
Every layer works without a central service — and every layer is an open-source building block you can use on its own.
Building blocks
Showcases, prototypes, components and libraries — not slideware. Every one is open source, most come with a live demo, many as an npm package.
yogasuci.le-space.de
Yogasūcī (योगसूची)
Yogasūcī (योगसूची)
showcase
IdentityDataSync
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
simple-todo.le-space.de
Relay Button
Relay Button
beta
Infrastructure
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: decentralized compute, VMs without a cloud account; further providers — decentralized and centralized — planned.
webrtc-qr.le-space.de
libp2p WebRTC over QR
libp2p WebRTC over QR
beta
Sync
Two browsers connect directly as libp2p peers — no relay, no signaling server. One phone scans the WebRTC handshake off the other screen.
Signaling as a QR code: offer and answer travel out-of-band as signed, deflate-compressed payloads instead of through a circuit relay. A text field is the copy/paste fallback.
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.
→ New — released on npm as @le-space/libp2p-webrtc-qr
simple-todo.le-space.de
simple-todo
Simple Todo
Simple Todo
tutorial
IdentityDataSync
Tutorial for local-first P2P PWAs: WebAuthn/Passkey identity, OrbitDB data, browser-to-browser sync. No server, no accounts, no passwords.
▶ simple-todo — chapter "main" — every visitor automatically joins the same shared todo list; just open the URL.
▶ collab01 — chapter "collab01" — create your own lists and share them with chosen peers via their OrbitDB address.
▶ passkey01 — chapter "passkey01" — sign in with a passkey instead of a throwaway key. Your WebAuthn DID signs every entry and is shown as its author.
▶ acl01 — chapter "acl01" — private, owner-only lists with per-DID write permissions. Grant or revoke access at runtime, without the list address changing.
▶ qr01 — chapter "qr01" — hand a list to another device by scanning a code. No relay, no bootstrap list, no internet: the two devices meet directly and the data stays in the browser's own storage.
connect.nicokrause.com
chat
Universal Connectivity
Universal Connectivity
stable
Sync
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.
▶ chat — the public room with the peers currently connected — discovery takes about half a minute after you open it.
▶ relay button — the embedded Relay Button: pick a tier and deploy your own relay without leaving the chat.
nikrause.github.io
OrbitDB Relay
OrbitDB Relay
beta
InfrastructureData
Relay and pinning service keeping OrbitDB databases available while peers are offline.
le-space.github.io
webauthn-did
OrbitDB WebAuthn DID
OrbitDB WebAuthn DID
beta
Identity
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.
▶ webauthn-did — a passkey becomes your OrbitDB identity — the DID is derived from the credential, no keystore involved.
▶ encrypted-keystore — an Ed25519 keystore encrypted at rest, unlocked once per session by WebAuthn — the pragmatic default.
▶ varsig — no keystore at all — the authenticator signs every entry itself, one passkey prompt per write.
P2P Spreadsheet + UCEP
P2P Spreadsheet + UCEP
hackathon
DataSync
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
ucan.nicokrause.com
UCAN Store
UCAN Store
in development
IdentityArchive
Browser-based storage with WebAuthn/Passkey DIDs and UCAN delegations — upload to Filecoin (planned) without accounts or passwords.
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
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 peers that anyone can start — 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.
Yes. On first start, the consent screen carries a checkbox: “Connect to the public libp2p relay network”. Clear it and the browser opens no outbound connection at all — no bootstrap, no relay. Nothing announces you, nobody can find you, and no foreign node pins your data.
You can still connect, just deliberately instead of automatically: by QR code directly between two devices, or by starting your own relay that only your devices trust.
Independently of that, there is the question of where the data lives: that is decided by the storage type in the IPFS/OrbitDB configuration. LevelDB or IndexedDB writes it to your device's disk; memory storage keeps it in RAM only. The Simple Todo demo currently runs on memory storage, so a reload starts over.
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 (at 0.0.2 — early, but it works): 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.
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.
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.
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.
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.
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.
See it work: the acl01 tutorial chapter creates an owner-only list, shares it by address and grants a second DID write access at runtime — the address never changes.
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.
Yes, and it costs nothing to run. With libp2p-webrtc-qr two devices exchange the WebRTC handshake themselves — as a scanned QR code when they are in the same room, or as an invite link sent through any messenger. Once the connection is up it is an ordinary libp2p connection: gossipsub forms its mesh across it, OrbitDB replicates over it, and a third device joining any member joins the same mesh.
The handshake travels in the fragment of the link, the part after the #, which browsers never send to a server. No signalling server sees it — and there is none to see it.
That makes it two things at once. It is the free default: an app can ship without any infrastructure behind it and still let people work together. And it is the fallback that holds when every relay is down, unreachable or blocked — because there is nothing at a fixed address left to block. What an attacker would have to interfere with is a QR code held up to a camera.
What it asks for in return is a human moment. Someone scans, or sends a link, and the other side opens it. A relay spares you that: it is reachable around the clock and peers find each other without anybody doing anything. Once a mesh exists, a dropped connection can be repaired through the peers that are still connected — but the first introduction is always made by a person.
Two honest limits. Devices on different networks still need STUN to discover their own public address; that is a single UDP question to a public server, carries no data, and can be switched off if both devices share a network. And a QR code holds a bounded amount, so a handshake with many candidates is split across an animated sequence rather than one still image.
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.
