0. Overview

2026年4月16日、BlueskyはDoS攻撃により13時間以上ダウンした。公式Web・アプリ・公式フィードが不通になる一方、Leafletは稼働を続けた。ATProtoの「PDS層がデータ主権を担保する」という説明はここまでは妥当である。だが、AppView-lessを標榜するRedDwarfが動かなかった事実がある。PDS層の分散性だけでは説明できない。本稿は、ATProtoスタックには「データ層」と「視点層」という二つの独立した主権次元が存在し、視点層は依然として単点集中していると主張する。AppView-lessは代替ルートであって分散ルートではない。

1. Definitions

Leaflet：ATProto上で動作するブログ・長文出版プラットフォーム。Hyperlink Academyが開発。ユーザーはBlueskyアカウントでログインし、記事データは各ユーザーのPDSに直接保存される。公式AppView（api.bsky.app）を経由せずに配信できるため、Bluesky障害時にも影響を受けにくい。

RedDwarf：AppView-lessを標榜するBluesky互換クライアント。公式AppView（api.bsky.app）を使わず、ユーザーのPDSへの直接問い合わせと、Microcosm（Constellation・Slingshot）が提供する逆引きインデックスから投稿・返信・いいね等を取得する。

Microcosm：bad-example.comが開発・運用するATProto向けインフラ群。Constellation（逆引きインデックス）、Slingshot（レコードのエッジキャッシュ）、Spacedust（リンクfirehose）等から構成される。公式Relay（bsky.network）のfirehoseを消費して稼働する。

データ主権（data sovereignty）：ユーザーが自らの記録（リポジトリ）を保持し、配信経路を選択できる状態。PDS層で実現される。ATProtoの既存言説が中心的に扱ってきた主権概念である。

視点主権（viewpoint sovereignty）：ユーザーが自らの記録を「どう見るか」の選択肢を持つ状態。逆引き（リプライ一覧、フォロワー一覧、言及一覧）を誰が集約するかの選択に関わる。AppViewおよびインデックサ層で決まる。

単点集中（single-point concentration）：特定の機能が単一または少数の運用主体に依存している状態。分散インフラ全体から見れば、その点が落ちれば当該機能が停止する構造を指す。ATProto設計議論でしばしば言及される「単一障害点（single point of failure, SPOF）」と本稿では同義に扱う。

代替ルート（alternative route）：既存の集中点を経由しない別の経路。だが別の集中点に依存している場合、障害耐性の点では既存ルートと等価である。

分散ルート（distributed route）：機能が複数の独立運用主体に冗長化されており、任意の一点が落ちても機能が維持される経路。

2. Propositions

P1：ATProtoスタックの主権は「データ層」と「視点層」の二次元で評価される必要がある。両者は独立に集中・分散しうる。

P2：PDS層はATProtoにおいて実効的に分散されている。Leafletは自前PDS配信で障害時も稼働を維持した。

P3：視点層は現状、少数の集中点に依存している。公式AppView（api.bsky.app）と、AppView-lessを標榜するクライアントが依存する逆引きインデックサ（Microcosmが運用するConstellationおよびSlingshot）は、いずれも単点である。後者は前者を回避する代替経路だが、それ自体が単一運用主体に依存している。

P4：逆引き操作（リプライ一覧、フォロワー一覧、言及一覧）はPDS単体では原理的に実行できない。誰かが集約する必要がある。この集約機能が視点層の臨界点である。

P5：AppView-lessアーキテクチャは、公式AppViewへの依存を回避する代替ルートを提供するが、分散ルートは提供しない。別の単点集中に依存を移しているにすぎない。

3. Corollaries

C1（P1, P2より）：データ主権の成立は視点主権の成立を含意しない。両者は別個に達成されるべき目標である。ATProtoの「分散」評価を一次元で行う言説は、少なくとも二つに分離して評価し直す必要がある。

C2（P3, P5より）：AppView-lessクライアントと公式クライアントは、障害耐性の観点では構造的に同等である。依存先は異なるが、依存の形態（単点集中への依存）は同一である。

C3（P4より）：視点層の分散化は、逆引き集約機能の冗長化を必要とする。PDSの数を増やすだけでは達成できない。複数の独立インデックサが同一ネットワークを並行して集約し、クライアントが任意に切り替えられる構成が要件となる。

C4（P3より）：Relay層の障害は視点層全体に波及する。PDSが稼働していても、firehoseが詰まれば下流のすべてのインデックサ（公式・非公式を問わず）が新規データを取り込めなくなる。Relay層もまた視点主権の臨界点である。

C5（C2, C3より）：「AppView-less」を分散性の指標として用いることは誤導的である。真の指標は「依存先インデックサが複数あり切替可能か」である。この条件を満たすATProtoクライアントは、2026年4月時点で存在しない。

4. Open Questions

Q1：視点主権を実現するインフラ構成は、経済的に持続可能な形で設計できるか。複数の独立インデックサを維持するコストは、公式AppView一点集中と比べて数倍のリソースを要する。誰がそのコストを負担するのか。

Q2：視点層の冗長化は、PDS層の分散と同じ設計思想で達成できるのか。PDSは「個人が自分のデータだけをホストする」ことで分散を達成した。だが逆引き集約は本質的に全体を見る必要がある。個人規模では担えない機能の分散は、PDSモデルとは異なる設計を要求するのではないか。

Q3：梁モデル（weir model）や水晶ラジオモデル（crystal radio model）は、視点層の設計原理としてどこまで具体化可能か。現在これらは比喩的構想にとどまる。実装可能な仕様にまで落とし込んだとき、PDS－Relay－AppViewという既存スタックのどこに、どのような形で挿入されるのか。

Discarded Hypotheses（棄却仮説）

  • RedDwarfが動かなかったのは、RedDwarf側の実装障害である——観察された事実（Leafletは稼働、公式AppViewは停止、RedDwarfは停止）を最も簡潔に説明するのは、RedDwarfが依存する共通インフラ（Microcosm／Relay）の障害である。個別実装の障害を持ち出す必要はない。

  • PDS層もまた集中している——Leafletが稼働を続けた事実がこの仮説を棄却する。少なくともLeafletが依存するPDS経路は、公式インフラの障害に対して独立に機能した。PDS層の実効的分散は観察事実として成立している。