このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ld-signatures/index.html at d0af56856684924156a94838f9482a27766bb2be · w3c-ccg/ld-signatures
https://github.com/w3c-ccg/ld-signatures/blob/d0af56856684924156a94838f9482a27766bb2be/index.html#L651-L652
> Remove any `signature` nodes from the default graph in _document_ and save it as _signature_.
本来なら文書全体をexpandして`sec:signature`を取り出すというのが"正しい"のだろうけど（仕様が曖昧なので実際の策定者の意図としてどうなのかは知らぬ）、それをやると正しく`@context`で定義されていない`signature`が消えるという
なので既存実装との互換性を考えると`signature`という名前のタームを決めうちで取り除くしかないのだけど、安易にそれをやると先祖オブジェクトの`@context`が`signature`オブジェクトに反映されなくなってしまうので、`signature`が先祖オブジェクトのタームを使っているケースを想定するなら先祖オブジェクトの`@context`を`signature`オブジェクトに注入するという面倒な前処理が必要になる[独自研究]：<https://github.com/tesaguri/rsa-signature-2017-rs/blob/38eca544e8179ac03c05f12d1eb4e872fd0812fc/src/json_ld.rs#L358-L362>
そもそものLD Signaturesのドラフト仕様が所定の「ターム」を取り除くべきなのか「プロパティ」を取り除くべきなのかに関して曖昧だからなあ……
https://github.com/mastodon/mastodon/blob/1726085db5cd73dd30953da858f9887bcc90b958/app/lib/activitypub/linked_data_signature.rb#L35-L50
それにつけてもMastodonが署名のハッシュ計算時にoptionsに`identity`コンテクストを埋め込んでいる一方で、最終的な署名済オブジェクトのoptionsからはコンテクストを省いているのは謎である
https://github.com/mastodon/mastodon/blob/HEAD/app/lib/activitypub/linked_data_signature.rb#L26
そして検証時に`identity`コンテクストを決めうちで上書きしているのはさらに謎
そもそもの仕様が中途半端にplain JSONの幻想に寄り添った書き方をしていたものだからCVE-2022-24307のような脆弱性を引き起こしたのではという気持ちがある。いずれにせよその程度はsecurity considerationsとしてカバーしておくべきだったとは思うけど（まあドラフトなので仕方ない）（ドラフトをプロダクションで使った方が悪い）
JSON-LD、結局のところ"all the memory safety of C combined with all the blazing speed of Smalltalk"になっている気がする（？）
JSON-LDの利点の一つとして既存のJSON文書を変更することなくlinked dataとしての解釈を与えられるという点があると思うけど、Activity Streams 2.0の場合は恐らく既存のJSON文書を考慮する必要は少なかっただろうから、辺に色気を出して短いタームを使わずともプロパティのIRIを全て書き出す（<https://codeberg.org/fediverse/fep/src/commit/8441175ce0a8434046ddc7a5cbf3e489db22d270/fep/e229/fep-e229.md#extension-property>）ようにした方が良かったのではという気がしている
単体で参照しても自己完結的になるようにスレッドを組み立てるべきだとは思いつつ、気を抜くとすぐに別のスレッドに依存した書き方をしてしまいがち
`endpoints`とかいう、アクターとは独立したオブジェクトを指すものとして定義されているものの、実際にURIで別文書を参照する形で使用されることが滅多にないプロパティなあ
https://github.com/w3c/activitypub/issues/410#issuecomment-1981457081
終いにはPrimerで`endpoints`にURIを指定することを非推奨にする可能性が仄めかされる始末
https://www.w3.org/TR/2018/REC-activitypub-20180123/#endpoints
`endpoints`プロパティの定義で"(typically server/domain-wide) endpoints"とあるので、当初の意図としては同一サーバ内のアクター間で同一の`endpoints`オブジェクトを共有するような用法を想定していたのかなあと
結局複数アクターにまたがる「サーバ」的な概念を指す役割は`sharedInbox`に取って代わられた感がある
https://www.w3.org/TR/2018/REC-activitypub-20180123/#x3-1-object-identifiers
> all objects distributed by the ActivityPub protocol MUST have unique global identifiers, unless they are intentionally transient
↑ほぼ空文化していてかわいそう（？）
というか、埋め込まれたオブジェクトが独立したオブジェクト（RDFリソース）であるという認識があまり浸透していない？
We are excited to launch a new project that will help small and medium-sized fediverse servers and their users have better access to search and discovery through the use of pluggable Fediverse Discovery Providers, supported by a grant from @EC_NGI. See our new dedicated website for details:
> Fediverse platforms like Mastodon that offer search have thus made it opt-in
🤔
いやしかし実際ね、横着してMastodon基準のオプトインをあたかも普遍的なものであるかのように扱っているといつか皺寄せを受けると思うのですよ