マストドン公式のインスタンス一覧が仕様変更。面倒な規則を課すも、たぶん誰も守らない

joinmastodon.org はマストドンの公式ウェブサイトである。そこにはインスタンス一覧が付属している。このインスタンス一覧の仕様が、2019年5月ごろから変更になった。

これまでのjoinmastodon.orgは、instances.social のデータからインスタンス一覧を生成していた。instances.socialでは、インスタンスの登録は自動化されていた。joinmastodon.orgの新しい仕様では、インスタンスの登録は人間がメールを読んで行うので、技術的には後退している。

さらに重要な変更点は、Mastodon Server Covenant という文書が追加され、インスタンス一覧への登録に厳しい制約が課されるようになったことである。その制約の内容は以下。

  1. 人種差別、性差別、同性愛差別、性転換差別に対する活発な処罰。
  2. 定期的なデータのバックアップ。
  3. 緊急時にサーバーをメンテナンスできる人が複数いること。
  4. インスタンスを閉鎖する3ヶ月前にはユーザーに告知すること。

とはいえ、この規則を真面目に読むのは時間の無駄である。実際にjoinmastodon.orgのインスタンス一覧を見てみると、中小のインスタンスも数多く掲載されており、このような厳格な体制を構築しているとはとうてい思えないインスタンスが多数を占めている。日本の鯖缶たちは法フィリアが多く、これらの厳格な規則をどのように遵守しようか思い悩んでしまうかもしれないが、海外のハッカーたちはそんなことはお構いなしというわけだ。そして、これらの規則を遵守する意志があるかどうかは自己申告であり、特に審査は行われていないし、証明を求められることもない。そもそも、joinmastodon.orgの運営者 (それはGargronその人である!) には、そのような能力も時間もない。結局のところ、このような規則が守られるかどうかは誰も気にしておらず、くよくよ思い悩むだけ時間の無駄である。

そもそも、マストドンのインスタンスの一覧なんて誰も必要としていないのかもしれない。日本語圏ではいまだにk52とかいう腐臭を発するゴミが幅を利かせている。みんな登録ユーザー数の偽装でもすればいいと思う。

この規則を遵守することは可能か?

それはそれとして、Mastodon Server Covenantという偉そうな名前の規則をちゃんと守ることが可能か、ざっとでいいので検討してみよう。

人種差別、性差別、同性愛差別、性転換差別に対する活発な処罰

これは言われなくてもちゃんとやってほしい。ヘイトスピーチを規制することは、マストドンのインスタンスに限らず、すべてのウェブサイトにとっての義務である。

そして、ヘイトスピーチの排除は、小規模なインスタンスほど容易である。管理者の目が届きやすいし、住民の相互監視もある。これに対して、中小企業が実力以上に巨大なインスタンスを保有している場合には、対応がおざなりになりそうだ。

例えば Patriot_silver@mstdn.jp というユーザーは、過激なレイシストであるが、垢バンどころかサイレントにすらなっておらず、ローカルタイムラインに公然とヘイトスピーチを垂れ流している。mstdn.jpがこの条項を遵守するのは不可能だろう。

定期的なデータのバックアップ

これはすでに実現しているインスタンスも多いだろう。ただ、資金難のインスタンスは、背伸びをしてバックアップにまで手を出さないほうがいいと思う。

緊急時にサーバーをメンテナンスできる人が複数いること

これは個人運営のインスタンスでは実現が困難であろう。この条項は、信頼できる人物に、サーバーの管理者パスワードを渡すということを意味する。そのような、全面的な信頼を預けられる人物を、見つけることができるだろうか?

これに関連しそうなトラブルの事例として、モデレーター権限の例が挙げられる。knzk.meでは、モデレーター権限の付与と剥奪をめぐって、人間関係に亀裂が生じたことがある。余談だが、マストドン日本語ウィキのある執筆者が、knzk.meの記事をめぐって関係者とトラブルになったことをきっかけに、この件が明るみに出たことがあった。このような経緯から、マストドン日本語ウィキでは、この件について記述しないことが申し送りとなっている。

話を戻すと、サーバーの管理者パスワードを渡すことは、モデレーターとは比較にならない強大な権限である。私たちは、このような強大な権限を共有すべき、信頼できる人物を見つけることができるだろうか?

ただし、形式的には、親兄弟にでもパスワードを渡しておけば、この条項をクリアすることができる。サーバーをメンテナンスできる人が複数いると言っても、実際にサーバーの修復に成功することまでは要求されていないからだ。

インスタンスを閉鎖する3ヶ月前にはユーザーに告知すること

この条項は手の込んだいたずらに思える。すでに閉鎖を決めているインスタンスが、インスタンス一覧に掲載されることを希望するとは思えないからだ。

とはいえ、過去に告知なしでインスタンスを閉鎖したことがある法人が、現存する他のインスタンスについても同様の疑いをかけられることはあるだろう。botdon.netが事前の告知なしに (事後の告知のみで) インスタンスを閉鎖したことは記憶に新しい。合同会社きぼうソフトが、mstdn.jpやmastodon.cloudといった主力のインスタンス (他人からわざわざ譲り受けたインスタンスでもある) をスナネコすることは考えにくいが、now.kibousoft.co.jpかplero.maあたりは、予告なしに閉鎖されてもおかしくない状況である。

別の観点から言えば、事前の告知は必要であるとしても、3ヶ月という期間は長すぎるという論点もある。friends.nicoが閉鎖を告知してから実際に閉鎖されるまでの期間は、ちょうど1ヶ月であった。この告知期間が短すぎるという意見は耳にしたことがない。

分散SNSは個々のインスタンスに過剰品質を求めるべきでない

Gargronが示した4条項のうち、第1条を除く残りの3条項は、いずれもサービスの継続性に関するものである。データをバックアップすること、緊急時にメンテナンスが可能であること、サービス終了を事前に告知すること。これらは、プロプライエタリなウェブプラットフォームであれば、当然に求められる品質である。しかし、これは分散SNSのインスタンスにとっても必要なのだろうか?

分散SNSのユーザーたちには、あるインスタンスがダウンしたときに、別のインスタンスに「避難」するという行動が普通に見られる。歴史的な話をすれば、分散SNSという発想の源流のひとつは、ツイッターが頻繁にダウンしていた時期に、あるインスタンスがダウンしてもSNSを続けられるようにしたいというものだった [横田真俊, 2017]。分散SNSにおいては、個々のインスタンスのサービス継続性が低品質であっても、ネットワーク全体として生き延びることができる。Gargronは、厳格な規則を振りかざすよりも、このような柔軟な発想を大切にすべきだろう。

投稿者: Hakaba Hitoyo

墓場一夜

“マストドン公式のインスタンス一覧が仕様変更。面倒な規則を課すも、たぶん誰も守らない” への 1 件のフィードバック

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Google フォト

Google アカウントを使ってコメントしています。 ログアウト /  変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください