BlueskyがActivityPubを採用しなかった3つの理由

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

Q. BlueskyはなぜActivityPubを採用しなかったのか

A. 一言で言うなら時代がそれを許さなかった

Twitterのメタクソ化と分散型SNS

Elon Musk氏によるTwitter（現X）の買収後、サードパーティーアプリの排除やインプレゾンビの発生など、さまざまな改悪が行なわれました。このような巨大プラットフォームの品質低下は「メタクソ化」と呼ばれます。

メタクソ化とは、元々有益だったサービスが時間の経過とともに利益追求を優先し、ユーザーにとって不便で使いにくくなる現象を指します。ユーザーはそのプラットフォームで築き上げた関係性（ソーシャルグラフ）を人質に取られているため、改悪が行なわれても他のプラットフォームへ移行できません。

プラットフォームはこのように滅びていく。まず、ユーザにとって良き存在になる。次に、ビジネス顧客にとって良き存在になるために、ユーザを虐げる。最後に、ビジネス顧客を虐げて、すべての価値を自分たちに向ける。そうして死んでいく。

Cory Doctorow, "Tiktok's enshittification"¹

近年、メタクソ化が進むTwitterの代替として「分散型SNS」が注目されています。分散型SNSとは、複数の運営者によって非中央集権化・分散化²されたソーシャルメディアです。これらのSNSは共通のプロトコルを使用します。

もっとも有名な共通プロトコルは「ActivityPub」です。ActivityPubを実装したSNSには「Mastodon」「Misskey」「Threads³⁴」などがあります。

画像：フェディバースのイメージ図

これらのSNSで相互接続された空間は「フェディバース⁵」と呼ばれ、異なるSNSのユーザーどうしでやりとりが可能です。例えば、mstdn.jpのユーザーがmisskey.ioのユーザーをフォローしたり、リプライを送れます。そのため、ユーザーはフェディバースの中から自分の好みに合う運営を選び所属できるのです。

BlueskyとAT Protocol

最近「Bluesky」というSNSが話題です。

Blueskyは、Twitterに似たマイクロブログ型のSNSです。

2024年9月には登録者数が1000万人を突破し、10月の月間アクティブユーザー数はフェディバース全体の4倍に達しました。³⁶日本人も多く、今年8月の国別統計では日本からのユーザーが一番多かったようです。⁷

このSNSは、もともとTwitterの社内プロジェクトとして始まりました。当初の目的は、Twitterが将来的に使用する分散型SNSのプロトコルを開発することでした。しかし、2022年後半にTwitter社との契約が解消されたため、Blueskyは独自のSNSとして新たな道を歩むことになったのです。

Blueskyは分散型SNSですが、プロトコルには「ActivityPub」ではなく「AT Protocol」を採用しています。このため、フェディバースと互換性がなく、MastodonやMisskeyとは直接連合できません。⁸

なぜBlueskyはActivityPubを採用しなかったのか？

なぜBlueskyはフェディバースとの互換性を犠牲にしてまで、新しいプロトコルを作る必要があったのでしょうか？

まずは公式の説明を確認しましょう。

ActivityPub を使用しないのはなぜですか?

アカウントのポータビリティは、別のプロトコルを構築することを選択した主な理由です。ポータビリティは、突然の禁止、サーバーのシャットダウン、ポリシーの不一致からユーザーを保護するため、非常に重要であると考えています。ポータビリティのソリューションには、署名済みデータ リポジトリ と DID の両方が必要ですが、どちらも ActivityPub に後から簡単に組み込むことはできません。ActivityPub の移行ツールは比較的制限されており、元のサーバーがリダイレクトを提供する必要があり、ユーザーの以前のデータを移行することはできません。

もう 1 つの大きな理由は、スケーラビリティです。ActivityPub は、小規模から中規模のノードの広範なネットワーク間でメッセージを配信することに大きく依存しているため、個々のノードにトラフィックが殺到し、アクティビティのグローバル ビューを提供するのが困難になることがあります。AT プロトコルは、集約アプリケーションを使用してユーザーのホストからのアクティビティをマージし、全体的なトラフィックを削減して、個々のホストの負荷を大幅に削減します。

https://atproto.com/ja/guides/faq

・
・・
・・・？

なかなか難しいことを言っていますが、要約すると以下の理由が挙げられます。

• ActivityPubには「グローバルビュー」がない
• ActivityPubには「アカウントポータビリティ」がない
• ActivityPubには「スケーラビリティ」がない

しかし、なぜこれらが問題になるのでしょうか？

