--- title: Building on ATProto | daily.dev description: A developer evaluates ATProto (Bluesky's Atmosphere Protocol) as a foundation for building local-first review applications. The author praises ATProto's... canonical: https://daily.dev/posts/building-on-atproto-yvlamkbx0 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Building on ATProto | daily.dev og:description: A developer evaluates ATProto (Bluesky's Atmosphere Protocol) as a foundation for building local-first review applications. The author praises ATProto's... og:url: https://daily.dev/posts/building-on-atproto-yvlamkbx0 og:image: https://api.daily.dev/og/posts/YvlamkBX0.png og:image:alt: Building on ATProto og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Building on ATProto **[Hacker News](https://daily.dev/sources/hn)** · 12 min read · 0 upvotes · 0 comments ## Summary A developer evaluates ATProto (Bluesky's Atmosphere Protocol) as a foundation for building local-first review applications. The author praises ATProto's identity system but criticizes its public-only architecture and the proposed 'permissioned data' design for private data. The core argument is that public and private data are fundamentally the same — just with different access rights — and treating them as entirely separate systems forces developers to build two parallel applications while hiding the complexity from users. The author also notes ATProto falls short of true local-first principles since the PDS is a remote server, not a local data store, making offline support require custom sync solutions. Despite these concerns, the author remains hopeful the design can improve before it's finalized. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 1 discussion and 122 comments across hackernews (as of 2026-07-24). **TL;DR:** The community is broadly engaged and curious about ATProto's direction, with lively debate around its public-data-only design, the permissioned/private data proposal, and whether Bluesky's centralized control undermines the protocol's decentralization claims. Many builders are excited about what they're creating on ATProto, while skeptics question governance, privacy limitations, and long-term sustainability. **Sentiment:** 35% positive · 40% mixed · 25% skeptical **The case for** - ATProto's public-data model enables data portability and continuity even when startups die, benefiting users who try new services. - The ATProto developer community and Bluesky leadership are unusually engaged and transparent compared to other decentralized protocol efforts. - Builders are already shipping interesting real-world projects (board game communities, git forges, forums, web-of-trust platforms) on ATProto. - The permissioned data proposal is actively being developed and iterated on with community feedback. - ATProto's identity and data portability (moving between PDSes with backlinks intact) is seen as superior to ActivityPub's current model. **The pushback** - ATProto's all-public-data design is a poor fit for the majority of social use cases where users want privacy or audience-limited posting. - Bluesky still controls the PLC directory and the vast majority of the network, undermining decentralization claims. - The permissioned data proposal's design (locational permissions tied to URI) is seen as jarring and hard to build on. - The protocol lacks local-first support, which limits certain application architectures. - Concerns that ATProto will never truly separate from Bluesky as a for-profit entity, similar to how other 'open' protocols remained controlled by their originators. **By community** - hackernews (mixed): Commenters are split between genuine excitement from builders shipping on ATProto and pointed skepticism about centralization, privacy limitations, and Bluesky's governance, with notable direct engagement from Bluesky's CTO adding both color and controversy. **Hottest debate:** Whether ATProto is genuinely decentralized given Bluesky's control of the PLC directory and dominance of the network infrastructure. **Open questions** - Will the permissioned data proposal actually ship in a form that's easy for third-party developers to build on? - Can ATProto ever truly separate from Bluesky as a for-profit entity, and what would that governance look like? - Is there a viable economic incentive model for running ATProto infrastructure nodes outside of Bluesky? - Should ATProto focus solely on public data and leave private/encrypted communication to other protocols like Matrix? **Highlights** > Luke's feedback on the permissioned data proposal is pretty interesting. The current proposal has a kind of locational element to permissions, where a record's URI reflects the access control, and I can understand why that would be jarring. I'm talking with the team about whether we think that's something that could change, and what a change like that would cost. We're still in the collecting feedback phase so it's good to hear how it hits people. Regarding his other concern, I would've loved to make atproto a localfirst protocol -- that's the field the atproto team came from -- but we had to pick & choose where to spend our complexity budget. I wouldn't say it's a nonstarter for the ecosystem; you can use something like iroh in conjuction with atproto to share identities -- dial people at their dids or domain names -- and then commit state to the atproto repo once it's ready to leave your local sync mesh. Maybe that sort of thing makes its way into future versions of the protocol. But, engineering often involves trades, and for the v1 that was one of the trades we had to make. > — [pfraze on hackernews · 1 comments](https://news.ycombinator.com/item?id=49027449) > a meta-note that i think deserves attention: we never ever seen such a level of engagement around a social media protocol as this. count the number of mastodon protocol discussions that have happened, or dispora, or activitypub. they exist as background. matrix maybe comes close if you look at raw count anywhere, but i'd say has no-where near the visibility, doesn't surface/emerge into the public. atproto is succeeding at being a discussed protocol. at being a socialized social media protocol. and that's just amount of discussion. but what about engagement by the people working on it? nothing like this, not by high level people, discussing in open, talking about protocols. you don't see permissioned data blog serieses coming out about the direction. you don't see the same blogsphere posts. you don't see the CTO coming to chat about it. a huge amount of this is just that Bluesky people really work hard to do the right thing, are humble and trying hard to build good protocols, good network design, trying to build the most distributable most easy to get the content network out there that works the best. i think also though, the ability of the systems / protocols here to be expressed lends itself to being discussable, has good primitives, that make it fruitful and interesting for things like Permissioned Data, or things like the sync 1.1 protocol, to be generally understandable, good primitives, that are discussable. luke's points about local first are really good. this is hard challenge for "Authenticated Transfer Protocol", at protocol, which prioritized a sense of identity and data coupling, that is harder to do in local context, that is harder to distribute without the online verification. great concern, great area to focus on. i look forward to more people experimenting with interesting PDS architectures & seeing what if anything might possibly relax to accommodate. > — [jauntywundrkind on hackernews · 3 comments](https://news.ycombinator.com/item?id=49028817) > This author speaks to me! > it should just be called “private data” > the resulting design looks very hard to build on > Private and public data are basically identical. ... The permission is world-read Way back before Bluesky decided on their own what permissioned data would look like, when the Atmosphere Private Data WG still thought they had a say in the design, I gave a talk on a ReBAC/Zanzibar style system that aligns with what I think the author is looking for. https://www.youtube.com/watch?v=oYKA85oZc8U&t=3730s I suppose we could still build on and run a fork like mine if enough people wanted a more robust IAM system. There are some fundamental issues that I am not sure are resolvable without building them into the protocol core from the start. I have personally given up because of the leadership and am waiting/pondering the next protocol. Another design constraint I'd like to see is incentivizing apps to be federated and installable at the PDS as well as incentivizing small social over public square modalities. https://github.com/verdverm/atproto > — [verdverm on hackernews · 3 comments](https://news.ycombinator.com/item?id=49026441) > Seriously, the entire separation of Bluesky from ATProto not happening is my main reason for not trusting it at all. You can't have a protocol owned by a for-profit entity and seriously call it "open" > — [polymer8563 on hackernews · 2 comments](https://news.ycombinator.com/item?id=49029304) > Reading articles like this one, I do think people are trying to put a square peg (their applications) through a round hole (ATProto). The ATProto was designed around all data being public. You write public data to a user's PDS and then any application can read that public data and do something with it. If all data was private (encrypted?) by default then that would defeat half of all of ATProto's goals. Imagine someone starts startup A on-top of the ATProto. They raise some money, get some users, some people love it, but ultimately they die. If the data was private to that service, that data dies with the startup. But if the data is all public future startup B can read that old data and do something with it. As a user that's brings me a ton of utility and comfort trying out new services. If you're trying to built a local-first, mostly private service I just don't think the ATProto is the right tool for the job. > — [ekosz on hackernews · 5 comments](https://news.ycombinator.com/item?id=49026468) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49025984) · 94 points · 122 comments ## Similar posts on daily.dev - [Why I'm betting on ATProto \(and why you should, too\)](https://daily.dev/posts/why-i-m-betting-on-atproto-and-why-you-should-too--lm4awkw56) · Hacker News · 0 upvotes · 0 comments - [How to Build More Resilient Local-First Applications With AT Protocol Infrastructure](https://daily.dev/posts/how-to-build-more-resilient-local-first-applications-with-at-protocol-infrastructure-cx1gb6ee8) · InfoQ · 0 upvotes · 0 comments - [I Was Right About ATProto Key Management](https://daily.dev/posts/i-was-right-about-atproto-key-management-nvtrycg8z) · Lobsters · 2 upvotes · 0 comments - [Be Wary of Bluesky](https://daily.dev/posts/be-wary-of-bluesky-k0inni2r9) · Hacker News · 0 upvotes · 0 comments - [Increasing Users' Data Agency: From BlueSky's AT Protocol to the Local-First Software Movement](https://daily.dev/posts/increasing-users-data-agency-from-bluesky-s-at-protocol-to-the-local-first-software-movement-gdelmv11w) · InfoQ · 0 upvotes · 0 comments --- Tags: [#data-privacy](https://daily.dev/tags/data-privacy), [#local-first](https://daily.dev/tags/local-first) [View this post on daily.dev](https://daily.dev/posts/building-on-atproto-yvlamkbx0) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Building on ATProto","url":"https://daily.dev/posts/building-on-atproto-yvlamkbx0","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/building-on-atproto-yvlamkbx0"},"datePublished":"2026-07-23T19:28:13.097Z","dateModified":"2026-07-24T09:31:32.278Z","description":"A developer evaluates ATProto (Bluesky's Atmosphere Protocol) as a foundation for building local-first review applications. The author praises ATProto's...","image":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","thumbnailUrl":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/building-on-atproto-yvlamkbx0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"data-privacy,local-first","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Building on ATProto"}]} ```