マストドンを始めたら誰をフォローすべきか?

マストドンを新たに始める人は誰をフォローすべきか? マストドンでユーザー登録を行うと、誰もフォローしていない状態で始まる。ローカルタイムラインと連合タイムラインは流れていくが、ホームタイムラインには何も流れてこない。

Twitterではどうか? Twitterにユーザー登録すると、まず大量の推奨ユーザーが表示され、フォローするかどうかを選択させられる。ここで表示される推奨ユーザーはタレントやニュースサイトなどで、率直に言ってあまり興味をそそられるものではない。

ユーザー登録を終えてTwitterを使い始めると「おすすめユーザー」が表示される。これはソーシャルグラフ (フォロー/被フォロー関係) をもとに推薦されるので、これに従ってユーザーをフォローしていくと、「クラスター」というフォロー/被フォロー関係のかたまりができることになる。

マストドンを新たに始める人は誰をフォローすべきか? この課題に一応の回答を示したのが、マストドン (Mastodon) ユーザなら必ずフォローしたい! アカウント一覧 – 運営・有名人・メディアほか と マストドン初心者がホントに知りたいのは「Mastodonが楽しめるフォローの方法」 である。これらは同じ著者による記事なのだが、前者は後者によって「有名アカウントだからと言ってトゥートが面白いとは限りませんし、アカウントが生きてるかどうかも不明です」と自己批判されている。

マストドンの推奨ユーザーリストを作ろうとする試みは、他にもいくつか存在する。User Localによるもの は、並び順としてフォロワー数を用いている。推奨ユーザーリストとして使われていることを意図しているかどうかは不明だが、MASTODONヤベーやつリスト というリストも作成されたことがある。

私は、マストドンの脱中央集権はユーザーにもあてはまると思っていて、有名人がマストドンではたいして評価されない文化が続いてほしいし、アルファマストドナーもできれば出現してほしくない。そう考えると、有名人のアカウントのリストフォロワー数順のリスト は、推奨ユーザーリストとしては使ってほしくないという気持ちがある。

分散SNSフォーラムの推奨ユーザーリスト は、流速と主観評価をもとに計算した得点でユーザーを評価している。流速も主観評価もそれぞれ固有の弱点がある指標であるが、それらを組み合わせることで、より確実な評価を目指している。

有名人のリストというのは、過去の名声のリストに他ならない。フォロワー数も、過去に大量にフォロワーを獲得したのが実力であったとしても、現在それが維持されているとは限らない。単にフォロワーたちがフォローの解除 (リムーブ) を怠っているだけかもしれない。

流速は、過去の蓄積に影響されない、現在の状態のみを評価する指標である。また、過去の名声や知名度にかかわらず、誰でも努力次第で獲得できる指標でもある。もちろん、流速はトゥートの質を担保しないどころか、一般的には量と質は反比例の関係にあるという、固有の弱点がある。分散SNSフォーラムの推奨ユーザーリスト は、主観評価でトゥートの質を評価することで、その弱点を補っている。ただし、主観評価が未評価であるユーザーについては、純粋に流速のみで評価される。

マストドンのインスタンスのリストが乱立しているのに対して、マストドンのユーザーのリストというアイディアは、あまり普及していない。これからマストドンを始める人たちは、分散SNSフォーラムの推奨ユーザーリスト をはじめ、さまざまな可能性を検討したうえで、快適なホームタイムラインを構築してほしい。

k52.org はインスタンス一覧を 20 ユーザー以上に限定するのをやめろ

k52.org は日本語圏のマストドンのインスタンスの一覧としてはデファクトスタンダードになっている。遅くとも2017年4月19日には存在し、マストドンブームの初期に開設されたことと、豪華なUIから、デファクトスタンダードになったことにはそれ相応の理由があると言える。しかしながら、ユーザー登録数をデフォルトの並び順にしていることはクソである。

さらに、k52.org はインスタンスの登録に「20人以上のユーザがいる」という条件を課している。これは新興インスタンスにとっては圧倒的に不利な条件である。2017年4月の状況であれば、個性的な名目を掲げればそれなりにユーザーを集めることが可能であった。しかしながら、ブームが去った今 (記事執筆は2017年7月) となっては、新興インスタンスがユーザーを集めることは容易ではない。ましてや、k52.org がインスタンス一覧のデファクトスタンダードとなった今では、新興インスタンスが20人のユーザーを集めるまでは、広報の手段が著しく不利になるという悪循環がある。

ようやくユーザーが20人に達し、k52.org への登録を果たしたときには、すでにユーザーのトゥートが停止していた例も少なくない。

  • mstdn.hanabi-life.net は7月19日にユーザー数 20 で登録されたものの、5月27日に事実上トゥートが途絶えている。
  • xmstdn.com は7月19日にユーザー数 20 で登録されたものの、6月12日にトゥートが途絶えている。
  • mstdn.web4u.jp は7月19日にユーザー数 23 で登録されたものの、4月20日にトゥートが途絶えている。
  • mastodon.maromaro.co.jp は7月18日にユーザー数 25 で登録されたものの、6月30日にトゥートが途絶えている。
  • animefun.jp は7月11日にユーザー数 42 で登録されたものの、5月26日に事実上トゥートが途絶えている。

