morethanwords/tweb/master • e532dd4 • 8 files, +282/-81 Notify when someone reacts to your story Set

morethanwords/tweb/master • e532dd4 • 8 files, +282/-81
Notify when someone reacts to your story

Settings → Notifications has carried a Reactions → Stories row since the
reactions settings landed: off, contacts, everyone. Nothing read it. The
`updateNewStoryReaction` the server sends when someone reacts to one of our
stories had no handler at all — it existed in the schema and was dropped on
arrival — so the row promised notifications the client never produced.

The foreground half has to be built locally, for the same reason posting
notifications are: the service worker suppresses a server push while any window
is alive, so with the tab open nothing else fires. Android does exactly this,
turning the update into a local notification; iOS and Desktop lean entirely on
the server push, and tdesktop does not even parse the update.

Gate on `stories_notify_from` from account.getReactionsNotifySettings — absent
means off — and drop reactions from non-contacts when it is
reactionNotificationsFromContacts. Android checks only the on/off half locally
and leaves the contacts filter to the server; applying it here costs one cached
read and keeps the row honest whatever the server decides to deliver. Reactions
that were removed, our own, and restricted peers never reach the notification.
`show_previews` off, or an emoticon we cannot resolve, falls back to the wording
the mobile clients use when they hide a sender.

Title and body come from PUSH_REACT_STORY verbatim: the peer's name, then
"❤️ to your story". Clicking opens the story of ours that was reacted to, not a
chat with whoever reacted — `openStoriesForPeer` takes a story id now, and the
cross-account URL carries it as `story_id` so the existing `story=1` marker
keeps meaning "the peer's whole ring".

That click had a second path worth fixing. A background REACT_STORY push sends
the story id as `msg_id` and `from_id` as the peer who reacted, so the story
branch in the click handler never matched: it fell through to setInnerPeer and
opened a chat with the reactor, scrolled to a message id that was really a story
id. Route on the loc_key instead, which also covers REACT_STORY_HIDDEN pushes
that carry no `from_id` and used to be dropped outright, and stamp the same
loc_key on the notification we build so the in-page and service-worker paths
land in one place.

The three builders had grown ~30 identical lines each. The other-account title
suffix, the peer avatar, the passcode-lock override, the push payload
boilerplate and the notify call move into finishNotification; peerString and
peerTitle into getNotificationPeer; the reaction emoticon into
getReactionEmoticon, which no longer walks into getCustomEmojiDocument with an
undefined id for a paid reaction. Each builder is left with the title, body, key
and click target that actually differ.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

#webk