この記事は、 Fediverse (3) Advent Calendar 2024 の4日目の記事です。
昨年の記事はこちら。
今年も前編と後編に分かれております。
お邪魔しております。
昨年の記事からの引用ですが、私にとってのFediverseの定義は以下なので、BlueskyもFediverseと認識しています。
私は「複数のインスタンスがつながりあって1つの世界を構成するもの」という定義をしています。
Federation（連合） ＋ Universe（宇宙/世界） のカバン語の私なりの解釈です。
そうすると、
ActivityPubという技術でつながっているMastodonやMisskey（ほかにはPleroma、Akkoma、Dolphinなどなど）に限らず、
ATProtocolを採用しているBlueskyもこれに含みます。
一方、Xやタイッツー、（記事公開時点ではまだActivityPubに対応していなかった）Threadsは除きます。
現在はThreadsはギリFediverseかもしれません。Xやタイッツーは違うというのは今も維持しています。
この記事では、「Fediverse」という技術から見たお話を展開しようと思います。
それも、おもにMisskey・Mastodon・Blueskyに絞っています。
Fediverseもそれ以外も含んだ、SNSの在り方については後編で触れます。
連合 – ActivityPub
ActivityPubという技術があります。
これによって、MisskeyやMastodonなどが連合としてつながりあい、1つの世界を作ることを可能としています。
しかし実際のところ、MisskeyやMastodonは基本的に各サーバーのローカルで完結して、
外の世界はわざわざドアを開けて「連合TL」を見に行かないと見えません。
いや、「連合TL」を見てもたいした世界は広がっていないかもしれません。
MisskeyやMastodonの仕様…いやActivityPubの仕様上、「自インスタンスがフォローしてる別サーバーの人」しか収集しないからです。
ActivityPub対応プロトコルを喋るサーバーは無数にあり、ユーザーも相当な人数がいるのですが
いかんせん、「どこのだれか分からない人がどこかで喋っている」状況を打破する何かは存在しません。
リレーサーバーという仕組みはあるものの、リレーに参加していないサーバーは見えません。
具体的には、Misskey.ioなどの巨大インスタンスはリレーには参加していないため、.ioの全貌を外から伺い知ることは不可能です。
これはActivityPubが、後付け連合機能として生まれたものだからだろうと思っています。
MisskeyもMastodonも、ActivityPubという概念よりも前に産まれたとのこと。
この時点で、どちらも「RPGツクール」ならぬ「SNSツクール」だったのです。
この「SNSツクール」で作られたSNS同士を、なんとかしてくっつけようと考えた結果生まれたのがActivityPub。
こういう経緯のゆえ、設計思想はメールと似ていて、あくまで本来のSNSの動きを阻害しないように配慮されています。
（以下、厳密にはちょっと違いますが）
ユーザーがポストしたら、フォロー関係の相手全員とリレーサーバーのキューに内容をポストしに行きます。
リレーの仕組みはカンタンに言うとメーリングリストです。
これらはPUSH型のやり取りと言えます。
（※W3C勧告上はPULL型の実装も可能なようですが見たことがないです）
PUSH型の利点は、後からの実装が容易です。
誰かの投稿を自サーバー内へ広める過程で、ついでに別サーバーにPOSTしに行けばいいのです。
また外部公開のキューを置いておけば、別サーバーからのPOSTを受けてTLを構築できます。
シンプル イズ ベスト。
PUSH型の難点は、詰まりうるということです。
自分のインスタンス内での処理であればメモリ上でなんとかなりますが、PUSH型は相手サーバーへアクセスして届けに行かねばなりません。
インターネットは基本的にミリ秒単位で応答が返ってくるものですが、相手サーバーの都合や経路の都合でそうもならない場合があります。
一度でもそうもならなくなった場合、仮に人気サーバーだったとしたら、行列が行列を呼びます。
そうすると、一度始まった遅延はひたすらずーーっと続くことになります。
急にユーザー数が伸びたMisskey.ioや、今年元日の震災でのMisskey.ioやNERVなどで発生していましたが、
遅延はSNSにとって大敵です。特に震災後はタイムリーな情報を求められるので、遅延すると相当痛い。
そうでなくてもエアリプが全く繋がらなかったりして、体験としてはたいそう良くないでしょう。
ただしインターネット上の都合で詰まることがほとんどなので、自鯖内では安定して他人の投稿が見えることが多いです。
Misskey.ioも、外部への送信が遅延していても内部から見たら特に問題ないケースは散見されます。
となると……Misskey.ioに登録したら.ioの発言をストレスなく見れるんじゃね？となります。
こういう面でも、「SNSツクール」をつなげた仕組みであるActivityPubは、本当のFediverseの目的を果たしにくくなっているんじゃないかと思っています。
また、去年も述べたのであまり詳しく話しませんが、以降で上げるATProtocol・Nostrとの違いとして、
「インスタンス単位で見れば中央集権であり、Nostrのリレーのそれよりも強大である」
「個々のSNSに独自拡張が多すぎて、別のインスタンスから参加する意味が乏しい」
「ローカルタイムラインが全世界だと勘違いしやすく、自鯖内の他ユーザーと他鯖の他ユーザーの距離が違いすぎる」
というデメリットはあります。
Misskeyをしていない人は、おそらく.io以外のインスタンスを知りません。
Mastodonをしていない人は、おそらくインスタンスの代表例を知りません。
日本においてはMastodonはMisskey（しかもio限定）と比べ圧倒的に劣勢かと思います。
連合 – ATProtocol
それと比較するのはATProtocol……ATmosphereっていうの？なんか急に名前が増えたんですよね。
Blueskyのアレです。
Blueskyは、（これも細かい点は端折っているので厳密には違います）
それぞれのインスタンスごとに投稿のストレージともいえる管理サーバー(PDSのこと)がいます。
この管理サーバーを、リレーサーバーという物体がまるでRSSリーダーのように巡回してきます。
リレーサーバーは拾った投稿を全部集約して、その裏にいるアプリケーションサーバー（appviewといいます）に流します。
アプリケーションサーバーは投稿をいろんな種類のタイムラインに加工して（フィードとか）保持しています。
閲覧者はアプリケーションサーバーによしなにアクセスして、自分の見たいTLを取り出して持ってきます。
PULL型といえます。appviewに拾いに行くことでTLを形成します。
PULL型の利点は、拾う側の負荷がほとんどかからないことです。
インターネットの調子が悪かったとしても、影響を受けるのはその人だけ。
全発言がビューで一元化されているので、拾えてしまえば、TL内の発言順序がおかしくなることもありません。
また、最初からアプリケーションサーバーが世界の中心として定義できることです。
ActivityPubではどこかの誰かの発言は、少なくともActivityPubの機能だけで探しに行くのは非常に困難ですが、
Blueskyではどこかの誰かの発言は検索可能です。
フィードという概念も（いわばRDBのビューのような存在なので）どこかの誰かの発言をピックアップする役割を果たしています。
PULL型の欠点は中央集権であることです。
上で説明したことって、つまりXの実装と同じです。
Xのクライアントは、Xのストレージに溜まった発言から、その人がフォローしている発言だけを抜き出してGETして表示しています。
アプリサーバーが1つしかない場合（実際bskyの中心となる巨大な（2つの？）appviewサーバーが今のBlueskyを支えています）、そのアプリサーバーをごにょごにょすれば言論統制でもなんでも自由にできるということです。
実際、海外において、すでに不透明で怪しいモデレーションが適用されている！という動きはあるようです。
また、当初から想定していないとこのような設計は難しいです。
ATProtocolはプロトコルとして最初からこれを構想していて、いろんな技術に応用可能としつつ、一番最初に最もわかりやすい例として、SNSの「Bluesky」を立ち上げた…という順序です。
ちなみに分散していないと言われがちなBlueskyですが、既に分散しているそうです。
PDSはBluesky公式レベルでたくさんあります。各ユーザー、どれか1つのPDSに属しています。
本稿執筆時点で49サーバーあるんだそうです。
理由は明かされていませんが、キノコの名前がついています。通称キノコサーバー。
私が属するのはAmanitaというサーバー。和名はテングタケ。毒キノコじゃねえか。
あとappviewも2つある？とかなんとか。
すでに地味に分散しているようです。
分散
ここまでをざっと眺めてみると、お互いに「分散」が指すものが違っていそうです。
ActivityPubは、SNSそのものが分散しています。
仕組み自体が分散している。Twitterライクな何かがいっぱいあるイメージ。
それらをまとめ上げるのがActivityPubなので……例えるなら、複数の会社をまとめる業界団体みたいなものですかね。
それぞれで独立して会計も法務もしているものを、全体的に把握して内部で橋渡ししてくれる存在。
分散しているものそれぞれが自立したSNSになっています。
一方ATProtoは、一部分を担うサーバーだけが分散しています。ストレージとか、ビューとか。
なのでこれは……インターネットに既にある、ロードバランシングの考え方に似てますかね。
リスク分散、あるいは負荷軽減のためにサーバーを分けるのと同じノリ。
ストレージサーバーを自社で何台も持つ代わりに、「あなたもストレージサーバーのホストになれます！」というのがATProto（の個別でPDSを立てれるというアレ）。
上では会社の例を挙げたので、それに倣うと、こちらは大会社そのもの。
1人の社長や特定の経営陣のもと、営業部門や製造部門、総務部門などがそれぞれ役割を分担して複数人で作業をしている感じ。
分散しているものそれぞれだけでは大きな何かにはならないけれど、違う役職が全部そろうと完成します。
…ということからして。「分散」が意味しているものが違います。
私はActivityPubにも参加していますしATProtoにも参加しています。
また色んな縁で、両方技術的な話をする界隈の隅っこに座らせてもらって、チラチラ話を聞いています。
まあお互い仲が悪い悪い。
技術者はそれぞれ自分の信念を掲げ、それを実現するために走る生き物なので、
（そうでないとこのように技術が乱立してないですよね）
おそらく…同音異義語で話が噛み合っていないように思えます。
ここまで書いてきたとおり、どちらも長所と短所があります。
ActivityPubから見たらBlueskyはロクに「分散」してないんですが、ActivityPubはSNS自体が分散しすぎていて、もはや世界のユーザーの投稿を1つにまとめることはできません。
Blueskyから見たらActivityPubは「分散」しすぎなんですが、だからこそBlueskyと違って「各インスタンスごとにモデレーション基準が違う」という自由があるんです。
お互い、長所と短所があります。
仲よくすればいいのに。
この記事を読んだ人は、お互いのことを理解してあげてね、とは思います。
ちなみに Nostr
Nostrについても、一応軽く触れておきます。
軽くというのは、私は正直技術も良さも、まだよくわかっていないからです。
基本的な理念は、ActivityPubではなくATProtocolに近いです。
各クライアントは、任意のリレー（1つ以上、いっぱいでも可）に同時に投稿を投げたり、TLを要求したりします。
各リレーサーバーは、配下に紐づいたクライアントから飛んできた投稿を整理し、配下にWebSocketなどで配信します。
また、リレーサーバー同士つながっていたりつながっていなかったりしていて、最初に投げたリレーサーバーの数以上にリレーされることもあります。
登場人物はこれだけで、同じPULL型であるATProtocolよりシンプルです。
クライアント以外の全ての機能を「リレー」に集約した形。
なので「リレー」に対する依存がすごいですが、それをたくさん連結させることにより、各リレーの負担を軽減しています。
そのリレーは現在は非常にたくさんあるとのこと。
（どうやら金を出さないと接続できないリレーとかもあるそうです）
ATProtocolは、自分が所属するPDSに対しては、ID・パスワードによる認証が必要です。
（パスワードはアプリパスワードでもいいですが、アプリパスワード発行のために最低でも1回はパスワードが必要）
Nostrはそういうものは不要で、手元にある秘密鍵を使って署名をした投稿は、その署名部分が自己証明になります。
これは印鑑登録みたいなものです。手元にある実印を押せば、その他の書類が何もなくとも、いつどんなものでも自分だと証明できます。
仮に市役所が占拠され、印鑑登録の台帳が流失したとしても、ホンモノの実印は手元にあるので、自己証明できるのは自分だけに変わりありません。
Nostrも同様で、台帳に相当する公開鍵はいくら盗まれようとも問題ありません。自らが署名に使う秘密鍵さえ無事であれば、いつでもリレーサーバーに本人だと証明できます。
実印と印鑑登録の台帳さえ無事であれば、たとえ印鑑登録した自治体が壊滅したとしても自己証明ができます。
Nostrも同じく、所属リレーサーバーが消えたとしても、同じ秘密鍵で署名をしたものを別のリレーサーバーに改めて投げたら、自分が生きていることを証明できます。
まあ、リレーサーバーが消えた以上、自分の過去の投稿は消えるんですが。
ただし、印鑑登録した実印が盗難されたら、誰でもあなたを騙れます。
Nostrも同じく、秘密鍵が流失すれば、自分を特定する鍵を失ったことになります。
こうなると、新しくあなたが生まれ変わる（印鑑登録しなおし ＝ 新しいユーザーで始める）しかありません。
また、徹底的な分散の副作用として、流出した鍵を使った「あなたを騙る人」を止めることは一切できません。あなたを騙って悪用する人を、誰も止められません。運営もいないし、リレーもいっぱいあるので。
ちなみに自己証明として、Blueskyと近いやり方ができます。
自己が管理するWebサーバーの .well-known ディレクトリ配下に所定のファイルを置くというもの。
そしてNostrクライアント側で証明手続きをすると、これは私だと証明できるようになります。
とはいえ、DNS認証であるBlueskyよりもひと手間多い上、認証マークの仕様が少々ややこしいので、そちらに比べると自己証明能力には劣るように見えます。
ないよりはマシですけどね。
技術的に考えると、なんか今流行りのパスキーと親和性があるような気がしなくもないですが…
とはいえ、これはSNSなのか？という気持ちがやはり拭えないのが現時点での所感です。
各種仕様もSNSユーザーのためになっているというよりは、技術者が満足する仕様に思い切り振っている気がします。
技術者としてはわくわくしますが、SNSとしてはもうちょっと様子を見たいところ…。
2025年のFediverse界隈はどうなるだろう
現状、自分の定義するFediverseにおける連合システムは、ここで取り上げた3つが大きな勢力かと思います。
ActivityPub、およびそれより前からあるMisskey・Mastodonは、いずれも「Twitterもいいけど、こういうSNSもいいよね」という発想から生まれました。
まだTwitterが無事だった時代です。
Misskeyは日本、Mastodonはドイツ産まれ。
ATProtocolのもともとの構想は旧Twitter社内で、Twitter創業者の一人であるジャック・ドーシーを含めた人々が考案しました。
もちろんTwitterが無事だった時代です。
（ちなみにNostrはTwitterが傾き始めた頃（イーロン買収前）、ActivityPubとは違う世界を提示するためにブラジルで産まれたんだそうです）
ActivityPubはSNSとしての新たな仕組みを、ATProtocolとNostrはいずれも通信手段の新しい仕組みを提唱するものです。
Twitterの代替を目指したものではないにせよ、一般市民においては新たなSNSを探しているムーブメントが発生し続けていることは、各技術者は認識したほうがいいかもしれません。
技術者しか分からないことは、一般市民にとっては分からないと同然のもの。
この仕組みはこういうものなんだ、これに気を付けるんだ というのを明確に示していく責務があるのではないかと思っています。
その一方で、各技術とも成長途上であることは間違いありません。
（正直、ActivityPubはもうあとは個々のインスタンス単位での成長しかなさそうですが…）
各技術者が作った「ぼくがおもうさいきょうのコミュニケーションツール」が、みんなに認められる最強のコミュニケーションツールとなる日は来るのか。
…2025年に落ち着くわけではない気がします。
このうちのどれかが勝つというよりは、いずれも共存しあうのかなと思います。
技術的に進化する余地はあるのかな？
おおっと驚くような変化は今のところ思いつきませんが、新しい実装が現れる日を楽しみにしたいと思います。
明日アップされる後編はSNSに着目した話です。
コメント