何とは言わない天然水飲みたさ

Mastodon が普及しつつあるけど、元 GNU Social 勢として思うこともありまして

Mastodon Advent Calendar 2017 の15日目の記事である。
前日の記事は『どうすれば変化するAPIと上手く付き合っていけるのか – Tootle Inside – Medium』、
翌日の記事は『Mastodon フロントエンド改造入門 | THE BOSS's blog』である。

見出し

あんただれ

私の分散 SNS 遍歴もそんなに長くないが、 Mastodon 以前より自分用の GNU Social インスタンスを持っており[0]、それからしばらくして Mastodon が ActivityPub プロトコルを実装したことを切っ掛けに Mastodon に引っ越した。 (その辺りのことは後述。)

そういった経緯もあり、 Mastodon 以外の場所から fediverse を見ていたユーザ(プヨグヤマ)としての話を書きたい。

GNU Social と 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

歴史

最初のコミットは 2016-02-21 なので、まだ2年経っていないということになる。 開発も活発である。

開発ペース、リリース周期

GNU Social では master ブランチで「テスト版」の開発が、 nightly ブランチで「不安定版」の開発が行われているが、その実態は素敵とは言い難い。 git-flow のような feature ブランチやプルリクを merge することを基本とする開発ではないようで、同じ機能を目的とする複数のコミットが分散したり、同じコミットが (merge 等ではなく) master と nightly に別々にコミットされているように見えたり[1]。 一応、 master から nightly への merge はときどき行われているようだが、 nightly only な機能が多いので、これ master にちゃんと merge できるのか……?という不安が物凄い。 (或いはバージョンが進んだら nightly が master に成り代わる予定なのかもしれない。) (ちなみにコミットのグラフはここから見られる。)

そもそも nightly の開発さえ停滞しているようで、なかなか厳しい。 たとえば nightly ブランチは を最後に、 に至るまでコミット(の push) が行われていない。 この様子では、 ActivityPub への対応などは状況が変わらない限り望めないだろう。

バージョンを上げるとなると、もっとペースが遅くなる。 最後のバージョンアップ (1.1.3 → 1.2.0) が行われたのが、 のことである。 尤も、これも「安定している」と言うことはできるから欠点だけというわけでもないかもしれない。

Mastodon

nightly のコミット一覧を見ても @mmn 氏ばかりである。 (もちろん、 merge request は様々なユーザが出せる。) この状況は、明らかに開発ペースの低下に貢献していそうである。

特になんとも言えない †趣†を感じてしまうのは、 master を nightly に merge するときのコミットメッセージが Merge branch 'master' of git.gnu.io:gnu/gnu-social into mmn_fixes などとなっている様を見たときなどである。

一方 Mastodon ではコミッタが多数活動しており、日本人も多くいる。 issue や pull request もよく消化されており、勢いがあると言えるだろう。

プロトコル

[2]。 これもアクティブなコミッタが1人であることを考えると、妥当というか仕方ないことに思われる。

Mastodon では、もともと GNU Social (や OStatus のサービス)と連合を組むため OStatus を実装していたが、その後 ActivityPub にも既に対応している。 規格書が散逸しつつある OStatus と W3C が策定している ActivityPub のどちらに力を入れるべきかといえば、当然後者であるし、これでも(機能に制限が付くとはいえ) OStatus のネットワークには相変わらず参加できるのだから、この点をもって機能性では Mastodon が GNU Social より大いに優位に立ったと言えよう。

開発言語と実行環境

[3]

動作環境としては MySQL と Apache / nginx 等を要求しており、古きよき LAMP (Linux, Apache, MySQL, PHP) 環境で動くため、サーバの準備については安心感がある。 ただし、公式の docker サポートは予定されていない(後述)。

Mastodon

Qvitter というプラグインは 3rd party では一番有名だろう。

Mastodon

[4]、ひとつのインスタンスだけ(外部に影響する)特殊な機能を持っているとかは好かれない気がする[5]

Mastodon AdC 2日目の記事: 『このIP網の片隅で : アイマストドンの7ヶ月半をgithubのPRベースで振り返る』などでは Mastodon を拡張した記録がまとめられているが、保守していくの大変そうだし、こうしてまとめられると、やはりプラグインのシステムも早期に必要なのかもなぁという気にさせられるので難しい。

公式 docker サポート

勝手にやってねという感じである。

その点 Mastodon では既に docker / docker-compose 対応があるので、導入が楽である。

言葉(用語)

表を作ったのでそちらを参照してもらうとわかりやすいかもしれない。

GNU Social は元々のプロトコル (OStatus やその基盤となっているプロトコル)がブログ関係発祥のものであるため、用語もそういった背景を感じさせるものになっている。 notice: 通知(ツイート相当)、 repeat: 拡散(リツイート相当) などはまだしも、 subscribe (フォロー相当) などは特にメーリングリスト的な雰囲気がある。

