マストドンのユーザーレコメンデーションがブームに?

ITmedia NEWSマストドンを始めたら誰をフォローすべきか? に言及しているのだが、情報が古いので補足。

広告

ITmedia NEWS が マストドンを始めたら誰をフォローすべきか? に言及しているのだが、情報が古いので補足。

追記 マストドンのユーザーレコメンデーションについて追記

ユーザーを推挙するソフトウェア

マストドンでユーザーを推挙するソフトウェアには、以下のものがある。ウェブサイトの名称は似たようなものになりがちなので、作者または運営者を付記した。

さっそく、これらの特徴を見ていこう。

マストドンユーザーマッチング (墓場人夜)

マストドンユーザーマッチングは、語彙の類似性をもとにユーザーを推挙する。語彙の抽出には、スクリーンネーム、bio、トゥート本文を使う。マストドンとPleromaのほとんどすべてのインスタンスが検索対象となる。

Mastodonおすすめユーザー検索 (きゅうりうむ)

Mastodonおすすめユーザー検索で検索を実行すると、類似ユーザーとおすすめユーザーが表示される。類似ユーザーとは、共通のユーザーをフォローしているユーザーである。そして、おすすめユーザーとは、類似ユーザーがフォローしているユーザーである。作者自身の説明 を読んだほうが早い。対応しているインスタンスは少ない。

おすすめフォロワー (おさ)

「あなたがフォローしている人が、よくフォローしている人を紹介します。」という公式の説明が分かりやすくていい。何も付け加えることはない。マストドンとPleromaのすべてのインスタンスに対応している。

Pawoo

Pawooはインスタンスの独自機能として「おすすめユーザー」を持っている。残念ながら検索結果はPawooユーザーのみである。ソースコード を見る限り、ユーザーを推挙する基準は以下であるようだ。

  • pixivでフォローしているユーザー
  • 人気のある (ファボ・フォロワー数・画像投稿経験の高い) ユーザー
  • アクティブな (最近のトゥートが多い) ユーザー

累進性と逆進性の評価

脱中央集権のためのデザイン: セレブのためのインターネットを99 %の手に取り戻す の補足。「フォローされている」情報をユーザーの推挙に使うと、それだけで逆進性が強い。

  • (↑逆進的)
  • おすすめフォロワー (おさ)
  • Mastodonおすすめユーザー検索 (きゅうりうむ) のおすすめユーザー
  • Pawoo
  • Mastodonおすすめユーザー検索 (きゅうりうむ) の類似ユーザー
  • マストドンユーザーマッチング (墓場人夜)
  • (↓累進的)

ユーザーのリスト

マストドンのユーザーのリストみたいなものも複数ある。ここからユーザーを選んでフォローしてもよい。

また、ローカルタイムラインまたは連合タイムラインからユーザーを拾ってフォローするという使い方もある。これらの 累進性と逆進性を評価した記事 もあるので、よろしければどうぞ。

マストドンのユーザーレコメンデーションの歩み

株式会社ユーザーローカルのランキングは2017年4月から、Pawooのおすすめユーザーは2017年5月から存在するらしい。墓場人夜の流速順リストは2017年7月。

マストドンユーザーマッチング (墓場人夜) は2017年11月15日に公開されたものの、公開初日は検索結果がぶっ壊れており、その後は少しずつ検索アルゴリズムが改良されてきた。

Mastodonおすすめユーザー検索 (きゅうりうむ) は2018年2月4日に 仮完成 した。3月25日に 作者のブログ記事 が出ると、その日のうちに ITmedia NEWSの記事 になった。

そして3月27日には、おすすめフォロワー (おさ) が出た。タイミングから見て、ITmedia NEWSの記事に触発されたようだ。

というわけで、ITmedia NEWS (というか、マストドンつまみ食い日記) の影響力は2018年にも健在ということだ。マストドンユーザーマッチングの作者としては、急に競合が増えたことが励みになるので、PleromaにWho to followパネルを設置する などの異常な機能拡張をやっていきたい。

pleroma-fe の開発環境を作る

Pleromaの開発環境を作る の補足。pleroma-fe の開発環境を作るところの説明が雑すぎたので、書き忘れていたことを書く。

