もっと見る

結局、Pleromaとずっと格闘してしまった……。

・個人リレー参加(送信のみ)
・サーバ参加(受信のみ)

このへんは で動くようになっています。

サーバ参加の場合、コマンドはこんな感じです。
mix pleroma.relay follow hashtag-relay.dtp-mstdn.jp/act

Pleroma側にも機能を実装していきたいところだけど、その前に、 のコード(pub-relayのフォークで、selective-relayというのがプロダクト名だったりする)をちゃんとして、独自性、有用性、存在感を確立させておかないと相手にされないでありましょう。

取り急ぎ、Misskeyの方を先にやろう。

スレッドを表示

Pleromaのリレー機能追いかけていたんだけど、今のこれってちゃんと機能してるんだろうか……。

まぁとりあえず、 では、Pleroma標準のリレー参加コマンドで参加を受け付けるようにして、リレーから受信できるようにはした。

リレーへの送信は、個人参加は動くので、とりあえずそれでなんとかしてくれって感じ。

まだ本番環境には適用してない。とりえあず現状報告。

Pleromaを(手動で)ハッシュタグリレーに参加させた状態です。リレーから受信できています。

送信も個人参加で実現できています。サーバ単位での参加は、Pleroma側の実装を確認中です。

まだ細かな部分では問題含みなので、解決に取り組んでいます。

とりあえず、技術的には可能、ということをお伝えしておきます。

リレー制限を10分にしたよ。ぽむたんを再召還して能力が封じられたか確認しようず。 @nippon

一応、Pleromaからの投稿がMastodonにも届くようになったけど、これ削除が転送できないのでは……。

Pleroma、リレーの受信は問題なさげ。

relayctlが送信するActivityの何かが原因でタイムラインの読み込みにエラーが発生する症状がでているので、原因解明までPleromaあての送信は失敗するようにしておくことにする。

Mastodon FE(PleromaのMastodonの見た目のフロントエンド)では問題が起きないので、Pleroma FEを調べる。

スレッドを表示

まぁ、非互換性といっても、一つ一つは些細なモノです。

ただし、どんなに些細な違いでも、エコシステムに致命的な影響を与えることがあります。

APIの破壊的変更を伴って、辛うじて生き延びていた古いバージョンのサーバやクライアントが死滅するかもしれません。まぁ、隕石が衝突したみたいな話ですね。

リレーの話で言うと、PleromaのinboxにPOSTする(Activityを送信する)際に、Content-Type : application/activity+json をちゃんと送信する、というのがありました。

pub-relay、何も送らないんですが、そうするとPleromaがHTTP 500エラーを吐きますw

Mastodonは動いちゃう。

いま、MisskeyからのPublicKeyがデコード出来ないってエラーでハマっています。解決方法は確認中です。まぁ、そういう話です。

なんか難しい話してる、としか思えないかと思いますが、恐らくActivityPubを扱っている人ならだいたい同じトコで悩むことが多いと思うんですよね……。

スレッドを表示

ハッシュタグリレーは、Mastodon本家のリレー(pub-relay / Crystal言語で書かれた配送にsidekiqを用いるバージョン / 作成者はChris Hobbs)から派生して書かれているのですが、

この本家リレー、ActivityPubベースでやりとりするようになっていて、一応はFediverseに向けた汎用目的になっていますが、実際はMastodonの実績はなく、そのままで機能するようにはなっていません。細かなところで非互換があって、実装間の差異を埋めていくには、ActivityPubの実務に詳しくなっていくしかなさそうです。

現在、少しずつActivityPub対応のコードを書く人が増えてきているように観測していますが、情報交換を行ったり、その記録を残したり、非互換の解消を働きかけたり、一緒にやれることについては協力できるといいなと思ったりします。

ちょっと簡単に言い直しますw

現状、Pleromaのハッシュタグリレー対応には、ちょっとPleromaの改造が必要になりそうです。
dtp-mstdn.jp/@noellabo/1014958

信頼できる署名(LDS)があれば、どれだけ多くのリレー先に届けても、送信元の負荷は一定です。リレーに預ければ、それで終わりです。