これとは別に、k52.org に登録されることを目的にユーザー数を水増ししているインスタンスも出現している。「君の名は。」非公式 マストドン は7月21日にユーザー数 22 で k52.org に登録された。しかし、「「君の名は。」Twitter連携」、「「君の名は。」動画リンク」「映画「君の名は。」公式情報収集」、「「君の名は。」トリビア集」、「「君の名は。」考察・研究・解説」、「「君の名は。」インタビュー記事」などといった細分化された多数のボットを作成することで、ユーザー数を多く見せかけている。ボットを細分化することは情報収集の利便性のために有益であることもあるが、このインスタンスの場合には、k52.org への登録にあわせてボットを作成した疑いが強い。

2017年4月のマストドンブームにおいては、k52.org のリストはマストドンの普及のために大いに貢献した。しかしながら、ブームが去った今、新興インスタンスは20人のユーザーを集めることができずに次々と枯死している。

マストドン (あるいは他の分散SNS) のキーワードの一つに「脱中央集権」がある。k52.org のリストは以下の4点において中央集権への逆走である。第1に、ユーザーを20人集めるという過酷な条件を新興インスタンスに課したことで、新興インスタンスの成長の芽を摘んだこと。第2に、2017年4月のマストドンブームに乗ってユーザーを集めたインスタンスがリストに載り続け、その後の新興インスタンスにとっては不利な条件であるために、前者のようなインスタンスにとっての既得権が生じたこと。第3に、登録ユーザー数をインスタンスの評価に用いることで、もともとユーザー数の多いインスタンスがさらにユーザーを獲得しがちであること。最後に、私たちが k52.org というデファクトスタンダードに頼りすぎ、他のリストに目を向けてこなかったことである。

k52.org は役割を終えた。分散SNSフォーラムの流速順インスタンスリストを使え。

登録ユーザー数をインスタンスの評価に使うのはもうやめよう

マストドンの話です。マストドンについての説明は以下をおすすめします。

マストドンには多数のインスタンスがあるので、インスタンスの一覧をうたうウェブサイトが多数あります。

なお、ウェブサイトのタイトルを書くとどれも「マストドンインスタンス一覧」みたいな名前になってしまうため、ドメイン名または運営母体を記載しています。

この投稿の話題からは外れますが、ユーザーの一覧は以下のものがあります。

では、インスタンス一覧の特徴を順に見ていきましょう。

instances.social

これは海外のサイトなので、日本語中心のインスタンスだけを選ぶことができません。インスタンスのリストのほかにインスタンス推薦ウィザードがあるのが特徴です。

リストのシンプルモードは新着順です。前に見たときはアルファベット順だったような記憶があります。アドバンストモードは以下のような多数のソート順を選択できます。

  • 状態 (稼動/停止)
  • ドメイン名 (アルファベット順)
  • 登録ユーザー数
  • トゥート数
  • 接続インスタンス数
  • ユーザー登録の受付可否
  • バージョン
  • 稼働率
  • HTTPS
  • Obs (日本語訳不明)

tacostea.net

作者は日本語話者なのですが、言語による区別を行っていません。以下のような多様なソート順を選択できます。

  • ドメイン名 (アルファベット順)
  • 状態 (稼動/停止)
  • バージョン
  • バージョンをアップデートした日
  • 登録ユーザー数
  • トゥート数
  • 接続インスタンス数
  • ユーザー登録の受付可否
  • IPv4, IPv6接続可否
  • ディレイタイム

文字がめちゃくちゃ細かく、オタク向けのUIです。「新バージョン追従バトルを観測する」ことを目的に開発されたとあります。

k52.org

おそらく最も有名なインスタンス一覧です。並び順は登録ユーザー数または新着順で、デフォルトは登録ユーザー数です。

インスタンスの名称または説明文に日本語が含まれていることが条件なので、日本語圏のインスタンスのみを探すことができます。この性質のため、mastodon.cloud は日本語のトゥートが多いにもかかわらず k52.org に収録されていません。

また、登録ユーザー数が 20 以上のインスタンスのみが表示されるため、新興インスタンスにとっては参入が難しいリストになっています。

mastodon-instance.com

言語は「日本のみ」と「全世界」から選べます。並び順は以下のものがあります。

  • 新着
  • 登録ユーザー数
  • トゥート数
  • 接続インスタンス数

デフォルトは新着順です。

マストドン検索ポータル

並び順は登録ユーザー数です。

分散SNSフォーラム

