のえる DTP鯖管 @noellabo@dtp-mstdn.jp

リレーによる機能の実現

・リレーに送信するが、受信しないインスタンスを認める（inboxに投げるだけでフォローしなければOK）
・特定の条件を満たす情報のみリレーする機能（タグ、キーワード、インスタンスなど）
・リレーをリレーする機能（ループしないよう、経路情報やTTLのような情報が必要？）
・経路情報やキーワードマッチ結果などの付加情報を持たせる機能（元情報をペイロードとするガワをつくる等）

リレーの倫理

・利用目的の明示（目的外利用の禁止：検索インデックス作成、トップランキング、ワーストランキング等）
・検閲・情報統制への利用を防ぐとともに、スパム・迷惑行為への対処をどう実現するか

#relay考

リレー＋インスタンス側のフィルタによる機能の実現（クライアントによっても実現できる）

リモートタイムライン（指定インスタンスのトゥートだけを選択的に表示するTL）
・リレー供給を受けていれば、自インスタンスに居ながらにして別のインスタンスのTLが再現できる

インタレストフィルタ（被ブースト・お気に入り・リプライ数によって表示可否を設定）
・リレーによって流入したトゥートを非表示にする（ユーザーが選択）
・誰もインタラクションしていないトゥートを非表示にする（ユーザーが選択）

インタレストフィルタの考察
・インスタンス内の誰かが関心を持っている外部の情報、というこれまでのインスタンス毎の連合タイムラインの意味を再確認し、その方向を強化するためのフィルタ
・当初フィルタされていたトゥートがあとから表示する条件を満たした時に、どのような挙動となるのが理想か（ひょっこりその場に現れるべきか、何らかの基準でageられるべきか）

#relay考

大規模インスタンス

・大規模なインスタンスは、既に十分なユーザーを抱えていて、基本的に自己充足している
・ユーザーのリモートフォロー・リプライ・ブースト等により、連合タイムラインに他のインスタンスのトゥートが十分に流入している
・他のインスタンスのLTLから無条件の供給を受ける必要はない
・網羅的な情報が有用なので、タグTLの供給は受けてもよい
・最小限の負荷であれば、LTLを供出してもよい

中小インスタンス

・少ないリソースで運用しなければならないため、身の丈を超えた流入は受け入れられない
・負荷軽減のため、流入量に制限を設けたい
・特定のタグの情報は欲しい
・特定のキーワードなど、内容により選別されたトゥートは欲しい

お一人様インスタンス

・あらゆる戦略が考えられるが、他のインスタンスのアカウントを必要とせず、自インスタンスに居ながらにして最大限Fediverseを活用するという目的であれば、興味のあるインスタンスの情報は受け取りたい
・情報を絞り込む戦術など、その他の事情は、中小インスタンスと共通
#relay考

ちょっと #relay考 ってタグを試してみます。

Mastodonの管理画面、超格好良いダッシュボードが追加されましたね。なんでいままでなかったんだコレ……w
#dtp

自分でリレーサーバのコードを書いたみたいな実装の説明をしましたが、単に読んで説明しただけです。読み違えていたらご容赦ください。

このあたりを踏まえておくと、リレーってどうよ、という話をする際に、実装を知らずに話すより生産的な議論ができるのではないかと思います。

https://dtp-mstdn.jp/@noellabo/100380169856378128 #dtp

リレーサーバの実装の話。

現在のリレーサーバ実装（pub-relay）は、登録インスタンスのリスト（ドメインとinboxのアドレス）と、登録を拒否（ブロック）するドメインのリストだけをデータベースに持っています。

relay@リレーサーバ というアカウントが直接生えているので、各インスタンスはこれとやりとりしています。

登録インスタンスがrelayのinboxに投稿を投げてよこしたら、全登録インスタンスのinboxにそれを投げ直します（パススルー）。

relayへのフォローリクエストの体で、リレーに登録し、フォロー取り消しで削除。

sidekiqでProcessWorkerとDeliverWorkerが走っていて、ProcessWorkerがrelayに対するリクエストの処理、DeliverWorkerが各インスタンスへトゥートを配信する処理を行います。

sidekiqのキューはdefaultのみ、リトライは行いません。

登録インスタンス一覧と、ブロックの登録・削除を行う、シンプルなコマンドラインツールがついています。

実に美しく読みやすい。
※個人の感想です #dtp

リレー、動かしてみて良いところをみつけたり、問題点をあぶり出したりする段階なので、たくさん話題になるといいな。 #dtp

箕面どんの鯖缶 @toneji さんが、v2.4.3にリレーの機能だけをcherry-pickして動かし始めました。

https://relay.dtp-mstdn.jp をリレーに登録し、参加いただいています。こちらは現在11のインスタンスが登録しています。

@h3zjp@m.xn--fiqwix98h.jp によると、現在下記のリレーが観測されているようです。
https://m.中二病.jp/@h3zjp/100379360586852696

※ リレーはオプション機能で、全文検索機能のように、Mastodonに必ず必要なものではありません。また、まだ最初の実装が提供されて日の浅い、極めて実験的なものです。皆さんに積極的におすすめするものではありません。

いち早く体験し、どういうものが導入されようとしているのか、自ら確認してみたい！という人はやってみてもいいんじゃないかな、という程度です。

※ もともとがオプションということもあり、導入しても具合が悪ければすぐにリレー登録を止められるので、過度な心配は不要です。

※ cherry-pick：自分の気に入ったものだけをつまみ食いする、の意。gitで、特定の変更だけを取り入れるときに使う機能 #dtp

migrateは、データベースに変更が必要な箇所をソースコードから見つけ出して、追加・変更のためのマイグレーションコード（rubyのプログラム）を生成します。

生成したmigrate用のコードは~/live/db/migrate/ に増えていきます。ここをチェックすると、データベースにいつどのような変更をしてきたのか、履歴がたどれます。

生成したコードを実行して、データベースに実際の変更を行います。

このコード生成と実行を行うのが、いつもやっている
RAILS_ENV=production bundle exec rails db:migrate
です。

（まれにmigrateに失敗して、アップデートが立ち往生することがあります。そのときに、問題を起こしているファイルを削除てやりなおしたり、コードに手を入れる場合があります）

Mastodon本体のプログラムは開発者達が修正してくれますが、自分のインスタンスの状態は自分で面倒をみなければならないので、覚えておきましょう！

@toneji #dtp

ここんとこマジメなことばかり言っていたから、少しくだらないことをいって中和せねば（いらない #dtp

@Cutls さんが違う世界線に生きているっぽくて……ゾクゾクする（ちがう #dtp

ふぅ。おはようございます（ぉぃ #dtp

ちなみに relay.dtp-mstdn.jp の確認用臨時サーバはこちらです。
https://mstdn01.noellabo.jp

こちらは参加していただいているインスタンスは現在7つ（＋この臨時鯖）です。 #dtp

@h3zjp@m.xn--fiqwix98h.jp テスト用の臨時インスタンスおいときます。

mstdn-relay.hama3.net 観測所
https://mstdn02.noellabo.jp/

連合にトゥートが流れる状況を観測するためにご活用ください。このリレーにのみ参加しています。 #dtp

同一サーバにインスタンス2個立てのテストをするなど。 #dtp