broadcast channel reactions by r10s · Pull Request #8450 · chatmail/core

r10s · 2026-07-23T13:36:05Z

this PR adds support for reactions in broadcast channels.

the idea of broadcast reactions is that they are sent as usual from subscribers to owner. after some time, the owner broadcasts them to all subscribers, who only get to see reaction+count, not who-reacted-what

the PR is quite large, but a good share are tests and otherwise many things are straight forward.

review should be done by-file, not by-commit. to make review easier, here is a high-level overview:

first a change in the existing internal Reactions object was required. before this PR, Reactions had a "contact to reaction map" only, and the "frequencies map", that are actually mainly needed for UI, were calculated as needed. with this PR, the "frequencies map" is the field that always exist, the "contact map" is only available on top of that.
moreover, this PR shifts that part to the core, it was unfortunately in the bindings before.

with that preparation things done as follows:

reactions from broadcast channel subscriber (Chattype::InBroadcast) to broadcast channel owner (Chattype::OutBroadcast) are sent as usual, only change for that step was to allow sending them at all
the owner receives reactions and saves them to the existing reactions table as usual. additionally, the changed message is remembered in reactions_need_broadcast table
in the IMAP loop, when ~10 minutes have passed, and reactions_need_broadcast contains entries, a single, hidden message with accumulated reactions is sent. this message may contain reactions to different messages. for each message, all known reactions are sent as reaction+count.
subscriber receive that message and save the accumulated reactions in reactions_broadcasted
get_message_reactions is adapted so that frequencies are set independently of who-reacted-what (the old and only field). who-reacted-what is called by_contact now. it is always set for compatibility reasons, however, it is not exhaustive for subscribers.
in general, UI should work with frequencies, the API itself, however, has not changed.

other tweaks:

outgoing channels are muted on creation, and UI shall allow to unmute/mute them as all other chats. reason is that reactions are notified, but in many cases not of large interest. this is also what telegram is doing
to have an intermediate feedback when reacting, the local state should include ones own reaction, even if it is not yet broadcasted. for that, we modify reactions_broadcasted using modify_frequencies() as needed when sending an reaction. there are still some situations where the update may not include ones own reaction, in this case it is added lately by refine_frequencies(), so that get_message_reactions() always contain SELF.
(in a first implementation, we always increased SELF reaction in refine_frequencies(), however, that was worse and led to SELF counted twice once the owner sent broadcast)

wire format

wire format is a JSON in the Broadcast-Reactions: header. additionally, Content-Disposition: reaction is set to not show the hidden message on existing devices.

using a header also allows us to broadcast reactions with resent channel messages (on joining) later.

{
  "messages": [
    {
      "id": "12345678",
      "reactions": [
        { "emoji": "👍", "count": 4 },
        { "emoji": "🎉", "count": 2 }
      ]
    },
    {
      "id": "23456789",
      "reactions": []
    }
  ]
}

for id, the wire format needs to use rfc724_mid as msg_id are local only.

known issues

if the channel owner uses multiple devices, broadcasted reaction updates are sent from each device. the updates are not that big, so that is probably not a big deal. if it turns out that this is an issue, we can think about fixes in another PR. might be done by restarting our 10-minute-wait once we see an update from another device
we cannot set contact_id for DC_EVENT_REACTIONS_CHANGED - but i doubt it was ever used

for another pr

add Broadcast-Reactions: header also for resent channel messages, so that new subscriber do not only get the latest messages, but also their reactions. for that, the Broadcast-Reactions: header can go to the corresponding message, no need to send extra messages. we would need to change the sending part to send all reactions for a given message. on receiving part, we need to make sure, receive_broadcast_reactions() is called when the message actually exist.
EDIT: subsequent PR for resending broadcast reactions at resend broadcast reactions together with message #8496
add api to allow only a subset of reactions, fiter incoming reactions before broadcasting

misc.

ui pr: deltachat/deltachat-ios#3225 and deltachat/deltachat-android#4560 , which both were tested successfully with this core PR already. desktop is meant to be done once this is merged