この3要素が欠けていることで、フェディバースではどのような課題が生じているのでしょうか？

この記事では、現在のフェディバースで発生している問題を深堀りし、BlueskyがActivityPubを採用しなかった背景を考察します。

ActivityPub / フェディバースの概要

ActivityPub

ActivityPubは、W3Cによって標準化された非中央集権型ソーシャルネットワークのプロトコルです。⁹MastodonやMisskeyでは、このプロトコルを使用してサーバー間で連携します。

ActivityPubによる連合の仕組みは、Eメールの動作に似ています。各アクター（ユーザー）は、世界中からのメッセージを受け取る場所である「Inbox」を持っています。ユーザーが相手のInboxへメッセージを配送することで、異なるサーバー（インスタンス）間での連合が実現します。¹⁰¹¹

具体的に、ユーザーAが新しく投稿した場合の流れを追ってみましょう。

ユーザーAは、他のサーバーに所属するB, C, Dからフォローされています。Aが投稿すると、その投稿はB, C, DのInboxに送信（POST）されます。B, C, Dは自分のInboxを確認（GET）してAの投稿を閲覧できます。

このように、ActivityPubではアクションを起こしたユーザーが相手のInboxにアクティビティを配送する仕組みになっています。まるで、BCCを大量に指定したEメールのようといえるでしょう。

なお「Shared Inbox」という仕組みがあるため、あるサーバーに所属する複数のユーザーからフォローされていても、そのサーバーへの配送は一度で済みます。

ここまでActivityPubの概要について説明しましたが、実はこの仕様を理解しただけではフェディバースと連携できません。なぜなら、W3Cが定めるActivityPubの仕様は基本的な部分しかカバーしておらず、詳細についてはMastodonなどの既存の実装に依存しているためです。

そのため、現在のフェディバースには全員が従う単一の標準規格が存在せず、さまざまな独自の動作や拡張機能が多数存在する状況となっています。¹²

分散型SNSでは一度投稿した内容を消せない？

Mastodonでは、ユーザーAが投稿すると、それを受け取ったB、C、Dの所属するサーバーに投稿のコピーが保存されます。これは、ユーザーがホームタイムライン（HTL）を表示する際に必要となるためです。

したがって、連合しているサーバーは同じ投稿を重複して持つことになります。例えば、ユーザーAが1000個のサーバーからフォローされている場合、Aの投稿は1000個に複製されて保存されます。投稿が他のサーバーからがブースト（リポスト）されると、そのサーバーにもコピーされます。

投稿を削除する際には「Delete」アクティビティを送信し、各サーバーに削除を依頼します。しかし、この削除リクエストが見逃された場合は、そのサーバーには投稿が残ります。

このような理由から「分散型SNSでは一度投稿した内容を消せない」と言われることがあります。¹³

ドメインブロック

ドメインブロックは、特定のドメイン（サーバー）からの通信を制限する機能です。ActivityPub自体にはこの機能に関する具体的な仕様はありませんが、多くのActivityPub対応ソフトウェアで実装されています。

無制限にコンテンツを受け入れると、悪意あるサーバーからスパムや違法コンテンツが流入してしまいます。このリスクに対処するため、ドメインブロックが活用されます。

画像：pawoo.netやmisskey.ioは、多くの海外サーバーからドメインブロックされている

Mastodonでは、以下の3つの方法でドメインブロックを実行可能です。

• メディア拒否（Reject media）
  • 対象サーバーからのメディアファイルを拒否します。
• リミット（Limit）
  • 対象サーバーのすべてのユーザーを非表示にします。ユーザーは検索、メンション、フォローを通じて見つけるられますが、コンテンツは公開されません。
• サスペンド（Suspend）
  • 対象サーバーのすべてのアカウントとの連携を停止します。いわゆるBANです。

その他

ローカルタイムライン

ローカルタイムライン（LTL）はActivityPubの仕様に定義されておらず、必須の機能ではありません。フェディバースとの親和性の高さから多くのサーバーで実装されていますが、LTLを持たないものも存在します。例えば「Fedibird」にはLTLがありません。

アカウントポータビリティ

MastodonやMisskeyでは、あるサーバーから別のサーバーに引っ越しが可能です。ただし、この機能はあくまで独自実装であり、一部の対応しているSNSでしか使用できません。例えば、MastodonとThreadsの間でアカウントの移行はできません。

アカウントを移行させるためには、元のサーバー管理者の協力が不可欠です。管理者がユーザーの移行に対して非協力的な場合や、元サーバーの運営が終了している場合、移行はできません。

