#リレーの話
ハッシュタグ #リレーの話 の付いた公開トゥートです。どこでもいいので、連合に参加しているSNS上にアカウントを作れば会話に参加することができます。
ハッシュタグリレーは、Fedibirdよりも前に作られたもので、前身みたいなところがある。
ハッシュタグでFediverseを繋ぐ仕組みが欲しかったことと、購読の仕組みを作ろうと思って作ったのね。
普通は、サーバの管理者がリレーに参加するかどうかを決めて実行する。流量が増えて、サーバの負担が大きくなるからね。
ハッシュタグリレーは、投稿についてはハッシュタグがついているものだけを転送するリレーで、つないだサーバの負担がいくらか軽い。投稿以外、例えばアカウントの削除とかそういうアクティビティは全部転送するんだけどね。
あと、実は個人でリレーに参加することができるんだよ。
自分の投稿をリレーに流して、ハッシュタグリレーに参加しているサーバに流すことができるのと、
リレーに対し、欲しいハッシュタグやアカウントを指定して購読することができる。
misskey.ioとかmstdn.jp、Pawooのような、リレーに参加することが期待できない（大きすぎるので）サーバから自分だけ参加することもできるんだ。
リレー全体に参加すると負荷が高すぎると感じる場合に、たとえば # gochisou_photo だけ流して貰うようにするとか、そういう選択もできるよ。
ハッシュタグリレーの非効率だった部分に手を入れて、だいぶ動きが良くなったよ。もう2年とか3年ぶりにコードいじるので、完全に忘れてるよね！
--
ウチのリレーはCrystal言語で書かれているんでみんな馴染みがないと思うけど、CrystalはRuby風の静的型付け言語で、バイナリにコンパイルされて実行速度は速いし、書いてて楽しい感じはRubyと一緒。
Mastodon用に、最初はRubyでpub-relay-protoが作られて（Eugenさん作）、そのCrystal版をChris Hobbsが作った。たぶんMastodon本家から有償開発依頼して書いてもらったものだと思う。
このCrystal版は、一回大規模なリファクタリングが行われて、当初はCrystal版のSidekiqベースで作られていたんだけど、途中でプロデューサー・コンシューマーパターンのアーキテクチャに変更になっているのね。
ハッシュタグリレーは、Sidekiq版からの派生。Fedibirdリレーで使ってる方は、後者のpub-relayの直系になってるよ。
sidekiqは使い慣れてるのと、複数プロセスで動かせばスケールし易い。後者は何かプロセス間通信の仕組みを導入する必要があるね。
この自己返信連鎖の全体についてハッシュタグを付けておきます。 #リレーの話 #ハッシュタグリレー
Fedibird Relay Service（まあFedibirdリレーとでも呼んで下さい）をホストしているサーバを移転し、構成を工夫して安定させました。
リレーへの追加や解除がうまく動かなかった方、恐らくきちんと応答するようになったと思います。
複数のリレープロセスが状態を共有するのに若干のラグがあり、接続直後1分ぐらいは配送が欠けたりしますが、ご了承ください。
Sidekiqでちょいちょいリトライになっていた件も、だいぶ安定したのではないかと。
様子をみますので、よろしくお願いします。
ちなみにFedibirdのリレーもここんとこちょっと遅延することがおおかったんだけど、これは配送先がコケてるとこが多い時。
Sidekiq版はそういう障害に強かったんだけど、いまのヤツは弱いんだよねー。
ちょっと中国系のサーバでコケてる（のか遮断されてるのか）が多かったので、いくつか切断させてもらいました。復帰したら再接続してください（って言っても届かないか）
ハッシュタグリレーはやたら頑丈で、こいつほっといても全然大丈夫。 #リレーの話
割とMastodon Projectではやってみたけど上手く回らずそれっきり、というものがあるんですが、リレーも該当しまして、joinmastodon.orgで動かしていたリレーサーバは当初からダウンが多く、そのうちなくなってしまいまして、公式サーバに該当するサービスがありません。 また、リレーサー...
リレーサーバは、外部から異質なものを取り入れるための機能です。
特にコミュニティ性向の強いサーバでフォロー対象に広がりが期待できない場合、まだ誰もフォローしていない未知の範囲をカバーする重要な役割があります。
ついては、接続システムが機能停止するような脅威は防がねばなりませんが、それ以外は何でもリレーするようにしなければ、あまり意味を成しません。
ノイズが多いぐらいが丁度良いということです。
これを、必要に応じて選別すべきなのは、リレーに送信するサーバ、および受け取るサーバで、連合から必要な情報を見つけられるようにするのも各サーバの役割だと考えています。
そのあたりのことは、サービス開始時点より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の一つ前のバージョンの派生で、基本的な部分は共通しています。なので、こちらの成果をバックポートして、安定したら、逆にハッシュタグリレーの次版をこちらをベースに書き直そうかなと思っています。 #リレーの話
A service-type ActivityPub actor that will re-broadcast…
github.com本当は、ほとんど同じ内容をリレーする、別運営のリレーが並行で運用されてて、両方に接続しておくと良いのであります。
投稿は先に届いた方が受理され、重複するものは捨てられるので、遅延したものが流れてきても害がないのであります。
ちなみに我が #ハッシュタグリレー は条件厳しくて、10分遅れの投稿はリレーせずに捨てちゃうのであります。 #リレーの話