Mastodon が普及しつつあるけど、元 GNU Social 勢として思うこともありまして
この記事は、 Mastodon Advent Calendar 2017 の15日目の記事である。
前日の記事は『どうすれば変化するAPIと上手く付き合っていけるのか – Tootle Inside – Medium』、
翌日の記事は『Mastodon フロントエンド改造入門 | THE BOSS's blog』である。
あんただれ
-
GNU Social
- GNU Social 個人用インスタンス勢 (gnusocial.cardina1.red)
- nightly 追従勢
- クソザコ PR を送ったことはあるが、コードそのものに手を入れたことはない
- 周辺プラグイン (Qvitter 等)に PR 送ったことはある
-
Mastodon
- Mastodon 個人インスタンス勢 (mastodon.cardina1.red)
- master 追従勢
- PR とか issue は書いたことなし(純粋なユーザ)
-
その他
- 昔『gnusocial や mastodon の哲学』なる記事を書いた
- 個人インスタンス推進派
私の分散 SNS 遍歴もそんなに長くないが、 Mastodon 以前より自分用の GNU Social インスタンスを持っており[0]、それからしばらくして Mastodon が ActivityPub プロトコルを実装したことを切っ掛けに Mastodon に引っ越した。 (その辺りのことは後述。)
そういった経緯もあり、 Mastodon 以外の場所から fediverse を見ていたユーザ(ﾌﾟﾖｸﾞﾔﾏ)としての話を書きたい。
GNU Social と Mastodon を比較してみる (おまけ)
Mastodon しか使っていないユーザにとっては、どうでもいい話かもしれない。 というか、書いてる人をあまり見なかったので書いてみただけで、私の本題は次のセクション以降なのでそっちを読んでほしいです。
| 観点 | GNU Social | Mastodon |
|---|---|---|
| 歴史 | 古い | 新しい |
| 開発ペース、リリース周期 | 極めておそい | はやい |
| (アクティブな)コミッタ数 | 実質1人？ | たくさん |
| プロトコル | OStatus, XMPP? (あとはプラグイン次第？) | OStatus, ActivityPub |
| 開発言語 | PHP | Ruby |
| 実行環境 | PHP, MySQL, www サーバ | Ruby (Rails), Node.js, Postgresql, Redis |
| 拡張機能 | プラグイン | コードの直接変更 |
| 公式 docker サポート | なし(されない予定) | あり |
| 言葉(用語) | notice / repeat / subscribe | toot / boost / follow |
歴史
私もそんなに詳しくないが、 GNU Social は元は StatusNet という名前(もっと昔はもっと別の名前だったらしい)で開発されており、その歴史は古い。 実装も PHP で行われている。 最近は開発も停滞している(ように見える)。
一方 Mastodon は新しいので Ruby on Rails で開発されている(らしい)。 最初のコミットは 2016-02-21 なので、まだ2年経っていないということになる。 開発も活発である。
開発ペース、リリース周期
Mastodon
一方の Mastodon の開発とリリースは活発である。 開発は master ブランチで進んでおり、それが開発版(不安定版)のようなものになっている。 そのため、「安定版」ブランチのようなものは存在せず、新機能や修正が欲しくば新しいリリースを追い掛けなさいという方式になっている。
連合を組むという性質からいえば、安定版の古いバージョンにしがみ付かれると迷惑だったり面倒だったりするので、古いバージョンを保守するよりも新しいリリースをどんどん乗り換えましょうという方針は正しいように思われる。
機能の開発等は issue と pull request を活用して行われており、特定の機能のためのコミット群を追い掛けるのは(少なくとも GNU Social よりは)簡単である。
アクティブなコミッタ数
GNU Social では、コミット権を持っているのは実質 @mmn 氏の一人だけしかいないように見え、 nightly のコミット一覧を見ても @mmn 氏ばかりである。 (もちろん、 merge request は様々なユーザが出せる。) この状況は、明らかに開発ペースの低下に貢献していそうである。
特になんとも言えない †趣†を感じてしまうのは、 master を nightly に merge するときのコミットメッセージが Merge branch 'master' of git.gnu.io:gnu/gnu-social into mmn_fixes などとなっている様を見たときなどである。
一方 Mastodon ではコミッタが多数活動しており、日本人も多くいる。 issue や pull request もよく消化されており、勢いがあると言えるだろう。
プロトコル
GNU Social は古くから OStatus へ対応しているが、 ActivityPub への対応の兆しはない[2]。 これもアクティブなコミッタが1人であることを考えると、妥当というか仕方ないことに思われる。
Mastodon では、もともと GNU Social (や OStatus のサービス)と連合を組むため OStatus を実装していたが、その後 ActivityPub にも既に対応している。 規格書が散逸しつつある OStatus と W3C が策定している ActivityPub のどちらに力を入れるべきかといえば、当然後者であるし、これでも(機能に制限が付くとはいえ) OStatus のネットワークには相変わらず参加できるのだから、この点をもって機能性では Mastodon が GNU Social より大いに優位に立ったと言えよう。
開発言語と実行環境
Mastodon
Mastodon は Ruby on Rails で開発されており、最近のプロジェクトだけあって現代的である。 アセットもビルドが必要な形式で管理されていたりする。 私は最近の web 開発界隈の技術には詳しくないが、どうせ何も考えずとも docker をドキュメント通り動かせばうまくいくようになっているので、開発者からすれば便利なことであっても、ユーザ(鯖缶)の負荷がそこまで大きくなるということにはならないだろう。
Mastodon では docker や docker-compose などが公式で用意されており、ドキュメントも十分にあるため、 Rails や Node.js が必要とはいえ、(高性能を求めない限りは)導入自体は難しくない。 むしろ個人規模のサービスであれば docker を使う機会も多いだろうから、小規模インスタンスでは助かるかもしれない。
拡張機能
Mastodon
Mastodon は(私の知る限り)プラグインの仕組みを持っておらず、改造にはリポジトリを fork してコードを直接弄る必要がある。 とはいえ Mastodon もまだまだ枯れて安定するのは先になるだろうし、今の段階でプラグイン用の仕組みを用意するのはあまり重要ではないかもしれない。
また、 Mastodon は相互運用性とか Mastodon 自体のデザイン方針を大事にしている節があり [4]、ひとつのインスタンスだけ(外部に影響する)特殊な機能を持っているとかは好かれない気がする[5]。
Mastodon AdC 2日目の記事: 『このIP網の片隅で : アイマストドンの7ヶ月半をgithubのPRベースで振り返る』などでは Mastodon を拡張した記録がまとめられているが、保守していくの大変そうだし、こうしてまとめられると、やはりプラグインのシステムも早期に必要なのかもなぁという気にさせられるので難しい。
公式 docker サポート
GNU Social では行われない予定。 勝手にやってねという感じである。
その点 Mastodon では既に docker / docker-compose 対応があるので、導入が楽である。
言葉(用語)
これについては、昔表を作ったのでそちらを参照してもらうとわかりやすいかもしれない。
GNU Social は元々のプロトコル (OStatus やその基盤となっているプロトコル)がブログ関係発祥のものであるため、用語もそういった背景を感じさせるものになっている。 notice: 通知(ツイート相当)、 repeat: 拡散(リツイート相当) などはまだしも、 subscribe (フォロー相当) などは特にメーリングリスト的な雰囲気がある。
しかし同じ GNU Social でも、 Qvitter プラグインで UI を変更すると、表示される用語も変わる。 quip: クイップ(ツイート相当)、 requip: リクイップ(リツイート相当) などは語源がよくわからないが、何なのだろう[6]。
Mastodon では更に別の言葉となり、 toot: トゥート(ツイート相当)、 boost: ブースト(リツイート相当) などになっており、 Mastodon が隆盛の今、(少なくとも私の観測範囲では)この言葉が浸透しつつある。 これについては思うところがあるので後述する。
その他
Mastodon では現代的なエコシステムが活用されているが、 GNU Social ではより古典的に、サードパーティのライブラリを全て同梱して配布しており、その理由が少し興味深い。
PHP には composer という (Ruby で言うところの gem のような)パッケージマネージャがあるが、それを使わないのかとの merge request が、このコメントにあるように「 GitHub への依存を増やすと環境によっては問題が出たりするのと、動くものをまとめて一度に配布した方が簡単だし確実に動く(あとプロプライエタリなプラットフォームに依存するのは良くない)」とのことでクローズされている[7]。 GNU の名を冠しているだけあり、 GNU Social の方が少々原理主義的というか、 Free/Libre software として「自由」をより重視しているように見える。
Mastodon 以外の“仲間”を無視しないでください
3rd party サービス
最近「 Mastodon のインスタンス一覧/ネットワークで云々」みたいなサービスを見掛けるようになった。 それ自体は大変良いことだが、 Mastodon と繋がっているサーバは Mastodon だけでなく、 GNU Social や Pleroma 、そしてこれから生まれるであろう ActivityPub 対応サービスなどもあるのである。 GNU Social 等をガン無視して Mastodon だけ対応されると、分散というアーキテクチャは何も理解されていなかったのだなという無力感を感じさせられる。
Mastodon が実装する ActivityPub はオープンなプロトコル(仕様)であり、それゆえ第三者が自由に参加可能であり、 Mastodon に縛られずに済むという重要な特徴がある。 サードパーティサービスでこれを活かさず Mastodon のみに対応するのは、結局「 Twitter 専用サービスが twitter でしか使えない」というのと本質が変わらないのではないだろうか。 折角 ActivityPub や OStatus という実装非依存の共通規格が用意されているのだから、できればそういった“Mastodon の仲間”を無視しないで fediverse と関わってほしいものである[8]。
サービス開発者の皆様は、「 Mastodon のほげほげサービス」を作ろうとするとき、それを本当は「 ActivityPub のほげほげサービス」だとか「 ActivityPub / OStatus のほげほげサービス」にできるのではないか、ということを是非考えていただきたいと思っている。
たとえば togetter の「Mastodon 版」のようなものが公開されたとして、 GNU Social や Pleroma の投稿が利用できなかったら泣きます。 ほんとお願いします。
言葉の多様性
GNU Social で Mastodon のインスタンスと繋がっていた時代、「 RT ではなく BT やで」といった投稿などを見るにつけ、「うち (GNU Social) では repeat であって boost ではないから RT の方が妥当なんだよなぁ」などと思っていた。
Mastodon ユーザの皆様は、「おっこいつ Mastodon 初心者か？」と思って指摘を投げる前に、もしかするとあなたが見ている投稿の発信者が「トゥート」「ブースト」する環境にいないかもしれないということを念頭に置いておいてほしい。 (念頭に置くだけでいいです)
ちなみに私は、サービス中立性の高い用語を意識して使っていこうと思っているので、「 post / 投稿」「 repeat / 拡散」などの言葉を使っている。 気に入ったら皆様もどうぞ。