misskey-dev
ap: ノートのemoji_reactionsに対応する？
Summary
ActivityPubで、Fedibirdが採用しているemoji_reactionsを配信・読み込みする
リモートのリアクションを反映することができる
https://fedibird.com/users/noellabo/statuses/109951471711685649/emoji_reactions
first.itemsにそのノートに対するリアクション行為が配列として入っている（リアクションがいくつあるかは配列をfilterとかreduceとかして算出するらしい）
Misskeyはデータベースにjsonbで{ '👍': 2, ':wakaru:': 1}みたいに入っているしapi同士のやり取りも大体そのようにしており、配列のように表現する必要はない
ioみたいに大量にリアクションが入ってるとサイズがすごいと思う
( emoji reaction emojireaction reactions )
Likeオブジェクトでactorを含んでいる場合もあって、MisskeyはNoteReactionsリポジトリを持っているのでそれを元に全部Likeとして配信できなくもないがそれ負荷どうなん
いわゆるLikesコレクション (with Misskey拡張部分) だわね https://github.com/misskey-dev/misskey/issues/7934 https://www.w3.org/TR/activitypub/#likes
related to https://github.com/misskey-dev/misskey/issues/5425
むしろこっち？ https://github.com/misskey-dev/misskey/issues/4622
リアクションのLikesコレクションを公開することにより、現状各フォロワーにpush配信しているLikeアクティビティをpull型にすることで無くせる可能性がある。 https://github.com/misskey-dev/misskey/issues/12914
連合Activityの8割を削減できるので、うまくいけば送受信側双方にメリットがある
push型: 圧縮出来ない, キャッシュできない, キュー処理周りの重さ, 受け側はリソースに関係なく受ける羽目になる VS pull型: 圧縮可, キャッシュ可, CDNキャッシュも出来るかも, タイミングは受け側が選べる ので、うまくいけばやはり送受信側双方にメリットがある
ただし、受信側がどのタイミングでpullするべきかという問題は残る
なので、実装してうまく活用できればゲームチェンジャーになり得る気はするのだわ。
：
この機能があることにより配信側のデメリットはさほどないので (実装するにはリモートリアクションに対して NoteReaction.uri を格納する必要が出てくるなど) 今後の実装次第で効果が期待できるならあってもいいかもだわ。
受信側のデメリットは、pullタイミングなど有効活用が難しいかもなど。
あとコレクション名は emojiReactions ではなくて likes でもいいかも？