Big Fedi と Small Fedi

ActivityPubを実装したSNSどうしの連合を「フェディバース」と呼びます。⁵

フェディバースの立ち位置に関する分類として、ActivityPubの共同著者であるEvan Prodromou氏は「Big Fedi」「Small Fedi」の2つの立ち位置があるとしています。

Big Fedi

フェディバースはもっと大きくあるべきです。本当に大きく。地球上のすべての人がフェディバースにアカウントを持つべきです。そうすればインターネットも世界もより良くなるでしょう。

商用アカウント サーバーは歓迎です。この多様性には商用サービスも含まれます。特定のユーザーが望む機能とトレードオフの適切な組み合わせを提供する場合は、特にユーザー数が多い場合は、そうしたサーバーを用意しておくと良いでしょう。

アカウント サーバーは大規模になることがあります。規模は関係ありません。100 万、1,000 万、1 億、10 億人でも問題ありません。

フェディバースには二次的なサービスが必要です。成長するためには、人材検索、オンボーディングツール、グローバル検索、ブリッジなどの二次的なサービスが必要です。

Small Fedi

フェディバースは安全でなければなりません。嫌がらせやプライバシー侵害から安全でなければなりません。

商用アカウント サーバーは推奨されません。商用サービスのほとんどは害を及ぼします。たとえフェディバース上にあるとしても、より多くのお金を稼ぐために害を及ぼそうとします。したがって、可能な限り避けるべきです。

アカウント サーバーは小さくなければなりません。人間のモデレーターが実行できる作業量には限りがあるため、モデレーターが管理するアカウント サーバーのサイズも限られています。

https://evanp.me/2023/12/26/big-fedi-small-fedi/

「Big Fedi」は、フェディバースがTwitterに代わる主要なSNSとして成長することを望む立場です。

一方「Small Fedi」は、フェディバースが小規模であることを重視する立場です。その特性を活かして、Twitterで見られるような嫌がらせやトラブルを避け、安全で安心できるコミュニティとしての役割を重視します。

BlueskyはActivityPubの採用を検討していた

Blueskyは最初から独自プロトコルを開発する方針だったわけではなく、既存プロトコルの採用も検討していました。

例えば、Blueskyの代表であるJay Graber氏は、2020年にActivityPubを採用するプロポーザルを提出しています。¹⁴

しかし、最終的にBlueskyは独自のプロトコルを開発する方向に舵を切りました。なぜBlueskyはActivityPubの採用を見送ったのでしょうか？

その理由は、冒頭で挙げた「グローバルビュー」「アカウントポータビリティ」「スケーラビリティ」という3つの要素が関係しています。

ActivityPubは、小規模なフェデレーション（Small Fedi）ではとても優れたプロトコルです。しかし、ネットワークの規模が広がり大規模なフェデレーション（Big Fedi）になると、以下の問題が発生します。

1. グローバルビューの欠如による「サイロ化」
2. アカウントポータビリティの欠如による「中央集権化」
3. スケーラビリティの欠如による「ボトルネックの発生」

理由1：グローバルビューの欠如による「サイロ化」

グローバル検索性

フェディバースがTwitterのような情報インフラとして機能するためには、トレンドトピックやサーバーを横断した検索機能といったグローバルビューが不可欠です。しかし、現在のフェディバースには全体トレンドがなく、異なるサーバー間での検索にも制約があります。

ActivityPubに対応したソフトウェアでは、通常、サーバー内にコピーが存在する公開投稿のみが検索可能です。つまり、フォローやブースト（リポスト）によって自分の所属するサーバーに配信された投稿以外は検索できません。¹⁵

ユーザー検索も不便です。たとえば、誰かがフェディバース上で私（boobam）のアカウントをフォローしたい場合を想像してください。私はmisskey.ioにアカウントを持っていますが、リモートフォロワーがいないため、他サーバーから「boobam」で検索しても結果に表示されません。

画像：フォロワー数2の男の末路

私のアカウントをフォローするには、なんらかの方法でハンドルを特定し、照会する必要があります。

クローリングに対する文化的抵抗

ここまでの話を読んで「フェディバースの全投稿を収集して検索できるようにした『フェディバース検索』のようなサービスを誰かが作ればいいのではないか？」と考える人もいるでしょう。

しかし、そのようなサービスは決して作ってはいけません。なぜなら、現在のフェディバースには投稿を無断で収集する行為（クローリング）に対する強い文化的抵抗があるからです。

