AppView-less Does Not Mean Decentralized: What the April 16, 2026 Bluesky Outage Revealed

[JP Ver is here] 0. Overview On April 16, 2026, Bluesky went down for over 13 hours due to a DoS attack. The official web, app, and feeds became unreachable, while Leaflet continued to operate. The standard account—"the PDS layer secures data sovereignty in ATProto"—holds this far. But RedDwarf, which advertises itself as AppView-less, also failed. The PDS layer's distribution alone cannot explain this. This essay argues that the ATProto stack contains two independent sovereignty dimensions, the data layer and the viewpoint layer, and that the viewpoint layer remains centralized at a single point. AppView-less is an alternative route, not a distributed route.

1. Definitions Leaflet: a blog and long-form publishing platform running on ATProto, developed by Hyperlink Academy. Users log in with their Bluesky account, and article data is stored directly on each user's PDS. Because it can distribute content without going through the official AppView (api.bsky.app), it is less affected by Bluesky outages. RedDwarf: a Bluesky-compatible client advertised as AppView-less. Without using the official AppView (api.bsky.app), it retrieves posts, replies, likes, and so on through direct queries to users' PDSes and reverse lookup indexes provided by Microcosm, specifically Constellation and Slingshot. Microcosm: a suite of ATProto infrastructure developed and operated by bad-example.com. Consists of Constellation (a reverse lookup index), Slingshot (an edge cache for records), Spacedust (a link firehose), and others. It operates by consuming the firehose from the official Relay (bsky.network). Data sovereignty: the state in which users retain their own records (repositories) and can choose distribution paths. Realized at the PDS layer. This is the sovereignty concept that existing ATProto discourse has primarily addressed. Viewpoint sovereignty: the state in which users have choices over how their records are viewed. Concerns the choice of who aggregates reverse lookups such as reply lists, follower lists, and mention lists. Determined at the AppView and indexer layers. Single-point concentration: the state in which a specific function depends on a single or small number of operators. From the perspective of the distributed infrastructure as a whole, it refers to a structure in which the failure of that point halts the function in question. This essay treats the term as synonymous with "single point of failure (SPOF)," often invoked in ATProto design discussions. Alternative route: a path that bypasses existing points of concentration. But when it depends on another point of concentration, it is equivalent to the existing route in terms of fault tolerance. Distributed route: a path in which the function is redundantly distributed across multiple independent operators, such that the function is maintained even if any single point fails.
2. Propositions P1: Sovereignty in the ATProto stack must be evaluated along two dimensions: the data layer and the viewpoint layer. The two can concentrate or distribute independently. P2: The PDS layer is effectively distributed in ATProto. Leaflet maintained operation during the outage through its own PDS-based distribution. P3: The viewpoint layer currently depends on a small number of concentration points. Both the official AppView (api.bsky.app) and the reverse lookup indexers that AppView-less clients depend on, namely Constellation and Slingshot operated by Microcosm, are single points. The latter is an alternative path that bypasses the former, but it itself depends on a single operator. P4: Reverse lookup operations such as reply lists, follower lists, and mention lists cannot in principle be performed by PDSes alone. Someone must aggregate. This aggregation function is the critical point of the viewpoint layer. P5: AppView-less architectures provide an alternative route that avoids dependence on the official AppView, but they do not provide a distributed route. They merely shift the dependence to another single point of concentration.
3. Corollaries C1 (from P1, P2): Data sovereignty does not entail viewpoint sovereignty. The two are goals to be achieved separately. Discourses that evaluate ATProto's decentralization along a single dimension need to be re-evaluated as at least two dimensions. C2 (from P3, P5): AppView-less clients and official clients are structurally equivalent from the perspective of fault tolerance. Their dependencies differ, but the form of dependence, reliance on a single point of concentration, is identical. C3 (from P4): Distributing the viewpoint layer requires redundancy of the reverse lookup aggregation function. Increasing the number of PDSes alone cannot achieve this. The requirement is a configuration in which multiple independent indexers aggregate the same network in parallel, and clients can switch between them at will. C4 (from P3): Failures at the Relay layer propagate across the entire viewpoint layer. Even if PDSes are operational, when the firehose stalls, all downstream indexers, official and unofficial alike, stop ingesting new data. The Relay layer is also a critical point for viewpoint sovereignty. C5 (from C2, C3): Using AppView-less as an indicator of decentralization is misleading. The true indicator is whether there are multiple dependent indexers and switching is possible. No ATProto client satisfying this condition exists as of April 2026.
4. Open Questions Q1: Can the infrastructure configuration that realizes viewpoint sovereignty be designed in an economically sustainable way? Maintaining multiple independent indexers requires several times the resources compared to centralization on the official AppView. Who bears that cost? Q2: Can viewpoint layer redundancy be achieved with the same design philosophy as PDS layer distribution? PDSes achieved distribution by having individuals host only their own data. But reverse lookup aggregation inherently requires seeing the whole. Does the distribution of functions that cannot be borne at the individual scale require a different design from the PDS model? Q3: To what extent can the weir model and crystal radio model be concretized as design principles for the viewpoint layer? These currently remain as metaphorical proposals. When they are brought down to implementable specifications, where and in what form do they insert themselves into the existing PDS-Relay-AppView stack?

Discarded Hypotheses

• RedDwarf failed due to an implementation issue on RedDwarf's side. The simplest explanation for the observed facts (Leaflet operational, official AppView down, RedDwarf down) is a failure in the shared infrastructure, Microcosm or Relay, that RedDwarf depends on. There is no need to invoke individual implementation failures.
• The PDS layer is also centralized. The fact that Leaflet continued to operate rejects this hypothesis. At least the PDS path on which Leaflet depends functioned independently of the official infrastructure failure. The effective distribution of the PDS layer holds as an observed fact.