並び順は流速のみで、変更できません。日本語圏のインスタンスのみを収録しています。ただし、mastodon.cloud は日本語のトゥートが多いためリストに含めています。インスタンス開設以来のトゥート数が 40 に達するまで表示されないため、新興インスタンスは表示されない場合があります。

流速は、ローカルタイムラインの直近 1 時間または直近 40 トゥートを収集し、「トゥート数/時間」を計算したものです。流速は 1 時間に 1 回の間隔で測定します。

登録ユーザー数をインスタンスの評価に使うのはもうやめよう

instance.social は海外、tacostea.net は技術者用、mastodon-instance.com分散SNSフォーラム はまだあまり知られていないので、k52.org が日本ではデファクトスタンダードになっています。例えば、2017年7月21日の日経スタイルの記事でも k52.org が紹介されています。この k52.org のデフォルトの並び順は登録ユーザー数です。

 

しかしながら、登録ユーザー数をインスタンスの評価に使うのは悪い考えです。2017年4月のマストドンブームに乗ってユーザーを集めたものの、すぐに荒廃してしまったインスタンスが複数あります (この投稿の付録参照)。また、ローカルタイムラインを見るためにユーザー登録して、トゥートは他のインスタンスで行うようになったユーザーも多いはずです。

新着順は、新興インスタンスに光が当たるという利点があり、悪くないアイディアです。しかし、ユーザーの立場からすると、新興インスタンスはユーザーが少なすぎ、ローカルタイムラインでの交流は寂しくなりがちです。(リモートフォローを駆使してホームタイムラインを充実させていくという使い方もあり、分散SNSフォーラムはそれを推奨していますが、そうであればそもそもインスタンスを選ぶ必要がありません。)

トゥート数は、登録ユーザー数よりはインスタンスの実力に一致していると感じられます。しかしながら、これはインスタンスの開設から現在までの累積であるため、過去には勢いがあったものの、現在は荒廃しているインスタンスが上位に来ることがあります。特に、マストドンにおいては、2017年4月のブームの時期と、それ以降の時期とで状況が大きく異なるため、当時を含む累積値を指標として用いると現在の状況が反映されにくいという事情があります。

流速は、過去からの累積を用いず、現時点でのインスタンスの活発さを反映した指標です。そのため、過去の人気にとらわれず、現時点での実力を見ることができます。

とはいえ、流速順にもいくつかの欠点があります。第1に、スパムによる投稿を算入してしまうことです。ただし、あまりにもトゥートが多すぎるスパムは、ユーザーやインスタンス管理者にブロックされやすいため、スパマーはぎりぎりの投稿頻度に調整しようとします。そのため、流速がスパムによって極端に影響されることはありません。

第2に、流速はトゥートの数を数えるのみであり、トゥートの質を考慮しないということです。流速は遅いものの、ほどよく限定されたテーマについて、よく考えられたトゥートが見られるインスタンスに、かくどんユリトピアがあります。

いずれにせよ、マストドンのインスタンスの評価に登録ユーザー数を使うことは最悪です。かわりにローカルタイムラインの流速を採用すれば、より直感に合致した評価基準にもとづいて、インスタンスを選択することができるでしょう。分散SNSフォーラムのリストを使ってください。

付録: 登録ユーザー数が多いにもかかわらず荒廃したインスタンスの実例

マスタベ丼

ドメイン名は masutabedon.com。現在はアクセスできないのでリンクにしない。

最盛期には5,000人を超える登録ユーザー数を誇ったが、業者によるボットがAVの宣伝を流すだけのインスタンスになり、ユーザーによるトゥートはほとんど途絶えた。2017年6月に予告なしに閉鎖された。

マストドン史上最悪のインスタンスとして呼び声高い。

堀江丼

堀江貴文の名前を借りて3,567人のユーザーを集めたものの、記事執筆時点 (2017年7月21日22:17) の流速は 1.5 トゥート/時で 32 位。これは末代メンヘラなどの小規模インスタンスを下回っている。しかも、その流速の大半をボットが占めている。

カブトドン

登録ユーザー数は2,335人を誇るものの、記事執筆時点 (同上) の流速は 0.9 トゥート/時の46位、しかもその大半がボットである。

HVDSGMの仕様を少し整理した

これまでのあらすじ

サービス

HVDSGMは複数のサービスの集合体として構成されるミニブログである。それぞれのサービスは複数のホストに分散していてもよい。サービスは以下のものがある。

  • ソーシャルグラフサービス
  • テキストサービス
  • マルチメディアサービス
  • 疫病サービス

ソーシャルグラフサービス

ソーシャルグラフサービスはユーザー (複数) のレコードを永続化する。ユーザーは以下のフィールドを持つ。

  • ユーザー名 (単数、独自のログイン機構を持つ場合)
  • パスワード (単数、独自のログイン機構を持つ場合)
  • スクリーンネーム (単数、文字列)
  • Bio (単数、文字列)
  • 観察対象のソーシャルグラフサービスのユーザーURL (複数)
  • テキストサービスのユーザーURL (単数)
  • テキストサービスのユーザーURLのタイムスタンプ (単数、Unixエポックからの秒数)

