のえる DTP鯖管 @noellabo@dtp-mstdn.jp

【DTP-Mstdn.jp】
HEAD is now at 28866d329 Bump version to 2.7.1 (#9932)

Mastodon v2.7.1になりました。
https://github.com/tootsuite/mastodon/releases/tag/v2.7.1 #dtp

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

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

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の改造が必要になりそうです。
https://dtp-mstdn.jp/@noellabo/101495837167912013
#リレーの話
#ハッシュタグリレー

信頼できる署名（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の送信元と不一致で信頼できません。
#リレーの話
#ハッシュタグリレー

めかぶ美味しいよね。

それはそうと、形態素解析とか手軽に出来ていい時代や。SNS使うんだから、テキストをソースに色々やるのがやはり楽しい。
#theboss_tech

マストドンクライアントは、API使って作る分には難易度低いので、いろいろ開発すると良いと思うよ。
https://docs.joinmastodon.org/

ActivityPubでお話するの、誰もまとめてない感じで難易度高いよ……。ソースコード読んで、立てて試すのが最良という感じ。 #theboss_tech

こちらはpleromaのソースみてるけど、internal server errorの原因を調べるの、動かさないでやるの難しいね。たてるのか？これ。 #theboss_tech

ざぼてくタグ、techの話してる。良き哉。 #theboss_tech

マンバ通信さんのドラゴンボールの考察話なんですけどね、ベジータと悟空、とてもいいですよね。いわゆる、ご飯何杯でもイケる系。

何かに帰属する生き方、なにものにも捕らわれないこと、どちらについても考えさせられます。
https://magazine.manba.co.jp/2018/01/29/ueda-dragonball5/
#ドラゴンボール #マンバ通信