前提として、ディストリビューションは Ubuntu (TODO: バージョンはあとで調べて書く) とする。Pleromaの開発環境を作る では、いきなり npm install を叩いているが、その npm はどこから来るのか? 特に驚くようなことはなく、apt から来る。注意事項としては、npm だけでなく node-legacy も必要っぽい。

あと、現時点での環境だと node_sass が壊れているので、npm uninstall node_sass で消してから npm install node_sass で入れなおすみたいなワークアラウンドが必要っぽい。

GitLabと仲良くなる

Pleromaの開発はGitLabが使われている。本稿では、GitLabの使い方情報と、Pleromaの開発に固有の事情を織り交ぜてやっていく。

developブランチとfeatureブランチ

まず超実践Gitは強いのでみんな読むといい。ところで、超実践Gitの既存の戦略を知るという節によると、Git界隈で使われているブランチの名前には、以下のような流派がある。

  • git-flow: development, features, hotfix, releases, master
  • github-flow: master

さて、PleromaのGitLabがどうなっているかというと、develop がデフォルトのブランチであり、feature/XXX というブランチと fix/XXX というブランチが大量に作られている。masterブランチは、存在するがまったく使われていない。

Pleromaの開発体制は、ブランチの名前はgit-flowだが、実際にやっていることはgithub-flowである。Pleromaのdevelopブランチは、github-flowにおけるmasterブランチと同じように使われている。そのため、インスタンスを運営したい人はdevelopブランチからコードを持っていくことになっている。

余談だが、ブランチの名前に / を含めることが普及しているのは、初心者にとっては割と驚きがある。

ブランチをいっぱい作る

開発者にとって最終的な目標の一つがマージリクエストを出すことだ。GitHubにおけるプルリクエストのことをGitLabではマージリクエストと呼ぶ。

マージリクエストの実体は2個のブランチの組である。これらのブランチは別のレポジトリに置かれていてもよい。いずれかのブランチに新しいコードがコミットされれば、マージリクエストの内容も変化していく。そのたびに、マージが成功したりコンフリクトしたりするし、テストが通ったり通らなかったりする。

マージリクエストを出すことを想定して、1個のブランチには1個のテーマのコードのみをコミットする。このようなブランチを特にトピックブランチと言うこともある。

トピックブランチとは別に、インスタンスで実際に稼動しているコードを入れるブランチも必要である。AGPLにより、インスタンスが独自機能を持つならば、コードを公開する義務があるからである。私はdistsnという名前のブランチにしたが、deploy/distsn のような説明的な名前のほうがわかりやすいかもしれない。

本稿の読者の知識をどのように想定すればよいかわからないが、クローンとは以下のようなコマンドをやっていくことである。-b のあとの feature/who-to-follow-panel はブランチの名前であり、最後の who-to-follow-panel はローカルのディレクトリ名である。

git clone https://git.pleroma.social/hakabahitoyo/pleroma-fe.git -b feature/who-to-follow-panel who-to-follow-panel

本家のdevelopブランチに追従する

インスタンスを運営しているならば、新機能を取り入れることは欠かせない。また、トピックブランチにおいては、他の開発者による変更と衝突がないようにするために、きりのいいところで本家のdevelopブランチに追従する必要がある。

この作業はGitLabではなくローカルのgitコマンドでやっていく。Pleromaのレポジトリにはpleromaとpleroma-feがあり、ここでは例としてpleroma-feの方でやっていく。

git remote add official https://git.pleroma.social/pleroma/pleroma-fe.git
git fetch official
git merge official/develop

git remote add はレポジトリをクローンしたときに1回やればよく、git fetch と git merge は本家のdevelopブランチに変化があったときにはやるべきである。余談だが、git remote add でスペルミスをやらかしたときの直し方は git remote set-url である。

応用としては、レポジトリをクローンしたときには、自分のレポジトリが origin という名前で登録されている。これに対して fetch と merge をやっていくことにより、トピックブランチから機能を取り込むことができる。

git fetch origin
git merge origin/feature/who-to-follow-panel