特に海外のフェディバースコミュニティでは、オプトアウト方式（デフォルトで全投稿収集）を決して認めず、オプトイン方式（希望者のみ収集）のみを許容する動きが強いです。過去にオプトアウト方式の検索サービスを提供した人々は強い批判にさらされ、サービス終了に追い込まれています。

Bridgy Fedの炎上

Blueskyとフェディバースを繋ぐ「Bridgy Fed」というプロジェクトがあります。¹⁶このサービスは、ActivityPubとAT Protocolという異なるプロトコルを橋渡しし、双方のSNSを連携可能にします。Blueskyチームは、この取り組みを歓迎し、好意的に受け止めていました。¹⁷

当初、Bridgy FedはデフォルトですべてのBlueskyアカウントとフェディバースアカウントを連携し、希望者のみが個別に解除できる「オプトアウト方式」で進める予定でした。

しかし、この方針がオプトアウトを嫌う海外のフェディバースコミュニティの目に留まり、Bridgy Fedの該当Issue¹⁸には罵詈雑言が寄せられました。その結果、プロジェクトはオプトイン方式に変更されました。

わざわざオプトインして連携を有効にするユーザーは少数であり、これではブリッジサービスとしての意義は薄いです。こうして、AT ProtocolとActivityPubをブリッジするという壮大な試みは、実質的に無意味なものとなってしまったのです。

もしBlueskyがActivityPubを採用していたら？

このようなフェディバースの文化的背景を考慮すると、もしBlueskyがActivityPubを採用していたとしてもグローバルビューを追加するような拡張は難しかったでしょう。

この件について、BlueskyチームのPaul Frazee氏は以下のように述べています。

「私たちは、ActivityPubコミュニティが情報の集約についてどう感じているかを見て、私たちの前提をコミュニティに受け入れてもらうのが難しいだけでなく、それを試みることさえコミュニティに対して敵対的な行動と見なされるかもしれないと判断しました」

We saw how the AP community felt about aggregation and we decided, not only would it be difficult to get our premise to be accepted by the community, it might honestly be hostile of us to even try.

— Paul Frazee (@pfrazee.com) 2023年5月4日 11:43

Q.技術上は可能なのであれば、大した問題ではないのでは？

グローバル検索性の低さは、技術的な制約ではなく文化的な問題であるところが大きいです。そのため、将来的には改善されるだろうと楽観視する意見もあります。

しかし、フェディバースが真に「非中央集権」であるならば、一度確立された文化を変えることは非常に難しいはずです。

日本におけるエスカレーターの片側空けの例を考えてみましょう。このような文化を変えるには、条例による規制といった「中央集権的」な介入が必要です。

一方フェディバースは「非中央集権型」のネットワークとされています。中央集権的な権力が存在しないため、強制的な変更は難しいはずです。¹⁹

理由2：アカウントポータビリティの欠如による「中央集権化」

ActivityPubは、自身を「非中央集権型ソーシャルネットワークプロトコル」であるとしています。はたして、フェディバースはBig Fediにおいても非中央集権性を保てるのでしょうか？

一極集中

フェディバースの既知の問題として「一極集中」が知られています。

フェディバースでは各サーバーの独立性が高いため、異なるサーバーに所属するユーザーは同じ体験を得られません。ローカルタイムラインの存在や、前述したグローバルビューの欠如もこれを助長します。

また大手サーバーは優れたインフラとコンプライアンスを提供できる一方で、零細サーバーの運営者はBOFH（ユーザーに対して寛容でない嫌な管理人）として振る舞うことがあり、たびたび問題になります。²⁰

このような理由から、ユーザーは大手サーバーに一極集中します。特に、影響力を求めるインフルエンサーや公式アカウントは大手サーバーに所属する傾向があります。その結果、ユーザーの分布はパレート分布に近づきます。

実際に2019年の調査では、上位5％のサーバーに90.6％のユーザーが集中していることが判明しました。²¹

中央集権化

一般的に、ActivityPubによる連合はフルメッシュ型のトロポジーで表現されます。

画像：フェディバースのシンボルとして広く使用されている図

しかし、これはフェディバースが小規模な場合に限られます。フェディバースが拡大するにつれて、一極集中によりサーバー間の力関係は不均衡になります。

このような状況では、人々は主に以下のユーザーをフォローします。

• 同じサーバーに所属する気の合う仲間
• 大手サーバーに所属するインフルエンサーや公式アカウント

つまり、他サーバーへのフォローは大手サーバーばかりに偏るので、連合の実態はスター型トポロジーに近づきます。

ここで問題なのは、依存関係が一方向であることです。

