feat: client version information by r10s · Pull Request #8557 · chatmail/core

r10s · 2026-08-10T18:52:51Z

we aim to inform about updates for installations outside of any appstore soon.

there is already a PR on android at deltachat/deltachat-android#4582, however, the information about "update available" is a mockup there.

in general, there are 3 ideas around about how to gather the "update available" infomation - (1) checking a central url, (2) let contacts provide information, (3) let relay provide information. on various one-to-one discussions, outcome is that (3) is the most reasonable way to go.

this PR is about reading update information via IMAP metadata from the relay.

it is up to the UI to call get_app_version() at a reasonable time and frequency, see comment in the code. when called, get_app_version() iterates over all known profiles and relays and checks for version information, returning the newest for the given scope.

we do not use an event, as that is tricky wrt changes - we do not know if other relays report later a newer version. we also do not cache anything, to prevent bad relays avoiding us to update permanently. also it is easier :)

outdated notes and questions

~~it is up to the clients to get the needed information, we could let core filter, but it seems easy enough the other way round, and may have debug advantages, one can iterate etc.~~ EDIT: we now filter in core, this also makes the jsonrpc part easier, see review comments
when is IMAP METADATA actually read? when are they ready? is that really the correct place? i am up to change that, but beware, this is not really my expertise, so someone else may need to take over :)
EDIT: see below, IMAP METADATA is read on connection, before fetching starts, usually fast enough
relay part is missing. once the format is settled and discussed shortly here, that should be done soon as well. but this is definitely not my expertise and needed to be done by someone else :)
key for IMAP METADATA is /shared/vendor/deltachat/appversions - shall we continue use deltachat for compatibility or so? chatmail seems to be more correct
EDIT: we stay with the current

relay counterpart issue: chatmail/relay#1037

cc @link2xt @Hocuri @hpk42

Hocuri

Just some quick comments from quickly reading over it. Would like to finish #8544, afterwards I can take this over if still needed

when is IMAP METADATA actually read?

After starting io, before starting to fetch messages.

when are they ready?

Right now, core doesn't tell the UI that they are ready because the UI never needed any metadata. So, we will need a new event

link2xt · 2026-08-11T12:17:56Z

key for IMAP METADATA is /shared/vendor/deltachat/appversions - shall we continue use deltachat for compatibility or so? chatmail seems to be more correct

This one is going to contain deltachat APK URLs, so it's fine if it is called deltachat.

r10s · 2026-08-11T16:33:50Z

This one is going to contain deltachat APK URLs, so it's fine if it is called deltachat.

idea is to have a appversions.json on https://github.com/chatmail/relay that in theory could contain also other app versions, tho not planned for the next months. i was re-using the deltachat namespace only as it was the one used elsewhere, i do not want to complicate things :)
i would tend to stay with that as well tho

r10s · 2026-08-11T16:35:16Z

i had a call with @Hocuri and incorporated all things we discussed there.

if there are no more comments wrt json format and IMAP METADATA name, i will file an issue for the relays soon.

otherwise, this PR can be re-reviewed, so it gets used by android then soon :)

hpk42

overall looks good but the parse-error issue is a blocker i think, and freshness deserves refinement.

