#relay考

https://dtp-mstdn.jp/@noellabo/101679372761506662

これはそうなんですよねｗ

何となく「#relay考」ってあったなと思い出してそれをパクって #ハッシュタグ考 を使ってみた感じです。

https://minohdon.jp/@moriyaki/100648625919384104

そんな感じのrelayサーバ立てて、後は参加する各インスタンスが適宜ドメインブロックで調整するとか割と良さげ？
#relay考 #Mastodon

#リレーの話
#ハッシュタグの活用

以前に #relay考 というタグで書いたことがあるんだけど、そうやってタグ付けしておいた情報は、あとから引っ張り出してきて読むことができます。

このリンクから辿ると、DTP-Mstdn.jpに蓄積されたタグ付き発言がみられます。
https://dtp-mstdn.jp/tags/relay%E8%80%83

これ、すごく強力ですよね。 #dtp

リレー機能の件。
ルートリフレクタに例えたように、リレーションの数が極端に多い場合はフルメッシュよりも転送負荷は下がるのよね。
ただ、iBGPみたいに、ハブスポークか、フルメッシュか、どっちかとやるわけでなし、どちらも共存となった場合は少し事情が異なるのかなと思う。
あくまで、リレーしとるインスタンスのユーザー全体数と同数のインスタンスとフルメッシュするよりは負荷は軽いよね位の認識かなぁなんて。
JPがリレーとかしたら、大惨事やろうなぁ。
大規模インスタンスは多分それ専用のリレーサーバを構えて、覚悟した鯖缶のみつなぎに行くようにしたほうが良いのだろう。
#relay考

最近あまり活用されていないMastodon日本語メタフォーラムですが、こちらのトピックも参考になるので掘り起こしておきます。

インスタンスの容量の節約のアイデア
https://discourse.mstdn.jp/t/topic/181

#relay考
QT: https://dtp-mstdn.jp/@noellabo/100386583641342200

インスタンスのDBやメディアの保存容量圧縮について

リレーによるトラフィック増大を受けて、マジで考えなくてはいけなくなってきた件。

ちょうど今 @Gargron さんがpostした内容がぴったりです。
https://mastodon.social/@Gargron/100386555690511875

こちらのissueです。
https://github.com/tootsuite/mastodon/issues/1554

問題は認識されています。

掃除する基準、それを実行するsidekiqタスクが膨大になる件、など、相応に難しい問題だということですが、解決したいですねー。 #relay考

@toneji さん管理の箕面どんで、ディスク容量不足によるダウンがありました。

リレーによる急激なトラフィック増大が、直接または間接的な原因と考えられます。

@theoria さんが指摘していた通りのことがストレートに起きた感じです。
https://wug.fun/@theoria/100379745939116761

俳句検出Bot @find575@theboss.tech も、自鯖におかないようにしているそうですw
https://wug.fun/@theoria/100384460903755520

#relay考

あ、リレーサーバ経由でインスタンスが受信して連合タイムラインに流れるトゥートに対して、ユーザのワードミュート・ユーザミュートが効くなら、botのトゥート云々はそこまで気にしなくてもいいかも？
#Mastodon #relay考

@centumix そういやホスティング勢は改造するワケにはいかんのか……。

必要性を訴えてマージしてもらうの、ハードル高いな……。 #relay考

＞・リレーに送信するが、受信しないインスタンスを認める（inboxに投げるだけでフォローしなければOK）

これの逆で、トゥート量の多いインスタンスが、リレーを受信するが、送信はしない、という設定もMastodon標準で実装されて欲しいかも。

(Mastodonホスティングサービス利用勢なので、MASTER動かしてる訳ではないですが、現状ではリレー送信/受信がセットになっている？)
#Mastodon #relay考

@centumix botバッチが設定されているアカウントのトゥートを、インスタンス側で投げないようにしました ＞ DTP-Mstdn.jp

commitおいておきます。誰でもできる簡単なお仕事です……
https://github.com/dtp-mstdn-jp/mastodon/commit/84ba276d980e28306f756dc546315c4e4d8c8550

インスタンスでルール化しているなら、Mastodon側でBotアカウントの公開トゥートを強制的にunlistedにしてもいいような気がします。 #relay考 #dtp

https://dtp-mstdn.jp/@noellabo/100382151508775296

botバッチが設定されているアカウントのトゥートは、
・そもそもリレーしない
か
・リレー自体はするが、管理者orユーザが除外指定できる
のどちらかにしておいた方が良いかもと思ったり。

#Mastodon #relay考

@Cutls クライアントで実現しちゃうのが手っ取り早いので、私もクライアントに手を出したい……。

他方、WebUIや本体が標準でもっていないと、Mastodon全体の発展には繋がらないんですよねぇ。 #relay考

#relay考 のリモートタイムラインはそういう機能を持ったクライアントがいくつかありますね

Mastodonは、連合があるから、どこのインスタンスに登録しても同じだよ！

……というのは今のところ情報強者の理屈でして、

よくわかんないけど、たしかにそうだね

って状況を自然に実現する方法は、もう少し智惠を絞っておいた方が良いと思います。

リレーがうまく機能すれば、その一助になると思いますが、この観点からはどうでしょう？

#relay考

リレーされる情報を、無作為に減らして、一定量以上はリレーしないようにする、という乱暴な実装も考えられる。負荷軽減策。

1toot/秒以上は受け取らないとか、100toot/日をlimitにするとか。

pub-relayの実装も、全ての情報を確実に伝えることは意図していない（リトライしない）し、まぁ賑わえば歯抜けでもいいんじゃね

#relay考

リレーによる機能の実現

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

リレーの倫理

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

#relay考

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

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

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

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

#relay考

大規模インスタンス

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

中小インスタンス

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

お一人様インスタンス

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

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