ソーシャルグラフサービスにログインしているユーザーは、パスワード、スクリーンネーム、Bio、テキストサービスのユーザーURLを変更できる。このうち、テキストサービスのユーザーURLが変更されたときは、テキストサービスのユーザーURLのタイムスタンプが更新される。また、観察対象のソーシャルグラフサービスのユーザーURLを追加または削除することができる。

ソーシャルグラフサービスのユーザーには一意なURLが割り当てられる。これをソーシャルグラフサービスのユーザーURLという。このURLに対してGETメソッドを要求すると、以下の情報が得られる。

  • スクリーンネーム
  • Bio
  • 観察対象のソーシャルグラフサービスのユーザーURL
  • テキストサービスのユーザーURL
  • テキストサービスのユーザーURLのタイムスタンプ

テキストサービス

テキストサービスはホスト設定 (単数) のレコードを永続化する。ホスト設定は以下のフィールドを持つ。

  • 信頼するマルチメディアサービスのホスト名 (複数)

テキストサービスはユーザー (複数) のレコードを永続化する。ユーザーは以下のフィールドを持つ。

  • ユーザー名 (単数、独自のログイン機構を持つ場合)
  • パスワード (単数、独自のログイン機構を持つ場合)
  • ソーシャルグラフサービスのユーザーURL (単数)
  • イベント (複数)

イベントは以下のフィールドを持つ。

  • タイムスタンプ (単数、Unixエポックからの秒数)
  • イベントID (単数、機械可読な文字列)

イベントは以下の種類がある。

  • 投稿
  • 賛美
  • 拡散
  • 削除
  • 疫病
  • 疫病の拡散

投稿は以下のフィールドを持つ。

  • 内容 (単数、文字列)

賛美は以下のフィールドを持つ。

  • オリジナルのテキストサービスのユーザーURL (単数)
  • オリジナルのイベントID (単数)

拡散は以下のフィールドを持つ。

  • オリジナルのテキストサービスのユーザーURL (単数)
  • オリジナルのイベントID (単数)
  • 内容のコピー (単数、文字列)

削除は以下のフィールドを持つ。

  • 削除されたイベントのイベントID (単数)

疫病は以下のフィールドを持つ。

  • タイトル (単数、文字列)
  • 疫病のURL (単数)

疫病の拡散は以下のフィールドを持つ。

  • オリジナルのテキストサービスのユーザーURL (単数)
  • オリジナルのイベントID (単数)
  • タイトルのコピー (単数、文字列)
  • 疫病のURL (単数)

テキストサービスにログインしているユーザーは、パスワードを変更できる。また、イベントを追加することができる。タイムスタンプとイベントIDと疫病のURLは自動的に生成される。

テキストサービスのユーザーには一意なURLが割り当てられる。これをテキストサービスのユーザーURLという。このURLに対してGETメソッドを要求すると、以下の情報が得られる。

  • イベント (複数)

ユーザーがテキストサービスにログインしているとき、テキストサービスは一定時間ごとにリフレッシュ動作を行う。リフレッシュ動作は以下のように行う。

  1. ソーシャルグラフサービスのユーザーURLに対してGETメソッドを発行し、諸情報を得る。
  2. 観察対象のソーシャルグラフサービスのユーザーURLに対してGETメソッドを発行し、諸情報を得る。
  3. 観察対象としているユーザーが、自分自身を新たに観察対象に加えたならば、通知を表示する。
  4. 観察対象のテキストサービスのユーザーURLに対してGETメソッドを発行し、諸情報を得る。
  5. 削除イベントによって無効化されていないイベントを以下のように表示する。ただし、疫病の拡散は削除イベントによって無効化されない。
    • 賛美、拡散、疫病の拡散のオリジンが自分自身であれば、通知を表示する。
    • 投稿または拡散の内容を表示する。このとき、信頼するマルチメディアサービスのホスト名を持つURLが含まれている場合は、そのURLの内容をダウンロードし、自動再生する。
    • 疫病または疫病の拡散のタイトルを表示する。

ユーザーがテキストサービスにログインしており、疫病の内容を表示する操作を行ったとき、テキストサービスは以下のように動作する。

  1. ソーシャルグラフサービスのユーザーURLに対してGETメソッドを発行し、諸情報を得る。
  2. ソーシャルグラフサービスが申告するテキストサービスのユーザーURLが自分自身に一致しているか調べる。一致していなければ、疫病の内容を開示しないことを表すメッセージを表示する。一致していれば、次のステップに進む。
  3. 疫病のURLに対してGETメソッドを発行し、応答を受け取る。このとき引数として、ソーシャルグラフサービスのホスト名と、テキストサービスのユーザーURLのタイムスタンプを渡す。
  4. 疫病サービスが疫病の開示を拒否したならば、疫病の内容を開示しないことを表すメッセージを表示する。そうでなければ、次のステップに進む。
  5. 疫病の拡散イベントを追加する。
  6. 疫病の内容を表示する。

