ATProtoには「インスタンス」なんて存在しない！？その構造を徹底解説

よくある質問ですが、ATProtoにはMastodonのような「インスタンス（サーバー）」という概念は存在しません。ATProtoにおける「サーバー」は、単なるユーザーデータのホスティング場所（Personal Data Server: PDS）に過ぎず、ネットワークそのものは中央集権的な単一のインスタンスではなく、プロトコルとして分散して機能しています。

なぜRelayについて軽く触れただけで、ネットワークの他の部分とどうやり取りするのか説明がないのか不思議だ。たぶん、それを詳しく説明するとatprotoにも実質的に「インスタンス」が存在することがバレるからかもしれないが、実際のところはどうなんだろうな。

自分の理解では、Relay[1]はATProtoを効率的に動かすための接着剤みたいなものだよ。Relayはコンテンツに関与しないのが前提で、単にデータを中継して、各AppViewが認識しなければならないサービスの数を減らしているんだと思う。

ブログにもあるように、Mastodonに対する大きな改善点は、Relay、AppView、PDSがそれぞれ独立したサービスとして、個別にスケーリングできることだ。これはシステム設計上の問題に対する、かなり美しい解決策だよ。

[1] https://atproto.com/guides/glossary

ATprotoは整合性のために真の分散化を犠牲にしていて、MastodonやActivityPub（AP）はその逆で、よりアクセスしやすい分散化のために整合性を犠牲にしているんだ。

ATでコンテンツRelayを動かすよりもAPノードを動かす方が一般的なセルフホストユーザーにとってはるかに簡単だから、少なくとも自分はそう理解している。

だから、ATで「分散化」できるのは結局自分のデータだけで、ネットワークの一部をみんなで所有するというよりは、自分のデータを所有することに重点が置かれているんだと思う。

この話はHNでも何度も繰り返されてきたことだけどね。

重要な違いとして、ブログは独自のウェブサイトを持っているし、RSSフィードに記事の全文を掲載する義務はない。

Blueskyは通常そういう仕組みじゃなくて、PDSにあるすべてのデータが複製される。彼らは複製しやすいようにブログの全文をPDSに置くことを推奨しているんだ。だから、インデックスを作りたい人は誰でもコピーを手に入れることができるし、それに対してこちら側が制御することはできない。

もちろん、そうする必要はないよ。自分のウェブサイトでブログを公開して、Blueskyにはそのリンクを投稿するだけで済むからね。

Google Readerを例えに出すのは、不吉な予感がするよ。確かにRSSはGoogle Readerの終了を生き延びたけれど、RSSを使っていたすべてのコミュニティ（今でもRSSが何か知らない人も多いけど）が生き残ったわけじゃない。

あるものを「分散型」だと主張しておきながら、その例えとして分散型エコシステムの巨大な（ソーシャル面での）集権化をポジティブなものとして挙げるのは、なんだか「フロイト的」な深層心理を感じる。特にその結末を知っているならなおさらだ。Google Readerは多くのRSSサイトを統合して、ソーシャルグラフやコメント機能で付加価値を与えたけれど、幹部の気まぐれで閉鎖されてRSSを死に追いやり、素晴らしいソーシャルグラフを破壊したんだから。

この例え話を聞いても、ATProtoにあまり自信が持てないな。

Hacker Newsでatprotoに関する投稿があるたびに、コメント欄で「Blueskyのインスタンスはどこにあるんだ？」と聞く人がいる。問題は、atprotoにはインスタンスなんて存在しないということだ！その質問自体がカテゴリーエラーなんだ。インスタンスという概念はMastodon脳のもので、これを明確に説明するためのリンク先が欲しかったんだ。

あなたは（意図的なのか？）「インスタンス」を都合よく解釈して、ActivityPub（やRSS）を犠牲にしてATProtoを売り込んでいるように感じるよ。こういうやり方は自分自身の価値を下げていると思うな：

1. ATProtoのRelayの是非や、ActivityPubのアカウント移行の是非といった、技術的な真実を省略したり捻じ曲げたりせざるを得なくなっている。

2. 同じような問題を解決しようとしている2つのプラットフォームの間で、不必要な対立や批判を生み、不必要に分断を煽っているように見える。

それに、「インスタンスはどこ？」という質問に対して、それがサーバーやソフトを動かす環境、VM、コンテナといった一般的な意味で使われていると想定しないのは少し馬鹿げているよ。

厳しすぎるかもしれないし、誤解しているかもしれないけど、ActivityPubやそのユーザーを純粋に啓蒙したいというよりは、彼らに対する軽蔑や不満が動機になっているという強い印象を受けるな。

図解や解説は楽しめたんだけどね！ただ、ActivityPubに対する微妙な当てこすりが不必要なノイズになっていると感じただけだよ。

この解説で両者の違いがわかったのは評価するよ。

でも、ちょっともどかしい部分もあった。質問の一端には答えているけれど、「じゃあATProtoはどうやってインスタンスが解決している問題に対応しているの？」という疑問には答えられていないからだ。

例えば、記事内で連合解除（defederation）を「友達の投稿が見えなくなる謎の理由」として片付けているけれど、これだと「じゃあATProtoはどうやって連合解除が解決していた問題を解決するの？」という問いに答えていない。この枠組みで考えると、自然と「解決していない」という答えが出てきてしまう。

ここで示された例えは破綻していると思う。RSSはGoogle Readerに全く依存していない。全盛期でさえ、今のメールがGmailに依存している度合いよりも、RSSのGoogle Reader依存度は低かった。ATProtoではAppViewが実用化のためにRelayに強く依存しているし、Relayの運用はかなり高コストだ。それに、RSSの図でブログを表す黄色い丸は、Facebookの投稿を表す同じ丸と同じ性質のものではない。ブログは自己完結しているからね。

ATProtoがダメだと言っているわけじゃないけれど、このブログ記事は何かを明確にするどころか、むしろ混乱を招いている気がする。

アヒルみたいにガーガー鳴くなら、それはアヒルだろ…。アカウントは単一の個人データサーバー（PDS）を持つんだよね？DIDはユーザーのデータフィードの正本となるPDSに紐付いていて、ユーザーの書き込みはそこに行く。データは複製可能だが、PDSが正本として扱われる。これは分散アーキテクチャというより、クライアント/サーバーアーキテクチャに近い。P2Pデータベースがあるわけでも、DHTやピアへの書き込みがあるわけでもない。自分のPDSに書き込んで、それがオプションでミラーリングされるだけだ。それに、発見（discovery）はDNS経由で行われるから、データについてピアに問い合わせる必要すらない。Relayへの接続もピアとしてではなく、PDSが管理する正本データのコピーを要求するクライアントとして繋いでいる。PDSをインスタンスと呼び、Relayをミラーと呼ぶのは、それほど飛躍した考えだとは思わないな。

このブログはアーキテクチャの説明としては素晴らしいね。ただ実際には、「問題」はBluesky社がメインアプリを運営し、ユーザーデータのほぼすべてをホストしていることにあると思っていた。

つまり、プロトコルレベルでは分散化されているけれど、実際には運営側の管理という点でシステムはかなり中央集権的なままなんだ。

これが必ずしもBlueskyのせいだとは言わないけれど、これまでのところはそういう状況になっているよね？