noellabo's tech blog

@noellaboの技術ブログ

インスタンスの役割とリレーのもたらすもの

この記事は、ぐすくまさん主催のMastodon Advent Calendar 2018の10日目の記事です。

昨日9日目の記事はろーかるゆーざーさんのMastodonは「きっかけ」 | WWW.BLUECORE.NETでした。


おはようございます。のえる@DTP鯖管です。

DTP-Mstdn.jpというDTP・デザイン・印刷がテーマのMastodonインスタンスと、ハッシュタグ付きトゥートのみをリレーするハッシュタグリレーを運営しています。

本稿では、何か連合リレーの話をしようということで、インスタンスの役割を振り返りながら、リレーについて考えたことをまとめてみました。

リレーの概要

リレーがやっていること

リレーですが、技術的には、

  • リレーに参加したいインスタンスの登録を受け付け
  • インスタンスの公開トゥートを預かって
  • 全ての参加インスタンスに引き渡す

公開トゥートの共有を支援するシンプルなサービスです。

  • 保持するのは登録インスタンスのリストだけ。ひたすら登録先へトゥートを配送する
  • 配送が済んだらトゥートは破棄される。配送に失敗した場合も、そのまま破棄する
  • ハッシュタグリレーのように、内容を特定の条件でふるい分けて、配送する亜種あり
  • 配送には、新規の公開投稿の他、公開投稿の削除、ブーストされた投稿が含まれる

インスタンスで起きること

接続すると、連合タイムラインに、参加インスタンスの公開トゥートが次々と流れてきます。

自インスタンスの公開トゥートも、リレー参加インスタンスに配送されていきます。

これにより、

  • 参加者が多く、流れの速いタイムラインを形成できる
  • あまりフォローされていないユーザーの公開トゥートが、より広い範囲で観測される
  • 相互に、キャッシュ済みのトゥートが蓄積される

ここでのポイントは、フォロー関係にないユーザーのトゥートが流通しているということです。

インスタンスの役割

リレーは単純な仕組みですので、リレーだけを見てもそれにどういう意味があるかはわかりません。

分散して連合するFediverseの中でインスタンスが果たしている役割を考えることで、初めてリレーがもたらしているものが見えてきます。

ユーザーの本拠地

インスタンスの主要な役割の一つは、ユーザーの本拠地としての機能の提供です。

  • アイデンティティ(acctと秘密鍵)と公開情報・設定を保持し、適切に開示する
  • 投稿したトゥートと添付データ(画像・動画等)のオリジナルを保持し、適切に開示する
  • フォロワーのリストを保持し、アクティビティを配信する
  • ブロック、ミュートしているリストを保持し、拒否する

ユーザーにまつわる様々な情報のオリジナルを保有し、それを適切に処理する役割です。

情報のキャッシュ

もうひとつの主要な役割は、外部の情報をキャッシュすることで、所属ユーザーに自立したサービスを提供することです。

  • リモートユーザーのアイデンティティの複製を保持し、なりすましを拒否するとともに、リモートユーザーに対するアクションを助ける
  • リモートユーザーのトゥートの複製を保持し、そのトゥート一覧の他、お気に入り、ブースト、リプライツリー、ハッシュタグタイムライン、リストなどの表示の要求があった際に、インスタンス内で解決するに十分な情報を保有する
  • 一定数、インスタンス共通の各タイムライン、各ユーザーのホームタイムラインの内容を保持する

常時要求に応えること

もう一つ見逃せない点として、インターネット上で常にサービスを提供するため動作しつづけていることがあります。

  • 接続しているインスタンスのアクティビティに常時応答し、Fediverseの一員として責務を果たすこと
  • オフラインのユーザーのためにあらかじめ必要なものを用意しておき、オンライン時にそれを提供すること

つまりインスタンスの役割とは

タイムラインを流れる“今”を提供し、ユーザーのアクティビティを支援するために、オリジナルとして保持するストックと、外部から取得したキャッシュを組み合わせて、常時稼働してそれを維持し、ユーザー体験を向上させていくことです。

リレーの役割

さて、インスタンスの役割を確認したところで、あらためてリレーの役割について考えます。

ユーザー情報の充実

リレーを導入することで、接続したインスタンスで公開トゥートを行っているユーザーの情報が、順次インスタンスにキャッシュされていきます。これにより、インスタンスに多数のユーザー情報が集まります。

この“インスタンスが既に知っている”ユーザー情報を使って、ユーザーの検索や、メンション(@付きのユーザー指定)の際のユーザー名の補完などが可能です。