マルチメディアサービス

マルチメディアサービスはファイル (複数) を永続化する。ファイルは以下のフィールドを持つ。

  • ファイル名 (単数、機械可読な文字列)
  • バイトストリーム (単数)

ユーザーはマルチメディアサービスにファイルを追加できる。

ファイルには一意なURLが割り当てられる。これをファイルのURLという。ファイルのURLに対してGETメソッドを要求すると、バイトストリームが得られる。

疫病サービス

疫病サービスはホスト設定 (単数) のレコードを永続化する。ホスト設定は以下のフィールドを持つ。

  • 信頼するソーシャルグラフサービスのホスト名 (複数)
  • 信頼するテキストサービスのホスト名 (複数)
  • テキストサービスのユーザーURLの最低安定時間 (秒、単数)

疫病サービスは疫病 (複数) のレコードを永続化する。疫病は以下のフィールドを持つ。

  • 内容 (単数、文字列)

ユーザーは疫病サービスに疫病を追加できる。

疫病には一意なURLが割り当てられる。これを疫病のURLという。疫病のURLに対してGETメソッドを発行するときは、以下のパラメーターが必要である。

  • ソーシャルグラフサービスのホスト名 (単数)
  • テキストサービスのユーザーURLのタイムスタンプ (単数、Unixエポックからの秒数)

疫病のURLに対してGETメソッドを発行すると、疫病サービスは以下のように動作する。

  1. 下記の条件を満たしているか調べる。
    • GETメソッドを発行したホストが、信頼するテキストサービスのホスト名に含まれている。
    • ソーシャルグラフサービスのホスト名が、信頼するソーシャルグラフサービスのホスト名に含まれている。
    • テキストサービスのユーザーURLのタイムスタンプが、テキストサービスのユーザーURLの最低安定時間よりも古い。
  2. 前項の条件がすべて満たされるならば、疫病の内容を返す。そうでなければ、疫病の開示を拒否するメッセージを返す。

水平分業型ミニブログHVDSGMの提案

2017年のマストドンの流行により、分散型ミニブログというアイディアも注目されるようになった。過去記事 分散型ミニブログの水平分業—素朴ディジタル画像インフラストラクチャーの設計と応用 では、ミニブログの機能をソーシャルグラフ層、テキスト層、マルチメディア層の3層に分類し、そのうちテキスト層とマルチメディア層の境界で水平分業するアーキテクチャーを提案した。本稿では、これらの3層がすべて分離した水平分業型ミニブログの仕様を提案する。本稿は概念的な提案のみであり、実装例は存在しない。

HVDSGMはhorizontally and vertically distributed social graph and messagingのアクロニムである。

以下、ミステリーポスト拡張は赤字で表記する。

 ソーシャルグラフ層

ソーシャルグラフ層はユーザー (複数) のレコードを永続化する。ユーザーは以下のフィールドを持つ。

  • ユーザー名 (単数、独自のログイン機構を持つ場合)
  • パスワード (単数、独自のログイン機構を持つ場合)
  • スクリーンネーム (単数、文字列)
  • Bio (単数、文字列)
  • フォローしているユーザーのソーシャルグラフ層のURL (複数)
  • テキスト層のユーザーのURL (単数)

ログインしているユーザーは、パスワード、スクリーンネーム、Bio、テキスト層のユーザーのURLを変更できる。また、フォローしているユーザーのソーシャルグラフ層のURLを追加または削除することができる。

ユーザーには一意なURLが割り当てられる。このURLに対してGETメソッドを要求すると、以下の情報が得られる。

  • スクリーンネーム
  • Bio
  • フォローしているユーザーのソーシャルグラフ層のURL
  • テキスト層のユーザーのURL

テキスト層

テキスト層はユーザー (複数) のレコードを永続化する。ユーザーは以下のフィールドを持つ。

  • ユーザー名 (単数、独自のログイン機構を持つ場合)
  • パスワード (単数、独自のログイン機構を持つ場合)
  • ソーシャルグラフ層のユーザーのURL (単数)
  • イベント (複数)
  • 信頼するマルチメディア層のホスト名 (複数)
  • 信頼するソーシャルグラフ層のホスト名 (複数)
  • 信頼するテキスト層のホスト名 (複数)

イベントは以下のフィールドを持つ。

  • タイムスタンプ (単数、Unixエポックからの秒数)
  • イベントID (単数、機械可読な文字列)

イベントは以下の種類がある。

  • メッセージ
  • いいね
  • 拡散
  • 削除
  • ミステリーポスト
  • ミステリーポストの拡散

メッセージは以下のフィールドを持つ。

  • 内容 (単数、文字列)