pleroma.distsn.org は本番環境が開発環境を兼ねているので、この方法でトピックブランチを取り込んで動作確認をやっている。

ESLintを倒す

PleromaのGitLabレポジトリでマージリクエストを出すと、自動的にテストが走る。マージリクエストではなく普通のコミットでも自動的にテストが実行される。pleroma-fe は JavaScript 的なもの (Vue.jsとwebpackあたり) で書かれているので、ESLintでチェックされる。Lintとは人類にコーディングスタイルを強制するプログラムで、ESLintはそれのJavaScriptのやつである。

ESLintを倒さないと気分が悪いので、倒す。JavaScript Standard Styleという偉そうな名前のやつが相手なので、あらかじめ読んでおくと倒しやすい。

ユニットテストを倒す

pleromaレポジトリはElixirで書かれているので、それ用のユニットテストフレームワークが作動する。ただし、テスト環境が壊れていることも多い。テストの結果を見て、自分が書いたコードとは関係なさそうなところがエラーになっていたら、マージリクエストのコメントあたりで発言すれば、強い人たちが直してくれそうである。

Pleromaの開発環境を作る

Pleromaという異常な分散SNSがあり、3.distsn.orgというインスタンスを運営している。インスタンスの運営よりも独自機能をもりもりやっていくことに興味があるので、そのようにする。

インスタンスを設立する

Pleromaのインストールは公式のWikiを読めば難しくない。日本語もあるが、英語が苦痛でなければディストリビューション別のドキュメントを読むほうが早い。やっていきましょう。

余談ですが、マストドンと比較して、Pleromaのインストールの楽なところを挙げる。

  • メールサーバーの設定が不要。マストドンでは、メールサーバーを自分で建てるか、Mailgunあたりのメールサーバーを使う必要がある。
  • 管理者ユーザーの作成が不要。Pleromaには管理者ユーザーが存在せず、インスタンスの設定はローカルなファイルを編集することで行う。
  • 安価な計算機資源でまともに動く。さくらのVPS 512 MBでも余裕。

Pleromaのインストールの面倒なところは、Elixirのバージョンが最新である必要があり、ディストリビューションのパッケージではなく、Elixirのウェブサイトからパッケージを取ってくる必要があることである。前述の手順書にはこの方法も書いてあるので安心だ。

レポジトリが2個ある

開発環境を作るということは、ソースコードとやっていくということで、まずはPleromaのGitLabにアカウントを作る必要がある。GitHubに依存して生活していると、まずここが面倒だが、やっていく。

次に pleromapleroma-fe をフォークする。レポジトリが2個あるというのが割と驚きポイントである。pleromaはバックエンド (サーバーサイド)、pleroma-feはフロントエンド (クライアントサイド) であり、両者は別のレポジトリになっている。

独自機能をやっていくことに興味がなく、単にインスタンスを設立したいだけなら、pleromaレポジトリだけをクローンすればよい。なぜかというと、pleroma-feレポジトリをビルドした生成物を、定期的に (開発者が手動で) pleromaレポジトリにコピーしているからである。具体的には、pleroma-fe の /dist/index.html と /dist/static が、それぞれ pleroma の /priv/static/index.html と /priv/static/static にコピーされる。

ここで、pleromaレポジトリが ~/pleroma にクローンされており、pleroma-fe レポジトリが ~/pleroma-fe にクローンされているとする。まず準備として、pleroma-fe で以下をやっていく必要がある。(補足: pleroma-fe の開発環境を作る)

npm install
npm run build

すると ~/pleroma-fe/dist ディレクトリに生成物が入る。あとは以下のようなシンボリックリンクを作ればよい。

cd ~/pleroma/priv/static
mv index.html index.html_
mv static static_
ln -s ~/pleroma-fe/dist/index.html .
ln -s ~/pleroma-fe/dist/static .

これで動くと思う。pleroma-fe の側でコードを編集したときは npm run build で新しくなる。pleroma の側でコードを編集したときは、たいてい何もしなくても新しくなるが、ごく稀に MIX_ENV=prod mix ecto.migrate が要る。

