Local-first software and data ownership

Local-first software is an approach to building applications in which the primary copy of a person's data lives on that person's own device. The software works offline and syncs between devices and collaborators without depending on a central server staying alive.

Idea and origin

The term comes from an essay titled "Local-first software: You own your data, in spite of the cloud," published in April 2019 by Ink & Switch, an independent research lab that studies tools for thought.^[1]^[2]

The essay starts from a trade-off. Cloud apps such as Google Docs and Trello make collaboration easy, but centralized storage takes ownership from users, and if a service shuts down the software stops working and the data can be lost.^[1] In a cloud app the local copy is only a cache. A local-first app swaps the roles: the copy on the laptop, tablet, or phone is primary, and servers hold secondary copies that help with access from several devices.^[1]

The seven ideals

The essay lists seven ideals.^[1]

Fast. No spinners waiting on a server.
Multi-device. Work is free to move between devices.
Offline. The network is optional.
Collaboration. Several people can work together.
Longevity. Work stays accessible after the software maker is gone.
Privacy. Security and privacy are the default.
User control. The person keeps ownership.

Compared with cloud-first and offline-only software

Cloud-first software treats the server as the authority. Each change must reach the server, so speed depends on the network, and the application depends on the service staying in business.^[1]

Purely offline software, such as a classic text editor, keeps files on the local disk. It is fast and private, but sharing usually means email attachments or manual merging, and simultaneous edits produce conflicted copies.^[1] Local-first software keeps those strengths and adds automatic sync and collaboration.

Technical building blocks

CRDTs. A conflict-free replicated data type lets replicas change independently and then merge, with an algorithm that resolves inconsistencies automatically.^[3] The essay proposes CRDTs as a foundational technology for local-first software.^[1]
Operational transformation. This older technique adjusts concurrent operations so collaborators see the same document. Some designs use a central server to order operations, a contrast with CRDTs.^[4]
Sync engines. A sync engine stores changes locally, exchanges them when a connection exists, and merges them.
Peer-to-peer sync and relays. Devices can connect directly. Otherwise a relay passes data along, and in Syncthing it only retransmits encrypted data.^[5]
End-to-end encryption. Servers that store copies can hold only data they cannot read.^[1]
Local databases. SQLite is an embedded SQL database engine with no separate server process, and a whole database sits in one disk file.^[6]
File-over-app formats. Plain text and Markdown files open in many programs, which helps data outlive one application.

Example tools

Obsidian stores notes as Markdown plain text files in a vault, which is a folder on the local file system.^[7]
Syncthing is a continuous file synchronization program, and its site says there is no central server.^[8]
Automerge describes itself as a local-first sync engine that works offline.^[9] Yjs is an open CRDT library that does not require a central server for coordination.^[10]
Git is a distributed version control system. Clients fully mirror the repository, so any clone can restore a lost server.^[11]
Logseq is an open source knowledge management platform that supports Markdown and Org-mode files.^[12]

Benefits

Speed comes first, because reads and writes happen on the device. Resilience follows: work continues on a plane or during a service outage. Privacy improves because a device holds only its owner's data instead of a central database for everyone. Longevity improves because work should keep running after a company is gone.^[1]

Limitations

Conflicts and merge semantics. A merge can be consistent and still surprise a person, so interfaces must show what changed.
Large shared datasets. A device may be unable to hold everything a big team shares.
Search across devices. Each device indexes only what it has.
Access control and revocation. Data already copied to a device is hard to take back.
Backups and device loss. A lost device holding the only copy means lost work.
Schema migration. With no central database there is no single current schema, so app versions must interoperate as formats change.^[1]
Many collaborators. Large groups may still need servers for permissions and history.

Connections to this wiki

Decentralized and permanent knowledge is a close neighbor. Arweave describes itself as permanent information storage.^[13] A local-first wiki can keep the editable copy at home and publish stable snapshots, as in A design for a permanent decentralized wiki using Arweave and Bitcoin Cash Memo and Building a Second Brain on the Permaweb Without Losing Ownership. For a practical start, see How to run a personal wiki.

Local AI fits the same philosophy, since a model and a notes folder can share one device, so personal data stays there. See Running AI models locally.

Agents benefit from plain files, because an agent can read and write them directly. The Model Context Protocol is an open standard for connecting AI applications to systems such as local files and databases.^[14] See Model Context Protocol.

Open code and open formats let communities maintain software after its first maker stops. See Open-source software that should exist.

Discussion questions, essay ideas, and learning related AI prompt ideas

Discussion questions

Which of the seven ideals matters most for your own notes, and which could you give up?
When two people edit the same sentence while offline, what should the merged result look like?
How can an agent be allowed to edit local files without risking data loss?

Essay ideas

Compare a cloud-first and a local-first note app on speed, privacy, and longevity.
Explain why plain text files may outlast many applications.

AI prompt ideas

Explain CRDTs with a shared shopping list example, then quiz me with five questions.
Help me plan a backup routine for a folder of Markdown notes synced across three devices.
Act as a skeptic and list the weakest points of local-first design.

Readings from Wikipedia

External links

References

[essay-1] 1.00 ^1.01 ^1.02 ^1.03 ^1.04 ^1.05 ^1.06 ^1.07 ^1.08 ^1.09 Local-first software: You own your data, in spite of the cloud, Ink & Switch

[inkhome-2] Ink & Switch

[wpcrdt-3] Conflict-free replicated data type, Wikipedia

[wpot-4] Operational transformation, Wikipedia

[relay-5] Relaying, Syncthing documentation

[sqlite-6] About SQLite

[obsidian-7] How Obsidian stores data, Obsidian Help

[syncthing-8] Syncthing

[automerge-9] Automerge

[yjs-10] Yjs

[gitbook-11] About Version Control, Pro Git

[logseq-12] Logseq, GitHub

[arweave-13] Arweave

[mcp-14] What is the Model Context Protocol, modelcontextprotocol.io

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]