いいねは以下のフィールドを持つ。

  • オリジナルのユーザーのソーシャルグラフ層のURL (単数)
  • オリジナルのイベントのイベントID (単数)

拡散は以下のフィールドを持つ。

  • オリジナルのユーザーのソーシャルグラフ層のURL (単数)
  • オリジナルのイベントのイベントID (単数)
  • 内容のコピー (単数、文字列)

削除は以下のフィールドを持つ。

  • 削除されたイベントのイベントID (単数)

ミステリーポストは以下のフィールドを持つ。

  • タイトル (単数、文字列)
  • 内容 (単数、文字列)
  • ミステリーポストのURL (単数)

ミステリーポストの拡散は以下のフィールドを持つ。

  • オリジナルのユーザーのソーシャルグラフ層のURL (単数)
  • オリジナルのイベントのイベントID (単数)
  • タイトルのコピー (単数、文字列)
  • ミステリーポストのURL (単数)

ログインしているユーザーは、パスワードを変更できる。また、イベントを追加することができる。タイムスタンプとイベントIDとミステリーポストのURLはサーバーサイドで生成する。

ユーザーには一意なURLが割り当てられる。このURLに対してGETメソッドを要求すると、以下の情報が得られる。

  • イベント (複数)

ただし、ミステリーポストの内容は除かれる。

このGETメソッドの引数にタイムスタンプを指定すると、そのタイムスタンプよりも新しいイベントのみが得られる。

テキスト層は一定時間ごとにリフレッシュ動作を行う。リフレッシュ動作は以下のように行う。

  1. ソーシャルグラフ層のユーザーのURLに対してGETメソッドを発行し、諸情報を得る。
  2. フォローしているユーザーのソーシャルグラフ層のURLに対してそれぞれGETメソッドを発行し、諸情報を得る。
  3. フォローしているユーザーから新たにフォローされたならば、新しいフォロワーの通知を表示する。
  4. フォローしているユーザーのテキスト層のURLに対してそれぞれGETメソッドを発行し、諸情報を得る。
  5. 削除イベントによって無効化されていないイベントを以下のように表示する。ただし、ミステリーポストの拡散は削除イベントによって無効化されない。
    • いいねまたは拡散のオリジンが自分自身であれば、通知を表示する。
    • メッセージまたは拡散の内容を表示する。このとき、信頼するマルチメディア層のホスト名を持つURLが含まれている場合は、そのURLの内容をダウンロードし、自動再生する。
    • ミステリーポストまたはミステリーポストの拡散のタイトルを表示する。

マルチメディア層

マルチメディア層はファイル (複数) を永続化できる。ファイルは以下のフィールドを持つ。

  • ファイル名 (単数、機械可読な文字列)
  • バイトストリーム (単数)

ユーザーはファイルをアップロードできる。アップロードが完了すると、ファイルのURLが表示される。

ファイルのURLに対してGETメソッドを要求すると、そのファイルが得られる。

ミステリーポスト

テキスト層でミステリーポストを開く操作を行ったとき、以下のような通信が行われる。これらの通信はテキスト層とソーシャルグラフ層にまたがって行われる。

  1. テキスト層のホストAは、ソーシャルグラフ層のユーザーのURLにGETメソッドを要求する。
  2. ソーシャルグラフ層は、テキスト層のユーザーのURLを含む諸情報を返す。
  3. テキスト層のホストAは、ソーシャルグラフ層が申告するテキスト層のユーザーのURLが自分自身に一致するときのみ、以下の処理に進む。そうでなければ、ミステリーポストを開くことが許可されなかったことを表示する。
  4. テキスト層のホストAは、ミステリーポストのURLにGETメソッドを要求する。ミステリーポストのURLのホスト名は、別のテキスト層のホストBである。このとき、引数として、ソーシャルグラフ層のホスト名を渡す。
  5. テキスト層のホストBは、テキスト層のホストAと、ソーシャルグラフ層について、それぞれ信頼できるかどうか調べる。いずれも信頼できるときのみ、以下の処理に進む。そうでなければ、ミステリーポストを開くことを許可しないことをテキスト層のホストAに返信する。
  6. テキスト層のホストBは、ミステリーポストの内容をテキスト層のホストAに返信する。
  7. テキスト層のホストAは、ミステリーポストの拡散イベントを自分自身に追加する。
  8. テキスト層のホストAは、ミステリーポストの内容を表示する。

制限

フォロー、いいね、拡散の通知は、すでにフォローしているユーザーのみから受け取ることができる。未知のユーザーからいきなり通知を送られることはない。

ソーシャルグラフ層またはテキスト層のサーバーが、ミステリーポストの拡散に協力せずに内容のみを盗み見ることを試みた場合、信頼するサーバーのリストからそれらを除かなければならない。

メッセージを削除しても、その拡散は削除されない。同様に、ミステリーポストを削除しても、ミステリーポストの拡散は削除されない。

議論

