AT Protocol入門：プロトコルの背景にある考えを理解する

※この記事は「BlueskyがActivityPubを採用しなかった3つの理由」の続編です。先に前編を読むことをおすすめします。

• 前編「BlueskyがActivityPubを採用しなかった3つの理由」
• 中編「AT Protocol入門：プロトコルの背景にある考えを理解する」←イマココ
• 後編「AT Protocol入門：ActivityPub連合との違いはなにか？」

前回までのあらすじ

• ActivityPubは「Small Fedi」向けのプロトコルである
• 「Big Fedi」を目指すBlueskyは、新たにAT Protocolを開発したのであった

お断り

この記事の目的は、一般の方にAT Protocolの概要をなんとなく理解してもらうことです。主にアーキテクチャやその背景にある考え方へ焦点を当てており、技術的な詳細については触れません。具体的には、アイデンティティ（DID）、自己認証データ構造（Repository）、スキーマシステム（Lexicon）などのトピックは対象外としています。

詳細な情報が知りたい方は必ずatproto.comなどのオフィシャルな情報を参照してください。

AT Protocolとは？

AT Protocolは、ソーシャル アプリケーションを構築するためのオープンな分散型¹ネットワークです。

Bluesky社が開発を進めており²、同社のSNS「Bluesky」や、このブログサービス「WhiteWind」はAT Protocol上に構築されています。

プラットフォームではなくプロトコルを

このプロトコルは、Mike Masnick氏の「プラットフォームではなくプロトコルを」³という考えに強い影響を受けています。

Twitterのような巨大プラットフォームのモデレーションには、さまざまな意見があります。言論の自由を重視する人々は、プラットフォームが特定の視点を抑圧していると批判します。一方で、荒らしやデマが放置され、ヘイトスピーチが広がることを懸念する声もあります。Masnick氏は、このような板挟みが生じる原因として、現代のプラットフォームが多くの役割を担いすぎていることを指摘しています。

彼は、この問題に対処するために、巨大プラットフォームが持つ役割の分割を提案しました。具体的には「人々が自由にコンテンツを公開し、企業はそのコンテンツのキュレーションに専念する」というモデルを提示しています。

これは本来の「Web」の概念に似ています。Webでは誰でも自由にコンテンツを公開でき、そのコンテンツはプロトコル（HTTP）を通じて検索エンジンが収集します。

AT Protocolの目的

AT Protocolの目的は、以下の3つです。⁴

• ユーザーがプラットフォームにロックインされないこと
• ユーザーが自身のコンテンツを所有し、持ち運べること
• 非中央集権化によって生じる複雑さで、ユーザー体験を損なわないこと

「耐検閲性」や「耐障害性」は、このプロトコルの目的ではありません。⁵

AT Protocolの特徴は、はじめから大規模なネットワーク（Big Fedi / Big World）を想定して設計されたことです。

ActivityPubとの違い

ActivityPubによる連合が「Fediverse」⁶と呼ばれるのに対して、AT Protocolによるエコシステムは「Atmosphere（アトモスフィア）」⁷と称されます。

両者の違いは「Twitterをどのように分割したのか」という視点で見るとわかりやすいです。

ActivityPubの場合

まず、フェディバースについて考えてみましょう。

フェディバースでは、Twitterを複数の「ミニTwitter」に分割しました。

このとき、ユーザーの「アイデンティティ」「データ」「サービスロジック」は同じサービス内に存在します。

例えば、misskey.ioでアカウントを作成すると、そのユーザーはmisskey.ioに所属します。ユーザーの投稿はmisskey.io上のサーバーに保存され、タイムライン作成などのロジックもmisskey.ioが提供します。

AT Protocolの場合

これに対して、AtmosphereではTwitterを「役割」ごとに分割しました。

したがって、ユーザーの「アイデンティティ」「データ」「サービスロジック」は別のサーバーに置かれます。

AT Protocolでは、ユーザーのアイデンティティがサービスから独立しています。Blueskyで新規アカウントを作成しても、そのユーザーはBlueskyに所属せず、他のサービスで同じIDを利用できます。

データもサービスから独立しています。たとえば、BlueskyとWhiteWindは異なるサービスですが、共通のサーバー（PDS）にデータが保存されます。

これが両者の大きな違いです。

アーキテクチャ

AT Protocolは「PDS」「Relay」「AppView」の3つの主要コンポーネントで構成されています。

PDS

PDS（Personal Data Server）はデータの置き場であり、Atmosphereのあらゆるデータがここに保存されます。ユーザーは必ず1つのPDSに所属します。Blueskyで新規登録すると、同社の管理するPDSが自動的に割り当てられます。

