トップQs
タイムライン
チャット
視点
AT Protocol
ウィキペディアから
Remove ads
AT Protocol（Authenticated Transfer Protocol、「アット・プロトコル（at-protocol）」と発音し、一般にATProtoと略記される）[1][2]は、分散型ソーシャル・ネットワークのためのプロトコル・オープン標準である[3]。現在はBluesky Social PBCにより開発が行われている。パブリック・ベネフィット・コーポレーションであるBluesky Social PBCは、もともとTwitter内でサービスの非中央集権化の可能性を研究するために作られた独立研究グループをもとに設立された[4]。
AT Protocolは、ユーザーエクスペリエンス、プラットフォームの相互運用性、ディスカバラビリティ、ネットワークのスケーラビリティ、ユーザーデータとソーシャルグラフのポータビリティなどの、他の分散型プロトコルで認識されている問題に対処することを目指している[3]。また、モジュール式のマイクロサービスアーキテクチャと、サーバーに依存しないフェデレーション型ユーザーIDを採用することで、プロトコルサービス間の移動を可能にし、統合されたオンライン体験を提供することを目標としている[5]。このプラットフォームでは、フェデレーションされたネットワーク全体のデータストリームから、事前定義されたデータスキーマに合わせてフォーマットされたコンテンツを取得することにより、ネットワーク内のすべてのユーザーコンテンツへのアクセスと配信ができるようになっている[6][7]。
AT Protocolはプロトコルの概念実証として作られたBlueskyソーシャルネットワークの基礎となっており、Blueskyは、AT Protocol上に構築されたプラットフォームとサービスのエコシステム（ATmosphereと呼ばれる）の主要なサービスである[8][9][10]。Bluesky Socialは近い将来、プロトコルの開発をInternet Engineering Task Forceなどの標準化団体に移管することを約束している[11]。
Remove ads
設計
要約
視点
AT Protocolは、非中央集権的で相互運用可能なスケーラブルなオンラインエコシステムATmosphereを作ることを目指している。ATmosphereでは、ユーザーは単一のフェデレーションされたオンラインIDをさまざまなオンラインプラットフォームやサービスで保持・管理・カスタマイズできる。Bluesky Socialは、このプロトコルを「オープンウェブそのものをモデルにした」ものだと説明している[5]。
ソーシャルネットワークのための他の標準プロトコル（ActivityPubなど）は通常、ユーザーデータとアプリケーションの両方をホストするモノリシックなサーバーとしてデザインされるのに対して、AT Protocolではこれらの要素をより小さなマイクロサービスに分割し、必要に応じて使用できるように設計されている[12]。
AT Protocolのクライアントとサービスは、主にJSONをデータシリアライゼーションとして利用するXRPCと呼ばれるHTTP APIを通して相互運用される[13]。さらに、プロトコル内のすべてのデータは認証、参照され、保存時にはCBORにエンコードする必要がある[14]。
ユーザーID
AT Protocolは、ドメイン名を利用する変更可能なハンドルと、変更不可能な分散型ID（decentralized identifier、DID）を組み合わせたデュアルIDシステムを採用している。ハンドルはユーザーが利用するIDのためにあり、ドメインのリソースレコードにクエリを送ることで検証される。DIDはDIDドキュメントへと解決され、その中にはユーザーのハンドル、公開鍵、データリポジトリなどのユーザーの主要なメタデータへの参照が含まれる[15]。
サービスは、サインイン時に新規ユーザーにサブドメインを使ってハンドルを割り当てることもできる（例：@username.bsky.social）。また、ドメインのレコードにTXTレコードを追加するか、特定の.well-known URLへのHTTPリクエストにレスポンスを返すことで、ドメインまたはサブドメインをユーザーのDIDに関連付けて、ユーザーのカスタムのドメインやサブドメインをハンドルとして設定することもできる（例：@username.comや@username.wikipedia.org）[16][17]。
AT ProtocolのデュアルIDシステムは、エンドユーザーサービスで使用するためのユーザーフレンドリーな識別子と、プロトコル内での一貫した暗号化IDの両方を提供すると同時に、プロトコルレベルでの堅牢なTCP/IPベースのアカウント検証メカニズムも提供している。
ユーザーデータリポジトリ
AT Protocol内のユーザーデータは専用のデータリポジトリ（repository、repoとも呼ばれる）。各ユーザーは1つのリポジトリに関連付けられ、リポジトリ上の排他的な管理の権利を持つ。リポジトリには、ユーザーレコード（record）の変更可能なコレクション（collection）が保存され、投稿、いいね、フォロー、ブロックなどのアクションがそれぞれレコードとして記録される。レコードは永続性を持ち、ユーザーの明示的なリクエストが行われたときにだけ追加または削除ができる[18]。
リポジトリのコレクション内の各レコードには、ユニークなレコードキー（record key）が割り当てられ、ネットワークエージェントがユーザーのリポジトリ内のレコードを参照するために使用される。レコードキーの現在の実装は、レコードの作成時刻から派生したタイムスタンプ識別子（timestamp identifier、TID）である[19]。リポジトリはコレクションをマークル探索木に格納し、レコードをTIDをもとに時系列順にソートする[20]。
メディアファイルは、ユーザーのホストサーバー内にリポジトリとは別に、非構造化バイナリデータの一種であるブロブ（blob）として、メタデータ、サイズ、メディアタイプとともに保存される[21]。これにより、ネットワークエージェントは元のスキーマやアップロードのコンテキストに関係なく、任意のメディアファイルにアクセスして処理できるようになる[22]。
パーソナルデータサーバー
パーソナルデータサーバー（Personal Data Server、PDS）は、ユーザーリポジトリと関連メディアをホストする役割を持つ。PDSはユーザーのネットワークアクセスポイントとしても機能し、リポジトリの更新、バックアップ、データクエリ、ユーザーリクエストを容易にする[5]。
プラットフォームのクライアントは、ユーザーに代わってPDSにクエリしてプロトコルにアクセスし、そのPDSはネットワーク内の他のサービスから要求されたデータを取得する。この設計は、ActivityPubではプロトコルのやり取りやサービスがモノリシックなホストサーバーによって処理されるのと対照的である。ネットワークイベントは、プロトコルのネットワーク全体のインデックスインフラストラクチャを通して解決されるため、設計上、PDSはユーザーエクスペリエンスにほとんど影響を及ぼさない[23]。
AT Protocolはデータポータビリティを優先しているため、敵対的なPDSが作られた場合でも、ユーザーがデータを失うことなく自分のリポジトリと関連メディアをバックアップ・移行できるように設計されている[24]。AT Protocol内のPDSの設計により、操作に必要な計算量が少なくなり、個人やグループが大きな計算リソースを必要とせずに独自のPDSを実行できるようになっている[3]。
ほとんどのユーザーのリポジトリはBluesky Socialが運営するPDSに保存されているが、ネットワーク内には多数の独立したPDSも存在する[2]。
リレーとfirehose
リレー（relay）は、プロトコルのインデックスインフラストラクチャのキーコンセプトであり、ネットワーク内のコアとなるインデクサーとして機能する[5]。リレーはPDSのリポジトリの更新を連続的に取得することでネットワークをクローリングし、これらの更新を集約、インデックス化して、ネットワーク全体のデータストリーム（総称してfirehoseと呼ばれる）に転送する[7]。firehoseはすべてのネットワークエージェントで利用可能であり、ネットワーク内のどのサービスでも使用できる[3]。リレーは、ネットワークの全体または一部のいずれかをインデックスすることを選択できる[5]。
リレーは、ユーザーデータのクローリングや保存の必要性をなくし、統一されたデータストリームを提供することにより、プロトコル内のアプリケーションとサービスの開発を簡略化し、運用コストを削減している[25]。
リレーは、AT Protocolネットワークにおいてほぼ不可欠な役割を担っているが、リレーを運用する明確なインセンティブが欠如していることから、プロトコルの設計において最も集中化されたコンポーネントであると批判されてきた[26][27]。
App View
App Viewは、ユーザーのPDSからのクエリに応答して、リレーからユーザークライアントにデータを消費・処理・配信する、現在のソーシャル・ネットワーキング・サービスに類似したプロトコル内のエンドユーザープラットフォームおよびサービスである。App Viewは、firehoseから取得したネットワーク全体の投稿・いいね・フォロー・返信などの情報を利用して、クライアント内でカスタマイズされたユーザーエクスペリエンスを実現する[3]。
プロトコル内のApp Viewの設計により、様々な種類の実装が可能になる。App Viewには、招待システム、カスタムアルゴリズム、代替クライアント、さまざまな収益化、コンテンツモデレーション戦略、プロトコル外サービスなどを実装できる[28]。こうした違いにもかかわらず、すべてのApp Viewは、firehoseから取得された同じデータに基づいて動作する。このアーキテクチャは、App Viewの計算負荷とストレージ要件を軽減するとともに、ユーザーが投稿、フォロー、いいねなどを維持したままApp Viewを簡単に切り替えられるようにすることで、ユーザーのロックインを防いでいる[29]。
現在、プロトコル上の最大のApp ViewはBlueskyであるが、WhiteWind（長文ブログプラットフォーム）、Frontpage（Hacker Newsスタイルのソーシャルニュースウェブサイト）、Smoke Signal（出欠確認管理サービス）など、独立したApp Viewも存在する[30][31][32]。
Lexicon
AT Protocol内のすべての投稿は、さまざまなサービスやプラットフォームの形態をサポートするために、lexiconと呼ばれる独自のグローバルスキーマ言語に従う[33]。プロトコル内のApp Viewには、独自のlexiconを定義したり既存のlexiconを利用する柔軟性がある。
このアプローチのおかげで、App Viewは特定のユースケースに合わせてカスタムのlexiconを作成できるようになり、同時により広いネットワークとの互換性も維持できるようになっている。たとえば、マイクロブログにフォーカスしたApp Viewに表示されるレコードは、通常動画共有サービスにフォーカスしたApp Viewとは異なるlexiconを持つ。これは、取り扱うコンテンツの種類が異なる属性を必要とするためである。
しかし、App Viewは、たとえコンテンツがもともとネットワーク内の他の場所に投稿されたのだとしても、他のApp Viewが定義したlexiconを使用してコンテンツを配信することを選択することもできる[6]。たとえば、新しいマイクロブログのApp Viewは、既存の競合マイクロブログが定義したlexiconを使用して過去に投稿された投稿を配信することを選択することも可能である。これにより、新しいApp Viewは、既存のコンテンツとの互換性を維持しながら、新しい機能やサービスを提供できるようになる。
このスキーマ設計は、App Viewにコンテンツへの排他的アクセスに頼るのではなく、独自のユーザーエクスペリエンスと追加機能を通じて差別化することを強いることにより、ユーザーのロックインを排除し、ユーザー中心のイノベーションを促進することを目的としている[34]。
lexiconは、レコード内で名前空間識別子（Namespaced Identifier、NSID）として参照される。これは、ドメイン名の逆順に並べたドメインオーソリティとそれに続く任意の名前セグメントからなる[35]。たとえば、com.appview.fooは有効なNSIDの一例で、com.appviewがドメインオーソリティ、fooが名前セグメントである。
現在ネットワーク内で最もよく使われているlexiconは、Blueskyのマイクロブログスキーマを定義しているapp.bskyである[6]。
意見を持つサービス
意見を持つサービス（opinionated service）は、firehoseからのデータを処理して、コンテンツモデレーションやキュレーションの目的でネットワークデータに関する主観的な判断を提供するプロトコル内サービスである。これらのサービスは、リレーやApp Viewが意図的に「意見を持たない（unopinionated）」性質を持つのとは対照的である[3]。意見を持つサービスにより、ユーザーはプロトコルのコアコンポーネントの中立性を維持しながら、プロトコル内でのコンテンツ消費とモデレーションの設定をカスタマイズできる。
ユーザーはこれらのサービスをクライアントアプリ経由で（ユーザーの現在のApp Viewにハードコーディングされていなければ）いつでも購読または購読解除できる[28]。これらのサービスのモジュール性のおかげで、プロトコル内でのコンテンツのキュレーションとモデレーションに対して、カスタマイズ・積み重ね可能でユーザー中心のアプローチが可能になる[36]。
ラベラー
ラベラーは、スパムや不適切なメディアの識別など、ユーザーが生成したコンテンツに関する判断を提供する。ラベルは、投稿・画像・アカウントなど、ネットワークのさまざまな側面で適用できる。ラベラーの出力はApp ViewとPDSによって利用され、ユーザーにラベル付けされたコンテンツに対するさまざまな戦略（非表示にする、警告を付ける、画像をぼかすなど）を提供できるようになる[37]。
Bluesky Socialは内部で使われているモデレーションサービスのラベラー「Ozone」をオープンソース化しているため、ユーザーはこれを活用してネットワーク向けのカスタムのモデレーションサービスを作成できる[38][36]。
ラベラーはモデレーションサービスとして利用できるが、それ以外にも投稿のトピック、ユーザーの代名詞、ポジティブで楽しいラベルをユーザーのプロフィールや投稿に付けるなど、情報提供やエンターテイメントの目的で使うこともできる[39]。
フィードジェネレーター
フィードジェネレーターは、firehose内の投稿を処理してカスタムフィード内に含めることができる。PDSにクエリを送ると、ユーザーのApp Viewに投稿IDのリストが返されるため、このIDをキュレーションされたフィードを作成するのに利用できる[40][41]。
Remove ads
採用
プロトコルのリファレンス実装は、2022年5月4日にGitHub上でAuthenticated Data Experiment（ADX）という名前でMITおよびApacheライセンスのもとで公開された[42]。2022年10月にAT Protocolというブランドに変更された[43]。
AT Protocolは、Blueskyソーシャルネットワーク（これもBluesky Social PBCによって開発された）で採用されており、これが最も多く利用されている実装となっている。Blueskyは、Bluesky Social以外が運営している他のサーバーとのフェデレーション機能なしで立ち上げられたが、2024年2月下旬に他のPDSとのフェデレーションを開始した[44]。また、ニュースアグリゲータサービスのFlipboardを使用すると、ユーザーはBlueskyアカウントでログインして、サービスからの投稿を表示したり操作したりできる[45]。AT Protocolの導入を支援するために、Bluesky Socialはコンテンツのフェデレーションや作成にAT Protocolを使用するさまざまなプロジェクトに助成金を提供している[46]。助成金を受け取っている著名なアプリケーションには、SkyBridgeと呼ばれるプロキシサーバーがある。SkyBridgeは、MastodonアプリからのAPI呼び出しを同等のAT Protocol/Bluesky API に変換できるため、公式のプロトコルサポートがなくてもユーザーが両ネットワークに相互アクセスできるようになる[47]。
AT Protocolは、他のプロトコルと技術的に大きな類似点がない独立したプロトコルであるが、プロトコル間でコンテンツをブリッジできるサービスが開発されている。一例は、ActivityPubとAT Protocol間でコンテンツをクロスポストできるソフトウェアBridgy Fedである[48][49]。Nostrからの投稿は、NostrからActivityPubに投稿をクロスポストできる別のブリッジを介することで、AT Protocolに「ダブルブリッジ」することもできる[50]。
Remove ads
批判
ActivityPubプロトコルと、Bluesky Socialでは採用されなかったアーキテクチャの初期の内部提案の共同作者のクリスティン・レマー-ウェバーは、「Blueskyでは意味のある非中央集権化はされておらず、分散型ソーシャルネットワークの文脈でこれまで見られてきたフェデレーションの技術的な定義によれば、フェデレーションされていないことは明らかである。Blueskyが目指しているものを表現するのに適切な言葉は『credible exit（信頼できる出口）』である」と述べている。
関連項目
- 分散ソーシャルネットワーク向けソフトウェアおよびプロトコルの比較
- ActivityPub - Mastodonなどのサービスを支えている代替プロトコル
- Nostr - 類似のソーシャルネットワークプロトコル
- Secure Scuttlebutt
出典
参考文献
外部リンク
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads