Skip to content

feat: Key update messages - #8588

Draft
Hocuri wants to merge 2 commits into
mainfrom
hoc/key-update-messages
Draft

feat: Key update messages#8588
Hocuri wants to merge 2 commits into
mainfrom
hoc/key-update-messages

Conversation

@Hocuri

@Hocuri Hocuri commented Aug 14, 2026

Copy link
Copy Markdown
Collaborator

Motivation: We want to proactively inform contacts about new relays by sending them key update messages, in order to maintain connectivity.

When we add a new relay, we don't know whether our existing relays are still working, or have lost connectivity in the meantime. So, as the simplest approach, we will just send updates to all of our contacts (with some exceptions, see below), in order to restore contact if one of our relays doesn't work anymore. Everything else then is an optimization, but it's unclear whether it's necessary, since 90% of users have at most 50 contacts (see https://github.com/deltachat/bg-deltachat/blob/master/statistics/README.md ), and these key update messages are cheap (even if you have 700 contacts, this design will just cause an extra 35 small messages everytime you add a relay).

Details

Specifically, we want a function that is called when adding a relay, which does the following:

  • Query all key contacts that are not blocked, and with whom we are in a 1:1 chat, group chat, or incoming broadcast channel (there is no need to send a key update to broadcast channel recipients, and there are potentially a lot of them)
  • Group these contacts into chunks of 20
  • Send a silent message to each of these chunks (if we want it to be backwards-compatible, this can be an MDN or a securejoin vc-pubkey message)
  • On the receiving side, make sure not to update last_seen, in order to prevent the green "online" dot from appearing (we will likely need a new header for this)

As an optimization, we can debounce these messages, be smarter about which contacts we send these messages to, introduce some limits to how many contacts we send a message, and/or send these messages in housekeeping rather than immediately. But we can think about these optimizations later if problems arise or people complain.

We can then get rid of the concept of unpublished relays, because they are not needed anymore to prevent losing contact. This will make core conceptually simpler and to improve things from a privacy (policy) standpoint.

@Hocuri
Hocuri marked this pull request as draft August 14, 2026 12:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant