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

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 を比較してみる (おまけ)

Mastodon しか使っていないユーザにとっては、どうでもいい話かもしれない。 というか、書いてる人をあまり見なかったので書いてみただけで、私の本題は次のセクション以降なのでそっちを読んでほしいです。

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

歴史

私もそんなに詳しくないが、 GNU Social は元は StatusNet という名前(もっと昔はもっと別の名前だったらしい)で開発されており、その歴史は古い。 実装も PHP で行われている。 最近は開発も停滞している(ように見える)。

一方 Mastodon は新しいので Ruby on Rails で開発されている(らしい)。 最初のコミットは 2016-02-21 なので、まだ2年経っていないということになる。 開発も活発である。

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

GNU Social

  • 1.2.x "stable", few updates, well tested code
  • master "testing", more updates, usually working well
  • nightly "unstable", most updates, not always working

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

一方の 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 より大いに優位に立ったと言えよう。

開発言語と実行環境

GNU Social

このブログを燃やすつもりはないので本音を書くのは控えたいが、 GNU Social が PHP で開発されているのは流石に歴史を感じさせる。 しかも master ブランチは PHP 5.5+ 対応であり、 PHP 7 への対応を明言していないのである[3]

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

Mastodon

Mastodon は Ruby on Rails で開発されており、最近のプロジェクトだけあって現代的である。 アセットもビルドが必要な形式で管理されていたりする。 私は最近の web 開発界隈の技術には詳しくないが、どうせ何も考えずとも docker をドキュメント通り動かせばうまくいくようになっているので、開発者からすれば便利なことであっても、ユーザ(鯖缶)の負荷がそこまで大きくなるということにはならないだろう。

Mastodon では docker や docker-compose などが公式で用意されており、ドキュメントも十分にあるため、 Rails や Node.js が必要とはいえ、(高性能を求めない限りは)導入自体は難しくない。 むしろ個人規模のサービスであれば docker を使う機会も多いだろうから、小規模インスタンスでは助かるかもしれない。

拡張機能

GNU Social

GNU Social はプラグインの仕組みを持っている。 内容は UI を変更するもの、プロトコルを実装するもの、 API を拡張するもの、投稿にフックをかけたり内容を変更するもの等々、様々である。 UI を twitter 風にする Qvitter というプラグインは 3rd party では一番有名だろう。

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 / 拡散」などの言葉を使っている。 気に入ったら皆様もどうぞ。

分散/連合 SNS という思想の重要性

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

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

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

Pawoo に引っ越して安心するのは、あまりに呑気

日本において Twitter からユーザが Mastodon へ移行した理由で一番大きなものは、 Twitter の運営者の暴挙にやられたとか、フォローしているユーザがその影響を受けたとかであろう。 この場合、問題の本質は中央集権のシステム、すなわち twitter 社が圧倒的に強力でユーザは権利を著しく制限されている/されうる環境であったというところにある。

それを踏まえて、今の mstdn.jp や Pawoo や friends.nico 等の「大規模インスタンス」の現状はどうか。 サービス運営者を変えただけで、本質は段々と twitter と同様の中央集権に近付いており、 twitter と同じようなリスクを抱えつつあるのではないか。

今のところは、 twitter のような暴挙が行われていないように見えるが、それは今のところそうだというだけである。 twitter だって、きっと最初から暴君だったというわけではない。 自分以外の他人や組織が運営し管理しているということ自体がリスクなのである。

たとえば、「○○文化に理解がある」からといって、それらが全面的に保護されるわけではない。 運営者が取りたくないリスクは回避され、投稿の削除やアカウント BAN が行われることはあるのである(たとえそれが合法であっても、である)。 少なからぬユーザが twitter に見切りを付けて Pawoo や mstdn.jp 、 friends.nico 等の Mastodon インスタンスに流れてきたが、いつか将来事情が変わってそれらにもまた見切りを付けるときが来るかもしれない[9]。 私もそのような未来は信じたくないが、それを想定し事前に備えておくことが重要なのである。実際 twitter でも、凍結されたときには既に手遅れで、引越しをお知らせすることさえ難しくなっている。

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

ではユーザは何をすべきかといえば、大規模インスタンスに集中するのではなく、より分散を積極的にする(理想的には、個人単位でインスタンスを立てる)ことである。

twitter に懲りた人々は、「誰かに権利を縛られ、コミュニケーションや宣伝の生命線を握られながら生きる」という在り方そのものに疑いを持つべきである。 「権利を縛られる相手が悪かった」などと考えることを放棄して問題を回避せずにいれば、やがて訪れるのは“第2の twitter ”からの凍結に怯える日々かもしれない。

そもそも Mastodon (そして ActivityPub や互換ソフトウェア) が twitter より優れているのは、自分のサーバを自分用に立ててネットワーク (fediverse) に参加できること、Mastodon を使えない場合でも、他のサービスを利用したり開発することで fediverse に参加できること、などである。 これらの本質は「自分の面倒を自分で見ることができる」ということであり、「自分以外の他人に管理されない、権利を制限されない」ということであり、そしてまた「文句があるなら別のインスタンス、別のソフトウェアへ逃げることができる」ということである。

「自分の面倒を自分で見る」ことを必要とする Mastodon や GNU Social 、 Pleroma 等が可能にするのは、「自分を縛るのは自分だけである」という在り方である。 これはまた、他人に侵されない情報発信の場を確保できるということでもある。 特に虐げられがちな文化やコンテンツの発信者は、この性質をこそ大切にするべきではないだろうか。 この性質が、他人による(理不尽かもしれない)規制などから自分を守ってくれるのである。

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

自分の面倒を自分で見る

LTL (Local Timeline) はローカルである

自明っぽいが、そうなのである。

ここで私が問題としたいのは、「ローカルタイムラインを重要視する使い方、またそれを積極的に推進することの危うさ」である。 分散 SNS (Federated social web) で我々が手に入れようとしている「自分の情報発信の場を他人に侵されない」という性質は、十分な(可能なら個人や近い単位での)分散とそれらの連合に依拠するものである。 しかし「テーマ別インスタンス」のような棲み分けは、利点もある一方で、分散を妨げる大きな要因でもある (それが典型的に現れているのが、絵を描く人々が Pawoo 等に集まる現象である)。

Mastodon が十分に普及し人口に膾炙しなければ SNS としての意味が薄くなり、そもそも利用の動機が小さくなってしまうということはわかっているし、今は普及のためにユーザ数を増やす段階にあるということも、まあ納得している。 ローカルタイムラインや同インスタンスの同志の存在は、そのための強力な動機であることは現状が証明している。

しかし、ユーザが増えた結果、また twitter やその他中央集権的なサービスと同じ事件を繰り返すようでは仕方がない。 ユーザは、最初に参入したときの動機はさておき、後付けでもいいから自分で自分を守る方法を、自由を守ろうという意思を身に付けるべきである。

タイムラインは自分で作るもの

これも当然といえば当然なのだが、ローカルタイムラインはそれを当然でなくしている。

与えられた餌を食べているだけでは、中央集権サービスの運営者に飼われているのと大差ない。 「誰かが用意してそこにあるもの(タイムライン)に自分も飛び込む」という考え方を、「自分で自分の環境や居場所(フォローとタイムライン)を確保する」という考え方に転換することが必要なのではないだろうか。

Mastodon には、フォローしているユーザをファイルにして保存したり、アップロードして再現する機能がある。 つまり「自分で作ったタイムライン」を再現するための機能だ。 この機能が存在することで、たとえインスタンスが潰れたり自分が別インスタンスに引っ越すことになったときにも、自分のための場所をすぐに確保できるのである。 これもまた分散 SNS におけるユーザの分散と連合を推進するものだ。

ローカルタイムラインで面白いと思ったユーザは、そこで眺めて満足するのではなく、フォローして「自分のための環境(タイムライン)」に取り込むべきである。 そうしていずれ来るかもしれない運営者との決別の時、あるいは自立の時に備えておくこと、これも Mastodon を“第2の twitter ”にしないための極めて簡単な努力の形である[11]

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

私の原理主義的な言動が良くないのかもしれないが、分散 SNS で個人単位への分散を推進するのは、分散そのものが重要だからではない。 ユーザ一人一人が自分の自由を守るために現状で最適な(実現可能な)手段が分散と連合だからである。

コミュニティやサービスが荒れるとき、その原因はコミュニティ等の構成員同士(更に、存在するなら管理者や運営者)で何らかの事柄に合意がとれないからである[12]。 しかし、自分でサーバを用意できるインターネットにおいて、「意見も活動方針も合わないのに同じ場にどうしても存在しないといけない」というケースは、現実でのそういった場合よりも極めて少なくなるはず(そしてそうあるべき)である。

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

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

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

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

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

よーするに

  • 自分のことは自分で守ってください

    • 日常生活における「権利」と同じです

    • そのための手段を Mastodon その他が提供してくれます。 あとはうまく使うだけです。

    • 権利には義務が伴うものですが、 Mastodon 個人インスタンスの場合、たとえば具体的には「月額1000円と多少の知識」とかです。たとえばね。 (お金を使う以外の方法も、探せばあるかもしれませんが。)

  • 少しは自分の身を守ることに関心を持ってください

    • 最初のうちは、理由は楽しいからでもみんながいるからでも何でもいいけど、 twitter に懲りたなら同じ失敗を回避するのが賢明です

    • あなたを一番よく守れるのは、あなた自身です。 自分のために行動を起こしてください

    • 現実を見てください。あなたが必要としている権利、特に情報を発信する権利は、本当に確保されていますか? 実は誰かに(法律以上に、あなたが許容できる基準以上に厳しく)制限されているのに意識していなかっただけではありませんか?

      • 制限されていることに気付いたなら、その制限を小さくする努力をすることができます。 今すぐやる必要はないかもしれませんが、状況が変わってしまう前に、早めになんとかした方がいいと思います。

    • 分散/連合 SNS 、Federated Social Web の考え方は単なる概念というか思想なので、技術的に難しいとかは特にないです。 知ってください。 それで十分です。