やや面倒なのは、pleromaレポジトリの側でgit関連の操作をしたいときは、これらのシンボリックリンクを元に戻す必要があることだ。そのために、上記のコマンド例ではmvコマンドで元のファイルを残している。

config.jsonをやっていく

さて、pleromaレポジトリには /priv/static/static/config.json があり、pleroma-feレポジトリには /dist/static/config.json がある。これらは内容は同一であるべきであり、開発者がぼんやりしていない限りはそうなっている。とはいえ、このファイルはインスタンスごとに設定を書き換えて使うので、どちらか一方だけを書き換えるというミスがあり得る。すると、シンボリックリンクに切り替えたときに動作が変わることになる。両者を常に同一の内容に保つべきだろう。

訂正 よく考えたら pleroma-feレポジトリの /static/config.json が /dist/static/config.json にコピーされるので、/static/config.json を編集する必要がある。npm run build で更新される。

追記

ふむっふむっ

ツイッターからPleromaに移住する方法

界隈で言うところの、鳥を捨てて神の連合に移住する方法。フレンズを維持したまま、異常者は置き去りにする。

もしあなたがPleromaを知らないなら、マストドン日本語ウィキの記事新しい連合型SNS「Pleroma」はMastodonを置き換える?Mastodonに続く新たな連合型SNS「Pleroma」作者に聞く開発の背景、特徴、ロードマップを読むとよい。簡単に言うと、Pleromaは脱中央集権なソーシャルネットワークで、自由ソフトウェア信者によって開発されており、ツイッターによく似ているが、さらに価値が追加されている。

もしあなたがまだツイッターを使っているなら、Pleromaに移住する理由は以下のものが考えられる。

  • Pleromaは友好的、会話的で新鮮。初期のツイッターに似ている。
  • ユーザーが最初に置かれている。Pleromaのアーキテクチャは完全にハラスメントとイジメに対する防御のために設計されている。
  • ナチスがいない。(ナナチはたくさんいる。)
  • 企業の利益のために運営されていない。あなたのデータを収穫し第三者に売る中央権威が存在しない。
  • 中毒性のあるテクノロジーではない。ログインと投稿を促すメールリマインダーを送らないし、あなたの個人的な詳細を手放すこともない。
  • 脱中央集権でオープンサースなソフトウェアがコミュニティにより開発されている。政府または邪悪な集団が、禁止したり検閲したりすることが難しい。

もしあなたがすでにPleromaのアカウントを持っているなら (もしまだならPleroma公式サイトPleromaインスタンス一覧が助けになるかもしれない)、移住を助ける以下のようなトリックがある。

ツイッターから

  1. あなたのツイッターのフレンズのうちマストドンに移住している者を探し、フォローする。Pleromaのユーザーはマストドンのユーザーをリモートフォローできるからである。残念ながら、ツイッターからPleromaに移住した人を探すウェブサイトはまだないので、かわりにツイッターからマストドンに移住した人を探すウェブサイトを利用する。同じことを3ヶ月から6ヶ月くらいの周期で繰り返すとよい。すべての卒鳥が2017年4月に行われたとは限らない。まさに今日、移住した人もいるかもしれない。それを探してPleromaからリモートフォローしよう。
  2. Pleromaに移住したことを知らせるアナウンスと、PleromaのプロフィールページのURLをツイートする。私は鳥のアカウントを消してしまったので例を示すことができない。
  3. 移住を通知するツイートをプロフィールに固定する。これにより、ツイッター側のプロフィールページを見る人に移住を知らせることができる。
  4. ツイッターはスクリーンネームの文字数が多くなったので、ツイッターでのスクリーンネームの末尾にPleromaのハンドルネームを含めることができる。これはツイートのたびにメッセージを広めることができる。Pleromaのハンドルネームは @your-username@the-instance-where-ist-located のような形式である。私の例は @vaginaplant@3.distsn.org である。メールアドレスに似ているが、最初に @ がある。ところで、このアドレスにメールを送らないこと。送っても届かないぞ。
  5. あなたがまだツイッターにいるなら、Pleromaのツイッターアカウントは知られていないので、マストドンの公式アカウントをフォローするとよい。マストドン公式ツイッターアカウントは移住を決断したことを継続的に思い出させてくれるし、リツイートするに値する話を提供してくれる。

