FEP-521a (Representing actor's public keys)のmotivationとして（既存）実装が典型的に単一の鍵対しか受け入れないことを挙げているけど、これがよく理解できていない。`publicKey`が複数指定された場合の対応としてはMastodonのようにJSON表現の配列における先頭の鍵のみを受け入れるのが典型的[^1]であるわけだけど、2番目以降の鍵が無視される分には先頭にRSA鍵を入れておけば後方互換性は保てるし
廃止されたプロパティを使いたくないよねというのはまあ理解できるけど
@tesaguri ActivityPubの実装がJSON-LDの正しい意味論を常に尊重すべきかどうかについて、尊重すべきだという意見と、一般的なJSONで処理することもできるべきだという意見が常にあるようです。 私は個人的にはJSON-LDの意味論を尊重すべきだと思う方ですが、ちゃんとしたJSON-LDの実装がない言語でJSON-LDの正しい意味論を尊重するのはかなり負担になるかもしれません。
@hongminhee 一般論としてJSON-LDの意味論の完全な尊重を求めるのは過剰な要求であるという意見については私も同意しますが、特に配列の扱いに関してはMastodonの`JsonLdHelper#first_of_value`のようなhelperを利用するというのはそこまで複雑でもないですし、FEP-fffdのような拡張に有利という実益もあるので、トレードオフとしてはやはり正しく処理できるに越したことはないのではないかなと個人的には思っています
@tesaguri そうですね。ちなみに、Misskeyは最近publicKeyの配列をちゃんと処理するように修正されました。
https://github.com/misskey-dev/misskey/pull/13464/commits/64004fdea244f039c34e9f59a103be9b9e164f77
@hongminhee そのPRについてはその後にrevertされてしまったようですね……
https://github.com/misskey-dev/misskey/commit/337b42bcb179bdfb993888ed94342a0158e8f3cb
[^1]: 現行のMisskeyのように配列を上手く処理できない実装もあるけど、そもそも開世界仮説的なJSON-LDの意味論においては複数の値が渡された途端にエラーを吐くというのが正しくないわけで、ここでは考慮しないものとする。先行例として、FEP-fffd (Proxy Object)とかも同様の理屈でゴリ押して（？）`url`に配列を突っ込んだりしているようだし