4月28日に角川アスキー総研主催の「マストドン会議」に登壇しました。
会議の感想
マストドン会議、参加者も遅れてくるし、登壇者も遅れてくる。そんな時間押し押しのイベントでした。一言で言えば運営も雑なんだけど、参加者も雑な感じでちょっと昭和っぽい感覚を覚えました。（昭和体験したことないけど）でも、そんなところがいいんだと思います。
前半は、僕とぬるかるさん、さくらインターネット研究所の鷲北所長で、4月14日からここまで何があったのかが語られました。ぬるかるさんの手書きのプレゼンが若者っぽいなと思いました。未来ではきっと紙ではなくタブレットに手書きをするのが（技術向上のおかげで書きやすくなっていて）当たり前になるのかな、なんて。前半はNHKのスタジオパーク並にまったりトークが進んでいました。
問題は後半からです。業界の古残古参が遅刻して乱入してきて、デートをキャンセルしてきたと言っていたと思ったらこんどは「プレゼンしたいから席を外してくれ」とかやりたい放題です。正直、こうでもして自分の話す時間を作っていくスタンスと行動にすごいなぁと感じました。しかしプレゼンの内容は企業PRでした。会場の人やニコ生で視聴していた人はCM視聴の謝礼を受け取るべきです。ほかにも金髪の人が僕の隣りに座って話していましたが、政治の話をしていたので聞いていませんでした。江添さんはマストドンに使われている技術のクソさとGNUやAGPLライセンスの思想の素晴らしさについて語っており、正しさのある人だなぁと思いました。実物は、話し方や動きが可愛らしくてブログやTwitter、マストドンでの発言の仕方にギャップを感じましたが、たぶんあれはアイコンのせいです。アイコン変えたほうが良いです。本当はかわいいのだから。
きょうのイベントでは僕の話す時間がなかなか無かったので、きょう言えなかったことを書き残しておきます。
ぬるかるさんとのストーリー
ぬるかるさんとは、もともとTwitterで相互フォローの関係にありました。それまではTLでよく見かけるなという程度。4月14日の朝に、ぬるかるさんが前日からサーバの調達に困っているのを見てDMしました。それが朝の9時ちょうどのことです。ちなみにMicrosoft Azureの人は9時14分にぬるかるさんにメンションしているので、タッチの差で連絡していました。
少し話しが逸れますが、マストドン会議のなかで、僕とさくらの関係については「深い縁がある」としか語られていないので、マストドン会議を視聴されていた方はどれくらいの縁なのかご存じない方も多いと思います。もともと東日本大震災のときに回線がパンクしていたところをさくらインターネットの田中社長に（僕がぬるかるさんに連絡したように）Twitterで助けていただいたのが始まりです。その後セキュリティが分かる人ということでさくらのクラウドの開発に参加し、ゲヒルンという僕がやっている会社もさくらインターネット東京支社の中に移りました。今思い返せば、名古屋市が災害で回線がパンクしたときには電話してデータセンタを貸したりして、インフラに困っている人にさくらのクラウドを無償提供する窓口になることが多かったです。そのあといろいろなことがあって2016年にゲヒルンはさくらインターネットの100%子会社になりました。ということで、さくらの子会社の社長やるくらいには、「深い縁がある」わけです。
4月14日以降は、ぬるかるさんとさくらの窓口として連絡を取りつつ、さくらの中で無償提供のための稟議をお願いしたり、話をすすめるのに調整をしました。鷲北所長はじめさくらのエンジニアたちがどう支援できるのかみんなで悩み考えた2週間でした。
ぬるかるさんは、自宅サーバからさくらのクラウドにインフラを移行するために作業をはじめましたが、ここでDBリセットが行われます。なんとも豪快です。イベントの中でも鷲北所長は「事業者なら4万ユーザをリセットするなんて考えられない」といっていました。たしかにさくらの会員IDが4万ユーザも吹っ飛んだら大変なわけですが、そこは無料サービスの黎明期というかユーザみんなで優しく見守っているところもまた良さがありますね。
さくらの人たちがぬるかるさんに会いたいということで調整したところ、ぬるかるさんがゼミで忙しいのでということで少し先に会うことになりました。しかし、事態はどんどん急速に進行し、ぬるかるさんがさくらに遊びにくる前にドワンゴさんへの入社のニュースがあったりと、ぬるかるさんがさくらに遊びにくるまでのあいだに目まぐるしい1週間を過ごしました。本当は無償提供の今後についての確認などをする予定だったわけですが、ドワンゴさんの支援が入るということで無償提供についてもドワンゴさんとの協議が必要となったわけです。このことはマストドン会議のなかでも鷲北所長の口から語られていました。もうびっくりの連続だったわけです。
今回のマストドン無償化では、鷲北所長やさくらの人たちの熱意も非常に高く、多くのユーザが驚くくらいの金額が無償化されています。アスキー総研の方がマストドンのことを「新しいおもちゃ」と呼んでいましたが、その新しいおもちゃを動かすのに莫大なお金が掛かっています。mstdn.jpをお使いの方は、さくらやドワンゴさんに感謝の念を送ってから使い始めると御利益がありそうです。
エンジニアが前のめりになってマストドンを開発する理由
ここからはきょう話せたら良かったことについて書いていきます。
エンジニアがマストドン開発に手を染める理由です。一言で言えば自分で開発に参加できるからです。これまで、Twitterには公開されないAPIや不便を感じるところなどがありましたが、それらはTwitterにしか直せません。Twitterのサービスを改良するにはTwitterに入社するほかないのです。しかしマストドンはオープンソースですから、自分でプルリクエストを送って修正を送りつけたり、Issueで不具合を相談したりすることができます。仮に本家にプルリクエストがマージされなかったとしても、自分のインスタンスだけでやっていけばいいわけです。
この自分の手でなんとかできるというところが、エンジニアが楽しめる部分だったりするわけです。また、たとえコードを直せなくてもサーバを立てる作業そのものが好きだったりします。
発信専用なのか、コミュニティ運営用なのか
企業がマストドンのサーバを立てるときにunnerv.jpのように発信専用にするのか、ニッポン放送のTUNERのようにリスナーと番組をつなぐコミュニティ運営用にするのか、選択する必要があります。
ここで、発信専用インスタンスと、ユーザ登録機能を開放したコミュニティ運営用インスタンスのメリットを見てみましょう。
発信専用インスタンスのメリット
- 負荷が少ない。
- アカウントや投稿内容を好きなように管理できる。
- インスタンスのアカウントが全部公式だとわかる（偽アカウントが作成されない。）
- 不正な投稿や画像のアップロードが行われる心配がない。
- 多少サーバを止めても怒られない。（そのインスタンスのアカウントが誰も外部インスタンスのユーザをリモートフォローしていない場合）
コミュニティ運営用インスタンスのメリット
- ファンクラブとしての機能
- ファン同士の交流
- 自社に関するローカルタイムラインを構築できる
- SNSの醍醐味を体験できる
- Pawooやfriends.nicoのようにサービスのアカウントとの結びつきを強化できる。
このメリットを見てお気づきの人もいるかもしれません。それぞれのメリットはそれぞれのデメリットになるということです。
コミュニティ運営用インスタンスでは、不正なユーザや不正な投稿に注意が必要です。児童ポルノを共有する場になったり、マルウェアへの命令が記述されるC&C（コマンド＆コントロール）サーバとして使われるおそれがあります。マストドンのDM機能を使えば、他の人やインスタンス管理者の気づかないところで、そのインスタンスに違法なコンテンツがアップロードされ、インスタンス管理者が気づかないまま自分の設備に違法コンテンツを保持することになりかねません。誹謗中傷や権利侵害、リモートフォローによる他のインスタンスへのスパム投稿や通報にも対応していかなくてはなりません。インフラ事業者やサービス事業者には日々、警察機関等からの照会があります。これらの対応を行うことを想定してコミュニティ運営用インスタンスを作らなければなりません。不正ユーザ対策は、ユーザ登録機能を開放したインスタンスに起こりうるリスクです。ユーザがDMを使って連絡し合う場合には、届出電気通信事業者になる必要があるかもしれません。ほかにも当然、負荷が高まればそれなりに投資も必要です。これはmstdn.jpでも課題になっており、そこをドワンゴさんの経験を活かせるということでぬるかるさんの入社の話が進みました。
こうした費用と人のリソースを投入できないと、なかなかマストドンをユーザに開放することは難しいわけです。
一方、僕が推奨しているお一人様インスタンス・発信専用インスタンスはこれらのリスクを回避し、アイデンティティをドメインで確立していくのに良い方法だと考えています。
マストドンの向こう側に「ホームページ」の再来をみた
いまマストドンは「SNS」として捉えられていますが、僕は「ホームページ」だと捉えています。最初にマストドンのお一人様インスタンスの可能性に気づいたとき、 マストドンの向こう側にホームページの再来をみました。
1990年代の終わりから2006年くらいまで独自ドメインでホームページを作ることが流行りました。2001年にロリポップ、2004年にさくらのレンタルサーバがサービスを開始して個人でも気軽に自分のドメインで自分のWebサイトを持つようになりました。あの頃は中高生や若い世代の人がオリジナル小説を書いたり二次創作の絵を掲載していました。そして「相互リンク」という文化がありました。普段は発信専用のホームページですが、アクセスカウンタのキリ番報告BBSやゲストブックという一言書き残しておける掲示板の機能を持つサイトも多かったです。このゲストブック、携帯電話がなかった頃の観光地にあるノートや駅の伝言板みたいでしたね。個人的にはホームページの文化がとても好きでした。
そのあと、ホームページはブログに変わっていきました。ブログになってから、ゲストブックは廃止され記事ごとにコメント機能がつきましたが、コメント機能のほかに、ある記事について書かれたことをその記事のサイトに通知する「トラックバック」「ピンバック」という機能がつきました。ほかにもブログにはRSSやATOMフィードが提供され、更新情報を閲覧者が巡回できるようになりました。
マストドンには、これらの要素が多分に含まれています。まず自分のドメインで作れるということ。自分の文章、自分の創作物を気軽に投稿できること。リモートフォローが相互リンクの手続きを簡略化したこと。そして更新をリアルタイムに他のユーザに通知し、その投稿に返信したりお気に入りにいれたりブーストしてリアクションできるようになったこと。これらのホームページとブログの文化がSNSっぽいインターフェイスに入り込んできたというわけです。これがマストドンの正体です。
マストドンの下にあるOStatus
マストドンを支えるOStatusは、もともとマイクロブログの更新通知をやり取りするために作られており、ATOM、PubSubHubbub、Salmon、Webfingerといったブログと通知、ユーザの発見のための仕組みが組み合わされたものです。源流はブログとフィード公開・購読・更新通知ですから、ホームページ感やブログ感があるわけです。
そこにSNSの皮をかぶせているのがGNU Socialやマストドンです。一皮むけば中身はホームページ。
マストドンでは https://ostatus.isidai.com/@isidai.atom のように、ユーザ名に.atomをつけるとATOMフィードを購読できます。というわけで、RSS/ATOMフィードリーダでマストドンの投稿を読むのも面白いかもしれません。
Publishは大変、Subscribeは楽
さて、マストドンが富豪的な作り方をしていることを差し置いても、OStatusを使っている以上、いずれはスケールしなくなると言われていますがなぜでしょう。
それは、PUSH通知に問題があります。一般的にサーバは大量のアクセスを受けるのには慣れていますが、大量のアクセスを発生させる方は下手なのです。大量のアクセスはCDNやロードバランサなどでスケールアウトしていくことができます。つまりSubscribeされるのは良いのです。いままでのRSS配信やWebサイトの配信はCDNでキャッシュしておけば悩まずに済みました。しかし、色んな所にPUSHを送るときには、自分のサーバは元気でもPUSH先のサーバが元気でいてくれる保証はありません。PUSH先が応答しないとタイムアウトまで待たされたりキューが詰まってきます。このPUSHすることが大変なのです。
加えてマストドンは、ユーザごとにPublish・Subscribeが管理されているためオーバーヘッドも大きく、管理が大変です。この仕組はなんとかしてインスタンス間でPubSubを一本にまとめるなど効率的な通信の仕方にしてもらいたいなと思いますが、OStatusの仕様を改める必要がありマストドンだけなんとかすればいいわけではないところも課題になっています。
PuSHと気象庁XML
さて、このスケールしないPubSubHubbubを使っている国の機関があります。国土交通省気象庁というところです。PubSubHubbubはPuSHとも言われます。
気象庁XMLは、PubSubHubbubを使って配信されます。気象庁XMLが始まったばかりのとき、応答しないサーバがいるせいなのか、よく気象庁XMLが配信されてこなかったり大幅に遅延することがありました。多分、いまのOStatusの問題を何年も前に気象庁は経験しているはずです。
気象庁XMLが送られてこないとき、僕は気象庁に電話をして「落ちてますよ」と何度か報告しました。わりと気象庁もフランクで、「あ、どうもどうも直して来ますわー」的な感じでした。誤解のないように言うと、気象庁XMLのPubSubHubbubによる配信は試行段階ということになっており、報道機関や自治体、気象会社などはもっとちゃんと法人向けにSLAが高く配信される気象業務支援センター経由で情報を受け取っているので、気象庁XMLのPubSubHubbubが死んでいても国民への情報伝達には影響がないので気象庁の担当者も暢気に対応してくれるわけです。
もしかしたら、マストドンの運用は気象庁が得意だったりして、なんて思っています。そして、PubSubHubbubはクソだとずっと思っていた僕が、PubSubHubbubを使ったOStatusで防災情報を配信しているのだから、自分でも驚いています。
防災情報を配信・受信するのは得意かもしれない
マストドンの登場で、リモートフォローがUIから簡単できるようになりました。これは別の言い方をすると、PubSubHubbubのSubscribeがワンクリックでできるようになったということです。気象庁XMLの受信には、自分でSubscriberを構築して、メールでユーザ登録を申請して、気象庁の人が作業して購読するという人力で大変なやり取りがあったわけですが、例えば気象庁がOStatusでアカウントごとに各ジャンルの気象庁XMLを配信すると、とってもかんたんに購読できるようになるわけです。
まえに諸多日記（このブログ）のなかで、PUSH型RSSだと説明したことがありました。いままで天気の情報もRSSで配信されたりしていましたが、PUSH型RSSとして気象情報や行政のお知らせをアカウントをわけて配信していくと良いわけです。
アカウントを複数作って情報を細分化した防災情報配信の具体例は https://unnerv.jp/about/more を見れば一瞬で理解できるはずです。
Twitterに233アカウント作ってボットで情報を配信することは難しかったわけです。
まとめ
きょうのマストドン会議でほかの登壇者は、マストドンをSNSとしてとらえ、この分散型SNSがどうなっていくのかについて主眼に据えて話が進んだように思います。
僕が見ていて楽しいのは、マストドンの皮を一枚剥がしたところについてなんだなと思いました。