移住するとき

あなたがスマートフォンでツイートしているなら、Pleromaはさまざまな方法でそれを代替する。Pleromaのスマートフォン用クライアントは知られていないが、マストドンのクライアントはおおむねPleromaのインスタンスに接続できる。Pleromaで動作確認されたスマートフォン用クライアントの一覧 が提供されている。ただし、それよりも、スマートフォンのブラウザでウェブUIを使うほうがよい。近年ではスマートフォンのブラウザも優秀なので、いつまでもアプリにこだわる必要はない。それはそうと、こんな話もある:

  1. ツイッターの公式アプリをアンインストールしよう。あいつは悪い。あなたの位置を追跡するし、ツイートを時間順に配列してくれないし、あなたがスマートフォンでやることをすべて捕捉しようと試みている
  2. かわりに……マストドン用のスマートフォンアプリで、Pleromaでの利用に適したものがあれば教えてほしい。

Pleromaへ

Pleromaを、あなたが入学した大学か、あなたが引っ越してきた都市であると想像してほしい。あなたはPleromaがどのように動作するか知っているとする。ここにはあなたにとってなじみ深いものもあるし、よく知らないものもある。ここにはあなたの新しい友になる人がたくさんいるが、あなたがすでに知っている人はわずかである。いずれにせよ、引っ越しのたびに、ほんの少しの努力が必要である。

Pleromaではツイッターよりも少しだけ困難がある。けれども、必要なことは、自分自身であることである。それぞれのソーシャルネットワークには雰囲気に違いがある。Pleromaがいくらツイッターに似ているとしても。その違いを見つけようと意識するとよい。これは、あなたが引っ越してきた通りの角に喫茶店を見つけたときに似ている。混んでいるだろうか? もっともよい注文は何だろうか? なぜ人々は電話をするとき外に出るのだろうか?

ここに、あなたが興味を持つかもしれない少数のアカウントを挙げる。

もちろんもっとたくさん (マストドンとPleromaを合わせれば17,000くらい)。連合タイムラインまたはローカルタイムラインに飛び込めば、とてもたくさんの投稿が多様な言語でなされていることを見るだろう。特にアカウントを作った直後は連合タイムラインまたはローカルタイムラインを見るべきだ。それによりここがどういう所かが分かる。そして、これは基本的にPleromaでしかできないことだ。次は新しい人々をフォローしよう。思ったほどおもしろくなければアンフォローするのもよい。誰も怒られない。ここは新しい土地だ。好奇心になろう。

沈黙しないようにしよう。ここはソーシャルネットワークである。もしあなたが何も持ち込まないならば、本当におもしろいものはない。ソーシャルネットワークツールはデフォルトでは空である。他人と話そう。ここは、ありあわせ料理、持ち寄りのパーティー、共有ランチである。すべての人が何かしらをテーブルに持ってくる。

ツイッターからPleromaに投稿をシェアする

あなたはツイッターで見た良い物をPleromaにシェアしようと思うかもしれない。これは良いことだ。これを正しく行うために、あなたのコピーの先頭に “RT @username@twitter.com” を付けよう。これはオリジナルの著者をクレジットするためである。ところで、これは最初期のツイッターで行われていたことである。

読者にとって攻撃的かもしれない投稿はContent Warningするとよい。マストドンにはある。Pleromaだと話がややこしく、Pleromaの独自UIはContent Warningを扱えないが、Pleromaのバックエンドとマストドンのフロントエンドという不気味な組み合わせだとContent Warningが可能である。

マストドンの人々は観客を尊敬する傾向にある。暴力、政治的な意見、ツイッター (鳥) に関することはContent Warningに隠すことが好まれる。Pleromaはマストドンに対する反動で不謹慎を好む文化があるが、それにも限界はある。

あと、チンコツイツイマストドンスペースを使うのは絶対にやめよう。鳥を燃やされても知らんぞ。

Pleromaからツイッターに投稿をシェアする