これ役に立つのか?

タイムラインのUIを提供するのはテキスト層なので、ソーシャルグラフを維持したままUIだけを変えたいときに便利かもしれない。

ミステリーポストの導入はテキスト層の変更のみで実現されている。一般に、何か目新しい機能を導入するときは、ソーシャルグラフ層とマルチメディア層を稼働したまま、テキスト層のみを交換することで対応できることが多い気がする。

分散型ミニブログの水平分業—素朴ディジタル画像インフラストラクチャーの設計と応用

2017年にマストドンが大流行すると、分散型ミニブログというアイディアにも注目が集まるようになった。分散型ミニブログは、複数の運営者がそれぞれサーバーを運用し、それらがリモートフォローによって接続されることでSNSを構成するものである。

本稿では、分散型ミニブログの機能を、ソーシャルグラフ層、テキスト層、マルチメディア層の3層に分類する。そして、従来の分散型ミニブログを垂直統合型としたうえで、水平分業型の分散型ミニブログを提案する。具体例として Yayaka19 を取り上げる。Yayaka19 の本体はソーシャルグラフ層とテキスト層を担当し、マルチメディア層は 素朴ディジタル画像インフラストラクチャー という独立したウェブサイトが担当している。

分散型ミニブログの階層モデル

本稿では、分散型ミニブログの機能を、ソーシャルグラフ層、テキスト層、マルチメディア層の3層に分類することを提案する。

ソーシャルグラフ層は、ユーザーのフォロー・被フォロー関係を保存する層である。この層は最も高度な故障耐性が求められる。ユーザーにとって、自分がフォローしているユーザーのリストや、自分の発言を聞いてくれるフォロワーを失うことは、多大な損失である。そのため、データの喪失には万全の対策が必要である。また、ソーシャルグラフ層が停止すると他の層も機能しなくなるため、一時的な停止も最小限にすべきである。

テキスト層は、あるユーザーが投稿した文字列を、フォロワーに届ける層である。分散型ミニブログにおいて、タイムラインは常に流れていくものであるため、データの喪失はそれほど問題にならない。とはいえ、データの喪失やサービスの停止は、あくまでユーザーが不便に感じない程度にとどめるべきである。また、テキスト層は、マルチメディア層のための識別子 (画像のURLなど) を配信する役割を持つ。

マルチメディア層は、画像、音声、動画などのさまざまなデータを配信する層である。マルチメディア層にとって重要なことは、テキスト層と比較して、データのサイズが大きくなることである。

また、マルチメディア層は、法的問題にさらされやすいという特徴がある。テキスト層においても、ヘイトスピーチや犯行予告など、違法もしくは邪悪な投稿が可能である。マルチメディア層では、それに加えて、著作権法違反や児童ポルノの公衆送信など、よりカジュアルに違法または邪悪な情報の共有が起こり得る。

分散型ミニブログの垂直統合モデル

GNU Socialやマストドンなど、いま主流の分散型ミニブログは、垂直統合モデルである。すなわち、1台のインスタンスが、ソーシャルグラフ層、テキスト層、マルチメディア層のすべての機能を提供している。そのうえで、複数のインスタンスが連合を形成するアーキテクチャーとなっている。

この方式にはいくつかの欠点がある。第1に、インスタンスに必要とされる計算機パワーが大きいことである。分散型ミニブログでは、個人、団体、企業など、さまざまな主体がインスタンスを運営することができる。しかしながら、計算機パワーの問題により、個人が運用するインスタンスでは、処理が遅くなったり、レンタルサーバーの高価なプランに移行する必要が生じるなどの限界があった。

第2に、データの長期的な永続化が必要になるソーシャルグラフ層と、それほど永続化が必要とされないテキスト層およびマルチメディア層が混在していることにより、データベースの管理が不便になっていることがある。もし両者が分離されていれば、ソーシャルグラフ層のデータベースのみを厳重に管理し、他のデータベースは状況に応じて破棄するという運用も可能である。

画像アップローダーの分離

そこで、Yayaka19 では、本体はソーシャルグラフ層とテキスト層のみを担当し、マルチメディア層は 素朴ディジタル画像インフラストラクチャー に委託するというアーキテクチャーを採用した。

Yayaka19での変更はクライアントサイドのみであり、サーバーサイドおよびプロトコルの変更を必要としない。Yayaka19のクライアントは、投稿された文字列に画像のURLが含まれていれば、それを画像のインライン表示 (<img src=”URL“> タグ) に置換する。

ここで、画像のインライン表示を、信頼できる発信源に限定することが必要である。そうでないURLは、インライン表示ではなく、ハイパーリンクにする。なぜなら、インライン表示された画像の提供元は、ユーザーの行動を追跡することができるからである。画像の提供元は、ユーザーのIPアドレスと時刻を記録することができる。これは、単に画像を読み出したことを意味しているだけでなく、その画像が埋め込まれた投稿を読んだことを意味する。もしこれを画像の提供元が悪用すれば、深刻なプライバシーの侵害となり得る。

