Podcast: Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement
Martin Kleppmann · podcast · 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.
practical · podcast interview (conversation) — An InfoQ podcast interview: Olimpiu Pop draws out Martin Kleppmann, whose second edition of Designing Data-Intensive Applications frames the discussion. Grounded in distributed-systems theory but oriented toward what practitioners should build and adopt (modular data stacks, open protocols, local-first apps). Claims emerge dialogically and are restated across turns; the host contributes practitioner anecdotes (InfluxDB/QuestDB stacks, IoT/CAD versioning) that Kleppmann affirms and extends.
Structure
| Part | Role |
|---|---|
| Intro and DDIA 2nd-edition framing | Context — establishes Kleppmann's authority and sets the frame: what has changed in data systems over the decade since the first edition |
| The shift to cloud-native architecture and object storage | Technical grounding — data storage decoupled from compute atop inherently replicated object stores rather than DB-managed local disks |
| Fragmenting monolithic data systems into modular building blocks | Core observation 1 — the database is unbundling into mix-and-match components, opening the field to experimentation |
| Decentralisation, sovereignty, and the AT Protocol | Core argument 1 — decentralisation buys autonomy and anti-lock-in, but AT Protocol deliberately trades some federation for a global index, guaranteeing provider portability instead |
| The local-first movement: definition and motivation | Core argument 2 — the primary copy of data on the user's device delivers offline use, speed, resilience, and ownership |
| Git as proof and the open sync protocol | Synthesis — Git shows local-first + an open standard sync protocol dissolves lock-in while keeping cloud convenience; this unifies AT Protocol and local-first |
| Bringing Git-like version control to non-text data | Extension — capturing edits for sync yields version control for spreadsheets, graphics, CAD as a near-free byproduct |
| Automerge, the implementation | Practical realization — a Rust/Wasm CRDT library that materializes the local-first principles |
| Limits, boundary conditions, and retrofit | Qualification — where local-first does not apply (authoritative-server data) and when it can be retrofitted |
| Community and convergence (conference, AT Protocol + local-first uniting) | Restatement of unity — both movements converge on user agency and empowerment |
Key terms
- local-first software 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. - data agency / user agency
Users' substantive control over and ownership of their own data: the ability to keep it, port it between providers, and not be locked out of it — the whole reason for pursuing local-first and AT Protocol. - AT Protocol (atproto) Local-First Software
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. - Personal Data Server (PDS) Local-First Software
A per-user data store holding a user's posts, replies, and social graph, portable between providers so switching loses nothing. - Relay / firehose
The AT Protocol service that combines activity from all PDSs into a single public stream, which any organisation can index to compute globally consistent views (unified reply threads, aggregated like counts). - modular building blocks (vs. monolithic database)
Composing a data system from interchangeable components — object store, columnar file format, table format, choice of query engine — instead of one monolithic system, which increases flexibility and lets people build or swap a single component rather than a whole system. - cloud-native
Systems designed from the ground up on cloud-service abstractions — inherently replicated object stores — rather than on local-disk/OS services, which decouples storage from compute and changes how you build everything above it. - Automerge Local-First Software
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. - open (standard) sync protocol Local-First Software
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. - federation (vs. global index)
The pure-federation model (ActivityPub/Mastodon) where each server knows only its local view, so reply threads and like counts differ per server — which Kleppmann contrasts with AT Protocol's deliberate global aggregation for consistency.
Propositions
- explicitdevelopedThe biggest architectural shift of the past decade is the rise of cloud-native systems, in which data storage is decoupled from compute and built on inherently replicated object stores (e.g. S3) rather than on database-managed local-disk replication.conf: highsupportsDesigning Data-Intensive Applications: The Cloud & Doing the Right Thing · p3 — Kleppmann here restates, conversationally, the cloud-native shift that DDIA credits with better performance and failure recovery: storage decoupled from compute atop inherently replicated object stores rather than database-managed local-disk replication.extends ←Presentation: Parting the Clouds: The Rise of Disaggregated Systems · p1 — Kleppmann states as a passing premise that cloud-native systems decouple storage from compute; Demirbas supplies the underlying economic mechanism (cost/scaling/statefulness mismatch) and concrete production examples (Aurora, PolarDB, TaurusDB) behind that observation.
- explicitMonolithic data systems are fragmenting into modular, mix-and-match building blocks (object store + columnar file format + table format + choice of query engine), which increases flexibility and lets people experiment by building or swapping a single component instead of a whole system.conf: high
- explicitMore distributed and decentralised systems make organisations and nations more autonomous and sovereign and less locked in by vendors, independent of the vendor's nationality or home country.conf: medium
- explicitSocial media is too important to be left in the hands of a single company — the founding value behind the AT Protocol.conf: high
- 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.conf: high
- 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.conf: high
- implicitA system can be centralised in practice — most BlueSky users use BlueSky's own services — yet still preserve user agency, as long as a real option to switch to a different provider exists.conf: high
- explicitWhether a system is actually decentralised depends not on the protocol but on whether funded alternative providers actually run competing services — something the incumbent cannot create by itself and which requires community effort and money.conf: high
- 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.conf: highextendsDesigning Data-Intensive Applications: The Cloud & Doing the Right Thing · p2 — Local-first — the primary copy of data on the user's own device — is Kleppmann's architectural remedy to the 'loss of control' that DDIA names as the biggest downside of cloud services: provider shutdown or account lockout can no longer take your data away.
- 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.conf: high
- 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.conf: high
- 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.conf: high
- 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.conf: high
- 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.conf: highextends ←Podcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing · p5 — Extends Kleppmann's CRDT/Automerge-centric account of how local-first is realized by presenting client-side event sourcing as a structurally different, equally valid mechanism for the same goals.
- 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.conf: highsupports ←Podcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing · p9 — Reinforces Kleppmann's claim that local-first fits user-authored data but not data with an authoritative external source, adding a concrete local-vs-global heuristic (personal notes vs. a global financial system) for applying it.
- 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.conf: highsupports ←Podcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing · p10 — Schickling's own account of leaving Prisma's server-centric architecture behind and rebuilding from scratch (rather than retrofitting) is a first-person confirmation of Kleppmann's claim that retrofitting to local-first is hard when logic already lives server-side.
- 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.conf: high
Arguments
A partly centralised system (like BlueSky) can still deliver genuine data agency, so the meaningful measure of decentralisation is the cost of exit, not the network topology. strength: high
Explicit premises:
- Pure federation (Mastodon) produces inconsistent views and a worse user experience
- Global consistency (unified reply threads, aggregated like counts) requires something that indexes the whole network — a Relay/firehose that aggregates all PDSs
- In practice most BlueSky users use BlueSky's own services, making it more centralised than Mastodon
- AT Protocol guarantees users can switch providers without losing username, posts, replies, or social graph
Implicit premises:
- The mere technical and legal option to switch providers disciplines the incumbent even if almost nobody actually switches
- Guaranteed portability of data is sufficient to preserve user agency — controlling the exit is equivalent to controlling the data
- Credible, funded alternative providers will in fact emerge (an assumption Kleppmann elsewhere admits the incumbent cannot guarantee)
- The incumbent benefits from 'good-enough' centralisation while retaining decentralisation credibility
Inferences:
- Decentralisation is a spectrum, and a pragmatically centralised design with guaranteed exit can beat a purist federated one on user experience without sacrificing agency
Holding the primary copy of data locally empowers users and de-risks provider failure, so collaboration software should be local-first. strength: high
Explicit premises:
- A local primary copy enables offline access and faster interaction
- SaaS/web software can be shut down or lock you out, and then your data is gone (e.g. Google Reader)
- Git demonstrates that local data plus an open sync protocol works at scale
- Capturing edits for sync yields version control for domains that lack it
Implicit premises:
- Sync conflicts between devices are reliably resolvable (CRDTs make merge automatic and acceptable)
- The most valuable collaboration apps are 'creation' apps where the user is the authoritative editor, not systems needing a server-side source of truth
- The costs local-first pushes onto clients and developers — end-to-end encryption and decentralised access control, which Kleppmann says are still in progress — are manageable
- Users (including non-technical ones) can and will actually steward and port their own data
Inferences:
- Local-first is both an ethical improvement (user ownership) and a practical one (offline, speed, version control), so it should become a default attribute of collaboration software
The way to keep cloud convenience without lock-in is an open, standard sync protocol that makes providers interchangeable — as Git already is.
Explicit premises:
- Peer-to-peer is genuinely hard to make reliable, so servers/cloud sync remain useful
- The actual lock-in is a single proprietary sync service (Google Docs), not cloud services as such
- Git's open push/pull protocol lets the same repository use GitHub, GitLab, or self-hosting interchangeably
- This is the same substitutable-provider principle AT Protocol uses
Implicit premises:
- Vendors will voluntarily adopt or standardise an open sync protocol even though proprietary lock-in is precisely what makes their SaaS commercially valuable (an incentive that runs against them)
- Even Git only partly escapes lock-in — GitHub issues and wikis are not in the repository and remain non-portable — so open protocols cover the core data but not necessarily the surrounding features
Inferences:
- Open standard sync protocols, not full decentralisation or peer-to-peer, are the practical mechanism that delivers data agency across both social media and collaboration software
Narratives
- The origin of the AT Protocol: Jay Graber recruited Kleppmann early to build decentralised infrastructure for what was then Twitter; after Elon Musk's acquisition and the rename to X, BlueSky pivoted to being its own social network but preserved the founding ethos that 'social media is too important to leave in the hands of a single company.'
→ Shows how a set of design values survived a major strategic pivot, and grounds the abstract 'guaranteed exit / portability' principle in a real, shipped system with real PDSs, a Relay firehose, and emerging alternative providers (BlackSky). - Google Reader, shut down by Google, is still mourned a decade later as the emblem of the risk of web/SaaS software: the provider takes it away and there is no way to keep running a local copy.
→ Supplies the emotional and practical motivation for local-first — provider shutdown and account lockout are real, recurring harms that holding a local primary copy of data would prevent. - Git as a lived example: engineers already take for granted local history, offline inspection of past versions, multiple remotes across GitHub/GitLab/self-hosted, and pull-request review — but Git has a brutal learning curve and treats a spreadsheet as an opaque binary blob.
→ Serves as both proof-of-concept (local-first plus open sync works) and as the gap local-first aims to close: bringing Git's powers to non-technical users and to non-text data like spreadsheets and CAD. - The host's IoT/CAD versioning saga: hardware and circuit-diagram designs cannot be versioned or diffed the way code can, so only the person who built a design knows what changed — a pain Kleppmann affirms extends to CAD and electronic-engineering tools generally.
→ Concretises the untapped surface for local-first version control beyond software, reinforcing the proposition that capturing edits for sync unlocks version control for domains that lack it. - Automerge and the local-first movement coalescing: a Rust/Wasm CRDT library (to-do-list Hello World, localfirst.fm comparison table, Discord community), a Berlin conference in its third year selling out at ~350 people, and the AT Protocol and local-first communities converging — with BlueSky CTO Paul Frazee speaking at the local-first conference.
→ Demonstrates that local-first is not a lone research idea but a growing ecosystem with competing implementations and shared values, and visibly unites the two threads of the conversation (AT Protocol and local-first) around user agency.
Questions addressed
- ✅ What has changed in data systems in the decade between the two editions of Designing Data-Intensive Applications?
The rise of cloud-native architecture — storage decoupled from compute atop inherently replicated object stores rather than DB-managed local disks — and the fragmentation of monolithic data systems into modular, mix-and-match building blocks. - ✅ Why pursue decentralisation, and how does the AT Protocol reconcile it with a good user experience?
Decentralisation buys autonomy and reduces vendor lock-in. AT Protocol keeps user data in Personal Data Servers but aggregates activity through a Relay/firehose that anyone can index, deliberately trading some federation for global consistency, and guarantees users can switch providers without losing anything. - ✅ What is the local-first movement and what is its mission?
A set of principles for collaboration software where the primary copy of data lives on the user's device — for offline use, speed, resilience against provider shutdown, and user ownership — motivated by user agency and empowerment. - ✅ Technically, what is local-first — a protocol, or something else — and how is it built?
It is a set of principles and values, not a protocol; it is realized by libraries such as Automerge (a Rust/Wasm CRDT data model with bindings for major languages) that different implementations interpret in their own ways. - ✅ When does local-first not apply?
For data with an inherently authoritative server copy — bank balances, warehouse stock, large product catalogues — where local edits are meaningless or downloading everything is impractical; local-first fits 'creation' apps where the user authors their own data. - ✅ Can local-first be retrofitted onto an existing centralised application?
It depends: straightforward if business logic and state already live client-side (swap the internal data model for Automerge), hard if logic lives server-side, where a rewrite is often easier. - ⭕ What business model funds the alternative providers that make decentralisation real, given that portability makes providers substitutable and erodes their pricing power?
- ⭕ Why would proprietary incumbents (e.g. Google Docs) ever adopt an open sync protocol that removes their own lock-in?
Gaps
- 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.
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.
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.
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. - incompleteThe hard tradeoffs of CRDTs and local-first are presented as a near-free win. Automerge's costs — metadata/storage overhead, merge semantics that need not match user intent, the loss of a server as an authoritative point for validation and permissions — and Kleppmann's own admissions that peer-to-peer is 'really hard' and that encryption/access control are unfinished, are not balanced against the offline/speed/version-control benefits.
Read next: Ink & Switch's original local-first essay on the 'seven ideals' and their unmet challenges; CRDT literature on garbage collection, storage overhead, and interleaving anomalies.closed byPodcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing — Partially answers the gap's 'merge semantics that need not match user intent' concern about CRDTs: Schickling explains his reason for moving away from CRDT-style mutable objects toward event sourcing is precisely that mutable data makes it hard to trace where a change came from and to reason about what should semantically happen — engaging directly with that specific cost, though not with the gap's other sub-points (storage overhead, loss of server-side authoritative validation). - 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.
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.
Closes gaps elsewhere
- Designing Data-Intensive Applications: The Cloud & Doing the Right Thing · g2 — DDIA-cloud examines cloud concentration only from the customer's cost side and names no remedy for the resulting control/lock-in problem. This conversation supplies the structural response: open standard protocols (AT Protocol's guaranteed provider-switching; local-first's device-held primary copy synced over an open protocol) that make providers substitutable and reduce dependence on any single controller of critical infrastructure — the missing 'what to do about it' next to DDIA's diagnosis.