移住の動機によっては、Pleromaでの行動を共有することによって、ツイッターのフォロワーとの接触を維持したいかもしれない。私はそれを行っていない。なにしろ鳥のアカウントをスナネコしてしまったし、もしそうでないとしても、Pleromaのアカウントをフォローしてもらうほうがよい。Pleromaはともかく、マストドンであればMastodon Twitter Posterという手がある。

結論

ツイッターは悪くなる一方ではあるが、かつては楽しく有望であったとあなたが感じているならば。より敬意ある文化のマイクロブログ、コミュニティの決定により運営されるプラットフォーム、中央集権なサイロでないSNSが可能であると信じるならば。新しい旅を始める時は今である。

さいわいなことに、私はこの記事で、移住を容易にするための複数のツールを紹介することができた。あなたの目的が、ツイッターのアカウントを完全に削除することであるとしても、あるいは、ツイッターが燃え尽きて灰になるまで両方のアカウントを維持することであるとしても。

いずれにせよ、未来は明るく、Pleromaの成長は早く、ソーシャルメディアの未来に対するインパクトを私たちは正確に見積もることができない。(PeerTubeとActivityPubのような新しい話題もある。)

この記事があなたを助けた、もしくは、この記事に間違いがあると感じたら、私に知らせてほしい。そして、「ちょうど羽田に着陸しました」と言うことを恥ずかしがらないでほしい。

謝辞

本稿はJulien Deswaef, How to transition from Twitter to Mastodonの日本語訳である。CC BY-SAが適用される。

Pleromaインスタンス一覧を作った

概要

Pleromaインスタンス一覧

背景

マストドンのインスタンス一覧が乱立しているのに対して、Pleromaのインスタンス一覧はほとんど知られていない。Pleroma公式ウェブサイトに掲載されているインスタンスは実質2件 (他にフロントエンドのみPleromaのインスタンスが1件) である。マストポータルはインスタンスを登録するときGNU social、マストドン、Pleromaから実装を選択できるが、Pleromaのインスタンスのみを検索する方法が見当たらない。マストドン日本語ウィキのPleromaの記事には7件のインスタンスが記載されている。

提案手法

そこで、Pleromaのインスタンスの一覧を自動的に生成する方法を提案する。すでに、Peers APIを用いてインスタンス一覧を自動的に生成する手法が知られている。このインスタンス一覧にはマストドンとPleromaのインスタンスが含まれるため、Pleromaのインスタンスのみを抽出して表示すればよい。

インスタンスがPleromaであるかどうかを判断するために /api/pleroma/emoji を用いる。Pleromaのみに存在するAPIのうち、GETメソッドかつ認証不要でアクセスできることから、このAPIを選択した。このAPIにアクセスしたときJSONを返すインスタンスはPleromaであると判断する。稀に、すべてのパスに対してHTML形式のメッセージを返すウェブサイトが存在する () ので、これを避けるため、応答がJSON形式であることを確認する必要がある。

実際にPleromaのインスタンス一覧 (API) を作成したところ、20件のインスタンスを収集することが出来た。

制限

今回の実装では、掲載されるインスタンスはPeers APIを提供しているものに限られる。これは、2018年1月15日以降にdevelopブランチのコードを取り入れていることが必要である。

感想

APIを提供しないインスタンス一覧は何をやってもだめ。

マストドンインスタンス一覧を自動で作る

概要

マストドン2.1.1より /api/v1/instance/peers が導入された。これを使えば、誰でも簡単にインスタンス一覧を作ることができる。

背景

日本語圏のマストドンではインスタンスの一覧が乱立していることが知られている。このうち、インスタンスの登録が自動化されているものはinstances.socialマストポータルがある。また、自前ではインスタンスの登録を受け付けず、instances.socialのAPIを利用しているインスタンス一覧もある。

一方、インスタンスの登録にウェブサイト管理者の承認が必要であったり、ウェブサイト管理者が自分でインスタンスを収集していたりする場合には、ウェブサイト管理者の負担が大きいという問題がある。さらに、ウェブサイト管理者がインスタンスの登録の申請に応答しなくなり、インスタンス一覧の更新が途絶えている例も少なくない。有力なインスタンス一覧の更新が途絶えた場合には、古参のインスタンスに有利であり、新興のインスタンスには不利な状況になる。