しかし同じ GNU Social でも、 Qvitter プラグインで UI を変更すると、表示される用語も変わる。 quip: クイップ(ツイート相当)、 requip: リクイップ(リツイート相当) などは語源がよくわからないが、何なのだろう[6]

Mastodon では更に別の言葉となり、 toot: トゥート(ツイート相当)、 boost: ブースト(リツイート相当) などになっており、 Mastodon が隆盛の今、(少なくとも私の観測範囲では)この言葉が浸透しつつある。 これについては思うところがあるので後述する。

その他

このコメントにあるように「 GitHub への依存を増やすと環境によっては問題が出たりするのと、動くものをまとめて一度に配布した方が簡単だし確実に動く(あとプロプライエタリなプラットフォームに依存するのは良くない)」とのことでクローズされている[7]。 GNU の名を冠しているだけあり、 GNU Social の方が少々原理主義的というか、 Free/Libre software として「自由」をより重視しているように見える。

Mastodon 以外の“仲間”を無視しないでください

[8]

サービス開発者の皆様は、「 Mastodon のほげほげサービス」を作ろうとするとき、それを本当は「 ActivityPub のほげほげサービス」だとか「 ActivityPub / OStatus のほげほげサービス」にできるのではないか、ということを是非考えていただきたいと思っている。

たとえば togetter の「Mastodon 版」のようなものが公開されたとして、 GNU Social や Pleroma の投稿が利用できなかったら泣きます。 ほんとお願いします。

言葉の多様性

過去の記事で散々強調してきたが、現状を見るにやはりこの思想が十分に浸透しているとは言い難く、非常にもどかしい思いをしている。

「思想から入るサービスは流行しない」などと適当なことを言う面々もいるようだが、定着したユーザが増えたこの辺りでもう一度、この思想の大事さを説きたい。

Mastodon を第2の twitter にしてはいけない

[9]。 私もそのような未来は信じたくないが、それを想定し事前に備えておくことが重要なのである。実際 twitter でも、凍結されたときには既に手遅れで、引越しをお知らせすることさえ難しくなっている。

自分の手で自分を救い、自分を守る

[10] から、誰もがそう在るということは現実的には無理だろうということは理解している。 しかし、憲法や法律で保証される権利と同じく、権利というのはそれを守ろうとする努力によって初めて守られるものであって、一人一人が「自分の(情報を発信し他者と交流する)自由を守る」ための努力をしなければ、その権利は理不尽に奪われてしまうリスクに晒される(その典型的な例が twitter での事例だ)。 Mastodon は関心のあるユーザもサーバ管理者も増えているから、気力があるなら是非とも自分の手で自由を守ろうという行動を起こしてみてほしい。 きっといろいろな人が協力してくれるだろう。

自分の面倒を自分で見る

[11]

思想が大切なのではない、思想が提示し実現しようとする世界が大切なのである

[12]。 しかし、自分でサーバを用意できるインターネットにおいて、「意見も活動方針も合わないのに同じ場にどうしても存在しないといけない」というケースは、現実でのそういった場合よりも極めて少なくなるはず(そしてそうあるべき)である。

Mastodon において具体的には、運営者や他のうるさいユーザに文句があるなら、そのインスタンスにいることをやめて別のインスタンスでそういった人々と関わらず(或いは積極的にブロックして)生きていけば良いのである。 物理的な位置や所属に縛られる現実とは異なり、インターネットにおいて「関わらない」「逃げる」ことのコストは遥かに小さい。 もっと気軽に面倒を避ければ良い。

では、そういった面倒やトラブルのリスクを軽減する根本的な手段が何かと言えば、それは当然「他人と同じリソースを共有したり奪い合わない」こと[13]である。 すなわち、これが個人規模への分散だ。 Mastodon 等の分散 SNS においては、たとえ「分散」したとしても、自分が関わりたい人をフォローして好きに繋がることができる。

結局、再三述べたように「自分の居場所を自分で統べる」「自分を縛るのは自分だけ」という話に戻ってくるのだが、それを実現するための手段が分散と連合なのであり、それゆえ私はこの思想を強調し啓蒙していきたいのである。 分散は手段に過ぎず、本当に重要なのはユーザ一人一人の権利と自由である

ただ、私が分散と連合を個人レベルまで推進することを推すのは、「分散 SNS だから」という名前の分類の問題ではなくて、「ユーザの自由を最大限担保するためのサービスの在り方だから」という理由であることは再三述べていきたい。
自由が要らないなら twitter なり何なり好きに使えば良いが、自由を守る努力をせず権利を失ったときには、往々にして既に手遅れになっているものなのでは。

だから「分散 SNS であること」が目的なのではなく、ユーザの自由を保証するという目的こそが最重要と考えており、分散 SNS 原理主義はそれを達成するための思想、手段に過ぎないというのを主張していきたい

よーするに