Building on ATProto

Luke Kanies, who founded Puppet, spent part of July 2026 at the Local First Conference in Berlin asking ATProto's builders and users whether he should build on it. His answer is a qualified no, and the post is structured as feedback to the protocol designers rather than a verdict: here is what I want to build, here is where your current and proposed designs work against it.

The application

The thing he wants is a suite of review apps — enough to displace Yelp, GoodReads and Letterboxd — and the reason is the business model, not the features. He and his wife have over a thousand bookmarks locked inside Yelp: unpublishable, unshareable, unscriptable, unversionable. A shared public data model would let one tool be good at writing reviews, another at publishing best-of lists, and a third at embedding them on a personal site, without any of them owning the data.

The sharper observation is about who these apps are actually built for. Kanies splits users into three groups: people who would only write a review if others will read it, people like him who want a mix depending on the subject, and people like his wife who will never publish anything online and would only record reviews visible to family. Every existing product serves the first group, because the first group are influencers and influencers are the growth engine. He guesses the other two are much larger. What he wants from a protocol is the ability to let a user pick — fully public, fully private, or shared piecemeal with a named group — without the app treating those as different features.

He also notes that public and private reviews of the same restaurant would say different things. He is vegetarian and autistic; a place that works for him is not necessarily a recommendation, and most apps offer no way to record the first without asserting the second.

What ATProto gets right

Identity, and Kanies is unstinting about it. He calls it the first protocol designed to solve identity at scale — an app can adopt ATProto identities for authentication, followers and following, and friend discovery instead of building a social graph from nothing. His only complaint is that the identifiers aren't human-readable enough. The evidence he offers is that nearly every speaker at Local First mentioned it, which was the thing that surprised him about the conference.

Where it breaks

ATProto today is public-only, and that assumption is baked into the storage systems and the publishing services, not layered on top. The community's answer is a design in progress called "permissioned data" — a name Kanies objects to twice over, because "private" is an actual word and because it names an implementation detail instead of the user behaviour.

His substantive disagreement is with the premise, quoted from the design post: "the through-line on all of this is that public broadcast data is substantially different from permissioned data." He thinks the opposite. A restaurant review is the same object whether one person reads it or a million do. Public data is a special case where the permission is world-read, and fully private data is the special case with no reader but the author. The design treats a difference in access control as a difference in kind.

The consequence for a developer is concrete. Permissioned data reuses ATProto's identity and its lexicons for type definitions, but adds new data structures and new methods for managing and validating them. So you write two applications — one for public data, one for private — and then hide the seam, because users will not accept "these are restaurant reviews, why are they in two places." Publishing a private review becomes a delete and a re-create in a different subsystem, and whether it keeps its likes, reposts and inbound links is, in Kanies's words, unknown but probably not. And because the Personal Data Server exposes your data to any application that wants it, every one of those applications has to implement both systems and hide the same seam.

The PDS is not a git repo

The section he flags as his own correction is worth the most. He assumed "you own your data" meant what it means in git — you hold a copy, you change your copy, you push it for distribution. It doesn't. The PDS is a server you speak a protocol to. You own your data in the sense that the storage and the access protocols are public and you can move where it lives. Cryptographic integrity guarantees exist, which is part of why the git analogy suggested itself, but they are applied on the server rather than in the protocols you use to write.

Measured against the Ink & Switch local-first principles, ATProto hits about half. It misses on data being at your fingertips and on the network being optional, along with everything those imply. Recording a review offline means building your own local store and your own sync layer to drain it — and if permissioned data ships as designed, that sync layer needs two protocols, and the online read/write path needs two more that are probably different again.

Where it lands

He is still excited, and careful to say the design is early enough to change and that he is not the only one pushing back. Even under the current proposal he could build on the identity and lexicon systems alone. But the closing worry is not technical: if he believes public and private data are the same thing with different access rights and the community believes they are and should be different, then he is fighting the protocol, the storage system, and the people maintaining both. He has done that before and says it sucks.

The frame underneath is generational. Kanies came up in the 90s, when the internet ran on community-maintained standards built to empower users rather than to defend a moat, and he wants that back. ATProto is the first candidate in decades.

tangled is the vault's other atproto entry and cuts the opposite way — a git collaboration platform where the whole point is that repositories and CI are public artifacts, so the public-only assumption costs it nothing. That is a fair test of Kanies's argument: the protocol suits applications whose data was always going to be published, and the friction shows up exactly where an application has users who don't want to publish.

Block's Buzz answers an adjacent question on a different protocol, using signed Nostr events to give humans and agents one identity across chat, code and approvals — same instinct that identity is the piece worth standardizing, different bet on where it comes from. And build-a-new-internet arrives at a similar diagnosis from the other end: the open commons was easy to pollute, and the response there is to retreat to small high-friction spaces rather than to build a better protocol. Kanies is making the case that the protocol is still worth attempting, which is the more optimistic reading of the same platform decay.