ところが、リレー先が一斉に送信元にデータを確認しにいく実装となると、リレー先が増えれば増えるほどアクセスが集中することになり、多大なる負荷となります。(nginx等でキャッシュすることで大幅に負荷を軽減できますが、依然としてリレーより負荷が高くなります)

やはり、PleromaにLinked data Signaturesのサポートを追加するのが現実的であるように思います。

スレッドを表示

Mastodonの場合、LDSが含まれるため、信頼できると確認できますが、Pleromaではこれができません。

Mastodon側で対応する方法としては、Activityに含まれる本来の送信元へ問い合わせして、裏付けをとるという方法があります。

投稿であれば、実際の投稿内容を取得して、一致しているかどうか確認すればいいわけです。動作としては、おおよそブーストの場合と同じです。(我々はフェッチしにいく、という言い方をします)

削除であれば、HTTP 404 Not Foundか、Tombstone(削除されたことを示す《墓石》)になっていることを確認すればいいわけです。

ただし、この実装は著しく非効率です。

Pleromaのリレー実装が、このようなブーストベースのものになっているということですが(詳しく見ていません)、コンセプトはともかく、実用上は現実ではないと言われています。

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

スレッドを表示

リレーの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平均とかそんな感じ。

これから何か実装する度に重くなるし、まだ最適化のことは考えていないけど、今は余裕がある。

リレーに流れてきた12時間以上古いアクティビティを捨てるようにしてみました。

効果があるかはわかりません🤔

その他、OpenSSL 1.1.1に対応するテストなどを行っています。動いている。たぶん。

個人でリレーに参加する場合、リレーは、フォロワーの一人としてprivate投稿まで受け取っています。publicのみに制限していますが、privateをリレーしてしまうこともできます。

実質的にリレー先にフォロワーがいるときと同じなので問題はないのですが、流量が増えるだけでどのみち誰も見られないので、メリットが特にありません。

一方、未収載は、公開投稿の一種ですし、各サーバのアカウントから辿れば内容を見ることもできます。サーバに情報をキャッシュさせておくメリットもありますので、やる価値はあります。

なお、ハッシュタグはpublicが原則なので、未収載ではハッシュタグタイムラインで見ることができません。

ただし、imastodon方面に未収載タグを有効にする改造があります。これに対しては、未収載がリレーされた方が、認識されてハッピーかもしれません。

受信側で未収載を受け取る設定ができるようにしましょうかね。

ちなみに、リレーは投稿を改ざんできません。署名を検証する機能があり、発信元のサーバ以外で変更すると、受け取る側のサーバに弾かれます。

ハッシュタグリレーは、2018年9月6日深夜に発生した北海道胆振東部地震の報を受けて、ハッシュタグの流通支援が役立つかもしれないと思い、午前中に鯖借りて昼に稼働と、半日で立てたところから始まっています。もともと専門でやるつもりじゃなかったという。

リレー本体のプログラムは、フィルタリング機能を持たせるための書きかけのヤツがあったので、ハッシュタグオンリーにする改造を場当たり的にやって投入しました。

まだ早すぎた感があり、そのときは特に活用されなかったのですが、徐々に認知が広がってきて使われるようになってきたので、結果オーライですね。

本日投入した個人参加機能は、大規模サーバや小規模サーバのように、サーバ単位でのリレー参加が難しい場合でも活用できるように考え出された機能です。
dtp-mstdn.jp/@noellabo/1014807

theboss.tech閉鎖、及びそのテスト用インスタンスmasi鯖の閉鎖によって各地に四散している元参加メンバーへの支援でもあります。

まだ色々バグや機能不足があるので、そのへんを直して、正式投入したいと思います。

なるほど、タグ固定でトゥートできる鯖は、ハッシュタグリレーと相性がいいんだな……。

スペルミスに気付く人だけが参加出来るトラップ(ではありません)

もっと見る

のえる :cava_red: DTP鯖管 によるおすすめ:

DTP-Mstdn.jp

DTP-Mstdn.jpは、DTP・デザイン・印刷に関わる人々のためのMastodonインスタンスです。特定分野の専門インスタンスですので、日々のつぶやき、耳寄りな情報の共有、ディスカッション、質問とその回答、役立つスクリプトなど、他では投稿しづらい内容も、思う存分トゥートしましょう!