Building on ATProto

That landed with a lot of agreement. The dominant view was that ATProto was built to solve portable public social data at internet scale, basically the Twitter problem, and it does that better than it handles private apps, local-first workflows, or small-group collaboration. Several people pointed out that this was an intentional v1 tradeoff, not an accident. A Bluesky core contributor said local-first ideas were considered but dropped because the team had to spend its complexity budget elsewhere, and suggested hybrid approaches like using Iroh for local sync and committing state back to ATProto later. On privacy, people drew a line between true private messaging and the narrower problem the protocol is now chasing: selective sharing such as clubs, events, forums, bookmarks, and follower-only spaces. That may be useful, but many readers saw it as middle-ground access control, not a clean answer to private-by-default software. The strongest thread-level conclusion was practical. ATProto looks compelling when your app benefits from public, reusable records that other apps can read without asking your startup for an API. One builder described exactly that with turn-based games, where shared replays could support analysis tools and alternate clients automatically. But once your product needs private repos, rich local-first behavior, or nuanced permissions that feel normal to end users, people stopped treating ATProto as an obvious base layer. At that point the conversation shifted from “how do we fit this in” to “maybe this is the wrong protocol for the job.”