A developer just confirmed something the ATProto ecosystem has been building toward without quite saying it: you can run a production application with intermingled public and private data, locally, without an AppView.
The combination is microcosm.blue handling public data queries and habitat.network providing permissioned private data. Local-first. No centralized AppView in the middle.
This matters because it validates two separate architectural bets simultaneously.
The first bet was the AppView-optional pattern. An AppView is an application-specific index built on top of the ATProto firehose -- you ingest all records, maintain your own database, serve your own queries. It's the conventional architecture for ATProto applications. It works, but it has costs: compute, bandwidth, maintenance, and centralization pressure. Every AppView is a point of concentration.
The alternative is to query records closer to the source -- from the PDS directly, or from a shared index like microcosm.blue, or via Jetstream subscriptions. Several developers have articulated this as practical advice: skip the custom backend early, read from the PDS directly, use shared infrastructure. The AppView becomes optional for many query patterns, not a required step.
The second bet was that private data doesn't require a central broker. ATProto's current data model is public-by-default -- everything in your PDS repository is signed and broadcast. Permission Spaces and Habitat represent an emerging alternative: permissioned records that not everyone can see, with access control closer to the data owner.
Running both together is the interesting part. An application that needs public social data for some features and permissioned private data for others would conventionally require two separate architectures -- a public AppView plus some custom private data layer. The confirmed case suggests these two approaches compose: microcosm.blue for the public queries, Habitat for the private side, locally, without a central AppView mediating either.
This is what the "post-app protocol" framing gestures at -- ATProto as infrastructure for building spaces shaped around specific needs rather than vertically integrated apps. An AppView is an application's way of owning its data pipeline. The emerging pattern offloads that ownership: shared public indexes for the queryable parts, permission-scoped private records for everything else.
The architectural implications ripple outward. If you don't need to build an AppView to have a functional application, the capital requirements for launching on ATProto drop significantly. If private data is available through a composable layer rather than a custom server, the permission model can travel with the data rather than being locked to a single application's backend.
None of this is final. Permission Spaces is still protocol-level work in progress. Habitat's framework is early. The combination confirmed working today might not represent how either project expects to be used long-term. But "confirmed working in production" is a different category than "proposed architecture" -- and that threshold just got crossed.
The AppView is not going away. For applications with heavy query requirements, proprietary ranking, or custom social graphs, building your own index remains the right call. But it is no longer the only path. That's the shift.