信頼できる署名(LDS)があれば、どれだけ多くのリレー先に届けても、送信元の負荷は一定です。リレーに預ければ、それで終わりです。
ところが、リレー先が一斉に送信元にデータを確認しにいく実装となると、リレー先が増えれば増えるほどアクセスが集中することになり、多大なる負荷となります。(nginx等でキャッシュすることで大幅に負荷を軽減できますが、依然としてリレーより負荷が高くなります)
やはり、PleromaにLinked data Signaturesのサポートを追加するのが現実的であるように思います。
#リレーの話
#ハッシュタグリレー
Mastodonの場合、LDSが含まれるため、信頼できると確認できますが、Pleromaではこれができません。
Mastodon側で対応する方法としては、Activityに含まれる本来の送信元へ問い合わせして、裏付けをとるという方法があります。
投稿であれば、実際の投稿内容を取得して、一致しているかどうか確認すればいいわけです。動作としては、おおよそブーストの場合と同じです。(我々はフェッチしにいく、という言い方をします)
削除であれば、HTTP 404 Not Foundか、Tombstone(削除されたことを示す《墓石》)になっていることを確認すればいいわけです。
ただし、この実装は著しく非効率です。
Pleromaのリレー実装が、このようなブーストベースのものになっているということですが(詳しく見ていません)、コンセプトはともかく、実用上は現実ではないと言われています。
雪餅(2018) 連合リレーと Activity Relay
https://blog.yukimochi.jp/2018/12/fediverse-with-relay.html
#リレーの話
#ハッシュタグリレー
リレーのPleroma対応、現在の結論としては、PleromaにLinked data Signatures(LDS)のサポートを追加するのが最善という判断です。
--
PleromaのActivityには、LDSによる署名が含まれておらず、リレーから送信されてきたActivityが信頼出来るかどうか判断できません。
そのため、リレーから送信するところまでは動作するのですが、受け取ったサーバが拒否します。
通常の連合では、HTTP Signaturesによって、送信元、送信先、日時、送信内容(Activity)のハッシュを署名して送信し、受け取った側でそれを検証することで、改ざんされていない内容であることを確認しています。
Pleromaでは、これで必要十分であるとして、LDSのサポートを省略しています。
ところがリレーの場合、送信元が元の送信元ではなくリレーになるため、Activityの送信元と不一致で信頼できません。
#リレーの話
#ハッシュタグリレー
sidekiq、25 worker が一気に始動して、あとは順次入れ替わっていって、全部終わって次が来るの待ってる、という感じ。実に健康的なお通じ(ブチミリません)
この時、エラー出たら即座にあきらめてリトライしません。何かあって受取損ねたら、配信されないで終わります。
#リレーの話
#ハッシュタグリレー
リレーの配信ログみてると、早いところは 0.1 sec とかで終わるし、遅いトコは 3.3 sec とかかかったりしてる。まんなかは 1.0 sec ぐらいかな。さすがにドイツの非力鯖は遅い(ウチの観測鯖)。ちほーがやたら速い。
sidekiqが 25 worker で動いていて、ひたすら配信だけしかしてない。メモリは半分ぐらい空いてる。CPUは76ms平均とかそんな感じ。
これから何か実装する度に重くなるし、まだ最適化のことは考えていないけど、今は余裕がある。
#ハッシュタグリレー
#リレーの話
個人でリレーに参加する場合、リレーは、フォロワーの一人としてprivate投稿まで受け取っています。publicのみに制限していますが、privateをリレーしてしまうこともできます。
実質的にリレー先にフォロワーがいるときと同じなので問題はないのですが、流量が増えるだけでどのみち誰も見られないので、メリットが特にありません。
一方、未収載は、公開投稿の一種ですし、各サーバのアカウントから辿れば内容を見ることもできます。サーバに情報をキャッシュさせておくメリットもありますので、やる価値はあります。
なお、ハッシュタグはpublicが原則なので、未収載ではハッシュタグタイムラインで見ることができません。
ただし、imastodon方面に未収載タグを有効にする改造があります。これに対しては、未収載がリレーされた方が、認識されてハッピーかもしれません。
受信側で未収載を受け取る設定ができるようにしましょうかね。
ちなみに、リレーは投稿を改ざんできません。署名を検証する機能があり、発信元のサーバ以外で変更すると、受け取る側のサーバに弾かれます。
#リレーの話
#ハッシュタグリレー
ハッシュタグリレーは、2018年9月6日深夜に発生した北海道胆振東部地震の報を受けて、ハッシュタグの流通支援が役立つかもしれないと思い、午前中に鯖借りて昼に稼働と、半日で立てたところから始まっています。もともと専門でやるつもりじゃなかったという。
リレー本体のプログラムは、フィルタリング機能を持たせるための書きかけのヤツがあったので、ハッシュタグオンリーにする改造を場当たり的にやって投入しました。
まだ早すぎた感があり、そのときは特に活用されなかったのですが、徐々に認知が広がってきて使われるようになってきたので、結果オーライですね。
本日投入した個人参加機能は、大規模サーバや小規模サーバのように、サーバ単位でのリレー参加が難しい場合でも活用できるように考え出された機能です。
https://dtp-mstdn.jp/@noellabo/101480747534086773
theboss.tech閉鎖、及びそのテスト用インスタンスmasi鯖の閉鎖によって各地に四散している元参加メンバーへの支援でもあります。
まだ色々バグや機能不足があるので、そのへんを直して、正式投入したいと思います。
#リレーの話
#ハッシュタグリレー
自分のトゥートをリレーに流せるメリット、実はかなりあると思う。フォロワーを獲得しなくてもばらまけるのだし。 #リレーの話 #distsns
QT: https://mastodon.cardina1.red/@lo48576/101228249967718981
Advent Calendarでも書いたけど、インスタンスが持っているリモートのキャッシュを充実させて、そこから必要なものを抽出することが目的。
リレー利用は強欲・富豪の戦略。分散SNSから、自分のところにコピーをできるだけ集めてくる。
インスタンスの役割とリレーのもたらすもの
https://noellabo.jp/blog/mastodon-advent-2018-10/
#リレーの話
Mastodon Advent Calendar 2018の10日目の記事をアップしました。
インスタンスの役割とリレーのもたらすもの | のえる研究所
https://noellabo.jp/blog/mastodon-advent-2018-10/
リレーが何をするもので、そもそもインスタンスが引き受けている役割はこういうことだから、リレーを導入するとこうなるよ、という話をまとめて書きました。
#リレーの話 タグで感想お願いします!
雪餅リレー、頼れるパトロン達が支援していて、ヘタなインスタンスより運営安定してきた感ある。
https://relay.toot.yukimochi.jp/
リレーサーバ、いうても受け取ったアクティビティを参加サーバの数だけリピート配信するだけだし、リトライしないので、そんなに重くないよ。画像とか処理しないし。
ハッシュタグをフィルターする処理あるっちゃあるけど、証明書の処理などと比べてたいした負荷じゃないし。
(時々不具合っぽいので死んでてご迷惑おかけしてますが)
いま、さくらのクラウド2Gなので、スペック不足なら増強して対処します。
#リレーの話
#theboss_tech が参戦したハッシュタグリレーですが、さすがにハッシュタグだけリレーなので、流量はたいしたことありません。
既に十分な流速のFTLをお持ちのインスタンスにおいては、参加しておいて損はないかと思います。
https://hashtag-relay.dtp-mstdn.jp/
#リレーの話
リレー参加のインスタンスは、選りすぐりのリストという話をしたな。あれはウソだ。
リレー管理者がメンテしないと、死んだインスタンスが混じってしまう。
リレー管理者は、停止措置ないし削除をする権限は確保せねばならぬ。あるいは、条件設定して、自動削除するようにすべきか。
リレー、やはりオプショナルな位置付けなのは変えない方がいいと思うな。
リレーの為に変更すべきところは、リレーに送信するトゥートをフィルタリングする機能。
今のところリレー側でrejectするようにコード書いてるけど、半分無駄なので、これをあとで本体に持ってくる(ちゃんと整えてから)。
#リレーの話
DTP・デザイン・印刷のテーマサーバ DTP-Mstdn.jpやってます。
#Illustrator #スクリーン印刷 #インクジェット #カラーマネジメント #運営
#searchable_by_all_users