2026/06/20 0:10
ATProto のインスタンスはありません
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
以下は、不足していた特定の詳細を統合しつつ流れを保つ改訂版です。
改善されたサマリー
記事は、「Bluesky インスタンス」について尋ねることがカテゴリエラーであることを明確にし、atproto がデータのホスティングとアプリケーションを根本的に分離することにより、Mastodon のような孤立した「インスタンス」という概念を排除していることを説明します。従来のモデルでは、これらの結合されたシステムが「領邦」を生み出し、インスタンス所有者がユーザーを追放できる一方、atproto においてはアイデンティティはサーバーではなくユーザーのデータに属しています。この構造により、ユーザーはソーシャルグラフへのアクセスを失うことなくホスティングプロバイダーを即座に切り替えるか、自動的にデータを移行することが可能になります。エコシステムはまたアプリの独立性を育みます; ユーザーは特定のクライアントに依存するのではなく、「Tangled」や「Semble」などのさまざまなアプリケーション間で切り替えたり、著者が言及したプロジェクトのようなカスタムオープンソースアプリを構築して任意のホストからのデータを集約したりすることができるようになります。リレーや Cloudflare などの特定のインフラストラクチャツールがこのモデルを可能にしており、データベースは孤立したアイデンティティサイロとして機能するのではなく、モデレーションの多様性またはキャッシュのために複数のコピーを実行します。したがって、業界は「インスタンス数」のような誤解を招く指標から離れ、ユーザー主体性、多様なアプリ開発、そして真のデータポータビリティによって定義されるより健全なエコシステムへと移行します。
本文
atproto アーキテクチャと「インスタンス」の誤解を解消する記事
すべての atproto に関する投稿が Hacker News に登場すると、コメント欄で必ず「Bluesky のインスタンスはどこにあるのですか？」という質問が出されます。しかし、atproto には「インスタンス」という概念は存在しません。これは「マストドン特有の用語を誤用している」ことによるカテゴリーの混同であり、この疑問に対する答えは以下の構成で解説します。
RSS と Google Reader に学ぶ分離の重要性
かつてブログが盛んだった時代、「ウェブの黄金時代」と呼ばれた時期には、「ホスティング」（コンテンツの保存場所）と**「集約」**（閲覧・配信インターフェース）は明確に分離されていました。
当時の構造例：
- alice のブログ（ホスティング側）
- cat のブログ（ホスティング側）
- bob のブログ（ホスティング側）
- Google Reader（集約側のアプリ）
- Feedly（集約側のアプリ）
この時代の重要な認識は以下の通りです：
- あなたが自前で作成・運営し、ホストするか、プラットフォーム上で展開するコンテンツが実体となります。
- Google Reader や Feedly といったアプリの中ではなく、そのアプリ自体がブログスフィアに対する単なる投影（プロジェクション）に過ぎません。
- ホスティングと集約は別々の概念です。
この「分離」の発想こそが、後で非常に重要になります。
従来のソーシャルメディア：中央集権化の問題点
Facebook 等の従来のモデルでは、上記の構造が一気に変化しました。すべてを一つの「箱」の中に閉じ込めることがなされたため、以下のような現象が起きました。
- 構造の変化
- alice の投稿 → Facebook
- cat の投稿 → Facebook
- bob の投稿 → Facebook
- アプリは一つだけ（Facebook）に固定され、代替アプリは許容されない状況に陥りました。
- 結果として起きた問題
- 中央集権化：すべてが单一の管理元に集中しました。
- 脱制御されたネットワーク効果の喪失：ユーザーは自由に選択できなくなりました。
これを脱中心化するためには、この「箱」を取り除き、元来の分離構造に戻す必要があります。
Mastodon と ActivityPub の誤解
議論の中でよく見られる反論として、「atproto は Mastodon が ActivityPub を実装した方法に過ぎない」という指摘があります。これは事実関係の混同です：
- ActivityPub: プロトコルの仕様であり、実践的な使用方法そのものを規定するものではありません。
- Mastodon: 上記のプロトコルを実装した具体的なソフトウェアです。
atproto アーキテクチャの真偽
これまでの議論を整理し、「箱」(Centralized Server) を描き込むのをやめましょう。atproto は RSS と同様に、あらゆるコンテンツタイプでこの分離構造をサポートしています。
1. 従来の誤ったモデル（Mastodon のような構造）
すべての要素を一つの管理領域内に統合している例です：
- alice, alex, ann, cat, crow, cali, bob, bree, boba 等の投稿
- Mastodon インスタンス #1
- Mastodon インスタンス #2
- Mastodon インスタンス #3
- ニュースフィード
これは、ホスティングとアプリが一体化した**「領邦」**のようなものです。
2. atproto の正しい構造（分離された構造）
atproto では、ネットワークレベルでホスティングと集約を完全に分離しています：
- alice, alex, crow, cali, boba, bree, ann, bob, cat 等のコンテンツ
- atproto ホスティング #1
- atproto ホスティング #2
- atproto ホスティング #3
- atproto（集約層：クライアントの基盤）
ここで利用可能なものは以下の通りです：
- ホスティング: 自由に切り替え可能。
- アプリ: 任意のクライアント（Bluesky, Tangled, Semble など）を選択可能。
「Bluesky のインスタンスはどこにあるの？」への回答
結論から申し上げます：atproto には「インスタンス」はありません。
もしホスティングサーバーを複数台動作させることが「インスタンス」と呼ばれるなら、以下のメリットがあります：
- ホスティングの自由な切り替え: ユーザーは好きなホスティングへ移行可能です。例えば、自分のデータを Cloudflare 上で無料でホストすることも可能になりつつあります（現在は Eurosky への移行など実際に実行されています）。
- アプリの多様化: Bluesky 以外の新しいアプリを試作・利用できます。
- 主権と去中心化: ユーザーは完全に分散された状態を自由に構築可能です。
Blacksky などの例のように、異なるモデレーション哲学などを目的に特定の設定を行うことは可能ですが、それは「インスタンスの数を増やす」という単純な話ではありません。Relays などの共有ネットワークインフラストラクチャが安価で稼働している現状があります。
インスタント思考様式からの解放
なぜすべての去中心化議論が「インスタンスの数」で測られるのか？ それは、Mastodon のアーキテクチャにおいて、**ホスティングとアプリが一体化した「箱」**しかなく、その数を増やすことだけが可能な操作だからです。デフォルトではそれらは隔離されています。
一方、atproto は以下の点で構造的に豊かで優れています：
- すべてのアプリは全体の大気圏（Atmosphere）に対する投影です。
- 去中心化は「ホスティングの切り替え」や「新しいアプリの開発・試行」によって実現されます。
Google Reader の多数のコピーを実行することに比べ、Blacksky のような設定にメリットはありません。重要なのは以下の二点です：
- 人々が代替ホスティングへ移行しているか？
- 人々が新しいアプリを試作・利用しているか？
結論：閉鎖型システムからの脱却
ホスティングとアプリを結合させることが「元祖罪」であり、atproto はこれを修正することで破綻したインセンティブを解消しています。
理想的な atproto の世界観は以下の構造です：
- alice, cat, bob 等のコンテンツがアプリの外側に存在する。
- アプリ（#1, #2 など）はそれらのコンテンツを単に集約・表示するだけの役割を持つ。
つまり、RSS と Google Reader の仕組みです。これで「Bluesky のインスタンス」を探す必要はないという事実をご理解ください。