PDSは「Mastodonのインスタンスと同じもの」と誤解されることがありますが、実際には異なります。PDSは単なるデータの置き場であり、WhiteWind作者の方の言葉を借りると「API付きクラウドストレージ」に近い存在です。⁸

Relay

Relayは、世界中のPDSと接続してデータを収集するクローラーです。PDSでデータが更新されると、Relayはその情報を取得し、他のサービスが利用できるように1つの大きなデータストリームとして出力します。このストリームは「firehose（消火ホース）」と呼ばれています。

画像⁹：PDSのあらゆる変更データを取得し、1つの口（消火ホース）から常時ドバドバ出力する

外部サービスのFireskyでは、Relayが現在流しているBluesky関連のデータを確認できます。

Relayはあくまで更新されたデータを右から左に流すだけの存在です。データに対してなにか変更を加えたりはしません。

AppView

AppViewでは、Relayから受け取ったデータをもとにサービス固有の処理を実行します。BlueskyのAppViewでは、いいねの集計やタイムラインの作成、検索用インデックスの生成などが行なわれます。

Bluesky以外にも独自のAppViewを持つサービスがいくつかあります。たとえば、このブログサービス「WhiteWind」や、イベント管理サービスの「Smoke Signal」などです。

投稿の流れ

Blueskyを例に、ユーザーの新しい投稿がどのように処理されるかを見てみましょう。

• ユーザーがBlueskyに新規投稿すると、その投稿はユーザーが所属するPDSに保存されます…(1)
• Relayは、PDSから新規投稿データを取得し「firehose」として出力します…(2)(3)
• BlueskyのAppViewは、firehoseから受け取ったデータをもとにタイムラインを生成します
• 生成されたタイムラインは、PDSを経由してユーザーのクライアントに表示されます¹⁰¹¹…(4)

スピーチ層とリーチ層

この記事の冒頭で、Masnick氏の「人々が自由にコンテンツを公開し、企業はそのコンテンツのキュレーションに専念する」というモデルを紹介しました。

AT Protocolのアーキテクチャは、人々が自由にコンテンツを公開する「スピーチ層」と、企業がそのコンテンツをキュレーションする「リーチ層」に分けられます。

スピーチ層

スピーチ層は、サービス「利用者」の領域です。ここにはPDSが含まれます。

PDSは、ユーザーが自分で運用できるように設計されています。しかし、専用サーバーの立ち上げは多くのユーザーにとって難しいため、通常はサービス提供者が管理するPDSに所属します。

日本ではXserver VPSがPDSのアプリイメージを提供しており¹²、これを利用して簡単にPDSを構築できます。またPDSは「DID（Decentralized Identifier）」という仕組みを利用して他のPDSへの引っ越しが可能です。¹³

リーチ層

リーチ層は、サービス「提供者」の領域です。この層にはRelayとAppViewが含まれます。これらのサーバーは、サービス提供者によって運用されます。

AT Protocolでは、すべてのコンポーネントがモジュール化されており、レゴブロックのように交換可能です。¹⁴RelayやAppViewは複数同時に存在できるため、ユーザー（PDS）は複数のサービスから自分が利用したいものを選択できます。

気になるのはリーチ層の運用コストです。2024年7月に行なわれた実験¹⁵では、Relayの運用には月額約150ドル（1ドル=140円換算で21,000円）が必要でした。ネットワークへの参加者が増加すればこのコストも上昇しますが、それでも非営利団体が運用できる範囲内に収まると思われます。

---

AT Protocolは、このアーキテクチャによってBig Fediで発生する3つの問題に対処しています。

1. グローバルビュー

AT Protocolではすべてのデータがリーチ層に集約されるため、Atmosphere全体を横断した検索やトレンドトピックの抽出が可能です。

また、このグローバルビューを利用して「フィード」や「ラベル」といった仕組みを提供できます。

フィード

XやThreadsのアプリケーションでは、タイムラインのデフォルト表示が「おすすめ」になっています。この「おすすめ」に表示される内容は、運営側のアルゴリズムによって決定されます。しかし、SNS上では過激な内容ほど注目を集めやすく、その結果「おすすめ」はそのような投稿で埋め尽くされる傾向があります。

Blueskyは、この「おすすめ」の仕組み自体に問題があるのではなく、ユーザーにアルゴリズムを選択する自由のないことが問題だと考えました。

