🌐

TwitterとFediverseの現在と未来

2022/12/25に公開

TL;DR

  1. 日本以外の国はどんどんTwitterを辞めていって、とりあえずFediverseを始めることになるよ。
  2. 日本のTwitterユーザーもそこそこ減るけど、結構な人が残るので無理して辞める必要はないよ。
  3. Twitterはどんどん制限が厳しくなっていくけど、Fediverseには自由があるよ。良くも悪くも。
  4. Fediverseで最も広く使われているプロトコル、ActivityPubは銀の弾丸ではないよ。
  5. MastodonはTwitterの代替だけど、FediverseはTwitterの代替ではないよ。
  6. SNSは使う時代から作る時代になるよ。作れば問題は全て解決するよ。

Intro

黒ヰ樹です。
2017年4月13日頃Mastodonを知りmstdn.jpに登録した後、一度mstdn.jpのDBを爆破することになったため様子見していたのですが、数日後にfriends.nicoがサービス開始しました。
アカウントを作りしばらく使っていたのですが、皆さんと大体同じタイミングで飽きて一度辞めるような人間でした。
そもそも私は当時すでにSNSに時間を費やすことが難しい生活をしていたので、2013年頃にTwitterアカウントを削除しているんですね。
もともと人混みがあまり好きではないので、当時Discordをメインで使うような生活をしていました。

あれはいつだろう?
数ヶ月ぶりにfriends.nicoにアクセスして投稿したら見知らぬ人からいいねをつけられました。
次投稿してもいいね。
何を投稿してもいいね……。
この神崎おにいさんという人は何者なんだろう?

調べていくとknzk.meというMastodonインスタンスのAdminらしく、ちょうどknzk.meのDiscordのリンクが紹介されていたので参加してみることにしました。
friends.nicoにアカウントありましたし、当時はknzk.meにアカウントを作成していませんでした。
そもそもMastodonアカウントって複数作成しても別にメリットありませんし。

少し期間が経過した後、knzk.meのサーバー管理者(Owner)をやっていたNCLSさんがPleromaというOSSをどこからともなく見つけてきて、Pleromaの開発者lainに建て方を英語で聞いていた光景を見かけました。
調べていくとどうやらこのPleromaというのはMastodonと全く違うソフトウェアなのにMastodonと同じように使うことができるようです。
しかも今後Mastodonが採用していく分散型ソーシャルネットワーキングプロトコルであるActivityPubのサポートを前提として開発している……。

「ActivityPubって何だろう?」

私は日本で2番目にPleromaへアカウントを作成した人間となりました(1番目はOwnerのNCLSさん)
2017年11月、何日だったかは覚えていませんが、あの時がなければ今の私は存在していなかったのかもしれません。

この記事は、Fediverse Advent Calendar 2022 25日目の記事です。

https://www.itmedia.co.jp/news/articles/1704/13/news131.html
https://www.itmedia.co.jp/news/articles/1709/15/news129.html
https://www.itmedia.co.jp/news/articles/1711/15/news124.html

knzk.me
Let It Be

Mastodon v4

Mastodon(マストドン)とは何でしょうか?

https://www.youtube.com/watch?v=IPSbNdBmWKE

これはMastodonとは何かを紹介した4年前の動画ですが、TwitterやTumblrのように気軽に投稿できるOSSであることが紹介されています。
そのTumblrがActivityPubを採用しMastodonと接続するというから驚きです。

https://www.techno-edge.net/article/2022/11/22/522.html

https://github.com/mastodon/mastodon

作者はオイゲンさんです。

この度Mastodonはv4となり、UIが一新されログインせずとも様々な情報を確認できるようになったため、今までMastodonを使ったことがない人でも親しみやすいものになりました。

Mastodonはビルド手順がどんどん早く簡単なものになっているのでこれを機に建ててみるのもいがでしょうか。

https://wired.jp/article/the-man-behind-mastodon-eugen-rochko-built-it-for-this-moment/

Misskey v13

さて、Misskey(ミスキー)とは何でしょうか?
最近Mastodonでよく見るようになりましたがこれ、実はMastodonとは何の関連性もないSNSなのです。
そんなSNSがActivityPubを実装することにより、あたかもMastodonで投稿しているように見えるわけですね。
今は当たり前ですが、これは私がPleromaをきっかけにActivityPubを知った時、ものすごく衝撃を受けましたし、初めて見る人はびっくりします。