リレーを用いない場合、直接acct(@noellabo@dtp-mstdn.jpのように、ユーザー名とインスタンスドメイン名を組み合わせた一意のユーザー識別子)を入力しない限り、誰かがフォローしたりブーストした、誰かが知っているユーザーしか候補になりません。

リモートユーザーの過去トゥートの充実

インスタンスで初めて認識されたユーザーは、過去のトゥートのキャッシュを持っていないため、これまでのトゥートが表示されません。リレー参加インスタンスのユーザーは、あらかじめトゥートが取得された状態で発見されるため、過去のトゥートを参照することができます。

元のインスタンスにアクセスすればオリジナルの完全な情報が取得できますが、それは強い関心を持っている場合に限られます。そうしなくてもその場で解決できることが重要です。過去トゥートをお気に入りしたりブーストするのも、その場で参照できればこそです。

ハッシュタグタイムラインの充実

ハッシュタグは、関心を軸にトゥートを横断的に参照する機能で、これはストックがモノを言います。検索に制限のあるマストドンにおいて、ある意味ハッシュタグは最強の部類です。リレーを導入することで、このハッシュタグつきトゥートのストックが充実します。

インスタンスによっては、ローカルタイムラインを特定のハッシュタグタイムラインに置き換える改造を入れているケースがあります。マストドン日本語ウィキのローカルタイムラインをデフォルトタグタイムラインに置き換えるを参照してください。私が運営しているDTP-Mstdn.jpもその一つです。リレーを導入することで、リレー参加インスタンスから、単に特定のハッシュタグをつけることで、そのインスタンスのローカルタイムラインに参加できます。

連合タイムラインの充実

リレーを導入することで、導入しない場合に比べて、連合タイムラインの流速が速くなります。見たことのないユーザーのトゥートも多数観測できるようになります。従前の連合タイムラインは誰かがフォローしている人が中心ですので、新しい発見が次第に少なくなってきますから、刺激になるでしょう。

新しいユーザーのトゥートをインスタンスの誰かがブースト、リプライしたり、そのユーザーをフォローすることで、交流の輪が広がる可能性が高まります。

お一人様インスタンスや、開設したばかりのインスタンス、規模の小さいインスタンスでは、リレーからの流量の方が多くなるかもしれません。

フォローしないことによる軽量化

リレーはその性質からキャッシュを増大させるため、負荷が高まるということで、敬遠されがちです。

しかし、実は従来の連合を充実させる手法、つまりインスタンスの所属ユーザーがいわゆる“FederationBot”として振る舞い、片っ端からユーザーをフォローしてまわることに比べて、負荷が軽くなるケースが考えられます。

100のBotにフォローされていると、1トゥートにつき、インスタンスは100個の配信を行わねばなりません。同じ事をリレーで行う場合、リレーに1個だけ配信すれば済みます。受け取る側も、無駄にBotのホームタイムラインを処理する必要がなくなります。また、インスタンスやアカウントが何らかの理由で繋がらなくなった場合、インスタンスが抱えてリトライする必要はなく、リレー側で代表して適切に処理されます。

FederationBotは未収載やフォロワーのみへのトゥートを受け取る主体としては不適格ですし、個人のユーザーで大量にフォローする行為も、結局は大部分を読んでいない無駄の多い行為です。フォローにせよ解除にせよ、まとまるとこれがなかなかに重い処理です。

個別にフォローする必要の低いアカウントについては、リレーにオフロードするという運用も一考頂ければと思います。

リレーの将来に向けて

リレーには、まだ解決できていない問題がいくつか残っています。全て網羅できませんので、ここは駆け足で。

リレーとインスタンスの連携によるフィルター処理

ハッシュタグリレーは、ハッシュタグ付きトゥートだけを配信するリレーですが、内部的には全てのトゥートを受け取って、タグ付きだけ配送し、それ以外は捨てています。これは、本当はインスタンス側で不要なものをリレーに投げないようにする方が良いわけです。このあたり、インスタンス側にも何らかの仕組みを仕込んでみたいですね。

なお、ハッシュタグリレーは、他にも様々条件でフィルターする処理が書かれていますが、今は稼働させていません。(そのうちやるよ!)

Mastodon以外のActivetyPubサービスへの対応

もともと、ActivityPubをリレーするためのサービスとして、pub-relayという名称がついています。Mastodonにべったり依存しないよう、登録や解除の方法も、専用のAPIではなく、フォローの仕組みを使うようになっていたりします。元々他のサービスからアイデアを借りてきたようなものなので、先方にも別の仕組みのリレーサービスがあったりするんですが、もう少し相互に利用しやすいように整備してもいいかもしれません。

