`Emoji`が標準化されていないとはいっても、オブジェクトの帰属を`id`のauthorityで判断するのは普通に普遍的な解釈だと思うけどなあ。
アクターのホストと`Emoji`オブジェクトのホストが食い違うときに無効なものと判定するならまだ分かるけど、当該の`Emoji`オブジェクトをアクターのホストのものとして処理する(というのが現行のMisskeyの仕様という認識で合っている?)のはかなりアクロバティックなように思える

というか少なくともFedibirdはローカルのアクターによるリモートの絵文字リアクションへの「相乗り」の`Like`アクティビティの`tag`にリモートの`Emoji`オブジェクトを全て埋め込んでいるようだけど、これは(C2Sでなく連合の場合は)本来なら単にURIで良いはずだよね。
仮に埋め込みでないと上手く相互運用できないというなら、それは相手のサーバが(`id`をfetchし直さず埋め込まれた内容をそのまま信用するなどの)怪しい処理をしているということに他ならないわけだし


Fedibirdの相乗りLikeのActivityの形は知らないけど、Like本体にidが記載されてないのなら紐づけられないんじゃないかしら

Like:
  content: ':name@host:'

  tag: [
    Emoji:
      id: 'https://example.com/emojis/xxx'
      name: ':name@host:'
  ]

@mei23 私もFedibirdの実装を詳しく追っているわけではないですが、`Emoji`オブジェクトに`id`があるならそのURIの同一性をもってリモートのものと同一の絵文字であることが判定できるのではないでしょうか

あーいやEmojiがuriだけだと blobsignya と紐づけられなくない?って話だわ

{
  "id": "fedibird.com/emoji_reactions…",
  "type": "Like",
  "content": ":blobsignya:",
  "object": "fedibird.com/users/tesaguri/…",
  "tag": [
    "misskey.m544.net/emojis/blobsign…",
  ]
}

@mei23 その場合はそのURIをfetchすれば良いのではないでしょうか。<github.com/kmycode/mastodon/se>のような脆弱性のリスクを避けるためにはいずれにしても`id`をfetchする必要はあるでしょうし

フォロー

@mei23 @tesaguri 結局既に該当idのキャッシュもってる場合以外はfetchしないといけないので、idだけにしちゃいましょう。

ログインして会話に参加
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。