enhance: 相互リンク機能の連合 by kozakura913 · Pull Request #704 · MisskeyIO/misskey
https://github.com/MisskeyIO/misskey/pull/704

> ActivityPub上定義されていないオブジェクトを生のJSONで転送しあう実装は、悪意のあるリモートサーバーからのXSS、Node.jsの脆弱性もしくは非常に大きいペイロードを受信した際の対策が困難であるため。
ふむ？　「ActivityPub上定義されていないオブジェクトを生のJSONで転送しあう」というのはコンテクストで定義されていないタームをそのまま生成・解釈するという意味だろうか。それなら確かに当該オブジェクトのアレのアレ時に当該タームがアレされずにアレになりうるけど、Misskeyの場合はアレだからアレだし、いずれにせよ単にコンテクストで定義しておけば特に問題はなさそうな気がするけど

互換性については、最低限のフォールバック表現を用意した上で`PropertyValue`あたりに追加のオレオレプロパティを生やして対応する気のあるサーバがより正確に解釈できるようにするくらいはしておいても損はないと思うけどなあ。まあこのパッチのオレオレプロパティはもっと減らせると思うけど

公開しているつもりの情報が実際にはオーディエンスに正しく伝わっていないというのはユーザとしても不利益だと思うのだけどなあ。正直私個人としては"相互リンク"云々はどうでも良いけど、使っている人々にとっては必ずしもそうでもないだろうし

ボット的なアプリケーションに直接ActivityPubを喋らせる利点としてはリクエストに応じて動的にアクターやその他のオブジェクトを生成させられることもあるだろうけど、Social APIのみではそれは難しいか。
それでもあえて汎用のサーバ実装を使うとすれば、サーバのリクエストハンドラにフックする仕組みが欲しくなってくるな
QT: https://fedibird.com/@tesaguri/112824005290340259 [参照]

AT ProtocolのrelayがPDSをクロールするという仕組み、relayの数についてはスケールさせることを目標としない設計なのかなという印象。例えば万のPDSを百のrelayがひたすらクロールするわけにはいかないだろうし

ATP、"small-world"とかいう複雑ネットワーク分野の重要な用語に無関係の用法を被せてくるのやめて欲しい（？）

ATPにおいてApp Viewやrelayが信用できない場合に何が起こるのかよく分かっていない。自分のPDSや相手のPDSが信用できない場合はオシマイというのは当然として。あと`did:plc`についても考えないものとする（？）