https://misskey-hub.net/

なのでMisskeyはオープンソースの分散型ソーシャルネットワーキングプラットフォームになります。

https://github.com/misskey-dev/misskey

作者はしゅいろさんです。

https://join.misskey.page/ja-JP/

長らくMisskey v12で開発が続けられていましたが、少し前にMisskey v13のアルファ版に関する情報がコミットされました。

WebアプリケーションフレームワークがKoa.jsからFastifyに変わったり、Yarn v3を使いパッケージインストール出来るようになっていたりよりNode.jsで動かすメリットを享受出来るものになっています。

暫し都会の喧騒から離れて、新しいインターネットにダイブしてみませんか?

Fediverse

では、Fediverse(フェディバース)とは何でしょうか?

https://www.youtube.com/watch?v=S57uhCQBEk0

これは英語の動画ですが非常に分かりやすくFediverseを紹介しています。

Fediverse(フェディバース)とはMastodonやMisskeyのようなActivityPub実装で何かうまいことやっているクラスタのことを指しますが、プロトコルはActivityPubだけにとどまりません。Wikipediaでは図で分かりやすく紹介しています。

https://en.wikipedia.org/wiki/Fediverse

最近はMozillaも分散型ソーシャルネットワークのテストインスタンスを2023年前半に立ち上げ、Fediverseに参加すると宣言し話題を呼びました。
Fediverseは「連合(federation)」と「世界(universe)」のかばん語なのですが、Publickeyではソーシャルメディア連合と呼んでいて面白いですね。

https://www.publickey1.jp/blog/22/mozilla2023.html

他にはMastodonのブログ記事を読めばFediverseについて理解が深まるかもしれません。

https://blog.joinmastodon.org/2018/12/why-does-decentralization-matter/

ブロックチェーンよろしくLayer3のIPだけを参照するP2Pではどうすることもできない問題点が存在しており、ActivityPubなどはLayer4のTCPで解決できるようにすることが多く、最近はL3-L7まとめて処理するHTTP SecureでJSONをPOSTするプロトコルが流行りつつあります。

https://en.wikipedia.org/wiki/OSI_model

今回は詳しく紹介しませんが、分散型メッセージングプロトコルのMatrixも似たような設計です。

https://matrix.org/
https://element.io/
https://wired.jp/2021/07/14/matrix-encrypted-messaging-app-governments/

ActivityPub

ActivityPubとは何か、というのはFediverseを語る以上に難しいものだと思っています。
例えば、ActivityPubの実装をしたとして、そのままMastodonと接続できるのでしょうか。

Mastodonと接続するためには最低限以下の3つが必要になります。

  • ActivityPub
  • WebFinger
  • HTTP Message Signatures

また、ActivityPubは以下の3つで成り立っています。

  • ActivityPub
  • Activity Streams 2.0
  • Activity Vocabulary

それらと関連性のある技術として以下のようなものもあります。

  • JSON-LD 1.0/1.1
  • Security Vocabulary

さらにMastodonに関連したサービスとも接続するためには以下のものも考慮する必要があります。

  • NodeInfo
  • Verifiable Credential Data Integrity 1.0

ごちゃごちゃ書いてしまいましたが、最初に書いた3つを実装すればMastodonと接続できます。
そしてActivityPubとWebFingerはHTTP JSON Body、HTTP Message SignaturesはHTTP Header Fieldをベースにしているので、最小限の実装であれば様々なプログラミング言語、Webアプリケーションフレームワークで実装することができます。

手前味噌で恐縮ですが私が今まで作ったActivityPub実装を紹介します。

最初に紹介したMatchboxはTypeScriptとHonoで書かれているので、Cloudflare Workers, Deno, Bun, Node.js, Fastly, Vercel, Lagonなどなど……。
様々なJavaScriptランタイムで動かすことができます。
実際に動作確認したのはDenoとBunだけですが、最小限のWeb Standard APIを使うだけで他のパッケージに依存することなく、ランタイムだけあれば動かせるようになっています。

https://common-min-api.proposal.wintercg.org/

