Fedibirdリレーは、こう。

> リレーへ送信するActivityは、送信サーバ側にて適切に取捨選択してください。リレーから受信するActivityは、受信サーバ側で適切に取捨選択してください。

自分で面倒見てねってルールです。Mastodon、Pleroma、Misskeyとも、全部送って全部受け取っちゃうんですけどねw

ウチのリレーは、ハッシュタグリレーが2代目で、Fedibirdリレーが3代目。初代はpub-relayのruby版でした。

ルールを変えるときは、立て直す感じでやってます。

Fedibirdリレーの説明文は読まれているかわからないけど、一般的なリレーサービスより踏み込んだ立ち位置のものになっています。

リレー、Fedibirdのキーワード購読とか、Misskeyのアンテナと組み合わせると強いよ。

本日のニュースとして、Misskeyがpub-relayに対応しました。めいすきーと、本家のMisskey v12.37.0です。

これまでフォロー関係が薄いとMisskey系のユーザーと接点が作りにくかったかと思いますが、リレーを通じてFedibirdの投稿がMisskey系サーバに伝わり、Misskey系サーバの投稿がリレーを通じてFedibirdの連合に流れるようになります。

あわせて、Fedibirdのリレーサービスを開始しました。こちらは、当然Fedibirdで行うリレーですので、Mastodonに留まらず、Fediverse全体に意味のあるサービスに発展させたいと考えています。

現在、国内のリレーサービスは雪餅リレーが牽引しており、今見たら179のサーバが登録されているようです。

Fedibirdのリレーは、雪餅リレーのバックアップを担いつつ、徐々により踏み込んだ機能を拡充していきたいと考えています。

も、基本的に継続して運用していきますが、徐々にFedibirdのリレーに役割が移っていくかと思います。

新しいリレーサービスとして、Fedibird Relay Serviceを設置しました。
relay.fedibird.com

現在はpub-relay 2.0 (noellabo fork)による、全ての公開投稿を中継する単純なリレーとして動作しています。

今後、ハッシュタグリレーの成果をマージしたり、これまでになかった機能をこちらに追加していく予定です。

Fediverse全体での利用を想定したサービスとして仕切り直しましたので、従来と比べて利用範囲が大きく設定されていますのでご注意ください。

なお、リレーを利用する際は、複数のサービスに同時に接続することをお勧めします。

リレーは中央集権的なポジションになる他、単一障害点になるため、複数のルートを確保することを想定して設計されています。

例えば、雪餅リレーに参加した上で、当リレーに参加した場合、いずれかを通じて先に届いた投稿が受理され、遅れてきた投稿が破棄されます。

これにより、どこかのリレーが遅延・停止しても、全体としては障害の影響を最小限にすることができます。

にサーバ管理者を認証する機能をつけている。これができあがると、サーバ毎のリレーの詳細設定を許可できる。

リレーは、つまるところActivityPubの配送システムなので、やれることはまだまだ色々ある。

問題は、ハッシュタグリレーが一義的にはハッシュタグ限定のリレーであることで、今後はより多用途に展開したいので、別サービスとして仕切り直すつもり。

まぁ、少しずつ進めるね。

分散で各自のサーバが責任と権限を持つべき重要な内容と、いくつかの集中システムで効率的に処理して良い副次的な内容があって、リレーは後者の役割として案外重要なんじゃないかなって、ずっと思ってる。

DeleteやMoveの配送なんかはそういうものの一つかなと。

Misskeyにリレーから配送するの、Announceベースでは問題無く流し込めるね。

Createだと、signatureチェックしないで弾かれちゃう。ここはMisskey側がわかってて未実装になってるのでコード足さないとダメだ。

pub-relayをフォークし、Pleroma対応など機能追加したものを公開しました。記載してませんが、Misskeyとの互換性も向上しています。
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が使われている例が一番多いと思います。
fediverse.network/activityrela
(なんかリストにfedibirdという文字が混じってるけど気にしないように)

で、まずは、リレーの話といったら雪餅さんのこの記事がマストです。何は無くとも、まずはこちらを読んで下さい。

連合リレーと Activity Relay
blog.yukimochi.jp/2018/12/fedi

リレーのプログラムは、どれもみんな同じ名前になりやすく、とてもわかりづらいです。上記記事をみて見分けが付くようにしておいてください。

この他、ランランさんのNode.js製のリレーもあります。

現在のPleromaのリレーは、Mastodonに対応しています。

なお、ハッシュタグリレーは『pub-relay (rewrite される前のもの)』の末裔です。独自にPleromaへの対応機能を追加しています。これは、リレー参加する際の手順への対応と、Linked Data Signature無しでリレーするためにブーストで配送することの2点です。

わはは、もう少ししたら仕事終わるから待っててねw >

2018年12月10日に書いた記事の掘り返し。2018年のAdvent Calendar。

インスタンスの役割とリレーのもたらすもの
noellabo.qrunch.io/entries/oh8

インスタンスが情報をキャッシュしてくれているんだよ、ということと、その橋渡しをするリレーの話。

私がリレーのMisskey対応サボってるのもアレ。そろそろちゃんとやろう……。

雪餅リレーってBot通さない設定だったよね。ハッシュタグリレーは何でも通すよ!(それはそれで)

要望を頂くことって皆無なんだけど、さっさとBotフィルタの設定できるようにした方が良い?

ちなみにfedibird.comは、雪餅リレーとハッシュタグリレー、あとmastodon.hostのリレーに参加してるよ。

Fedibird

LTLのないFediverse志向の汎用Mastodonサーバです。Fediverseの活動拠点としてご利用ください。