Blueskyでは「フィードジェネレーター」という機能を提供しています。この機能により、ユーザーは自分自身でカスタマイズしたフィードを作成できます。これにより、プラットフォームから一方的にコンテンツを押し付けられるのではなく、自分が見たい情報を自由に選択できるのです。

フィードの例としては、公式が提供する「Discover」、自分の最近の投稿と関連のあるポストを表示する「N-Feed」、リポスト直後の投稿が表示される「RepostNextPost」などがあります。

画像：「Discover」フィード

ラベル

AT Protocolには「ラベラー」という仕組みがあり、これを使って投稿やアカウントなどのデータに独自のラベルを付与できます。

このラベラーは誰でも運用可能です。ユーザーは特定のラベラーを購読することで、見たくないコンテンツを非表示にしたり、警告を表示できます。

Blueskyには、多様なラベラーが存在します。過激なコンテンツを非表示にする一般的なものから、作品のネタバレを防ぐためのものまで、さまざまな目的に応じて利用できます。

画像：Bluesky公式が提供するラベラー

2. 非中央集権性

前編の「理由2」で述べたように、ネットワークが拡大すると、大手サーバーを中心に事実上の中央集権化が進みます。

AT Protocolでは、このような状況で特定のサービスにユーザーが集中してしまうことは避けられないものとして割り切りました。その代わり、サービスに「敵対的相互運用性」を持たせることで、ユーザーが巨大プラットフォームにロックインされない仕組みを構築しました。

敵対的相互運用性

AT Protocolは、アカウントのポータビリティに加えて「敵対的相互運用性（Adversarial Interoperability）」¹⁶を備えています。これは、企業が他社の協力なしに既存の支配的な製品と互換性を持たせられる仕組みです。

具体的な例としては、Microsoft Excelのxlsxファイルがあります。

Excelはデータをxlsx形式で保存します。「Googleスプレッドシート」や「LibreOffice」などの他社製品もこの形式をサポートしており、Microsoftの協力なしに互換性を実現しています。

この相互運用性により、企業はユーザーを自社サービスに囲い込むことが難しくなり、サービスの質向上に注力せざるを得ません。

AT Protocolでは、データ（PDS）とサービス（AppView）が分離されています。PDSに保存されたデータ（レコード）は、そのデータを作成したサービス以外のAppViewからも利用可能です。

この敵対的相互運用性によって利用者の選択肢が広がり、公正な競争が促進されます。

Q. なぜアカウントポータビリティでは不十分なのか？

アカウントポータビリティだけでは「Big Fedi」における問題を完全には解決できません。

「Small Fedi」でメタクソ化が発生した場合は、アカウントを別のサーバーに移行することで対応できます。

一方「Big Fedi」では状況が異なります。大規模なプラットフォームでは、サービスの利用者は一枚岩ではありません。大手サーバーは、一部のマイノリティに対してのみ不利益をもたらすような改悪をする可能性があります。

このような場合、少数のユーザーが別のサーバーに移行しても、大手サーバーによる不当な扱いから完全には逃れられません。つまり、アカウントポータビリティは、マジョリティのユーザーが一斉に移行する状況以外では十分な解決策にはなり得ません。大手サーバーが暗黙の権力を持っている以上「嫌なら出て行け」は成立しないのです。

3. スケーラビリティ

AT Protocolの設計目標は、現在のグローバルサービスと同程度（2億人以上）のユーザーをサポートすることです。¹⁷

このプロトコルのアーキテクチャは、各コンポーネントから一方向に矢印が伸びています。PDSやAppViewなどの同じコンポーネントどうしは直接通信しないため、サーバーが増えても効率的にスケールできます。

AT Protocolのイベントストリーミングを中心としたシステム設計は、Martin Kleppman氏の「database inside-out」¹⁸というコンセプトに大きな影響を受けています。Kleppman氏は『データ指向アプリケーションデザイン』の著者であり、Blueskyチームのアドバイザーも務めています。

スケーリングの詳細については、公式サイトに日本語で詳しい説明があるので、ここでは割愛します。

分散システムエンジニアのためのATProto

中編のまとめ

以上がAT Protocolの概要と、その背景にある考えです。

後編では、AT ProtocolとAcitivityPubを比較し

• 分散に対するアプローチの違い
• 連合方法の違い
• AT Protocolが得意/苦手とすること

などについて解説します。

---

※この記事は2024年10月15日に書かれました。内容は執筆当時のものであり、現在の情報と異なる場合があります。

Footnotes