大手サーバーと零細サーバーは対等な関係ではありません。大手が零細の投稿を見られなくなっても影響は少ないですが、零細が大手のインフルエンサーや公式アカウントを閲覧できなくなると、ユーザー体験に大きな影響を与えます。

むしろ、大手サーバーにとって小規模サーバーとの連合は余計なコストです。零細サーバーから大量にフォローされると配送の負荷が上がりますし、投稿に対するモデレーションコストも増えます。

Twitter APIとの違いは？

ところで、この一方向の依存関係で、依存される側に直接的な利益がないという構図、どこかで見覚えがありませんか？

そう、APIに制限を加える前のTwitterです。

Twitterがサードパーティークライアントを締め出したように、Big Fediでは大手サーバーが零細サーバーをドメインブロックして締め出すことが可能なのです。

Mastodonのドメインブロックでは、メディア制限やリミットといったサスペンドよりも穏当な手段も用意されています。しかし、ビジネス上のメリットがないのであれば、これらを使うかどうかは大手サーバーの「良識」次第です。大手の「良識」に依存するのであれば、それはTwitterのような中央集権型SNSが提供するAPIと本質的には変わらないのではないでしょうか。

スパム騒動

この懸念が現実になったのが、2024年2月に発生したフェディバースのスパム騒動です。

この事件では、放置されたMisskeyやMastodonのサーバーにスパムアカウントを作成し、そこから大量のメンションをとばすという攻撃が行なわれました。そのため、サーバーを個別に確認してドメインブロックする方法では対応が追いつかず、サーバー管理者たちは頭を悩ませました。

対策として、一部のサーバーは連合をホワイトリスト制に移行しました。つまり、大手サーバーには連合を許可する一方で、自分達より小規模なサーバーに対しては問答無用でドメインブロックを行なったのです。

このような非対称性が現れるのは、フェディバースに「大手サーバーが"暗黙の"権力を持つ」という構造があるからです。

分散型である意義

中央集権化が進むと、分散型である意義が薄れてきます。

なぜなら、零細サーバーは大手サーバーからのドメインブロックを恐れ、独自のモデレーション基準を設定しづらくなるためです。もし、大手に毛の生えたレベルのモデレーションしか行なえないのであれば、複数のインスタンスが存在する意義は何なのでしょうか？

単にコミュニティごとの集まりを形成したいだけならば、中央集権型のSNSで十分です。Discordや5chは中央集権型のプラットフォームですが、ルームや板ごとに多様なコミュニティが形成されています。

Q.企業の公式アカウントが独自にサーバーを建てれば、中央集権化を防げるのではないか？

Twitterで災害情報を配信している「特務機関NERV」は、フェディバース上に自社のサーバーを設置して情報を発信しています。²²このように、企業が自前のサーバーから情報を発信する流れが広がれば、中央集権化を防げるのではないでしょうか？

しかし、この考えは非現実的です。なぜなら、大手サーバーに所属するほうが圧倒的に多くの人に情報を届けることができるからです。

仮に、この世のすべてのSNSがActivityPubの配送に対応したとしましょう。NERVは現在のTwitterアカウントを閉鎖して、自社サーバーからの情報発信のみに切り替えられるでしょうか？

結論としては、できません。自社サーバーからの発信だけではインプレッションを稼げず、大手サーバーにアカウントを持つ競合他社に負けてしまうでしょう。現在NERVが自社サーバーから配信できているのは、Twitterという中央集権型SNSで十分な注目を集められているからに他なりません。

インフルエンサーや企業の公式アカウントにとって、多くの人にリーチでき、運用コストも抑えられる大手サーバーから離れるメリットはほとんどありません。

Q. タイプが異なるソーシャルメディアどうしであれば、中央集権化しないのではないか？

異なる機能を持つ「マイクロブログ」と「長文ブログ」のようなサービスであれば、ユーザーが両方を利用することで依存関係が生まれにくく、中央集権化を避けられるという考えもあるでしょう。

しかし、異なるタイプのソーシャルメディアが連携する場合、新たな問題が発生します。

例えば、このブログがActivityPubに対応していると仮定します。ブログ記事をそのまま配信してもよいですが、MastodonのUIではブログ画像が適切な位置に表示されず、レイアウトが崩れます。そのため、配信内容はブログのタイトルとURLに限定し、ユーザーには直接ブログにアクセスしてもらう方法が適切です。

画像：このブログがActivityPubに対応した際の配送内容イメージ

