Message Reactions

Overview

Users can react to any message with a unicode emoji or a custom :name: emoji. Unlike a chat message, a reaction spends no keystream: it rides the same AES metadata control channel used for delivery-checks and profile sync, entirely separate from the OTP pad. A reaction is mutable side-metadata — receiving one edits an already-persisted message in place rather than appending to the write-once ciphertext log.

How it Works

1. Target = the stable message id: A reaction frame references its target by ChatMessage.id. That id is assigned by the sender and transmitted in the message envelope (envelopeJson['id']), so both peers store the same message under the same id — making it a valid cross-peer reaction key.
2. Transport frames:
   • 1-on-1 — content_type: 'reaction', encrypted with the peer's one-way metadata key (ChatMetaStore.keyFor), envelope {d: enc}. Mirrors chat_info_update.
   • Group — content_type: 'group_reaction', encrypted with SHA256(groupSeed) and sent full-mesh to every member, envelope {group_id, sender_id, d, t}. Mirrors group_member_profile.
   The decrypted payload is {target_id, emoji, op: 'add' | 'remove', v: 1}.
3. Reactor identity: A reaction is stored under the reactor's id — userId for the local user, the frame sender's key hash for everyone else. This lets the UI mark "your" reaction and, on long-press, resolve names (via groupMembersMetadata for groups, the contact name for 1-on-1).
4. Optimistic + best-effort: Toggling applies locally first (DB + in-memory + rebuild) and then sends the frame. Frames sit in the relay's 24h store-and-forward like any message; a missed reaction is acceptable loss (no ack/retry protocol). If a reaction arrives before its target message (store-and-forward reordering), it is dropped rather than queued.

Persistence (schema v6)

Reactions live in a new reactions TEXT column on the messages table (DB bumped v5 → v6 via ALTER TABLE). The value is JSON: {token: [reactorId, ...]}.

• Plaintext, not master-encrypted: unlike the message body (which stores a master-key copy in text_encrypted_master), reactions are low-sensitivity — emoji tokens plus key hashes already present in the contacts table — so they are stored plaintext for cheap in-place updates.
• Read-modify-write: mutateMessageReaction(id, token, reactorId, add) reads the row's reactions, applies one add/remove, and writes back. It returns the updated map, or null when the target row is missing (the best-effort drop above).
• Clobber guard: because reactions ride a separate channel, saveMessage preserves the stored reactions when the in-memory message carries none — otherwise a resync / duplicate INSERT OR REPLACE of the message row would silently wipe reactions accrued since.

UI

• Add: long-press any settled bubble to open showReactionPicker — a bottom sheet of quick unicode reactions, the chat's custom-emoji pool, and a + that opens the full curated emoji set (reusing EmojiPickerPanel.categories).
• Display: ReactionsRow renders chips under the bubble, flush to it (inter-message spacing is a trailing spacer, so reactions attach to their bubble, not the one below). Tap a chip to toggle your own reaction; long-press to see who reacted.
• Scale: chips scale with the chat text-size setting (chatTextScale). reactionTokenGlyph normalises unicode glyphs (rendered at ~0.82× font size) to the same visual box as custom-emoji images.

Key Files & Symbols

Gotchas & Edge Cases