ヘイトスピーチを印刷して踏むデモの写真を見て「ぼくが思ってたヘイトスピーチと違う」ってなってるの弱すぎでは?

ぼくがヘイトスピーチだと思ってるツイートを踏んでくれれば支持してあげるよ (そうでないのであいつらはバカ) ってことじゃん。

広告

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

登録ユーザー数をインスタンスの評価に使うのはもうやめよう から記事を分離しました

マスタベ丼

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

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

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

堀江丼

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

カブトドン

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

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

マストドンでユーザー登録を行うと、誰もフォローしていない状態で始まる。この状態から、フォローすべきユーザーをどのように見つけていけばいいだろうか? マストドン初心者がホントに知りたいのは「Mastodonが楽しめるフォローの方法」 を読むか、分散SNSフォーラムのマストドン推奨ユーザーリスト を参考にするとよい。

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

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

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

マストドンにはTwitterの「おすすめユーザー」に相当する機能は存在しない。Pawoo には独自の「おすすめユーザー」機能があるが、対象となるのはPawooのユーザーのみである。

では、マストドンを新たに始める人は誰をフォローすべきだろうか? この課題に一応の回答を示したのが、マストドン (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. 登録ユーザー数をインスタンスの評価に用いたことで、もともとユーザー数の多いインスタンスがさらにユーザーを獲得しがちである。
  4. 最後に、私たちが k52.org というデファクトスタンダードに頼りすぎ、他のリストに目を向けてこなかった。

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

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

マストドンのインスタンス一覧はユーザー数順のものが多く、デファクトスタンダードである 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フォーラムのリストを使ってください。

HVDSGMの仕様を少し整理した

追記: 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の提案

追記: 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だけを変えたいときに便利かもしれない。

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