分散SNS Advent Calendar 2018参加記事。
#mmt18 Mastodon Meetup at Tokyo参加報告 | LTLこそがMastodonの本質なのか？を読んだ。このsenookenの記事では、マストドンにプラグイン機構を導入することを主張している。この意見に対して、私は、半分賛成、半分反対である。マストドンの開発体制に闇があるという課題の認識は共通するが、その解決策がプラグイン機構であるとは思えない。
マストドンの開発体制は妥当か？
senookenの記事では、「友達と遊べなくて寂しくなった」というGargronの発言が引かれている。私も、この発言を見たときには、不吉なものを感じた。ドワンゴからの退職を水面下で進めていた時期のぬるかるを連想させたからだ。
とはいえ、マストドンの開発そのものは、いまのところ、そこまで悪い兆候は見られない。イシューは無視されるが、これはマストドンではいつものことで、これまでずっとそれでうまくやってきた。プルリクエストの消化は、それに比べれば順調だ。一例を挙げれば、(NFSWにかかわらず) すべての画像を非表示にする設定という日本発のプルリクエストは、速やかに受理されている。
他の不安材料も挙げてみよう。プロフィールで紹介するという機能はどうだろうか？ 私はこの機能に対しては「Endorsement is some kind of worship or flattery.」と猛反発したが、ここでは別の観点から見てみたい。この機能は、Gargronがユーザープロフィールページのレイアウトを変更しようとする過程で、画面上の空間を有効利用するために導入されたという経緯がある。これは、新機能を導入する動機としてはちょっと軽率である。悲観的に見れば、マストドンにはすでに本質的な新機能を導入する余地がなく、開発が自己目的化しているようにも見える。
まだ言い足りないこともある。マストドンの公式ドキュメントが https://source.joinmastodon.org/mastodon/docs に移動したとき、List of appsページは失われてしまった。かわりに https://joinmastodon.org/apps が導入されたが、掲載されているアプリは少なく、選考の基準は不明瞭である。別のアプリ一覧へのリンクを追加する提案と、Whalebirdを追加する提案は、長らく放置されている。マストドン本体は良いとしても、関連するウェブサイトにまでは手が回っていないのかもしれない。
最後に。GargronはGalleryという、やや大きすぎる名前のソフトウェアを公開した。これは機能的には#tusktowallとほとんど重複する。Gargronが先行事例をサーベイせずに再発明したことには、率直に言って失望されられた。もしGargronがtusktowallへのリンクをツイートしていれば、tusktowallのアクセスは飛躍的に増加したかもしれない。しかし、私たちの世界はそちらの方向に進むことができなかった。
老婆心ながら、Gargronは信頼できる副官に権限を移譲すべき状況にあるように見える。マストドン公式ブログはTremaine Friskeに移譲されているが、更新が停滞している。山岸和利はマストドン公式リポジトリのコミット権限を持っているが、その行動はあまり野心的ではない。あるいは、新都心に https://source.joinmastodon.org/mastodon/joinmastodon のコミット権限を与えるのはどうだろうか？ 新都心は、joinmastodon.org の日本語訳と、マストドン日本語ウィキの開設を行った人物であり、過去の実績から言えば適任に思われる。さらにトリッキーな案としては、glitch-socの開発者たちを取り込み、代表者にマストドン本体のコミット権限を与えるのも良いかもしれない。
PleromaとMisskeyの開発体制
senookenはGNU socialのユーザーの立場から、マストドンをそれと比較している。私は、長らくfreezepeach.xyzとsocial.pzn.lgbtのユーザーではあったが、GNU socialの内部構造には詳しくない。むしろ、PleromaとMisskeyのコードに触る機会があり、小規模なプルリクエストをいくつか通している。このようなバックグラウンドの違いからすると、senookenにとってプラグイン機構が魅力的であることと、私にとってそうでないことは、自然ななりゆきに思える。
Pleromaは小規模なプロジェクトであり、プログラマーの数は常に不足している。新機能の導入に慎重であることと、コードをミニマムに保つ努力をすることで、この弱点を補っている。
Pleromaのマージリクエスト (GitLabではプルリクエストことをこう呼ぶ) の受理は迅速である。これはkaniiniというコミッターの存在が大きい。Pleromaの作者はlainであるが、lainは日曜プログラマーであり、Pleromaに割く時間は少ない。大規模な新機能や、長期的な構想は、lainが決定する。kaniiniは小規模なマージリクエストを積極的に受理している。kaniiniの行動はやや拙速であり、もちろんコードをレビューしてからマージリクエストを受理しているものの、稀にその行動がlainによってリバートされることがある。(例: Markdownの導入とそのリバート。)
Pleromaが迅速にマージリクエストを受理することと、インスタンスの設定でOn/Offできる機能が多いことは、結果的に、プラグイン機構を発明しているようにも見える。あるインスタンスが独自機能を実装したとき、それをマージリクエストにまとめれば、Pleroma本体にマージされることは十分に期待できる。インスタンスの設定でOn/Offを切り替えられるようにしておき、デフォルトをOffにすれば、他のインスタンスや開発者も受け入れやすい。
lainが長期的な方針を決定し、kaniiniが当座の処置を迅速に進めることは、これまでのところ、良い分業として機能している。マストドン日本語ウィキにおける新都心と嗤民の関係も、これに似ている。
Misskeyは作者であるsyuiloが十分に強く、補助的な人員を必要としていない。村上はそれに近い立場にいるが、もっぱらmisskey.xyzのインフラを担当している。それでいて、開発の活発さは、毎日のように新しいマイナーバージョンが発行されるほどである。他の開発者によるプルリクエストも迅速に受理される。
プラグイン機構は何を解決するか？
senookenの記事が主張するように、diaspora*のプロトコルに対応するプラグインは魅力的だ。しかし、そのプラグインの開発は、これからも活発に行われるだろうか？ プラグイン機構は開発の停滞という問題を分割するし、それはそれで良いことではあるのだが、私たちは、分割された複数の問題に改めて向き合う必要がある。
私の観測範囲から見た結論としては、開発の停滞と独善に対する最良の対策は、信頼できる副官に権限を移譲することである。現時点では、Gargronはそれに失敗しているし、syuiloはそれを必要としていない。いずれにせよ、その結果、あんのたんやNCLS (現在は別の名前で活動しているらしい) がマストドンのコミット権限を得ることになってもかまわない。もしマストドンがevilになったとしても、他に競合する実装はいくらでもある。もちろん、GNU socialも、重要な選択肢の一つだ。
うなすけ
All senooken JP Social content and data are available under the Creative Commons Attribution 3.0 license.