[Hocuri]

If the user has only one transport, and it's on nine.testrun.org, then most likely they used automatic onboarding and do not really care about their transports. In order for these users to benefit from multi-relay, and in order to be less dependent on nine, we would like to fill up these transports.

Once 3 relays are reached, Config::AutorelayFinished is set, and nothing automatic is done anymore.

I tested on a real device that this works. If you also want to test this, here is a backup with only nine.testrun.org as a relay. I created it with an old version of Delta Chat that didn't have multi-relay onboarding yet. I needed to put it into a ZIP, because Github doesn't support attaching tar files.
delta-chat-backup-2026-11-01-00-ovkcnwm0i@nine.testrun.org.tar.zip

Open questions:

• Should we wait with merging this PR until we have parallel sending? The context is that some weeks ago, one of the default relays silently dropped messages, which meant that if this relay was chosen for sending, outgoing messages were lost. Parallel sending will fix this problem. I would say yes, we should wait until we have parallel sending, because this PR will probably multiply the number of users with relays from the default list, and we really don't want users to run into problems with sending messages.
• Should we fill up the relays even if the user is using a single relay that's not nine? The disadvantage is that users may have wanted to use this relay specifically, and not others. The advantage is that users may not have thought much about the relay, and maybe they chose an unreliable relay.

A known small issue: If the user has two devices and updates them at the exact same time, then both devices will add 2 relays so that there will be 5 relays in total. If 3 devices are updated at the exact same time, then there will be 7 relays in total, and so on. This seems such an unlikely edge case that we can just ignore it.

TODO for me:

• FAQ entry

[link2xt]

Should we fill up the relays even if the user is using a single relay that's not on the list?

I think we want to fill up relays at least for mehl.cloud because it is going to be shut down, and likely for all relays from the default list and chatmail.at website. But not for other servers because these are users who specifically want one particular relay. One example is nauta.cu, but there are other cases like this.

[hpk42]

as @link2xt suggested elsewhere, i think we can fill up all single-relay profiles if the single relay is listed on chatmail.at.
You can get it via uvx cmrelayinfo --json | jq -r .relay. So all non-relay profiles are not touched, as well as any of the hundreds of "unpublished" relays. I think we can still consider filling those up, but the chatmail-at list is kind of safe IMO.

[hpk42]

1. What about bots? Should they also do auto-fill (they do it in this PR)? I tend to say yes, but better to think explicitly about it. If we want to play it safe, we could not auto-fill relays for bots i guess.

2. If one device fills up relays, then the user removes relays so it's a single relay profile, a second device coming online later will get both add/remove sync messages, and also end up with a single-relay profile, and restart the filling process on upgrade. Maybe that's ok, but to play it safe/unsurprising for users who fiddled with the relay list, we could refrain from auto-filling up if there are any removed transports. (maybe just as runtime check, not in migration).

3. What remains is that multiple devices where one device is offline for 20+ days will never see the fill-up, and do a fill-up of its own on upgrade, resulting in 5 relays.
   The proper fix for that probably is re-sending transport syncs every ~14 days, so that any longer offline device will always have a fresh view on current transports.

I am still approving already, because it otherwise looks fine, and none of my remarks/recommendations are super-critical i think. But maybe you can do a follow-up PR or at least an issue for 3. if you agree.

[hpk42]

maybe here and also in maybe_add_additional_relays_inner we should better avoid adding relays that are in removed_transports table: single-relay profiles could have temporarily added then removed a relay.

[hpk42]

ah, post note: i don't think we need to wait for parallel sending. But FAQ entry we definitely need.