もちろん他のプログラミング言語、Webアプリケーションフレームワークで実装してもApache, Nginx, Caddyでhttps対応したりリバースプロキシすれば様々な環境で動かすことができます。

このようにActivityPubとWebFingerは非常に魅力的で成熟した仕様ではあるのですが、HTTP Message Signaturesはそうではありません。
なぜでしょうか。

HTTP Message Signatures RFC

実はActivityPubが標準化された際、サーバーを相互に認証するための標準化仕様は存在しませんでした。

https://www.w3.org/TR/activitypub/#authorization

B.1 認証と認可
ActivityPubは、二つの目的のために認証を使用する。一つは、クライアントとサーバーを認証することであり、もう一つは、連携した実装において、サーバーを相互に認証することである。
残念ながら、標準化の時点では、認証のための強く合意されたメカニズムは 存在しない。認証のためのいくつかの可能な方向性は、Social Web Community Group Authentication and Authorizationのベストプラクティスレポートに記載されている。

https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization

そのため、このWikiで紹介している通り、とりあえずHTTP Signatures(現在のHTTP Message Signatures)とLinked Data Signatures(現在のVerifiable Credential Data Integrity 1.0)を使うことになったのですが、Mastodonは実装当時のドラフト仕様を実装したまま、数年経っても最新の仕様に更新されることはないまま今日がやってきました。

https://github.com/mastodon/mastodon/blob/v4.0.2/app/controllers/concerns/signature_verification.rb#L3-L4

つまり、MastodonのServer to Serverに使用されている認証と認可はものすごく古いわけです。
今回はこのHTTP Signaturesの歴史を遡ってみましょう。

https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/

IETF Datatrackerを見ると非常に歴史があることがわかります。
始まりは2013年5月、10年近くDraftでやってきたんですね。

https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-10

ベストプラクティスレポートに記載されていたりMastodonに採用されているバージョンはdraft-cavage-http-signatures-10までに作成されたものです。

これはalgorithmに"rsa-sha256"を指定できるものですが、使用できる鍵がMastodonで使用しているRSASSA-PKCS1-v1_5など非常に少なく、署名や検証にあたりパースする部分にカンマやダブルクォーテーションを使用しており、HTTP Signaturesのライブラリを使わなければ仕様を準拠することが難しいものになっていました。

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-02

その後数年の時が流れ、様々なHTTP仕様の策定を行っているHTTPWGで再出発することになりました。
途中、先に述べた使用できる鍵が非常に少ない問題を解決するためalgorithmに"hs2019"を使用し、様々な鍵やハッシュ関数を検証側で選択したり、簡単に仕様を更新できるようにしました。

この仕様はあまりにもひどいです。
algorithmの"hs2019"は何を指すのでしょうか? RSAでしょうか? ECDSAでしょうか?
もしRSAだとして、そのRSAはRSASSA-PSSなのでしょうか? "rsa-sha256"と同様にRSASSA-PKCS1-v1_5なのでしょうか?
その場合"rsa-sha256"のエイリアスとして扱うのでしょうか。"hs2019"に含まれていないためエラーを返したほうが良いのでしょうか。
またこの仕様にはDeprecatedと記載されたalgorithm、"rsa-sha1"が含まれています。
なぜ存在するのでしょうか。
このDeprecatedは実装しなくてよいのでしょうか。
ではなぜ仕様に追加したのでしょうか。

このhs2019は送信は厳密に、受信は寛容にするポステルの法則(ロバストネス原則)を満たしていないように思えます。

irasutoya.com
インターネットの神様のイラスト

https://en.wikipedia.org/wiki/Jon_Postel

とまあそんな感じでDraft仕様の問題を解消しまくった結果、2022年9月26日頃Last Callに到達しました。

https://lists.w3.org/Archives/Public/ietf-http-wg/2022JulSep/0183.html

ただまだまだ問題点がたくさんあるそうで……。
すぐRFCに到達するかと思いましたが、まだまだ道のりは長いようです。

https://github.com/httpwg/http-extensions/labels/signatures

2024年2月27日追記:2024年2月14日にHTTP Message SignaturesとがRFC 9421として公開されました。

https://datatracker.ietf.org/doc/html/rfc9421

