インスタンスの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
DTP鯖管
さんがブースト
To Mastodon admins who are testing the federation relays feature, how's it going? #mastoadmin
DTP鯖管
さんがブースト
DTP鯖管
さんがブースト
うちのが大分古くて怪しい感じになってたので、Amazonプライムデーセールに入ってた国内正規品の方のi1 Display Proをここぞとばかりにポチッとな。キャリブレータ欲しい人はチャンス。とは言え、それでも並行輸入品の方が安いんだよなぁ。
https://amzn.to/2zJCWAH #dtp
relayの裏でwakinさんのsimple_apをずっといじってる。
なんか例外吐いてるっぽいところがあるんだけど、どうデバッグしていいかわからない。Pythonも頑張らねば……。 #dtp
DTP鯖管
さんがブースト
そもそも、旦那に浮気 🤔 #dtp
やっぱり銀河丼をリレーに引き込まなあかん。もっと環境を整備しておかねば……。 #dtp
Typekitの本当の凄さは、本家とはライセンス(許諾範囲)が異なることかな。
……DTP勢の詳しい人を呼んでこないと説明できないけどw #dtp
DTP鯖管
さんがブースト
| д゚) てな感じで例のアレを記事化しました。#dtpstudy28 /Windows 10のFont Cache Serviceを停止する方法 http://dslabo.blog4.fc2.com/blog-entry-2381.html #dtp
DTP鯖管
さんがブースト
今日でこのインスタンス・bookwor.msは一周年です。昨年7月16日の21:19に準備完了ってツイートをしております。特に一周年だから、というわけではありませんが、bookwor.msのロゴステッカーとしおり、ご希望の方に差し上げています。送り先を教えていただければ郵送しますよ。
(ロゴのデザインはxanac @rk_asylum さんです、カッコよくて嬉しい)
DTP鯖管
さんがブースト
宣伝です☺️
オリジナル漫画「メルプのまんが6巻 メルプと海と小宇宙」の電子書籍配信が本日から開始!
創作同人電子書籍 いっせい配信イベント第7回「創作同人2018年7月」に参加しています!
★Book☆walker
https://bookwalker.jp/de630f21df-a894-445d-b8c1-797dbed31937/
★booth (PDF)
https://achi.booth.pm/items/933884
★AmazonKindle
https://amzn.to/2L6inje
Mastodonは、連合があるから、どこのインスタンスに登録しても同じだよ!
……というのは今のところ情報強者の理屈でして、
よくわかんないけど、たしかにそうだね
って状況を自然に実現する方法は、もう少し智惠を絞っておいた方が良いと思います。
リレーがうまく機能すれば、その一助になると思いますが、この観点からはどうでしょう?
リレーされる情報を、無作為に減らして、一定量以上はリレーしないようにする、という乱暴な実装も考えられる。負荷軽減策。
1toot/秒以上は受け取らないとか、100toot/日をlimitにするとか。
pub-relayの実装も、全ての情報を確実に伝えることは意図していない(リトライしない)し、まぁ賑わえば歯抜けでもいいんじゃね🤔
見づらいとこ書き直したくなるけど、やめておこうw #dtp
リレーによる機能の実現
・リレーに送信するが、受信しないインスタンスを認める(inboxに投げるだけでフォローしなければOK)
・特定の条件を満たす情報のみリレーする機能(タグ、キーワード、インスタンスなど)
・リレーをリレーする機能(ループしないよう、経路情報やTTLのような情報が必要?)
・経路情報やキーワードマッチ結果などの付加情報を持たせる機能(元情報をペイロードとするガワをつくる等)
リレーの倫理
・利用目的の明示(目的外利用の禁止:検索インデックス作成、トップランキング、ワーストランキング等)
・検閲・情報統制への利用を防ぐとともに、スパム・迷惑行為への対処をどう実現するか
リレー+インスタンス側のフィルタによる機能の実現(クライアントによっても実現できる)
リモートタイムライン(指定インスタンスのトゥートだけを選択的に表示するTL)
・リレー供給を受けていれば、自インスタンスに居ながらにして別のインスタンスのTLが再現できる
インタレストフィルタ(被ブースト・お気に入り・リプライ数によって表示可否を設定)
・リレーによって流入したトゥートを非表示にする(ユーザーが選択)
・誰もインタラクションしていないトゥートを非表示にする(ユーザーが選択)
インタレストフィルタの考察
・インスタンス内の誰かが関心を持っている外部の情報、というこれまでのインスタンス毎の連合タイムラインの意味を再確認し、その方向を強化するためのフィルタ
・当初フィルタされていたトゥートがあとから表示する条件を満たした時に、どのような挙動となるのが理想か(ひょっこりその場に現れるべきか、何らかの基準でageられるべきか)
大規模インスタンス
・大規模なインスタンスは、既に十分なユーザーを抱えていて、基本的に自己充足している
・ユーザーのリモートフォロー・リプライ・ブースト等により、連合タイムラインに他のインスタンスのトゥートが十分に流入している
・他のインスタンスのLTLから無条件の供給を受ける必要はない
・網羅的な情報が有用なので、タグTLの供給は受けてもよい
・最小限の負荷であれば、LTLを供出してもよい
中小インスタンス
・少ないリソースで運用しなければならないため、身の丈を超えた流入は受け入れられない
・負荷軽減のため、流入量に制限を設けたい
・特定のタグの情報は欲しい
・特定のキーワードなど、内容により選別されたトゥートは欲しい
お一人様インスタンス
・あらゆる戦略が考えられるが、他のインスタンスのアカウントを必要とせず、自インスタンスに居ながらにして最大限Fediverseを活用するという目的であれば、興味のあるインスタンスの情報は受け取りたい
・情報を絞り込む戦術など、その他の事情は、中小インスタンスと共通
#relay考
DTP・デザイン・印刷のテーマサーバ DTP-Mstdn.jpやってます。
#Illustrator #スクリーン印刷 #インクジェット #カラーマネジメント #運営
#searchable_by_all_users