{"slug": "atproto-s-app-platform-ends-where-private-data-begins", "title": "ATProto's App Platform Ends Where Private Data Begins", "summary": "Luke Kanies, founder of Puppet, explained on Hacker News why he cannot build a suite of review apps on AT Protocol due to its architectural limitation of public-by-default data, which cannot handle private reviews. Bluesky's protocol team merged a permissioned data proposal on July 3 to address this, but it treats private data as separate structures, forcing developers to build two apps for public and private visibility. The ATProto ecosystem has grown with apps like Tangled and Leaflet, and AtmosphereConf attendance doubled, but the protocol's core design remains a liability for applications requiring private data.", "body_md": "[AI](https://sourcefeed.dev/c/ai)Article\n\n# ATProto's App Platform Ends Where Private Data Begins\n\nPuppet's founder wants to build on Bluesky's protocol, and his stumbling blocks are everyone's.\n\n[Priya Nair](https://sourcefeed.dev/u/priya_nair)\n\nLuke Kanies, the founder of Puppet, spent last week's Hacker News front page politely explaining why he can't build his app on [AT Protocol](https://atproto.com). Not a toy, either — a suite of review apps meant to replace Yelp, Goodreads, and Letterboxd, motivated by the thousand-plus Yelp bookmarks he owns but can't export, script against, or version. His post landed at an awkward moment for the protocol, and that's exactly what makes it worth reading: ATProto has never looked more like a real application platform, and its biggest architectural bet has never looked more like a liability.\n\n## The platform part is real\n\nStart with what's working, because it's more than skeptics assume. The \"Atmosphere\" — the developer ecosystem around ATProto — has quietly rebuilt a decent chunk of Web 2.0 on shared identity and user-owned data. [Tangled](https://tangled.org) is a git collaboration platform where your repos hang off your ATProto identity. [Leaflet](https://leaflet.pub) does collaborative publishing with documents stored on your Personal Data Server. Streamplace does livestreaming; Roomy is building Discord-shaped group chat. You sign into all of them with the same handle you use on Bluesky, and your data lands in a repository you control rather than a vendor's database.\n\nThe institutional signals point the same way. AtmosphereConf in Vancouver this March drew roughly double its inaugural Seattle attendance. The IETF approved a working group for the protocol in late March 2026 — the boring, load-bearing kind of milestone that separates a protocol from a product. And Bluesky's protocol team shipped OAuth permission sets, so third-party apps can finally request scoped access to an account instead of the keys to everything.\n\nSo the pitch — one identity, one data store, many interchangeable apps — is no longer hypothetical. If an app dies, your records outlive it, and a competitor can render them tomorrow. That's a genuinely different deal than the one Yelp offers.\n\n## The load-bearing assumption\n\nHere's the catch, and it's structural. ATProto's architecture — PDS, relay, firehose, app view — is cheap and scalable precisely because every record is world-readable. Relays can aggregate the whole network and app views can index it because nobody has to check permissions on read. \"Public by default\" isn't a policy choice sitting on top of the design. It *is* the design.\n\nKanies' review app is the simplest possible counterexample. A review of a restaurant and a private note about that restaurant are the same record with different audiences. His users span the whole spectrum — people who publish everything, people who share selectively, people who'd never make a review public. One data model, one permission bit. ATProto can't express that today, and the fix in flight doesn't treat it as one data model either.\n\nThat fix is the [permissioned data proposal](https://github.com/bluesky-social/proposals/pull/94), authored by Bluesky's Daniel Holmgren and merged on July 3 after months of design diaries. It introduces a new primitive — a named container with a single ACL and defined membership, built for group contexts like a chat or a shared workspace. It's thoughtful work, and the group-context framing is probably right for messaging. But read it as an application developer and you see what Kanies saw: private data lives in different structures, with different sync mechanisms and different access paths, than public data. Want to flip a private review to public? In the current shape of things, you delete one record and create another, shedding any likes or references the original accumulated. You're not building one app with a visibility toggle; you're building two apps wearing one UI.\n\nThe churn around the proposal tells you how unsettled this is. Successive drafts have tried out \"realms,\" \"buckets,\" and \"spaces\" as the core primitive's name. Even \"permissioned data\" itself is a compromise — community members who sat through the private-data working group say it exists because a faction insisted nothing short of end-to-end encryption deserves the word \"private.\" Meanwhile at least three independent teams — Blacksky, Northsky, and Habitat — are building their own non-public-data extensions in parallel, and Bluesky's own roadmap calls permissioned data the protocol team's major focus \"through the summer.\" Translation: the design merged three weeks ago, the implementation is WIP, and the semantics could still move under you.\n\n## The local-first mismatch nobody's fixing\n\nKanies' second complaint cuts deeper because no proposal addresses it. He expected a PDS to behave like a git remote — a canonical copy you sync with, while working locally and offline. It doesn't. ATProto is server-authoritative: reads and writes are protocol operations against a live PDS. There's no offline story, no local replica with merge semantics. For a movement that showed up in force at this year's Local First conference, that's a philosophical fork in the road, not a missing feature.\n\nThe ecosystem's own workaround is instructive: Roomy uses ATProto for identity and social discovery, then does actual data sync over Automerge CRDTs. Leaflet pairs PDS storage with Replicache for client-side state. The pattern emerging in practice is ATProto as an identity and public-graph substrate — a decentralized OAuth-plus-DNS with a firehose attached — with some other machinery handling anything private, collaborative, or offline.\n\n## What I'd actually do\n\nIf your app is public-publishing shaped — reviews-as-blogging, forums, git forges, streams, anything where world-readable is a feature — build on ATProto now. The stack is straightforward: define a lexicon for your record types, write to the user's PDS, consume the firehose into your own app view, authenticate with the new OAuth scopes. You inherit identity, spam-resistant social graph, and data portability for roughly the cost of running an indexer. One hard rule: treat every record you write as permanently public. Relays and mirrors cache the firehose; deletion is a request, not a guarantee.\n\nIf your app needs mixed visibility — and Kanies is right that most interesting apps do — don't build against permissioned data yet. Wait for the primitives to survive contact with the three parallel implementations, or run the hybrid pattern and keep private state in your own store or a CRDT layer, linked to ATProto identity.\n\nThe uncomfortable truth Kanies surfaced is that \"protocols empower users\" and \"this protocol assumed everything is public\" are both true, and the second constrains the first. ATProto earned its moment as a platform. Whether it becomes a general-purpose one depends on decisions being made, in public and under pressure, right now — which is, at least, exactly where an open protocol should be making them.\n\n## Sources & further reading\n\n-\n[Building on ATProto](https://lukekanies.com/writing/building-on-atproto/)— lukekanies.com -\n[Building on ATProto - Hacker News discussion](https://news.ycombinator.com/item?id=49025984)— news.ycombinator.com -\n[Permissioned data proposal (PR #94)](https://github.com/bluesky-social/proposals/pull/94)— github.com -\n[AT Protocol Roadmap (Spring 2026)](https://atproto.com/blog/2026-spring-roadmap)— atproto.com -\n[Permissioned Data Diary 2: Buckets](https://dholms.leaflet.pub/3mfrsbcn2gk2a)— dholms.leaflet.pub -\n[Beyond Bluesky: the apps building on the AT Protocol](https://techcrunch.com/2025/06/13/beyond-bluesky-these-are-the-apps-building-social-experiences-on-the-at-protocol/)— techcrunch.com\n\n[Priya Nair](https://sourcefeed.dev/u/priya_nair)· AI & Developer Experience Writer\n\nPriya covers AI frameworks, developer productivity tooling, and the startup ecosystem across South and Southeast Asia, bringing a researcher's rigour and a practitioner's empathy to every story. She is deeply sceptical of benchmarks and asks hard questions so her readers don't have to.\n\n## Discussion 0\n\nNo comments yet\n\nBe the first to weigh in.", "url": "https://wpnews.pro/news/atproto-s-app-platform-ends-where-private-data-begins", "canonical_source": "https://sourcefeed.dev/a/atprotos-app-platform-ends-where-private-data-begins", "published_at": "2026-07-25 15:09:43+00:00", "updated_at": "2026-07-25 15:28:14.891633+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools"], "entities": ["Luke Kanies", "Puppet", "AT Protocol", "Bluesky", "Daniel Holmgren", "Tangled", "Leaflet", "AtmosphereConf"], "alternates": {"html": "https://wpnews.pro/news/atproto-s-app-platform-ends-where-private-data-begins", "markdown": "https://wpnews.pro/news/atproto-s-app-platform-ends-where-private-data-begins.md", "text": "https://wpnews.pro/news/atproto-s-app-platform-ends-where-private-data-begins.txt", "jsonld": "https://wpnews.pro/news/atproto-s-app-platform-ends-where-private-data-begins.jsonld"}}