…ects

this reverts 4c75f2d, esp. in small channels, it is weird that there is an additional person reacting, always then minutes after you reacted with the same reaction. a ghost 👻

…cations easier

…ications for reactions is usually not wanted

link2xt · 2026-08-01T16:58:20Z

+
+        // Alice broadcasts recent reaction changes to Bob and Claire.
+        // On the wire, the hidden message has a header like
+        // `Broadcast-Reactions: {"messages":[{"id":"123@adc","reactions":[{"emoji":"🏳️‍🌈","count":1}]}]}`


A separate test for serialization/deserialization with such example would be nice to have, this is the first thing i looked for after seeing the wire format structures. This will also make sure we don't accidentally change the format by tweaking serde settings, refactoring the structures etc.

link2xt · 2026-08-01T17:00:08Z

+}
+#[derive(Debug, Serialize, Deserialize)]
+struct WireMessage {
+    id: String,


This needs a doc comment saying that this is an rfc724_mid of the message, this is unclear without reading receive_broadcast_reactions.

link2xt · 2026-08-01T17:02:15Z

+/// Seconds between sending out accumulated reaction updates for broadcast channels from `reactions_need_broadcast` table
+const REACTION_BROADCAST_PERIOD: i64 = 10 * 60;
+
+/// Starts broadcasting if last broadcasting so more than `REACTION_BROADCAST_PERIOD` seconds in the past.


Suggested change

/// Starts broadcasting if last broadcasting so more than `REACTION_BROADCAST_PERIOD` seconds in the past.

/// Starts broadcasting if last broadcasting is more than `REACTION_BROADCAST_PERIOD` seconds in the past.

link2xt · 2026-08-01T17:14:12Z

+        .get_config_i64(Config::LastReactionsBroadcast)
+        .await?;
+    let next_broadcast_time = last_broadcast_time.saturating_add(REACTION_BROADCAST_PERIOD);
+    if next_broadcast_time <= time() {


Standard comment for this kind of code: if last_broadcast_time is in the future, this should also broadcast, so we are not stuck not broadcasting for the next year if the user has accidentally set the year to +1 then rewinded the clock back.

link2xt · 2026-08-01T17:15:19Z

+    let next_broadcast_time = last_broadcast_time.saturating_add(REACTION_BROADCAST_PERIOD);
+    if next_broadcast_time <= time() {
+        context
+            .set_config_internal(Config::LastReactionsBroadcast, Some(&time().to_string()))


time() is called twice, so this can be moved to the beginning of the function with let now = time().

link2xt · 2026-08-03T17:53:28Z

+pub(crate) async fn save_broadcast_reactions(
+    context: &Context,
+    msg_id: MsgId,
+    frequencies: &Vec<ReactionFrequency>,


I would make a separate type instead of ReactionFrequency here. ReactionFrequency is a public type meant for API, and it contains e.g. is_from_self which is not stored anywhere.

Something like this, and not pub (pub(crate) or better local to broadcast_reactions):

/// Broadcast reactions as stored in the database. #[derive(Debug)] pub(crate) struct BroadcastReactions { /// The reaction emoji. pub reaction: Reaction, /// Number of contacts that reacted with this emoji. pub count: usize, }

Then you don't need comments like is_from_self: false, // set in refine_frequencies() when save_broadcast_reactions is called immediately after.

link2xt · 2026-08-03T17:56:59Z

+
+/// Merge `by_contact` status to broadcasted reaction frequencies.
+pub(crate) fn refine_frequencies(
+    mut broadcasted_reactions: Vec<ReactionFrequency>,


This could accept a vector of BroadcastReactions and return a vector of ReactionFrequency.

link2xt · 2026-08-03T18:00:18Z

                normalize_text(&chat_name),
                &grpid,
                timestamp,
+                MuteDuration::Forever,


Note (for other reviewers as well): this does not seem to be explicitly tested, but there is a "muted" emoji in snapshot tests.

link2xt · 2026-08-03T18:05:26Z

+    /// For Messages: Render message as a RFC 9078 reaction.
    Reaction = b'x',

+    /// For Messages: Additional reactions that go to the BroadcastReactions: header


Suggested change

/// For Messages: Additional reactions that go to the BroadcastReactions: header

/// For Messages: Additional reactions that go to the Broadcast-Reactions: header

link2xt · 2026-08-03T18:06:13Z


+    /// Broadcasted reactions for this or other chat messages.
+    /// See broadcast_reactions.rs for the wire format.
+    BroadcastReactions,


Maybe should be Chat-Broadcast-Reactions so we have everything in the Chat- namespace.

r10s force-pushed the r10s/channel-reactions branch 30 times, most recently from c8015bc to 8831752 Compare July 25, 2026 20:28

r10s added 27 commits July 29, 2026 11:21

create basic test for sending reactions to channels

4ce1377

use 'broadcast reactions' everywhere

f98e89d

apply received broadcasted reactions

13dd756

save one db call

8e4dfe7

move reaction&count logic from jsonrpc bindungs to core

fada3c3

move function needed for testing only to test module

8ce92af

use new frequencies field

2b366b6

streamline get_frequencies

0cde407

let get_msg_reactions() also return broadcasted reactions

32314be

refine broadcasted reactions by local by-contact state

061860a

clearer internal naming and documentation

85d6a97

remove unneeded cloning

8f743ad

replace low-level sql tests by higher-level functionality tests

12fbb81

remove superfluous error return

f6e8f57

fix typo and docs

cfd6f97

emit 'chatlist changed' event

019d528

simplify reaction refining and make it more robust

954252b

factor out sorting by frequencies

e053861

simplify reaction refining

3a3cdf0

add test for test_refine_broadcast_reactions()

4789f11

increase self counter so one gets an immediate feedback on reacting

7640a4d

factor out save_broadcast_reactions(), clearer names for the wire obj…

fff4333

…ects

revert increasing self-counter for immediate feedback

3243be1

this reverts 4c75f2d, esp. in small channels, it is weird that there is an additional person reacting, always then minutes after you reacted with the same reaction. a ghost 👻

let load_broadasted_reactions() return empty array; this makes modifi…

dce023a

…cations easier

modify broadcast reactions on SELF-reaction

3303f70

mute outgoing broadcast channels; receiving potentially lots of notif…

ae96959

…ications for reactions is usually not wanted

make clippy happy

21f00c0

r10s force-pushed the r10s/channel-reactions branch from f913680 to 21f00c0 Compare July 29, 2026 09:23

r10s mentioned this pull request Jul 30, 2026

resend broadcast reactions together with message #8496

Open

link2xt reviewed Aug 3, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

broadcast channel reactions - #8450

broadcast channel reactions#8450
r10s wants to merge 34 commits into
mainfrom
r10s/channel-reactions

r10s commented Jul 23, 2026 •

edited

Loading

Uh oh!

link2xt Aug 1, 2026

Uh oh!

link2xt Aug 1, 2026

Uh oh!

link2xt Aug 1, 2026

Uh oh!

link2xt Aug 1, 2026

Uh oh!

link2xt Aug 1, 2026

Uh oh!

link2xt Aug 3, 2026

Uh oh!

link2xt Aug 3, 2026

Uh oh!

link2xt Aug 3, 2026

Uh oh!

link2xt Aug 3, 2026

Uh oh!

link2xt Aug 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	/// Starts broadcasting if last broadcasting so more than `REACTION_BROADCAST_PERIOD` seconds in the past.
	/// Starts broadcasting if last broadcasting is more than `REACTION_BROADCAST_PERIOD` seconds in the past.

	/// For Messages: Additional reactions that go to the BroadcastReactions: header
	/// For Messages: Additional reactions that go to the Broadcast-Reactions: header

Uh oh!

Uh oh!

Conversation

r10s commented Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

known issues

for another pr

misc.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

r10s commented Jul 23, 2026 •

edited

Loading