hpk42 · 2026-08-11T23:54:05Z

    /// and [`/shared/admin`](https://www.rfc-editor.org/rfc/rfc5464#section-6.2.2)
    /// metadata.
    #[expect(clippy::arithmetic_side_effects)]
    pub(crate) async fn update_metadata(&mut self, context: &Context) -> Result<()> {


The full GETMETADATA runs only once per process and transport (but not per reconnection), afterwards only the TURN path refreshes. So a UI polling daily gets the same cached data and freshness comes from process restarts. Often on mobiles but rarer on desktop: IISIC even un-suspending a laptop would not refresh the metadata value. Maybe appversions could also be fetched in the TURN refresh way (which debounces re-fetching)? Maybe using the same timer even. Then UIs could poll however often they want, and core controls how often an actual re-fetch is done.

makes sense, currently afk, will have a look at that later

Co-authored-by: holger krekel <holger@merlinux.eu>

Hocuri · 2026-08-12T13:45:40Z

+    /// Security note: consumers need to verify themselves
+    /// that downloaded app files are valid before installing them.


Who exactly is responsible for verifying that the downloaded app files are valid? The UIs? I can't see any such logic in deltachat/deltachat-android#4582; right now, the relay could just point to some wrong download URL. They can't update the existing app on Android because the system checks the signature, but they can install an unrelated app (I don't think that many users would notice that they're asked to "install" an app rather than to "update" it).

So, I think we need either of these:

A whitelist of URL prefixes here in core (containing https://github.com/deltachat/deltachat-android/releases/download and URLs for the other UIs)

A whitelist of URL prefixes in the UIs

Checking that the downloaded actually is an update, rather than some other app, on Android, decide later what to do about other UIs

If the UIs are responsible, then get_app_version() in api.rs also needs a big security warning. Or maybe the required URL prefix could even be passed to get_app_version(), so that the UI can't forget it?

(I didn't actually notice this problem until hpk commented about it)

r10s force-pushed the r10s/get-app-versions branch 10 times, most recently from d9ac2fb to 12d8f41 Compare August 10, 2026 21:06

r10s marked this pull request as ready for review August 10, 2026 21:18

r10s force-pushed the r10s/get-app-versions branch from 12d8f41 to 698d83b Compare August 10, 2026 21:25

r10s mentioned this pull request Aug 10, 2026

Add simple update flow deltachat/deltachat-android#4582

Open

Hocuri reviewed Aug 11, 2026

View reviewed changes

Comment thread deltachat-jsonrpc/src/api/types/appversions.rs Outdated

Comment thread deltachat-jsonrpc/src/api/types/appversions.rs Outdated

Comment thread src/imap.rs Outdated

Comment thread src/imap.rs

Comment thread src/appversions.rs Outdated

r10s added 2 commits August 11, 2026 14:45

feat: client version information

ee7bfb7

UI only needs concrete client/source info

a636f3a

r10s force-pushed the r10s/get-app-versions branch from 698d83b to a636f3a Compare August 11, 2026 13:27

r10s added 3 commits August 11, 2026 15:31

let relay know we want 'appversions' data

4c37ac4

unify AppSource and source_id

6a4d08d

get_app_version() iterates over all profiles and relays

f9b5873

r10s force-pushed the r10s/get-app-versions branch from 6beb655 to f9b5873 Compare August 11, 2026 16:20

make clippy happy

a075f17

r10s requested review from Hocuri and link2xt August 11, 2026 16:34

r10s mentioned this pull request Aug 11, 2026

add "client version information" to IMAP METADATA chatmail/relay#1037

Open

hpk42 reviewed Aug 12, 2026

View reviewed changes

Update deltachat-jsonrpc/src/api/types/appversions.rs

8ffab36

Co-authored-by: holger krekel <holger@merlinux.eu>

r10s and others added 3 commits August 12, 2026 06:24

Update deltachat-jsonrpc/src/api.rs

c955d8b

Co-authored-by: holger krekel <holger@merlinux.eu>

Update src/appversions.rs

1a69e34

Co-authored-by: holger krekel <holger@merlinux.eu>

Update src/appversions.rs

3b8aca0

Co-authored-by: holger krekel <holger@merlinux.eu>

hpk42 mentioned this pull request Aug 12, 2026

feat: serve an APPVERSIONS.json index file to clients via IMAP metadata chatmail/relay#1038

Open

a relay serving broken json should not block discovery of others

340cb9c

Hocuri reviewed Aug 12, 2026

View reviewed changes

		/// Security note: consumers need to verify themselves
		/// that downloaded app files are valid before installing them.

Uh oh!

Uh oh!

Conversation

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

Uh oh!

Uh oh!

Hocuri left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

link2xt commented Aug 11, 2026

Uh oh!

r10s commented Aug 11, 2026

Uh oh!

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

Uh oh!

Uh oh!

hpk42 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hpk42 Aug 11, 2026

Choose a reason for hiding this comment

Uh oh!

r10s Aug 12, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Hocuri Aug 12, 2026

Choose a reason for hiding this comment

Uh oh!

Hocuri Aug 12, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

r10s commented Aug 10, 2026 •

edited

Loading

r10s commented Aug 11, 2026 •

edited

Loading