Local-First Software
Software designed so the primary copy of a user's data lives on their own device — synced via open standard protocols and CRDT libraries such as Automerge — giving offline access, speed, resilience against provider shutdown, and genuine user ownership and portability; the principle Kleppmann applies across collaboration software (local-first) and decentralised social media (AT Protocol/BlueSky) to reduce vendor lock-in.
Also known as: local-first, local-first software, local-first movement, offline-first, primary copy on device, data agency, data portability, CRDT, CRDTs, Automerge, AT Protocol, atproto, Personal Data Server, open sync protocol
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement Martin Kleppmann · 2026-07-06 | local-first software | A set of design principles and values (not a protocol) for collaboration software in which the primary copy of the data lives on the user's own machine — giving offline access, faster interaction without network round-trips, resilience against provider shutdown or lockout, and genuine user ownership — realized by libraries such as Automerge. |
| Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement Martin Kleppmann · 2026-07-06 | AT Protocol (atproto) | The decentralised protocol underlying BlueSky: user data lives in Personal Data Servers, a Relay aggregates all activity into a firehose, and anyone can build indexing services on it; designed to give a UX indistinguishable from a centralised network while guaranteeing users can switch providers without loss. |
| Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement Martin Kleppmann · 2026-07-06 | Personal Data Server (PDS) | A per-user data store holding a user's posts, replies, and social graph, portable between providers so switching loses nothing. |
| Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement Martin Kleppmann · 2026-07-06 | Automerge | An open-source CRDT library (written in Rust, compiled to WebAssembly with Swift/Java/Python/Go/C bindings) providing a data model that auto-syncs across machines and supports both real-time collaboration and Git-like branch/diff/merge/history, for many file types. |
| Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement Martin Kleppmann · 2026-07-06 | open (standard) sync protocol | A shared, non-proprietary syncing protocol — like Git's push/pull — that lets multiple interchangeable providers serve the same data, dissolving lock-in while retaining cloud sync's convenience; the missing ingredient in Google Docs. |
| How to Build More Resilient Local-First Applications With AT Protocol Infrastructure Olimpiu Pop · 2026-07-13 | local-first | Here narrowed to mean specifically: user data lives in a PDS and apps sync via shared atproto infrastructure, as opposed to the broader local-first movement's general principle of offline-capable apps that own their local data. |
| Podcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing Johannes Schickling · 2026-07-27 | Local-First | A design principle where the client (not the server) holds the primary copy of data and processes changes immediately, giving offline access and no-round-trip speed — distinct from mere 'offline mode' bolted onto a cloud-first app. |
| Podcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing Johannes Schickling · 2026-07-27 | CRDT (conflict-free replicated data type) | In Schickling's framing, a mutable-object abstraction (object, array, set, counter) with automatic, deterministic merge semantics across replicas — contrasted against event sourcing's append-only, replay-based model. |
Documents (3)
- Podcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing Johannes Schickling · 2026-07-27 source ↗ Reader 🖥️
Client-side event sourcing — replaying an immutable log of events rather than syncing a mutable, auto-merging CRDT object — is a structurally different but equally legitimate way to achieve local-first software's goals, and should be adopted (like local-first itself) only when an application's core value genuinely depends on offline resilience, client-side speed, and user data ownership, since restructuring where and how data lives is one of the most fundamental and hardest-to-reverse decisions a team can make. - How to Build More Resilient Local-First Applications With AT Protocol Infrastructure Olimpiu Pop · 2026-07-13 source ↗ Reader 🖥️
AT Protocol's personal-data-server-plus-relay infrastructure can serve as a general-purpose, resilient foundation for local-first distributed applications of any kind, not only social networking, by letting apps offload storage, sync, and auth to shared, fungible infrastructure instead of fragile app-specific backend servers. - Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement Martin Kleppmann · 2026-07-06 source ↗ Reader 🖥️
Users gain real agency over their data not by eliminating servers or fully decentralizing but by adopting open, standard protocols that keep data portable and provider-independent — the common principle Kleppmann traces from the unbundling of monolithic databases into modular building blocks, through BlueSky's AT Protocol, to the local-first software movement.
Propositions touching this concept (31)
By publication month, oldest first (extraction month when no publication date is known).
2026-05
- explicitBig tech companies are spending 50-75% of revenues on AI infrastructure, but Apple is a dramatic outlier at roughly 10%, which may reflect a deliberate bet on local-first AI.
2026-07
- explicitAT Protocol can serve as a general foundation for distributed applications, not only for social networking.
- explicitThe App View, the bespoke per-app server in the standard atproto architecture, is optional and is the weakest point in the stack.
- explicitA collaborative rich-text editor can be built using atproto as a YJS sync transport, with CRDT updates written as records to the user's PDS and replicated to collaborators via the relay.
- explicitUsing native, self-describing CRDT JSON records (with fields like $type, listId, text, done, createdAt) rather than opaque CRDT blobs lets other apps read and use the data even if they ignore the CRDT metadata.
- explicitField-level last-write-wins registers combined with compare-and-swap-and-retry on writes is a workable conflict-handling strategy for collaborative apps built on atproto records.
- explicitatproto's PDS-plus-relay infrastructure can be used purely as a signalling channel to establish direct WebRTC peer-to-peer connections.
- explicitSocial media is too important to be left in the hands of a single company — the founding value behind the AT Protocol.
- explicitPure federation (ActivityPub/Mastodon) sacrifices global consistency and user experience — different servers show different reply threads and like counts — so AT Protocol deliberately traded some federation for a global index (Relay/firehose) to deliver a UX indistinguishable from a centralised network.
- explicitThe core design principle of AT Protocol is that users must be able to switch providers without losing anything — username, posts, replies, or social graph — so guaranteed data portability, not network topology, is what defeats lock-in.
- explicitLocal-first software is a design principle in which the primary copy of collaboration data lives on the user's own device, giving offline access, faster interaction (no network round-trip per action), and resilience against a provider shutting down or locking the user out.
- explicitLocal-first is fundamentally about user agency and empowerment: if you hold a local copy of your data, nobody can take it away from you even if every server disappears.
- explicitGit is the existence proof for local-first done right: all data and history are local, and because its sync protocol is an open standard, the same repository can push to GitHub, GitLab, or a self-hosted server, removing most provider lock-in.
- explicitCloud services are not the problem — a single proprietary sync service is; an open, standard sync protocol that lets multiple providers serve the same data (as Git does) dissolves most of the lock-in while keeping cloud sync's convenience, which is the same principle that underlies AT Protocol.
- explicitBecause syncing edits between devices requires capturing those edits anyway, local-first brings Git-like version control (history, diff, branch, merge) to non-text domains — spreadsheets, graphics, CAD, presentations — that lack it today, almost as a free byproduct.
- explicitdevelopedLocal-first is a set of principles and values rather than a protocol, realized by libraries such as Automerge — an open-source CRDT data model (Rust compiled to WebAssembly, with Swift/Java/Python/Go/C bindings) that auto-syncs across machines and supports both real-time collaboration and version-control workflows across many file types.
- explicitcorroboratedLocal-first fits apps where the user authors and edits their own data (documents, spreadsheets, graphics, CAD) but not data with an inherently authoritative server copy — bank balances, warehouse stock, or a large product catalogue — where a local edit is meaningless or downloading everything makes no sense.
- explicitcorroboratedRetrofitting an existing app to local-first is straightforward when its business logic and state already live client-side, but hard when logic lives on the server — in which case starting over is often easier.
- explicitAT Protocol and local-first are the same underlying principle — empowering users by reducing lock-in and enabling data portability — applied to two domains: decentralised social media and small-group collaboration software, respectively.
- explicitLocal-first's core promise is shifting the primary data copy and the interaction loop to the client, not merely adding offline support to an otherwise cloud-first app.
- explicitNot every application benefits from local-first; adoption should be justified per-app by whether offline resilience and data ownership are core to that app's value, not treated as a default upgrade.
- explicitClient-side event sourcing — an append-only log of events replayed to derive state — is a viable alternative to CRDTs for achieving local-first's goals, trading a different set of complexities for a different set of guarantees.
- explicitEvent sourcing suits data that is messy, externally sourced, and needs schema evolution over time better than CRDTs, because new application logic can be applied by replaying full history rather than mutating an object in place.
- explicitCRDTs remain a sufficient and often simpler foundation when data types are simple (counters, sets, GitHub-label-style toggles) and merge semantics are not order-sensitive.
- explicitA local-first app's client-side speed can be combined with centralized durability by treating the sync backend purely as a backup/propagation channel rather than as the authoritative source of truth.
- explicitLocal-first fits domains where the user is the author/owner of their own data (a personal library, personal notes) and is a poor fit for data with an inherently authoritative external source of truth, such as a global financial system.
- implicitRetrofitting an existing application's data layer to local-first after the fact is far more costly than designing it in from the start.
- explicitDecomposing a monolithic centralized data model into small, independently syncable units (e.g. per-issue, per-canvas) is a necessary precondition for local-first to scale.
- explicitWhether an app's data can be cleanly decomposed into bounded units (vs. an all-connected social-network graph) is itself a signal of whether local-first is a good fit.
- explicitGenuine data ownership for a local-first app's users requires exposing a durable, legible source-of-truth artifact (the event log plus the materialized database), not just a one-off export dump.
- implicitGDPR's mandatory data-export requirement, though not designed for this purpose, inadvertently created reusable infrastructure for bootstrapping local-first or otherwise portable applications.
Open gaps (11)
- incompleteThe piece never addresses production-readiness concerns — the security model of PDS access grants, the cost and scaling behavior of relay infrastructure under real-world traffic, or how 'free public relays' stay funded and available — despite building its entire resilience argument on a comparison to a shut-down commercial sync vendor.How to Build More Resilient Local-First Applications With AT Protocol Infrastructure — read next: Look at atproto's own specs/documentation on PDS auth scopes (OAuth-style grants) and relay economics, or follow-up writeups/benchmarks of atproto apps actually running in production (not conference demos), to test whether the resilience claim holds beyond prototypes.
- incompleteThe 'TURN server of shame' moment is reported almost as a joke, but it is evidence against the article's throughline: even the most 'decentralized' of the three experiments needed a centralized relay to work reliably under real network conditions. The piece never examines what this implies for the resilience claims behind the other two experiments — do PDS/relay availability guarantees actually hold up better than the vendor infrastructure the talk criticizes?How to Build More Resilient Local-First Applications With AT Protocol Infrastructure — read next: Investigate whether atproto relays and PDS hosts have documented uptime/SLA characteristics, or whether they carry the same vendor-dependency risk the talk criticizes — i.e., is the central risk (single point of failure) actually eliminated, or just relocated to a different, still-centralized operator?
- incompleteThe interoperability cost of experiment 1 (document state spread across many records) is explicitly named as 'the main challenge,' but the article reports no proposed resolution, design pattern, or even acknowledgment from Lazaroff of how the tension between fine-grained per-user data ownership and cross-app interoperability might be architecturally resolved.How to Build More Resilient Local-First Applications With AT Protocol Infrastructure — read next: Look for Lazaroff's own materials (talk recording, slides, blog posts) or atproto community discussion on record/schema design patterns that balance granular ownership with interoperability — a known distributed-systems trade-off worth connecting to the persona's architecture and distributed-systems interests.
- uninformedAs InfoQ reporting on a talk rather than the talk itself or Lazaroff's own writing, the article gives no real content from the audience Q&A beyond naming three topic areas ('trade-offs of interoperability, synchronisation, and WebRTC deployment') — it is unclear whether anyone directly challenged the core resilience claim (e.g., whether a PDS host is itself just another centralized dependency).How to Build More Resilient Local-First Applications With AT Protocol Infrastructure — read next: Find the original talk recording or Lazaroff's own blog/notes to see the actual Q&A content and whether the 'shared infra reduces single points of failure' claim was scrutinized directly by the audience.
- incompleteAdoption economics of decentralisation are left open. Kleppmann concedes that real decentralisation depends on funded alternative providers actually existing, but never examines why they would be funded or what sustains a commodity, easily-substitutable provider — the very portability that empowers users also destroys the provider's pricing power. Without a viable business model for the exit option, 'agency via guaranteed switching' risks staying hypothetical, as it largely did for email/XMPP federation.Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement — read next: Two-sided platform and commons-funding economics; the decline of federated protocols (XMPP, RSS) despite openness; Cory Doctorow on interoperability mandates as the missing forcing function.
- incompleteThe incentive against open sync protocols is unaddressed. The argument assumes vendors will adopt open, portable sync (like Git's) even though proprietary lock-in is precisely what makes SaaS valuable. No mechanism — market pressure, regulation, a standards body — is offered that would make an incumbent like Google standardise away its own moat, and the Git example itself shows incumbents keep the non-portable parts (GitHub issues, wikis) closed.Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement — read next: EU Digital Markets Act interoperability provisions; the history of why Google Docs never opened its sync; the switching-cost/moat economics already in this corpus (extract-mellbye-wrapper-vs-infrastructure).
- incompleteEnterprise, regulatory, and security fit of local-first is barely touched. With the primary copy of data spread across many user devices, questions of enterprise governance, GDPR / data-residency, audit trails, device loss or theft, and access control at scale go largely unexamined — Kleppmann names end-to-end encryption and decentralised access control only as work still in progress. The hard organisational tradeoffs of device-held data are not weighed against the user-agency benefits.Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement — read next: Data-sovereignty sources in this corpus; EU AI Act / GDPR data-residency obligations; enterprise endpoint-security and MDM literature for the device-loss and access-control problems.
- incompleteWho actually benefits and who bears the cost is not asked. The framing centres user empowerment, but shifting storage, compute, conflict-resolution, and support burdens onto clients and app developers — while removing the server's authoritative control — may not translate into real agency for a median, non-technical user. 'Agency' that is only exercisable by switching providers or self-hosting may be agency mostly for the already-technical.Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement — read next: Hirschman's 'Exit, Voice, and Loyalty' on the limits of exit-as-empowerment; empirical uptake of GDPR Article 20 data-portability rights; digital-literacy research on who can actually exercise portability.
- incompleteSchickling advocates client-side event sourcing as a general alternative to CRDTs for local-first, but never explains how event sourcing handles concurrent conflicting writes from multiple simultaneous devices or users — the central problem CRDTs were explicitly designed to solve. LiveStore's actual conflict-resolution model for genuinely concurrent multi-writer scenarios is left unaddressed; every concrete example he gives (Overtone) is single-user.Podcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing — read next: LiveStore's own documentation/RFCs on multi-client concurrent writes and conflict resolution; Martin Kleppmann's 'Turning the Database Inside Out' talk, which Schickling names as event sourcing's intellectual ancestor.
- incompleteThe claim that event sourcing suits 'messy, externally sourced data' better than CRDTs is illustrated only by a single-user personal-curation app (Overtone tombstoning a removed Spotify track); no comparison is offered for how a CRDT-based app would actually handle the same de-duplication/tombstoning problem, so it remains unclear whether the advantage is inherent to event sourcing or specific to LiveStore's schema design.Podcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing — read next: A syntopical read against Kleppmann's own account of what CRDTs/Automerge can and cannot represent well (extract-kleppmann-data-agency-local-first).
- uninformedSchickling states LiveStore is 'still not fully production-ready' but never specifies which production gaps remain (performance at scale, missing tooling, security review, etc.), leaving open exactly how close it is to a safe choice for teams evaluating it today.Podcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing — read next: LiveStore's public roadmap/issue tracker for current production-readiness status.