ところで、マストドン2.1.1より /api/v1/instance/peers が提供されるようになった。これは、あるインスタンスに接続されている別のインスタンスのリストを提供するAPIである。Pleromaではstats-daemonブランチでPeers APIの開発が行われており、2018年1月15日にdevelopブランチにマージされた。すでにこのAPIを運用しているPleromaインスタンスには pleroma.distsn.org がある。

このAPIを再帰的に探索することにより、誰でもインスタンス一覧を作ることができる。このインスタンス一覧はインスタンスの登録が不要で、自動的にインスタンスを収集することができる。収録されるインスタンスの数と、新しいインスタンスを捕捉する早さは、既存のインスタンス一覧を簡単に凌駕する。

インスタンス一覧の作成

そこで、この節では、Peers APIを再帰的に探索することにより、自動的にインスタンス一覧を生成する方法を解説する。ソースコードは github.com/distsn/instances にある。重要なことは、深さ優先探索ではなく幅優先探索を用いることである。幅優先探索なので、先入れ先出しのキューを用いる。

準備

原初インスタンスのリストを用意する。私の実装では、以下のインスタンスを原初インスタンスとしている。これらのインスタンスのなかにはPeers APIを提供していないものもあるが、これは、将来のバージョンアップに期待してのことである。

  • mastodon.social
  • mastodon.cloud
  • pawoo.net
  • mstdn.jp
  • friends.nico
  • mstdn.kemono-friends.info
  • mstdn.maud.io
  • mastodon.juggler.jp
  • pleroma.soykaf.com
  • pleroma.knzk.me
  • ketsuben.red
  • plrm.ht164.jp
  • pleroma.vocalodon.net
  • plero.ma
  • pleroma.taketodon.com

反復

インスタンスの収集のため、以下の動作を繰り返す。

  1. 原初インスタンスのうち、キューに登録されていないものがあれば、キューの入口に追加する。
  2. キューの出口からインスタンスを1個取り出す。
  3. 取り出されたインスタンスの /api/v1/instance/peers を取得する。
  4. /api/v1/instance/peers のアクセスに失敗した場合は、手順1に戻る。
  5. /api/v1/instance/peers で得られたインスタンスを、すでにキューに登録されているものを除いて、キューの入口に追加する。
  6. 取り出されたインスタンスを、再びキューの入口から追加する。

追加の情報を得る

Peers APIで得られるのはインスタンスのホスト名のみである。ここでは、インスタンスのさまざまな情報のうち、自動的に取得できるものを紹介する。

/api/v1/instance

/api/v1/instance で得られる情報には、以下のものがある。

  • インスタンスの名称
  • インスタンスの説明文
  • 連絡先メールアドレス
  • バージョン
  • 登録ユーザー数
  • トゥート数
  • 接続インスタンス数
  • サムネイル画像
  • トゥートの最大字数

登録ユーザー数は、あまりに簡単に取得できるがゆえに濫用された指標である。

サムネイル画像を真面目に設定しているインスタンスは少数である。しかし、結月ゆかりインスタンスサムネイル画像は素晴らしい。

トゥートの最大字数を報告するのはPleromaの独自機能である。マストドンでのイシュープルリクエストは不穏になっている。

/api/v1/instance/activity

/api/v1/instance/activity と /api/v1/instance/peers は同時期に開発され、マストドン2.1.1から有効になった。/api/v1/instance/activity で取得できる情報は以下。

  • 週間トゥート数
  • 週間アクティブユーザー数
  • 週間新規ユーザー数

一例として、分散SNSフォーラムの流速順インスタンス一覧は、インスタンスの名称、サムネイル画像、週間トゥート数を用いている。

将来の課題

悪意のあるインスタンスが、無意味なホスト名を大量に羅列した /api/v1/instance/peers を送信することで、DoS攻撃が可能だと思う。

まとめ

インスタンス一覧は /api/v1/instance/peers を使えば30分くらいで作れる。あと、インスタンス管理者はサムネイル画像を設定してくれ。