素朴ディジタル画像インフラストラクチャーの設計

素朴ディジタル画像インフラストラクチャー は、水平分業されたウェブアプリケーションのマルチメディア層として使われることに特化した画像アップローダーである。水平分業に特化するため、以下のような仕様を採用した。

  • 画像のURLを得ることが容易である。
  • 画像一覧の画面を持たない。
  • UIの視覚的な魅力に乏しい。

素朴ディジタル画像インフラストラクチャーは画像のランディングページを持たない。画像を投稿すると、その画像をブラウザで直接表示している状態に遷移する。このときブラウザが開いているURLは、画像そのもののURLであるので、テキスト層にそのままコピーすることができる。

素朴ディジタル画像インフラストラクチャーは画像一覧の画面を持たない。これは、画像を紹介する機能を、他のウェブアプリケーションのテキスト層に依存しているためである。素朴ディジタル画像インフラストラクチャーで画像を表示するには、画像のURLに直接アクセスする必要がある。

また、素朴ディジタル画像インフラストラクチャーは、ソーシャルグラフ層およびテキスト層を持つウェブアプリケーションからの紹介で利用されるため、UIの視覚的な魅力を追求していない。「素朴ディジタル画像インフラストラクチャー」という名前も、意図的に冗長かつ時代遅れに聞こえるように選定されている。

素朴ディジタル画像インフラストラクチャーのソースコードは非常に単純で、以下の3個のファイルで構成されている。

  • index.html (8行)
  • mdii.js (43行)
  • mdii-post.cgi (15行)

これだけ単純なので、動作環境にあわせて改変することも容易である。これまでに SiteMixの無料プランさくらのレンタルサーバーのライトプラン でデプロイされた。

素朴ディジタル画像インフラストラクチャーは、もともとは、2017年にもなって画像アップローダーなどというコモディティを自分で開発したくない、という動機から開発された。そのため、仕様はよく言えば軽量、悪く言えば粗雑である。セキュリティもあまり上等とは言えない。例えば、DoS攻撃に対する耐性がまったく考慮されていないことは特筆に値する。

水平分業型ミニブログにおいては、マルチメディア層に技術的または法的な問題が発生した場合には、マルチメディア層を夜逃げさせて、ソーシャルグラフ層とテキスト層のみを防衛するという運用を想定している。ソーシャルグラフ層とテキスト層は、マルチメディア層が夜逃げする場合にそなえて、あらかじめ複数のウェブサイトをマルチメディア層として利用できるようにしておくなどのリスク管理が必要である。

また、素朴ディジタル画像インフラストラクチャーは、分業型ミニブログであるYayaka19の他に、不買運動ウェブ という情報共有サイトからも利用されている。画像アップローダーというコモディティを自分で開発したくないという動機からすれば、このように複数の異質なウェブアプリケーションから利用されることは、自然な使用法である。

議論

分散型ミニブログの水平分業は、さまざまな信念や政治的主張を持つ個人または団体にとって、計算機資源および人的資源を提供する動機になり得る。例えば、言論の自由を重視する団体はソーシャルグラフ層とテキスト層を、ポルノや二次創作を擁護する団体はマルチメディア層を運営する、といった応用が期待される。

歴史的には、2ちゃんねるが画像アップローダーをともなって運用されていた気がする。画像アップローダーはしょっちゅう夜逃げしてた。

Yayaka19に画像付きミステリーポストを投稿する方法

2017年5月15日から、Yayaka19に画像付きミステリーポストを投稿することができるようになった。本稿では、その操作方法を説明する。

まず yayaka.net または 19.fubaiundo.org にログインする。そして、ミステリーポスト作成画面を開く。この方法はインスタンスによって異なる。

  • yayaka.net では、右上のメニューから「New Mystery Post」を選択する。
  • 19.fubaiundo.org では、ツールバーの爆弾ボタンを押す。

ミステリーポスト作成画面では、タイトルと本文を入力する。タイトルは、通常のミステリーポストと同じように入力すればよい。

ここで、唐突だが、素朴ディジタル画像インフラストラクチャー という別のサイトを開く。そして、「ファイルを選択」ボタンを押して、投稿したい画像を選ぶ。スマートフォンであればカメラで撮影することもできる。続いて「送信」ボタンを押す。すると、画像そのものを表示する画面に遷移するので、画像のURLをコピーする。画像のURLは、例えば https://mdii.sakura.ne.jp/32245.png のような形式になる。

そして、ミステリーポスト作成画面に戻り、本文に画像のURLを貼り付ける。本文には、画像のURLとその他の文章を混在させることもできるし、複数の画像のURLを貼り付けることもできる。

すると、このミステリーポストを開いた人は、先ほどの画像を目にすることになる。

最後に、2017年5月29日の時点で、できることとできないことをまとめる。