ActivityPub を ATProto 上で動かす

運動政治の世界には、「トロツキストが一人いれば、一つの党ができる。二人いれば、二つの派閥ができる。三人いれば、党が分裂する」というジョークがあります。最近のオープンソーシャルメディア空間の雰囲気は、まさにそんな感じです。人々はどちらか一方を選び、それを擁護しなければならないと感じており、ヒョウ（ここでは対立する陣営）が互いを食い破るのを防ぐよりも、互いを食い合うことを好むのです。ある意味では、それは非常にソーシャルメディア的であり、また非常に愚かでもあります。このポーズの退屈さを和らげるために、皆が一緒に嫌悪できるような提案をしたいのです。あるいは、もっと真剣に言えば、建築的な詳細に少し注意を払うことが、それほど愚かなことではないかもしれないことを示す短い演習を行いたいと思います。これは、Web上のソーシャルメディアに関するより広範な議論の舞台を設定することになります。これは単なるスケッチであり、問題点もあります。当初はこれをプロトタイプにしたかったのですが、仕事の状況からプロトタイピングに使える帯域幅がほとんどありません（そのため、ほとんどのメモをこのブログに書き出しています）。デザイン上の挑発として考えてください。その挑発とは、比較的少ない作業で、AT Protocol PDS の上で ActivityPub を実行できるということです。どちらか一方、あるいは両方の現在の状態に変更を加えることなくそれができると皆さんを説得しようとはしませんが、なぜこれが考える価値のあることなのかに注意を向け、運が良ければ、私たちがその方向（たとえこの正確な組み合わせでなくても）に進むべきだと納得させたいのです。私がこれを考えた最初の人間ではないと信じるのは難しいのですが、何も見つけられませんでした。おそらく、私だけがこのアイデアを持つべきだと考えるかもしれません。まず理解すべきは、ATProto は Bluesky ではないということです。ATProto はソーシャルメディアアプリケーションを構築するための汎用的なツールボックスを意図しており、それは一般のパーソナルデータサーバー（PDS）のためのインフラストラクチャをサポートすることにまで拡張される（あるいは容易に拡張できる）と言えます。実際、ATProto のアーキテクチャは、明示的に PDS と、その PDS がユーザーエージェントであるという形で説明されています。Bluesky は、ATProto の上に Bluesky を実装する app.bsky API ルートの制御を維持する意向であることを明確にしていますが、com.atproto ルートはオープンスタンダードとして意図されていることも明確にしています。（これにはまだそれを保証するガバナンスがありませんが、私は許可を求める商売はしていません。）私がこの区別に注意を向ける理由は、ATProto が興味深い特性を持っているからです。特に、使用するサーバーに依存しないプラグ可能なIDと署名付きデータリポジトリのサポート方法です。これにより、権限はサーバー管理者（バニラフェデレーションの場合のように）ではなく、ユーザーの手の中に置かれます。これにより、常に信頼できるエグジットを保証でき、ロックインされることはありません。デフォルトでは、電子メールスタイルのフェデレーション（APの基盤となるモデル）は捕捉の対象となり、実際、電子メールは捕捉されています（約85%がGmailであり、移行はドメインレベルで行われるか、管理者の好意による転送を受け入れるかです）。しかし、ATProto 単体ではソーシャルメディア機能は何も提供しません。それは、プロトコルを実装できる「単なる」レイヤーです。これは、任意のプロトコルを実装するために使用できるという意味ではありませんが、ActivityPub/Activity Streams は、アクター文書という、それをはるかに容易にする非常に優れた間接参照を持っています。アクターとは、アクティビティを持つことができるエンティティであり、したがってソーシャル上で何かをすることができる存在です。アクター文書は、例えば私のMastodon IDのURLに.jsonを追加することで取得できます。ハンドルをDIDに解決し、DID文書に埋め込まれた情報を見つけることで取得することもできます。アクター文書には便利な機能があります。それは、さまざまな操作のためのAPIエンドポイントのURLを提供することです。つまり、API全体のエンドポイントが事前に決められた場所にあると期待するのではなく、各エンドポイントに対して任意のURLを指定します。私のMastodonアクター文書からいくつかの不要な部分を削除すると、次のようなものがいくつかリストされているのがわかります。 { "@context": "https://www.w3.org/ns/activitystreams", "id": "https://mastodon.social/users/robin", "type": "Person", "following": "https://mastodon.social/users/robin/following", "followers": "https://mastodon.social/users/robin/followers", "inbox": "https://mastodon.social/users/robin/inbox", "outbox": "https://mastodon.social/users/robin/outbox", "preferredUsername": "robin", "name": "Robin Berjon" } これは、ActivityPub ルートを持つ独自のアクター文書を、ActivityPub の間接参照として使用できることを意味します。たとえば、次のように ATProto PDS を指すことができます。 { "@context": "https://www.w3.org/ns/activitystreams", "id": "https://mastodon.social/users/robin", "type": "Person", "following": "https://pds.berjon.com/xrpc/org.w3.activitypub.following", "followers": "https://pds.berjon.com/xrpc/org.w3.activitypub.followers", "inbox": "https://pds.berjon.com/xrpc/org.w3.activitypub.inbox", "outbox": "https://pds.berjon.com/xrpc/org.w3.activitypub.outbox", "preferredUsername": "robin.berjon.com", "name": "Robin Berjon" } 成功か？まだ完全ではありません。問題に直面しました。 皆さんが座席の端で、爪を噛みながら、あるいは数人が真珠の首飾りを握りしめながら、少しのJSONのいじくりとATProtoアプリで、どちらの仕様も変更せずにActivityPubをATProto上で実行できるのか聞きたがっているのを承知しています。答えは「まだ完全ではないが、橋渡しできないほど遠いわけでも、非現実的でもない」です。最初の問題は、XRPC nsid（例: org.w3.activitypub.inbox）はクエリ（GET）またはプロシージャ（POST）のいずれかですが、私の知る限り、両方にはなれません。しかし、ActivityPub の inbox プロパティは複数のメソッドをサポートする必要があります。REST 対 RPC に関する永続的な議論（やれやれ）はさておき、これは橋渡しするための大きな問題ではありません。アクター文書は、異なるメソッドのために（非ATProto実装では同じURLを指すことができる）別々のプロパティで更新されるか、XRPC Lexicon がオーバーロードされたメソッドをサポートするように変更されるかのどちらかです。ここでの橋渡しを妨げている唯一のことは、人々がこの決定に対して宗教的になることです。実世界では、比較的簡単な修正です。第二の問題は、IDとハンドルシステムが完全に一致していないことです。com.atproto.identity.resolveHandle が @robin.berjon.com を解決するのと同じように @robin@mastodon.social を解決することを妨げるものは何も無いと私は信じています。単に先頭の @ を削除し、他の部分をピリオドに置き換えて、DNS を使用して DID を解決するだけかもしれません。これは、アクターが独自のドメインを持つ（ATProto ユーザーには比較的よくある）IndieWeb ActivityPub とも互換性があります。アクター文書が DID を指すことも可能であり、DID 文書が念のためそれにリンクバックすることもできるはずです。（DID の制限や、特に did:plc の問題には触れません。それらは統合には影響しないからです。DSNP が DID メソッドの適切な基盤を提供するのではないかと考えていますが、それはまた別の機会のトピックです。）そして…それだけです？私がこれをエンドツーエンドで実際に実装する機会がなかったため、おそらくいくつかの落とし穴を見落としていると bet します。しかし、最初の印象では、オンラインでの激しい議論から想像されるよりも、これは実現可能です。なぜこれをするのか？ 圧倒的に、私たちのソーシャルメディアの経験はサイロ化されています。それらは、あなたを内部に留めるように設計された閉鎖的な環境であり、世界の他の部分との統合が非常に貧弱です。Activity* 標準と ATProto は、異なる方法でこのサイロ化を破ります。Activity* は URL を中心に構築されており、Web 上のほとんどあらゆるものを「ソーシャル化」できますが、それは素晴らしいことです。しかし、それらは基盤となるサブストラクチャには触れません。期待されるのは、自分でサーバーを実行するか（これは誰にでもできるわけではありません）、あるいはフェデレーションサーバーに参加する必要があるかのどちらかであり、それはあなたを管理者のなすがままにすることになり（そして、残念ながら一部の人々が経験しているように...）