I noticed that in the change log for DC 1.44 there is now instant delivery on iOS devices.
I think instant delivery has been a challenge on iOS for a long time for DC (and probably any other app that doesn’t use Apple push servers), so I am interested to know how DC has now achieved this? Did it require some special innovation?
And some related questions:
Does DC still make use of Apple and/or Google central push servers or any other central server for heartbeats to wake up DC? And if so which server generates the push message?
If messages are now delivered instantly by default, does it make a difference whether a user (either on iOS or Android) selects the “reliable connection” setting with permanent notification?
Do the IMAP push messages contain any unencrypted information?
I am actually a bit surprised that there is not much information in the DC FAQ about how the push services work.
using apples server over a proxy we host. chatmail (our postfix/dovecot configuration) instances support instant notifications. (we plan to document / maybe standardise the protocol we made once we are happy with it, it is working, but not final)
when an iOS device connects to a chatmail server it gives it its wakeup token for Apples push notification server.
When a message comes in, the chatmail serve it contacts the our relay server with giving it the device tokens to ping, our relay sends “you have new messages” notifications to apples server which then sends it to the devices.
This wakes up DC, which fetches new messages and if it manages to download it fast enough it replaces the placeholder text of the notification with the downloaded message, if it isn’t fast enough it will still say “you have new messages”.
We have plans to reduce meta data so that the token is encrypted for the relay so that the mailserver does not know the device token.
If you don’t use a chatmail account you will still get a heartbeat from the notification relay every 10min that wakes up deltachat to fetch messages in the background, but iOS decides how often DC is woken up, so notifications are not instant. The background process had a few bugs that made it crash, we fixed those, so it should work better again.
iOS does not have such a setting and the relay does not support Google’s cloud messaging (android) yet. Also this is only if your server supports it, which means only chatmail instances at the moment.
The best thing would be if DC could hold the connection to the email server in the background, but android and iOS often times don’t let it keep the connection in the background.
Given that they do it to save battery, an api where you could give the socket to the Operating System and let it freeze your process until sth. comes at that socket would be perfect if they don’t trust DC with not wasting energy, but such an api does not exist yet.
not sure what you mean by that. The push notifications contain no real information (they are just wake up calls to wake up dc that it can download messages) and we still use IMAP IDLE.
Thanks for this explanation. I found this informative.
It seems there is a word missing or an extra word here (In case you want to edit for clarity)
Good to know
Does Delta’s heartbeat server send heartbeats only to iOS devices or both iOS and Android devices?
Yes it is a sorry state of affairs with Apple and Google
This already answers my question
Cool, look forward to reading it!
By the way do iOS devices wait for a minimum amount of time before putting an app to sleep? Because one idea that occurs to me is that if the proxy relay server is able to infer that the app is already awake (because it was recently woken up for example) then it won’t need to keep sending push tokens to Apple’s server for new messages until it can no longer be sure that the app is still awake. This might help slightly to prevent Apple from analyzing chat behavior but it might also mean a slight overhead for the relay server (keeping a hash table of recently sent push tokens).
only iOS at the time, but we are considering to add android support in the next months.
Not sure what they could know other than timestamps of receiving messages.
To really prevent that you need to live without push notifications or introduce a random delay.
Yes and from the timestamps infer who’s chatting to who for example
This is true if you want to completely prevent that but what I suggested is a kind of compromise, where the push notification is sent only for the first message if many messages are exchanged in a short period of time, but this assumes that iOS won’t immediately put the app back to sleep, I don’t know if that is a safe assumption to make or not
the main “delta chat app” is not even started when a push notification comes in.
instead iOS starts a special “Notification Service Extension” that needs to exit as soon as possible. so, servers cannot make assumptions currently about if the main app is running and leave out notifications.
in theory, “delta chat app” could inform chatmail if it is running or not, so that notifications are skipped. however, we would replace one data by others then and also get in additional complexity and states - so we abandoned that idea for now
if it comes to mistrust Apple: well, iOS, as the operating system that can supervise all app behaviour, could anyways infer quite some things in theory. if one is in that business, notification timestamps do not really add much
