Decentralizing the Upper Layers: What atproto Can Learn from nostr, and What It Cannot

1. Overview ATProto is routinely described as decentralized, yet its upper layers are not. The Relay and the AppView concentrate cost and, with it, control. nostr shows that a different architecture is possible: when every client pays its own aggregation cost, no layer has to carry the network. But nostr does not scale. The question is not which system is more decentralized. The question is what atproto can borrow from nostr without becoming nostr. This essay proposes that the portable element is not the architecture. It is the property that makes nostr's architecture work: data authenticity that does not depend on location.
2. Definitions Vertical decentralization: a design in which different functional layers are run by different operators, and each layer can in principle have multiple operators. atproto is vertical in this sense: PDS, Relay, AppView are distinct functions. Horizontal decentralization: a design in which nodes of the same kind run in parallel, each doing the same work. nostr relays are horizontal. Aggregation cost: the cost of producing a global consistent view from distributed events. This cost is paid somewhere. The question of decentralization reduces, in large part, to where. Partial AppView: an AppView that indexes and serves a bounded slice of the network rather than the whole. It gives up global search and gains local consistency at a fraction of the cost. Location-independent authenticity: the property, provided by per-record signatures, that a copy of public data can be verified as genuine regardless of where it was fetched from. atproto inherits this design choice from the same family of ideas that nostr relies on. Community AppView: an AppView operated by and for a specific community, with its own moderation, hosting, and sometimes its own client. Blacksky and Eurosky are the current examples.
3. Propositions P1: atproto is vertically decentralized. nostr is horizontally decentralized. These are not points on a single axis. P2: In nostr, aggregation cost is paid by the client. In atproto, aggregation cost is paid by the AppView. P3: Where aggregation cost is paid determines how decentralization can actually be realized. A layer that must aggregate globally cannot be cheaply replicated. P4: atproto's upper layers centralize because producing a global consistent view requires processing the full firehose. This is a structural requirement, not a policy choice. P5: The AppView is not one function but three: indexing, query processing, and delivery. Only indexing is strictly bound to global aggregation. P6: Partial decentralization of the upper layers is achievable through a plurality of partial AppViews. The global view is traded away. Local coherence is kept. P7: The portable lesson from nostr is not its architecture. It is its reliance on per-record signatures. Authenticity that does not depend on location is what makes mirroring meaningful. P8: Hubble replicates the data layer, not the view layer. It is the nearest atproto analog to nostr's relay redundancy, and it is not an AppView. P9: Hubble and the wider microcosm stack (Constellation, Slingshot, Hubble) lower the precondition cost for partial AppViews. They are infrastructure for the decentralization that has not yet happened. P10: The precondition layer currently runs on a single operator. The architecture is distributed. The operation is not. P11: Decentralizing AppView and Relay does not turn atproto into Mastodon. Mastodon binds identity to an instance. atproto binds identity to a DID that is independent of any service. P12: After upper-layer decentralization, atproto resembles the web browser or the RSS reader more than it resembles Mastodon. The same resource is viewed through different lenses, and the lens can be swapped at any time. P13: Social differentiation between AppViews is possible and likely. It is not equivalent to Mastodon's instance-bound communities, because exit cost stays near zero. P14: A community AppView becomes viable when three conditions converge: a concrete threat, an operating entity capable of running infrastructure, and an explicit commitment to moderation independence. P15: Blacksky emerged from a survival condition of its community. Eurosky emerged from a sovereignty narrative backed by institutional capacity. Both illustrate P14 from different directions. P16: A Japanese analog (JPSky) is technically feasible. The three conditions of P14 are not yet visibly met in the Japanese case.
4. Corollaries C1 (from P3, P4): Calling atproto "decentralized" without qualification is misleading. The data layer is meaningfully distributed. The view layer is not, and cannot easily become so. C2 (from P5, P6): Work on upper-layer decentralization should target partial AppViews first, not a redesign of the full AppView. The indexing problem is structural. The query and delivery problems are not. C3 (from P7, P8): Mirror projects like Hubble do not decentralize the AppView. They remove a failure mode at the data layer. Treating Hubble as a step toward AppView decentralization is a category error. C4 (from P9, P10): Whether atproto's upper layers can be decentralized in practice depends on whether the precondition layer can be operated by a plurality of independent actors. A single-operator precondition layer is a hidden single point of failure. C5 (from P11, P12): The correct reference architecture for a post-decentralization atproto is not the fediverse. It is the public web with multiple search engines indexing the same documents. C6 (from P14, P16): The question for a Japanese community AppView is not technical. It is whether the three conditions can be articulated and organized. Starting from the full stack is the wrong order. A labeler or a Japanese-language PDS is the viable entry point.
5. Open Questions    Q1: At what granularity does a partial AppView become useful? Per-community? Per-language? Per-topic? The answer shapes whether partial AppViews can form an ecosystem or remain isolated experiments. Q2: If global search is abandoned at the community AppView layer, what replaces it as the discovery mechanism? Federation of search across AppViews? Opt-in inclusion in a shared index? The question is unresolved. Q3: Is the precondition layer itself decentralizable, or is there an irreducible single-operator regime at some depth of the stack? If the latter, upper-layer decentralization has a ceiling that must be named. Q4: What distinguishes a community AppView from a forked client with custom moderation? The difference is a matter of which functions are actually independent. The boundary has not been drawn. Q5: For the Japanese case: what threat, if any, is currently invisible but real enough to warrant community infrastructure? The absence of visible demand is not proof of absent need. Nor is it proof of its presence.

Discarded Hypotheses

• nostr's architecture can be transplanted into atproto to decentralize the upper layers. Rejected: nostr does not solve the global consistent view problem; it dissolves it. Transplanting the architecture means giving up what atproto is for.
• Hubble decentralizes the AppView. Rejected: Hubble mirrors PDS repositories. The AppView layer is untouched.
• AppView-less clients such as RedDwarf constitute decentralization. Rejected: they route around the official AppView to another single point of failure. Substitution is not distribution.
• Decentralized AppViews would turn atproto into a Mastodon-like federation. Rejected: identity in atproto is independent of any service, which makes instance-bound community formation structurally different.