受信する処理能力とキャッシュの廃棄

流量が多すぎると、インスタンスの処理能力をギリギリで運用している場合は厳しいことがあります。キャッシュもどんどん膨らんでいきますので、古く有用性の低いもの、あるいはある程度の期間でバッサリ、古いキャッシュを削除する機能が必要かもしれません。(もちろん本家で検討されているけど結論は見ていない)

大規模インスタンスの参加

Pawoo、mstdn.jp、frends.nicoをはじめとする、ユーザー数の多いインスタンスがリレーに参加していません。リレー側が対応できたとして、前述の通り、リレー参加の小規模インスタンスが負荷に耐えられないかもしれません。ハッシュタグリレーのように絞り込めばある程度軽減できますが、結局、インスタンス毎にリレー上で大規模インスタンスの流量の大部分をブロックすることになりそうです。それでも、ハッシュタグ付きトゥートだけでも、大規模インスタンスに流し込みたいですね。

なお、既存サービスがFediverse対応してきた場合、マストドンインスタンスとは桁違いの流量が発生する可能性があります。リレー以前の話ですが、そのとき、Fediverseはどのように対応するのか、興味深いところです。本稿では割愛しますw

公開トゥートの二次利用

リレーの仕組みを利用すると、公開トゥートを、インスタンス間のリレーだけでなく、他の用途にも容易に利用できることがわかります。たとえば、検索のインデックスを作成したり、捜査機関により危険人物をスクリーニングするのに利用したり、といった具合です。

このあたり、リレーサービスを運用するにあたり、どのように規制しようか考えましたが、結論としては、公開トゥートである以上、防ぎようがない、という判断に落ち着きました。個々のトゥートに利用目的を限定するための情報を付加することは可能ですが、それに従うかは受け手次第です。むしろ、ライセンスと使用料などを管理する方向で、雑に扱うと扱った側がリスクを負う仕組みにしていくしかないだろうと思います。

こうした、国家を超え、司法や警察力を頼りにくい世界において、人間がどのように物事を解決していく知恵を生み出せるか、興味深いところです。本稿では割愛しますw

リレーは検閲やブロッキングを行うべきか

前述のように、リレーは一時的に公開トゥートを保持しますが、永続的には保持しません。添付データも取得しません。専ら、配送のみを行います。また、インスタンス管理者による個別のフィルターの設定を受け付けますが、インスタンスの管理者以外には設定を許可しません。リレーサービスそのものに対する脅威、たとえば脆弱性を突いた不正アクセスやサービス停止攻撃などの直接的な被害があれば、自衛のために接続の拒否などの処置を行います。しかし、トゥートの内容から個々にフィルターしたり、内容を書き換えたり、接続を拒否するなどの行為は、接続するインスタンスの管理人が判断すべきという考えです。

幸いなことに、リレーは中央集権的なサービスになりがちであることが最初から考慮されており、任意の複数のリレーを設置し、複数のリレーに自由に参加できる仕組みが用意されています。このことをもって、制限を課したリレーを設置する自由も担保されていると言って良いと思います。

オススメのリレーサービス

Mastodonのリレーの管理画面に最初からある、公式のjoinmastodonのリレー、あれはダメですw

日本国内では、YUKIMOCHI Toot Relay Service(雪餅リレー)がもっともユーザーが多く、オススメです。設置者の雪餅さんは、独自のリレープログラムを開発してしまうなど、日本のリレーサービスをリードしています。運営継続のための寄付も受け付けていますので、ぜひ皆さんで応援してください。なお、Advent Calendarの17日目にActivity-Relay を宣伝しますという記事を書かれるとのこと、今から楽しみですね!

また、ハッシュタグをリレーするメリットだけを享受したいという場合は、私の運営するハッシュタグリレーをご検討ください。両方を登録してもいいと思います。

あなたの #リレーの話 を聞かせてください

長々と書きました。ここまで飽きずに読めた人はいますか?w

もし、リレーについて何か考えたり、このエントリーの感想などがありましたら、ぜひ #リレーの話 タグをつけてトゥートしてください。

それでは、ありがとうございました。


明日11日目の記事はあくあーらさんのどうせ自分ひとりで使うものなんだし、自分で使いたい機能だけを盛り込んだオレオレクライアントを、みんな気軽にガンガン作っていこうぜ、という話の予定です。