Fedibird Relay Service(まあFedibirdリレーとでも呼んで下さい)をホストしているサーバを移転し、構成を工夫して安定させました。
リレーへの追加や解除がうまく動かなかった方、恐らくきちんと応答するようになったと思います。
複数のリレープロセスが状態を共有するのに若干のラグがあり、接続直後1分ぐらいは配送が欠けたりしますが、ご了承ください。
Sidekiqでちょいちょいリトライになっていた件も、だいぶ安定したのではないかと。
様子をみますので、よろしくお願いします。
ちなみにFedibirdのリレーもここんとこちょっと遅延することがおおかったんだけど、これは配送先がコケてるとこが多い時。
Sidekiq版はそういう障害に強かったんだけど、いまのヤツは弱いんだよねー。
ちょっと中国系のサーバでコケてる(のか遮断されてるのか)が多かったので、いくつか切断させてもらいました。復帰したら再接続してください(って言っても届かないか)
ハッシュタグリレーはやたら頑丈で、こいつほっといても全然大丈夫。 #リレーの話
リレーサーバは、外部から異質なものを取り入れるための機能です。
特にコミュニティ性向の強いサーバでフォロー対象に広がりが期待できない場合、まだ誰もフォローしていない未知の範囲をカバーする重要な役割があります。
ついては、接続システムが機能停止するような脅威は防がねばなりませんが、それ以外は何でもリレーするようにしなければ、あまり意味を成しません。
ノイズが多いぐらいが丁度良いということです。
これを、必要に応じて選別すべきなのは、リレーに送信するサーバ、および受け取るサーバで、連合から必要な情報を見つけられるようにするのも各サーバの役割だと考えています。
そのあたりのことは、サービス開始時点よりFedibirdリレーサービスなどには記載してあります。
https://relay.fedibird.com/
また、連合から必要な情報を見つけられるようにする機能群は、Fedibirdに実装しています。
#リレーの話 #fedibird
Fedibirdリレーは、こう。
> リレーへ送信するActivityは、送信サーバ側にて適切に取捨選択してください。リレーから受信するActivityは、受信サーバ側で適切に取捨選択してください。
自分で面倒見てねってルールです。Mastodon、Pleroma、Misskeyとも、全部送って全部受け取っちゃうんですけどねw #リレーの話
ウチのリレーは、ハッシュタグリレーが2代目で、Fedibirdリレーが3代目。初代はpub-relayのruby版でした。
ルールを変えるときは、立て直す感じでやってます。
Fedibirdリレーの説明文は読まれているかわからないけど、一般的なリレーサービスより踏み込んだ立ち位置のものになっています。 #リレーの話
リレー、Fedibirdのキーワード購読とか、Misskeyのアンテナと組み合わせると強いよ。 #リレーの話
#fedibird 本日のニュースとして、Misskeyがpub-relayに対応しました。めいすきーと、本家のMisskey v12.37.0です。
これまでフォロー関係が薄いとMisskey系のユーザーと接点が作りにくかったかと思いますが、リレーを通じてFedibirdの投稿がMisskey系サーバに伝わり、Misskey系サーバの投稿がリレーを通じてFedibirdの連合に流れるようになります。
あわせて、Fedibirdのリレーサービスを開始しました。こちらは、当然Fedibirdで行うリレーですので、Mastodonに留まらず、Fediverse全体に意味のあるサービスに発展させたいと考えています。 #リレーの話
現在、国内のリレーサービスは雪餅リレーが牽引しており、今見たら179のサーバが登録されているようです。
Fedibirdのリレーは、雪餅リレーのバックアップを担いつつ、徐々により踏み込んだ機能を拡充していきたいと考えています。
#ハッシュタグリレー も、基本的に継続して運用していきますが、徐々にFedibirdのリレーに役割が移っていくかと思います。
新しいリレーサービスとして、Fedibird Relay Serviceを設置しました。
https://relay.fedibird.com
現在はpub-relay 2.0 (noellabo fork)による、全ての公開投稿を中継する単純なリレーとして動作しています。
今後、ハッシュタグリレーの成果をマージしたり、これまでになかった機能をこちらに追加していく予定です。
Fediverse全体での利用を想定したサービスとして仕切り直しましたので、従来と比べて利用範囲が大きく設定されていますのでご注意ください。
なお、リレーを利用する際は、複数のサービスに同時に接続することをお勧めします。
リレーは中央集権的なポジションになる他、単一障害点になるため、複数のルートを確保することを想定して設計されています。
例えば、雪餅リレーに参加した上で、当リレーに参加した場合、いずれかを通じて先に届いた投稿が受理され、遅れてきた投稿が破棄されます。
これにより、どこかのリレーが遅延・停止しても、全体としては障害の影響を最小限にすることができます。 #リレーの話
#ハッシュタグリレー にサーバ管理者を認証する機能をつけている。これができあがると、サーバ毎のリレーの詳細設定を許可できる。
リレーは、つまるところActivityPubの配送システムなので、やれることはまだまだ色々ある。
問題は、ハッシュタグリレーが一義的にはハッシュタグ限定のリレーであることで、今後はより多用途に展開したいので、別サービスとして仕切り直すつもり。
まぁ、少しずつ進めるね。
#リレーの話
分散で各自のサーバが責任と権限を持つべき重要な内容と、いくつかの集中システムで効率的に処理して良い副次的な内容があって、リレーは後者の役割として案外重要なんじゃないかなって、ずっと思ってる。
DeleteやMoveの配送なんかはそういうものの一つかなと。
#リレーの話
Misskeyにリレーから配送するの、Announceベースでは問題無く流し込めるね。
Createだと、signatureチェックしないで弾かれちゃう。ここはMisskey側がわかってて未実装になってるのでコード足さないとダメだ。 #リレーの話
pub-relayをフォークし、Pleroma対応など機能追加したものを公開しました。記載してませんが、Misskeyとの互換性も向上しています。
https://github.com/noellabo/pub-relay
--
Mastodonのリレーサーバであるpub-relayは、2018/10/30のcommitを最後に開発が止まっていて、事実上放棄された状態にありました。
その間、旗艦サーバであったrelay.joinmastodon.orgも維持されなくなり、デフォルトのリストからも外されてしまいました。Crystalのバージョンアップにより、ビルドも通らなくなっていました。
ですが、ちょっとこのまま放棄されるにはもったいないプログラムでして、もう誰も手を付けないのは明かだったので、私が勝手に復活させちゃうことにしました。
#ハッシュタグリレー は、このpub-relayの一つ前のバージョンの派生で、基本的な部分は共通しています。なので、こちらの成果をバックポートして、安定したら、逆にハッシュタグリレーの次版をこちらをベースに書き直そうかなと思っています。 #リレーの話
本当は、ほとんど同じ内容をリレーする、別運営のリレーが並行で運用されてて、両方に接続しておくと良いのであります。
投稿は先に届いた方が受理され、重複するものは捨てられるので、遅延したものが流れてきても害がないのであります。
ちなみに我が #ハッシュタグリレー は条件厳しくて、10分遅れの投稿はリレーせずに捨てちゃうのであります。 #リレーの話
#リレーの話
Mastodonのpub-relayは、Crystal版を作るにあたっては開発者に資金も出ていたようなのですが、もうほったらかしになってしまって、いまでは無いモノ扱いに近い状態です。
rubyで書かれたMastodonのリレーの初期バージョン、今ではプロトタイプ版と呼ばれているものはMayaさんがメンテしていて、実は生き延びています。リレーサービスも運用されていますが、非公開です。
Crystal(sidekiq版)は私が密かにメンテしているので、こっちもどこかで復活させたいなと思っています。経緯により不本意ながらCrystal-langの立場が悪いので、汚名を返上したいところですw
全体的にほったらかしになっているのがMisskeyへの対応で、グループのこともあるので、今年は本気で取り組みたい所存です。
#リレーの話
私の観測範囲では、PleromaのActiveRelayが使われている例が一番多いと思います。
https://fediverse.network/activityrelay
(なんかリストにfedibirdという文字が混じってるけど気にしないように)
で、まずは、リレーの話といったら雪餅さんのこの記事がマストです。何は無くとも、まずはこちらを読んで下さい。
連合リレーと Activity Relay
https://blog.yukimochi.jp/2018/12/fediverse-with-relay.html
リレーのプログラムは、どれもみんな同じ名前になりやすく、とてもわかりづらいです。上記記事をみて見分けが付くようにしておいてください。
この他、ランランさんのNode.js製のリレーもあります。
現在のPleromaのリレーは、Mastodonに対応しています。
なお、ハッシュタグリレーは『pub-relay (rewrite される前のもの)』の末裔です。独自にPleromaへの対応機能を追加しています。これは、リレー参加する際の手順への対応と、Linked Data Signature無しでリレーするためにブーストで配送することの2点です。
わはは、もう少ししたら仕事終わるから待っててねw > #リレーの話
2018年12月10日に書いた記事の掘り返し。2018年のAdvent Calendar。
インスタンスの役割とリレーのもたらすもの
https://noellabo.qrunch.io/entries/oh8Xlu5uMhXe1o8X
インスタンスが情報をキャッシュしてくれているんだよ、ということと、その橋渡しをするリレーの話。 #リレーの話
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。