このように、異なるタイプのソーシャルメディアが連合する場合は、一方のUIに合わせたコンテンツ配信が求められます。フェディバースではマイクロブログが中心であるため、ブログ側が妥協し、RSSのような更新通知の提供に徹するでしょう。

こうした状況では、マイクロブログ側が優位となり、他の形式のソーシャルメディアは従属的な立場になります。結果として依存関係は一方向となり、中央集権化します。

理由3：スケーラビリティの欠如による「ボトルネックの顕在」

ActivityPubは、スケールしないことで知られています。具体的に、システムのどの部分がボトルネックとなるのでしょうか？

Mastodonでは、アクティビティを他サーバーへ配信するために「Sidekiq」というバックグラウンドジョブフレームワークと「Redis」というインメモリデータベースを使用しています。

画像：https://softwaremill.com/the-architecture-of-mastodon/

ActivityPubは、このアクティビティを配送するPubSub機構にスケールラビリティの問題を抱えています。他サーバーからのリモートフォローが増えると配送ジョブの負荷が高まり、ボトルネックが発生するのです。

例えば、2022年のTwitter買収時には数万人の新規ユーザーがフェディバースに参加し、多くのサーバーでSidekiqのキューが詰まってしまいました。²³

最近の話だと、ActivityPubに対応したCMS「Ghost」の公式ブログでは、5000人のフォロワーにニュースレターを配送するのに10台のサーバーが必要であったことを報告しています。²⁴

なぜ、このような問題が発生するのでしょうか？

わかりやすい例えがあったので、そのまま引用します。

たとえば、10,000 台のサーバーに 50 万人のフォロワーがいる人を想像してください。このようなユーザーが投稿するたびに、10,000 の Sidekiq ジョブが作成されます。インタラクションごとに、さらに 10,000 の Sidekiq ジョブが作成されます。投稿が人気になり、短期間で 1,000 件のお気に入り (その人のフォロワー総数の 1/500) を獲得すると、10,000,000の Sidekiq ジョブになります。

https://softwaremill.com/the-architecture-of-mastodon/

なお、このスケーラビリティの低さはMastodonの実装が原因ではなく、ActivityPubという「全対全通信」を基本とするプロトコルそのものが抱えた根本的な問題であるとの指摘があります。²⁵

もしBlueskyがActivityPubを採用していたら？

2024年8月末、ブラジル最高裁判所がXのサービス停止を命じたことを受け、Blueskyに多くのユーザーが流入しました。この結果、ユーザー数は1週間で200万人増加し、ピーク時には通常の20倍のトラフィックが発生しました。

急激なトラフィックの増加により、一部のサードパーティー製フィードが停止するなどの不具合が発生しました。²⁶しかし、Bluesky社が提供するインフラについては、この負荷に耐えることができました。

もしBlueskyがActivityPubを採用し、全ユーザーをフェディバースに接続していたら、スケーリングの限界に達していた可能性があります。

BlueskyのテクニカルアドバイザーであるWhy氏は「もし260万人のユーザーがMastodonに参加しようとしたら、完全に機能しなくなるだろう」と述べています。

ActivityPub can't scale, if 2.6 million users decided to join mastodon it would have fallen over dead

— Uai (@why.bsky.team) 2024年9月6日 7:37

負のループ

ところで、負荷が高まる条件の「複数サーバーからリモートフォローされる人気ユーザーを多数抱えるサーバー」という構図、どこかで見覚えがありませんか？

そう、2つ目の理由で挙げた「中央集権化した大手サーバー」そのものです。

今回挙げた3つの理由は密接に関連しており、結果として負のループが形成されます。

1. グローバルビューの欠如により、サーバーのサイロ化が進む
2. 異なるサーバー間で同じ体験が得られないため、ユーザーは大手サーバーに集まる
3. 大手サーバーはスケールするために多大なコストを負担する。連合投稿の保存やモデレーションにも大きな負担がかかる
4. コスト削減のため、他サーバーへの配送を制限し、一極集中をさらに促進する

実際、最近のmisskey.ioではコスト削減のために連合の制限を検討しているようです。

月49億リクエスト捌くのに今の金額じゃ厳しいから今後本格的に連合について制限かけていかないといけないかもなぁ

— 村上さん (@AureoleArk) 2024/10/2 21:13:26

Threadsによるロックイン

「他サーバーへの配送を制限」という話が出たので、少しThreadsについても触れておきましょう。

最近のThreadsは、いくつかの不穏な動きを見せています。

連合の制限

