そろそろマストドンについて語っておくか

世間ではマストドンが流行っている。結論から言うとマストドンは思想的にも設計的にも失敗しているのでお祭りのように一時の話題になった後、急速に忘れ去られる運命にある。

マストドンを語るには、まずマストドンが実装しているプロトコルであるOStatusについて説明する必要がある。これはもともと、StatusNetというソフトウェアが提唱したプロトコルで、Twitterようなマイクロブログの更新通知のためのプロトコルだ。StatusNetは今は名前を変えてGNU Socialとして自由ソフトウェア財団の傘下になっている。

マストドンはいうなればGNU Socialの互換実装だ。その基本的な思想や設計はGNU Socialと同じだ。どちらも現在の大手ソーシャルネットワークサービスに共通の問題に対処しようとしている。

問題とは何か。権力の一極集中である。TwitterにしろFacebookにしろGoogle+にしろ、そして現在ブログの文章を主にホストしているBloggerやGitHubも、筆者より強い権限を持っている。もしこの文章の内容が、彼らの気に食わないものである場合、彼らの一存のよりこのブログは削除、改変、監視といった検閲を受ける。これはTwitterやGoogleが技術的にサーバーを管理しているために生じる問題だ。

この問題に対処するにはどうすればいいのか。我々全員がサーバーを運営できるようになればいい。インターネットの当初の目的は、全員がサーバーを運営できるようになることだった。残念ながら、ハードウェア資源の制約、IPv4アドレスの枯渇、NAT、不思議な日本国内の法律（プロクシーサーバーを運営する出稼ぎ中国人を日本国政府が都合よく別件逮捕するのに使われている通信事業者法）により、我々は自由にサーバーを運営できるようにはなっていない。しかし、少なくともサーバーの実装であるソフトウェアを提供し、サーバーの設置をかんたんにしてはどうか。

GNU Socialやマストドンはこのような思想で設計された。Twitter社の方針が気に入らないのであれば、別のサーバーに移住すればよい。どのサーバーも気に入らないのであれば、自分でサーバーを立ち上げればよい。

思想としては悪くはないのだが、技術的にはあまりよろしくない。GNU Socialの前身StatusNetは2010年から開発が始まっているが、一向に主流とならない。主流となっていないソフトウェアには主流になれない問題があるのだから、その互換実装を作っても主流となるわけがない。では一体何が問題なのか。

サーバーの設置は自由なソフトウェア実装が存在するだけではだめで、十分な性能を持ったコンピューターと十分なネットワーク帯域が必要になる。GNU SocialはPHPで実装されているし、マストドンはRuby on Railsで実装されている。実行には普通にWebサーバーを運営するのと同じだけの煩わしさがある。

これだけサーバーの実行が面倒だと、結局、既存のサーバーを利用するものが大半だろう。その結果、どこかの学生が1個人が運営している怪しげなサーバーに人が集中する。これはとても問題だ。

信用の話をしよう。Twitter社と一個の人間、どちらが信用できるだろうか。これは圧倒的にTwitter社である。何故かというと、邪悪に至るまでの障害の多さによる。

一個の人間が運営するサーバーで邪悪を為すのは簡単だ。一個の人間が邪悪になるだけでよい。一方、Twitter社は法人格として登録をしており、税金の支払いのために収支を国家に報告する必要がある。Twitter社には現在3000人以上の被雇用者がいる。Twitter社が邪悪をなして、それが露見しないようにするのはとても難しい。Twitter社内の一個の人間がなした邪悪は、速やかに発覚する。Twitter社が社をあげて邪悪をなそうとした場合、3000人以上いる社員のうちの少なくとも数十人から数百人はその邪悪が為されていることを知るだろう。そのうち、一人でも正義感あふれる人間がいて公に邪悪を暴露した場合、邪悪が露見する。

したがって、一個の人間によって管理されたサーバーより、何百人何千人もの人間が関わる法人の方が邪悪に至るまでの障害が多いという点で、信用できるのだ。

事実、マストドンの初期の主流サーバーでは検閲が行われている。どのような検閲かと言うと、ドイツやフランスの法律の法律に違反しないように、ナチ党のシンボルであるハーケンクロイツ、ホロコーストの否定といった内容が検閲されていた。マストドンはむしろ検閲をやりやすくするプラットフォームであると言える。権力を一個の人間に委ねると、その人間の裁量で検閲が行われるわけだ。もちろん、これは効率のいいハラスメント対策にもなるという主張もあるだろうが、それはつまり独裁政権は一人の独裁者の判断だけで政治が進むので効率的というのと同じだ。たしかに効率的だが、失敗に至る道も効率的にたどることができる。かの毛沢東も国力を増そうと大躍進政策を行い、かのポル・ポトも子供によりよい教育を施そうと子供を家庭から取り上げて国家が管理する完璧な教育を施そうとした。かのルーズベルトとトルーマンは日本に降伏させて日本の民間人を守るために日本を無差別爆撃し核爆弾を二回投下し、日本の民間人の虐殺に貢献した。地獄への道は善意で舗装されているというわけだ。