1. 前編に引き続き、この記事における「非中央集権」と「分散」という用語は、イーサリアム創設者であるVitalik Buterin氏の記事「The Meaning of Decentralization」を参考に、以下の定義で使用します。

   • 非中央集権（Decentralization）…… "Political decentralization" の意味、つまり、システムを構成するコンピュータを何人の個人や組織がコントロールしているかという観点で使用します
   • 分散（Distribution）……"Architectural decentralization" の意味、つまり、システムが何台の物理的なコンピュータで構成されているかという観点で使用します
     
     よく見かける、Paul Baran氏の1964年の論文で使用された定義には従わないので注意してください。
   ↩

2. 将来的にはIETFなどでの標準化を目指しています。https://docs.bsky.app/blog/2024-protocol-roadmap#standards-body-timeline ↩

3. https://knightcolumbia.org/content/protocols-not-platforms-a-technological-approach-to-free-speech ↩

4. 「Bluesky and the AT Protocol: Usable Decentralized Social Media」のabstractから。原文では4つの目的が挙げられていますが、最初の2つは手段寄りのため「ユーザーがプラットフォームにロックインされない」として1つにまとめています。 ↩

5. 逆に、ユーザビリティなどと引き換えに「耐検閲性」や「耐障害性」を高めることに特化したプロトコルがNostrです。 ↩

6. フェディバースという用語には、以下の3つの異なる解釈があります。

   • 狭義の立場……フェディバースは、ActivityPubプロトコルを使用する連合型ソーシャルプラットフォームのみを指します。この見解では、ActivityPub以外を使用するプラットフォームはフェディバースに含まれません
   • 広義の立場……フェディバースは、共通のプロトコルを介して通信するすべての連合型ソーシャルプラットフォームを指します。この場合、ActivityPub以外のプロトコルであっても、ソーシャル機能があればフェディバースに含まれます
   • 最広義の立場……フェディバースは、フェデレーションを行なうすべてのものを指します。この見解では、XMPPや電子メールなどもフェディバースの一部と見なされます
     
     前編に引き続き、本記事では「狭義の立場」に基づき、フェディバースという用語を「ActivityPubを使用した連合型プラットフォームのみ」を指すものとして使用します。
   ↩

7. https://atproto.com/ja/guides/glossary#atmosphere 執筆時点（2024/10/15）では「Atmosphere」という用語は日本語圏にほとんど浸透していません。 ↩

8. 執筆時点では、PDSに保存された内容は原則公開されます。今後の計画として、PDSに保存した内容をRelayには公開せず、データへのアクセスを求める特定のアプリにだけ公開する仕組みを検討しているそうです。 https://gigazine.net/news/20240921-bluesky-meetup-kyoto-dan-abramov/ ↩

9. https://www.zdnet.com/article/kafka-channels-the-big-data-firehose/ ↩

10. 厳密な話をすると、BluskyのPDSにはRead-After-Writeという仕組みがあり、PDS側で既存のフィードに新しい投稿を挿入する処理が行なわれます。 ↩

11. PDSは、クライアントとAppViewの通信を媒介するプロキシとしての役割も担います。 ↩

12. https://vps.xserver.ne.jp/support/manual/man_server_app_use_bluesky.php ↩

13. すべてのアカウントは不変の一意な識別子であるDIDを持ちます。DIDはdid:plcもしくはdid:webを使用してDID Document（ユーザー情報を含むJSON）に解決されます。このDID Documentに含まれるPDSのURLを更新することで、引っ越しが実現します。 ↩

14. 厳密には、現状plc.directlyは中央集権化されています。BleskyではDIDという分散型識別子でユーザーを一意に識別しますが、この解決方法としてdid:plcを使用します。plc.directoryはこれらの識別子を管理し、ディレクトリとして機能するサービスです。PLCについては、将来的にはICANNのようなコンソーシアムへ移行するか、クローズドブロックチェーンになる案がありました。最近のBlueskyチームの発言からすると、前者を目指しているようです。 ↩

15. https://whtwnd.com/bnewbold.net/entries/Notes%20on%20Running%20a%20Full-Network%20atproto%20Relay%20(July%202024) この金額はクラウドで実行する場合のコストであり、年単位での運用を視野にいれる場合は、オンプレミスに移行することでコストを大幅に削減できます。 ↩

16. https://www.eff.org/deeplinks/2019/06/adversarial-interoperability-reviving-elegant-weapon-more-civilized-age-slay （日本語訳： https://p2ptk.org/monopoly/2088 ） ↩

17. https://bsky.app/profile/pfrazee.com/post/3kazzzbknhp2y ↩

18. https://www.confluent.io/blog/turning-the-database-inside-out-with-apache-samza/ ↩