現時点でhs2019は廃止となり、代わりにJWS/JWKが採用され、従来どおりalgorithmでもrsa-pss-sha512やed25519のように指定でき、署名や検証にあたりパースする部分にカンマやダブルクォーテーションではなく構造化されたStructured Field Valuesが使われ、HTTP Signaturesのライブラリを使わなくても実装できる特徴があります。

https://blog.jxck.io/entries/2021-01-31/structured-field-values.html

ただ別途Structured Field Valuesのライブラリが必要になったり、Mastodonなどで使われているrsa-sha256もrsa-v1_5-sha256に置き換わり廃止となるため、後方互換性をどのように持たせるか難しいところであります。
後者はrsa-sha256をrsa-v1_5-sha256のエイリアス、hs2019をrsa-pss-sha512のエイリアスとして使えば解決しそうですが、Structured Field Valuesはライブラリが非常に少なく、必要最低限の実装も難しいので古い仕様と新しい仕様の混在になりそうです。

2024年2月27日追記:2024年2月14日にDigest FieldsもRFC 9530として新たに公開されました。古いInstance Digests in HTTP(RFC 3230)は廃止されます。

https://datatracker.ietf.org/doc/html/rfc9530

AT Protocol

Twitterの未来について話す前に少し過去の話をしましょう。
Twitterは2019年頃にActivityPubに対抗して分散型ソーシャルネットワーキングプロトコルを開発する団体Blueskyを立ち上げました。
一時期Authenticated Data eXperiment(ADX)と呼ばれていたプロトコルですが、イーロン・マスクが買収する少し前にAT Protocolとして正式に発表されました。

https://gigazine.net/news/20221025-at-protocol-bluesky-social/
https://wired.jp/article/twitter-had-a-plan-to-fix-social-media-bluesky-will-elon-musk-follow-it/

一体これは何なのかは少し前に調査したことがあります。
ADXの頃なので情報が古く情報の正確性に欠けますが詳細は以下の記事を読んでみてください。

https://zenn.dev/tkithrta/scraps/d631817042b676
https://atproto.com/

改めて公式ドキュメントを読んでみましょう。

https://atproto.com/guides/faq

ATPはブロックチェーンですか?
いいえ。ATPは連合プロトコルです。ブロックチェーンではありませんし、ブロックチェーンを使用するものでもありません。

なるほど。
どうやら分散型台帳ではなく分散型識別子を使うようです。

https://atproto.com/specs/did-plc
https://www.publickey1.jp/blog/22/w3ciddecentralized_identifiers_dids.html

W3C DIDの仕様では、これをどのように実装するのか、例えば分散型台帳もしくはブロックチェーンの上で実装するのか、分散ファイルシステムの上で実装するのか、どのような暗号方式を用いるのか、DIDやDID文書はどのようなアプリケーションで管理するのか、などは規定しておらず実装者に任されていると同時に、さまざまな実装や相互運用性を許容するようになっています。

この実装や相互運用性を考慮した場合、did:web等、他の分散型識別子も対応する必要が出てきますし、他の分散型識別子の対応をしていく中で出来ることが限られているdid:plcが覇権を取れるとは思えません。
ブロックチェーンに関連した分散型識別子を採用する頃には「ATPはブロックチェーンですか?」の項目は削除されているのではないでしょうか。
そして、did:web等、他の分散型識別子が覇権を取った場合、ActivityPub以上に多くの仕様に依存しているAT Protocolの存在意義はどこにあるのでしょうか。

Twitter

いや~もうすぐ12月25日が終わりそうです。
最後に時間の許す限りTwitterの未来について語りましょうか。

まず日本以外の国はどんどんTwitterを辞めていって、とりあえずFediverseを始めることになります。

というのも英語だとTwitterの280文字制限はあまりにも短すぎるんですね。
つぶやくだけならそれでいいのですが、イーロン・マスクに買収された今のTwitterは果たしてつぶやくサービスなのでしょうか。

https://blog.twitter.com/ja_jp/topics/product/2017/Cramming-Design

長文を投稿するということは長文にあわせたデザインに作り直す必要があり、もともと140文字を前提としたサービスでは無理があります。

この280文字制限、日本語含めたいわゆるCJKでは140文字制限になるのですが、日本語は一文字に様々な意味を持たせることができますし、長い文字列であれば略称を使うこともあるためものすごく短い文字数で多くの意味を持たせることができるんですね。

