ATProto: なぜ「インスタンス」が存在しないのか

ATProtoとMastodonのような連合型ネットワークの根本的な違いは、ATProtoには「インスタンス」が存在しないことです。連合型ソーシャルネットワークはホスティングとアプリケーションのロジックが結合していることに依存していますが、ATProtoはこれらの機能を分離することで、ユーザーがアイデンティティやソーシャルグラフを失うことなくホスティングプロバイダーを切り替えられるようにしています。

ホスティングと集約の分離

ATProtoは、ホスティングと集約がネットワークレベルで2つの異なる機能として機能するように設計されています。従来の連合型システムでは、「インスタンス」はホスティングとアプリケーション自体のセットになっています。対照的に、ATProtoはデータホスティングを基盤となるレイヤーとして扱い、アプリはそのデータから集約を行うものとして扱います。

このアーキテクチャは、初期のウェブにおけるRSSとGoogle Readerのモデルを反映しています。ユーザーは自身のブログ（ホスティング）にコンテンツを公開し、アグリゲーターアプリ（Google Readerなど）を使用して、それらのコンテンツの統合フィードを表示します。ATProtoにおいて、アプリケーションはデータが保存されている場所ではなく、ネットワーク全体にホストされているデータの「投影（projection）」です。

比較：連合型 vs ATProto

連合型インスタンス（例：Mastodon/ActivityPub）

連合型モデルでは、ユーザーは特定のインスタンスに「所属」します。アイデンティティは参加しているサーバーに紐付けられており、これがいくつかの構造的な依存関係を生み出します：

アイデンティティの結合: ユーザーのアイデンティティはしばしば不変であり、サーバーに紐付けられています（例：user@instance.com）。
管理者ポリシーへの依存: 2つのインスタンス管理者が連合（defederation）を停止すると決定した場合、ユーザー自身の個別の好みに関わらず、それらのインスタンスのユーザー同士は通信できなくなります。
単一障害点: インスタンスがシャットダウンされると、手動で移行しない限り、通常、ユーザーのアイデンティティとデータは消滅します。
スケーリングの複雑さ: インスタンス同士が投稿を転送するために合意を形成する必要があるため、ネットワークトポロジーのスケーリングは $O(n^2)$ となります。

ATProtoモデル

ATProtoは、ホスティングとアプリケーションを独立して存在させることで、「インスタンス」という概念を取り除きます。これにより、ユーザーは自身のデータに対してより大きな主導権を持つことができます：

ポータブルなアイデンティティ: ユーザーは、アイデンティティを変更したりフォロワーを失ったりすることなく、ホスティング（Personal Data Servers または PDS）を移行できます。
アプリの多様性: アプリは単なるデータの投影であるため、ユーザーはBlueskyアプリケーションに縛られることなく、異なるクライアント（Tangled や Semble など）を使用して同じデータを見ることができます。
柔軟なインフラストラクチャ: ユーザーは、自身のPDSを実行するか、パフォーマンス向上のためにコミュニティが運営するキャッシュやリレー（relay）を使用してデータを集約することが選択できます。

技術的実装とコミュニティの視点

アーキテクチャは概念的に優れていますが、コミュニティの議論では、いくつかの技術的なトレードオフと実装の詳細が浮き彫りになっています：

リレー（Relays）とAppViewsの役割

リレーは、ATProtoのパフォーマンスを向上させる「接着剤」として機能します。リレーはPDSesからAppViewsへデータを転送し、アグリゲーターがクエリを行う必要があるサービス数を減らします。一部の批判的な意見では、これがシステムをコストの高いインフラストラクチャに依存させることになると主張されており、RSSの比喩は不完全であると示唆されています。なぜなら、RSSフィードは一般的にATProtoのデータフィードよりも自己完結型であるためです。

一貫性と分散化

一部のユーザーは、ATProtoが「真の」分散化よりも、一貫性とデータ所有権を優先していると主張しています。コンテンツリレーを実行することはMastodonノードを実行することよりもリソースを消費するため、ネットワークの分散化は、ネットワークインフラの集合的な所有権ではなく、個々のデータの所有権に焦点を当てています。

PDSは「事実上の」インスタンスか

Personal Data Server (PDS) は単に名前を変えただけのインスタンスではないかという議論があります。一部の人は、ユーザーが正規のPDSに書き込み、DNSを通じて発見されるため、アーキテクチャはピア・ツー・ピアの分散型データベースではなく、クライアント・サーバーモデルのままであると主張しています。

"If it quacks like a duck... An account has a single Personal Data Server (PDS), right? The DID links to a PDS which is the canonical data feed for a user... I don't think it's a stretch to call the PDS an instance and the relay a mirror."

ATProtoアプローチのまとめ

ATProtoの核心的な目標は、ユーザーデータをアプリケーションの外側に置くことです。ソーシャル体験の集約（aggregation）からデータのホスティングを分離することで、ATProtoは、クローズドなプラットフォームと連合型インスタンスの両方に内在するインセンティブと制限を解決することを目指しています。