一個の人間がサーバーを管理する場合に憂うべきことは単に恣意的な検閲や改変だけではない。大半の人間はパスワードを再利用するという問題だ。

xkcd: Password Reuse

なんか適当に便利な利用に登録が必要なWebサービス作ったらユーザーIDとパスの組み合わせが大量に手に入るじゃん。やったね。さあ邪悪を行おうぜ。でもなにする？

そして、日本のマストドンのサーバーで注目を集めてユーザーの急激な増加を得た管理者が、某クラウドベンダーからホスティングを促されたり、別の某クラウドメンバーでホスティングしようと動いているなどという話をみるにつけ、もはや悪いとこ取りの様相を呈している。一個の人間が管理する上に、インフラは自分で所有していない。

マストドンとGNU Socialは残念ながら設計的に間違っている。結局、やっていることはTwitter風サーバーのソフトウェア実装を提供したというだけで、解決しようとした問題は何一つとして解決していないばかりか、大半のコンピューターリテラシーの低い者にとっては悪い結果になるだろう。

では、本当に技術的に正しい設計とは何か。まずすべての参加者はサーバーでもありクライアントでもある、完全にP2Pメッシュネットワークを構築し、その上にマイクロブログサービスを実装すべきである。自分のデータは全てローカルに保持する。

問題は、これは15年前、P2P技術が夢の技術のように叫ばれていた時代に試みられたことだ。あの当時は様々なP2Pメッシュネットワーク上に構築されたチャット、掲示板、ブログ、Webページ、ファイル共有などの実装が乱立していた。その実装はどれもすべての参加者はコンピューターの性能やネットワーク帯域を別にすれば平等であり、全員がローカルで同じソフトウェアを実行する作りであった。

そのような状況ですら、当時も今と同じ問題を抱えていた。ローカルでそのようなソフトウェアを実装するのは大変にコストがかかるので、大半のものは他人が実行しているサーバーにアクセスして、そのサーバー経由で参加していた。残念ながら当時のP2Pメッシュネットワークによる全員が平等なネットワークの構築は失敗した。当時の実装の殆どは秘密で不自由なプロトコルやソフトウェア実装で非効率なため打ち捨てられ、残ったのは、BitTorrentプロトコルのような詳細が公開されていて当時のソフトウェア実装も自由で使いやすかったものだ。BitTorrentプロトコルは大容量データの配信に都合がいいもので、これは今も自由なOSのISOイメージの配布とか、ゲームやサーバーのアップデートパッチの全コンピューターへの効率的な配布といった健全でまともな用途にも使われている。その他の当時の有象無象のP2Pプロトコルは、筆者の知る限り絶滅した。

筆者が思うに、真に自由な通信手段のためには、物理層からのP2Pメッシュネットワークの構築が必須だ。例えばコンピューターが無線通信装置を搭載して近隣のコンピューターと通信したり、ストレージをスニーカーを履いた足で運んだりして、物理層からのP2Pメッシュネットワークを構築し、その上にNamecoinのようなP2Pかつ計算資源の多いものが正しいという名前解決の仕組みを導入し、公開鍵署名によって特定の秘密鍵にアクセスできるものによって発信されたデータだと証明できる通信でチャットや掲示板やWebページやメールの仕組みを実装し、すべてのネットワーク参加者は平等である仕組みがほしいが、これとて最終的には計算資源とネットワーク帯域と電力の強いものが正しい弱肉強食の世界になることが予想されるので、世の中は難しい。

とりあえずの対策として、筆者はこのブログの内容をgitで管理している。そのgitレポジトリはGitHubでもホストしていて、GitHub Pagesでも閲覧できる。こうすることによって、BloggerとGitHubが同時に検閲された場合でもローカルに全て残っているので、私はデータを失わない。外部のホスティングサービスがすべて検閲され、かつ、私の所有するストレージが全て強奪、破壊されたときのために、今、誰でも簡単に"git clone git@github.com:EzoeRyou/blog.git"というコマンド一発で複製できるようにしておくのも重要だ。gitレポジトリの複製が存在する限り、私は最新のコミットの40文字のハッシュ値を覚えておけば改変されていないことが保証できる。