さらに注目すべき機能は検索です。
先に述べたようにTwitterの280文字制限はあまりにも短すぎますし、いざ文字数上限を増やしたところで検索にかかるコストはものすごいものになります。
なぜコストがかかるのかというと、英語では単語と単語の間にスペースが入るためスペースを含めた検索が難しいんですね。
例えば「Bar Camp」で検索すると「Camp Bar」と書かれたTweetも出てきますし「Bar Foo Camp」と書かれたTweetも出てきます。

そうした問題を解決するためにハッシュタグという機能が登場しました。

https://twitter.com/chrismessina/status/223115412

こうすれば簡単に目的の結果を表示することができますし、ハッシュタグはリンクとしても機能しますので、文字を入力する手間も省けます。
Google検索なんかだと"Bar Camp"と検索する方法もありますが、ダブルクォーテーションを入力するのは手間です。

でも日本ではあまりハッシュタグは使われませんよね? まあ繋がりたいタグを使いフォロワー関係を増やす人はいるかもしれませんが、あまり検索目的は使われません。

これは日本語の単語の単語の間にスペースを入れることはほとんどないからです。

「イーロン マスク」と書く人はあまりいないですよね?
「イーロン・マスク」あるいは「イーロンマスク」になると思います。

なので単語をそのまま検索欄に入れるだけで簡単に目的の結果を表示することができます。

では中国や韓国でもTwitterが流行っていないとおかしいのでは? と思いますが、
中国ではWeibo、韓国ではInstagramが流行っているそうです。
韓国でInstagramが流行っている理由はよく分かりませんが、多分K-POPとか流行っているからじゃないですかね。知らんけど。

MastodonやFediverseではハッシュタグを使えば検索に困ることはないのですが、日本のハッシュタグはMastodonやFediverseでも全く異なる使われ方、例えばFedibirdのようなハッシュタグをフォローする機能やハッシュタグ専用のリレーサーバーとして発展したことにも納得がいきます。

https://fedibird.com/@noellabo/109359564491817926

なんにせよTwitterの280/140文字制限と検索機能は日本以外の国にとっては不便でしかなく、他の代替サービスがあれば今すぐにでもみんなで移行したい気持ちがあったのでしょう。
今回のイーロン・マスクの買収が大きなきっかけとなり、みんなでMastodonへ移行するに至ったわけです。

でも日本のTwitterユーザーはそれほど減っていないようです。
140文字制限と検索機能は日本に最適化されすぎているので、今後も結構な人が残るのではないのでしょうか。

ただこの欠点を解消するためにOSSである必要性はなく、MastodonやFediverseでなくても出来ることなので、とりあえず現時点で自由の高いFediverseに人が集まっただけに過ぎないわけです。

Outro

「ActivityPubって何だろう?」

そう思ったあの時から長い年月が流れました。

Twitterで何か気に入らないことがあれば毎回Mastodonが挙げられ、Mastodonに移民がやってきたと思えば数ヶ月後にはTwitterに戻る人が大半で、今回のイーロン・マスク買収に関しても同様だと思っていました。
アドベントカレンダー25日目を書こうと思った11月1日頃までは。

たった二ヶ月足らずであまりにも色んなことがありました。
日本以外の国はどんどんTwitterを辞めていき、もう戻ることはないだろう思っています。
そういった人たちがFediverseを始め、新しい世界を生み出そうとしている光景を見て懐かしい気持ちになりました。

まるであの日みたいだ。

Twitterを始めた頃と同じ光景が、今のFediverseには存在しています。
皆さんもぜひ新しい世界を創ってみてくださいね。

The best way to predict the future is to invent it. - Alan Kay
未来を予測する最善の方法は、それを発明することだ。 - アラン・ケイ

https://en.wikipedia.org/wiki/Alan_Kay

Ref

NHK

TechnoEdge

ITmedia

Gigazine

Getting Started

And More

Changelog

校正を要するほどの長文を書いてしまったため編集履歴を残しておきます。

  • 2023/02/19 typo修正
  • 2024/02/27 HTTP Message SignaturesのRFC 9421とDigest FieldsのRFC 9530について追記

Discussion