Threadsはデフォルトでフェディバースとの接続が無効化されています。ユーザーがフェディバースと連携するには、自ら設定を変更してオプトインする必要があります。そのため、執筆時点ではほとんどのThreadsアカウントがフェディバースに接続されていません。

2024年8月末のデータによると、Fedibirdに認識されているアカウント数は「mastodon.social」が約136,000「misskey.io」が約85,200であるのに対し「Threads」はわずか4,374でした。²⁷

APIの制限

2024年6月に公開されたThreadsのAPI²⁸は、基本的に書き込み専用です。Read系APIは意図的に制限されており、サードパーティークライアントが作成できないようにされています。Metaは今後もこの方針変える予定はないそうです。²⁹

非公式APIへの警告

過去にはThreadsのクライアントをリバースエンジニアリングし、非公式APIを使用してサードパーティークライアント作成するプロジェクトも存在しました。しかし、Metaはこれに対して弁護士を通じて警告文書を送りつけ、プロジェクトを停止に追い込んでいます。³⁰

---

このように、Metaは自社サービス外のユーザーに対して、Threadsと同じユーザー体験ができなくなるように仕向けています。ユーザーをロックインし、Threadsから離れられないようにしているのです。

彼らは非中央集権型のSNSを運営する気などハナからなく、単にTwitterからユーザーを奪い取る手段として「分散型SNS」のお墨付きが欲しかっただけなのではないでしょうか？

そうとでも考えなければ、ActivityPubへの対応とサードパーティークライアントの排除という矛盾した行動への説明がつきません。

こうして、MisskeyHQのような中小企業はコスト上の理由から、Metaのようなビッグテックは囲い込み戦略のために連合機能を制限していくのです。

フェディバースのなにがいけなかったのか？

「ユーザビリティ」と「非中央集権性」がトレードオフの関係になっている

フェディバースでは、大手サーバーに所属することで高いユーザビリティを享受できますが、その代わりに特定のサーバーに依存するリスクがあります。

一方個人や小規模サーバーに参加すると分散化できますが、グローバルビューの欠如や大手サーバーからの不利な扱いにより、ユーザー体験が損なわれます。

その結果、人々はユーザビリティを優先し、大手サーバーに集中します。本来は、ユーザーが自身の効用を最大化するよう行動しても、非中央集権性が得られる仕組みにするべきでした。

「理念」と「アーキテクチャ」が一致していない

ActivityPubには「Shared Inbox」という仕組みがあります。これにより、あるサーバーに所属する複数のユーザーからフォローされている場合でも、そのサーバーへの配送は一度で済みます。

つまるところ、ActivityPubというプロトコルは、分散すればするほどパフォーマンスが低下します。スケーラビリティの観点から見ると、多くのユーザーが1つのサーバーに集まるほうが効率的です。

これは分散を推奨するフェディバースの理念と矛盾しています。

分散が目的化している

分散化は本来手段であり、その目的は他にあるべきです。

「コミュニティの形成」が目的であれば、それを解決する手段は本当に分散でよいのでしょうか。Misskeyにおけるチャンネル機能のように、1つのサービス内でコミュニティを作れば済む話ではないでしょうか？

「メタクソ化しないSNS」の作成が目的であれば、それを解決する手段は本当に分散でよいのでしょうか。最初にサーバー選択の自由が与えられても、その後ロックインされてしまっては意味がありません。

一部のフェディバース支持者は、反中央集権を重視するあまり、分散そのものを目的としてしまっているように見えます。

前編のまとめ

現在のフェディバースでは規模が拡大するにつれて、以下の問題が発生します。

• グローバルビューの欠如による「サイロ化」
• アカウントポータビリティの欠如による「中央集権化」
• スケーラビリティの欠如による「ボトルネックの顕在」

したがって、Blueskyが目標とするBig Fediは実現しません。「Threads」が事実上の中央集権型SNSとしてTwitterの代替になれる可能性はあっても、「ActivityPub連合」がTwitterに取って代わることは難しいでしょう。

ActivityPubというプロトコル自体は、小規模なフェディバース（Small Fedi）で利用する限り決して悪いものではありません。あくまで大規模な環境での使用には適していないという話です。

これは、ActivityPubが設計された背景に由来しています。フェディバースの歴史を振り返ると、その前身であるOStatusや2009年に登場したStatusNetまで遡ることができます。

当時のSNSは、現在のようなビッグテックによる支配を想定しておらず、共通の通信プロトコルがあればすべてのSNSが統合できると考えられていました。

ある意味、ソーシャルメディアというものが当時の想定を超えて巨大化してしまったのです。

まさに、BlueskyがActivityPubを採用できなかった理由は「一言で言うなら時代がそれを許さなかった」といえるでしょう。

中編「AT Protocol入門：プロトコルの背景にある考えを理解する」につづく……

---

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

Footnotes

1. https://pluralistic.net/2023/01/21/potemkin-ai/ 日本語訳： https://p2ptk.org/monopoly/4366 ↩

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

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

3. Threadsは、デフォルトでフェディバースでのシェアが無効になっています。ユーザーがフェディバースと連携するには、自ら設定を変更してオプトインが必要です。そのため、この記事の執筆時点（2024/10/07）ではThreadsの大半のアカウントはフェディバースに接続されていません。 ↩ ↩²

4. この記事の執筆時点（2024/10/07）で、ThreadsのActivityPub対応には以下の制限があります。

   • フェディバースでのシェアはデフォルトでOFFになっています。フェディバースへ接続するには、設定→アカウントから「フェディバースでのシェア（ベータ）」をONにする必要があります
   • 居住区がヨーロッパ地域のユーザーはフェディバースでのシェアをONにできません
   • Threadsからフェディバースの投稿を見られません
   • Threadsからフェディバースアカウントへのフォローはできません
   • Threadsからフェディバースアカウントへのリプライ・返信はできません
   • Threadsからフェディバースのユーザーを検索できません
   • Threadsからフェディバースへの配送は常に15分遅延する仕様です。そのため、同時実況のようなリアルタイムな体験はフェディバース外と共有できません
   ↩

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

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

6. 執筆時点（2024/10/07）で、フェディバースは約120万MAU、Blueskyは約520万MAUです。なおfedidbはMisskeyがカウントされないため、+20万として見積もっています。 ↩

7. https://bsky.app/profile/bnewbold.net/post/3kzcvdtdehr2t なお2024/10/07現在はブラジル（ポルトガル語）が圧倒的1位です。 ↩

8. Bridgy Fedというブリッジサービスを使用することで、ActivityPubとAT Protocolの間での連合が可能になります。 ↩

9. https://www.w3.org/TR/activitypub/ ↩

10. ActivityPubにはクライアントからサーバーへのプロトコル（C2S）に関する仕様もあるのですが、ほとんど使われていないのでこの記事では触れません ↩

11. その人が投稿したメッセージを確認できる「outbox」も定義されていますが、話がややこしくなるのでこの記事では触れません ↩

12. この状況を改善するため、FEP（Fediverse Enhancement Proposals）やSWF（Social Web Foundation）という取り組みもあります。 ↩

13. 私見としては、これは連携するシステムの多寡の問題であり「分散型SNSでは〜」という表現は不適切と考えます。Twitterのような中央集権型のSNSでも、API連携を通じて外部システムが削除済みのコンテンツを保持し続ける可能性はあります。 ↩

14. https://gitlab.com/-/snippets/2535398 ↩

15. Mastodon系ソフトウェアにはさらに強い制約があり、公開投稿でも全文検索を許可していないアカウントの投稿は検索対象となりません。 ↩

16. 厳密に言うと、Bridgy Fedはもともとフェディバースとウェブサイトをつなぐサービスとして存在しており、そこにBlueskyへの対応が追加されたという流れです。 ↩

17. https://bsky.app/profile/bnewbold.net/post/3kfbcderomr27 ↩

18. https://github.com/snarfed/bridgy-fed/issues/835 ↩

19. とはいえ、私は「理由2」によりフェディバースが真に非中央集権であるとは考えていません。 ↩

20. https://web.archive.org/web/20230713014738/https://anond.hatelabo.jp/20230713050627 ↩

21. https://emilianodc.com/PAPERS/mastodonIMC19.pdf ↩

22. https://unnerv.jp/@UN_NERV ↩

23. https://nora.codes/post/scaling-mastodon-in-the-face-of-an-exodus/ ↩

24. https://activitypub.ghost.org/beta-plans/ ↩

25. https://gist.github.com/jdarcy/60107fe4e653819138396257df302eef キャッシュの話についてはコメントの反論も含めて読みましょう ↩

26. 現在は、フィード作成に不要なMST bitsなどを除いて帯域を99%以上節約した「Jetstream」が公式からリリースされています。フィード作者はこちらを利用しましょう。 ↩

27. https://fedibird.com/@noellabo/113044308165407144 ↩

28. https://developers.facebook.com/docs/threads/ ↩

29. https://www.threads.net/@0xjessel/post/C3_cKf5vs_0 ↩

30. https://github.com/junhoyeo/threads-api ↩