The Local-First Peer-to-Peer Stack

The term was coined by Ink & Switch (Kleppmann et al.) and describes software that follows seven ideals:

1. No spinners — fast, because it works with local data
2. Multi-device — seamless sync across all your devices
3. Offline — full read/write functionality without internet access
4. Collaboration — real-time collaborative editing for multiple users
5. Longevity — access and edit your data for decades, outliving any server
6. Privacy — encrypted data that service providers cannot read
7. 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.

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.

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.

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.