FEP-521a (Representing actor's public keys)のmotivationとして（既存）実装が典型的に単一の鍵対しか受け入れないことを挙げているけど、これがよく理解できていない。`publicKey`が複数指定された場合の対応としてはMastodonのようにJSON表現の配列における先頭の鍵のみを受け入れるのが典型的[^1]であるわけだけど、2番目以降の鍵が無視される分には先頭にRSA鍵を入れておけば後方互換性は保てるし

[^1]: 現行のMisskeyのように配列を上手く処理できない実装もあるけど、そもそも開世界仮説的なJSON-LDの意味論においては複数の値が渡された途端にエラーを吐くというのが正しくないわけで、ここでは考慮しないものとする。先行例として、FEP-fffd (Proxy Object)とかも同様の理屈でゴリ押して（？）`url`に配列を突っ込んだりしているようだし

廃止されたプロパティを使いたくないよねというのはまあ理解できるけど

@hongminhee 一般論としてJSON-LDの意味論の完全な尊重を求めるのは過剰な要求であるという意見については私も同意しますが、特に配列の扱いに関してはMastodonの`JsonLdHelper#first_of_value`のようなhelperを利用するというのはそこまで複雑でもないですし、FEP-fffdのような拡張に有利という実益もあるので、トレードオフとしてはやはり正しく処理できるに越したことはないのではないかなと個人的には思っています

`url`や`publicKey`が配列で受け取れたら便利だよねというのは分かるけど、だったら初めから`"container": "@set"`で定義しろよという話なのだよなあ（<https://github.com/w3c/activitystreams/issues/535>）。今さら言っても遅いのだけど

なので我々は配列とその他の値がくるケースの両方に対応する必要があるという……

@hongminhee そのPRについてはその後にrevertされてしまったようですね……
https://github.com/misskey-dev/misskey/commit/337b42bcb179bdfb993888ed94342a0158e8f3cb

Fediverse上のボットに任意のActivity Streamsの拡張プロパティを喋らせたいとか考え出すとボット実装自身に直接ActivityPubを喋らせるしかないよなあなどと考えていたけど、ActivityPubのC2Sプロトコル（Social API）をサポートしているサーバがあれば済む話か

Social APIなあ……。主要なマイクロブログサーバ実装でサポートしているのはPleromaくらいか？

ThreadsがMastodonを無視して（標準が認めている通りに）usernameを可変にしているらしいことについて、個人的にはいいぞもっとやれと思っている（？）。
ちょっとpotus@threads.netさん、試しにPOTUS@threads.netに改名してみません？（？）

この調子で（`acct:` URIスキームのRFCが認めている通りに）usernameに非ASCII文字を混ぜたりしようぜ💪（？）

ActivityPubのeditorの人たちによる評価などを見るに、Threadsの開発者はかなり標準を尊重する姿勢らしい

<del>何なら勝手に`fediverse:creator`のような独自仕様を追加するMastodonよりよっぽど尊重しているまであるのでは</del>

まあ超巨大企業なので開発者の姿勢とマネジメントの方針が整合するとも限らないだろうし、実際Fediverse共有を無効化するようにユーザに促してくるなどの報告が聞こえているわけだけど