Chatmail: Push Notifications

[s0ph0s-dog]

This is part of a series of issues tracking chatmail support in Mox.

Chatmail servers provide support for sending platform-native push notifications on iOS and Android.

• Upon set of the /private/devicetoken\[email protected] key (with a notification token), append that token to a table linking tokens to user accounts. Caution: all tokens set with this method should be preserved! This allows users to have multiple devices. The token should be treated as an opaque string with no meaning, which must be preserved exactly and sent exactly.
• Add configuration option in domains.conf to allow the administrator to specify a notification server URL. Default to https://notifications.delta.chat/notify if not set.
• Upon receipt of a new message, collect all of the tokens for that user from the database and enqueue requests to the configured URL with each notification in the body of the request. It should make one request per token. The requests should be retried via exponential backoff up to a deadline of 5 hours after enqueueing.
• Ensure notification tokens are deleted when an account is deleted.

(These two are not strictly notification related, but they require similar changes, so it would be reasonable to do them at the same time.)

• Add configuration option in domains.conf to allow the administrator to specify an Iroh relay server URL.
• Hook into reads of the /shared/vendor/deltachat/irohrelay key to return the configured Iroh relay server URL from the settings.

[mjl-]

I think we'll have to implement push notifications according to the current chatmail approach as you described.

At some point in the future, we can hopefully use a standardized push notification mechanism.
Perhaps through this: https://datatracker.ietf.org/doc/draft-gougeon-imap-webpush/ (with some background at https://unifiedpush.org/news/20250131_push_for_decentralized/).
This earlier work is also interesting: https://github.com/coi-dev/coi-specs/blob/master/webpush-spec.md

Anyway, it will take time before a push mechanism is standardized and before it makes it into software, so we shouldn't wait for it. Just wanted to mention potential future approaches for context.

[link2xt]

If WebPush draft is implemented in the server and has tests, we can implement it in https://github.com/chatmail/core
Without the server it cannot be implemented in the client and server is easier to test without the client than a client without the server, at least manually with rlwrap openssl s_client by copy-pasting the tokens.
I don't think IETF drafts get "standardized" (turned into RFC) without implementations, so mox can be the first implementation.

chatmail is hardcoded to use https://notifications.delta.chat server currently and there is no way to choose gateway, so I don't think it makes sense to implement it as is.

I am not sure if WebPush results in less privacy as it definitely requires to store subscription gateway in plaintext on the mail server, but that's how it is, maybe could be solved by encoding some data into tokens cryptographically so tokens are indistinguishable between at least all delta chat clients by default.

[mjl-]

FYI, I started on an prototype for the IMAP WEBPUSH draft. It helped shape the draft, so that's useful. The prototype currently lives at https://www.ueber.net/who/mjl/tmp/mox.imapwebpush.git, but I'll move it elsewhere at some point. It's prototype-level code, needs to be refactored and cleaned up. And of course the draft spec will change. It is being discussed in the IETF mailmaint WG, but isn't adopted at this point.

An IMAP server (eg mox) will store the following per push notification subscription for an account: The push server URL (e.g. https://notifications.delta.chat/..., as retrieved/created by the client, and I think client developers will have their own push servers, at least until the mobile platform providers expose a webpush server and let client developers register push subscriptions with them) and the client public key and auth secret (generated by the client, on its own) that is used for encrypting the message.

[link2xt]

Speaking about Delta Chat, it does not care about the push notification contents and is only interested in new messages arriving into INBOX. \Seen flag changes maybe too, but currently chatmail does not notify about these and it's not a big deal, this just results in messages marked as seen across devices non-instantly. In the end when notification arrives, UI (e.g. Android or iOS specific code) calls "background_fetch" method, e.g. this JSON-RPC API:
https://github.com/chatmail/core/blob/df245325039c590ee185f199ea8624795ed5b6a5/deltachat-jsonrpc/src/api.rs#L251-L263
There is a similar legacy CFFI API.
It just polls all IMAP connections for new messages then. This also helps other connections to servers that don't support web push, because they are checked every time notification arrives on some other profile.
Pushing actual FETCH messages is not super useful, trying to parse them from push notifications, dealing with managing encryption keys etc. is not worth the complexity there. May be useful for other clients.