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
I studied this topic and got completely confused…
maybe I don’t understand something again, you all refer to push notifications from Google and Apple, then why do I have notifications on my phone without any Android services (clear LineageOS), notifications come perfectly to both WhatsApp and Telegram and even to Element from Matrix… and you keep talking about the problems on the part of these two (Apple and Android), they have nothing to do with it at all. And now I’m having problems with notifications, most of the messages come quickly, but sometimes within 5-15 minutes.
This is very strange and because of this there may be problems (I’m talking about real life, you will laugh but: my wife sent to the store and told me to buy something, but in the process of my going to the store she wanted me to buy more, forgot to add to the shopping list, so she wrote to me but I did not receive the message while I was in the store, I totally screwed up.
And all this with nine.testrun…
For Apple: any way, didn’t understud, in any way he can go to sleep (push may come or didn’t) nobody guaranteed this for DC.
there is FAQ - Delta Chat that explains some basics about “Instant Delivery” and “Push Notifications”.
however, of course that is not all-embracing - and was created out of threads as this one
And all this with nine.testrun…
in general, PUSH notifications should work when all receivers use nine.testrun.org - or any other chatmail server. and this is also the feedback we got.
might also be that there were temporary outages by some involved server - but that should not happen on a regular base.
note, that iOS PUSH notifications are usually not delivered when the phone is in “battery saving” or “mobile data saving” mode - these modes are detected and shown at “Settings / Connectivity”, together with more things that lead to disabled PUSH notifications.
in case you encounter the situation again, consider checking the state and save a log at “Settings / Advanced / View Log”
And in Android the same (i forgot notice it) and 2 checkmark notifications that message was read did not switching. I test all OS и везде разные проблемы. I don’t see that all messages come in time and correct. I want but i cant use it and accept this.
I have long been with DC, so for 5 years (I will put it, delete) but then it was clear, right now with adapted servers, all early there are no guarantees as a chat.
Alas, I love DC, but still can’t solve problems (this is not your fault, I know).
But that will only work if you have FCM setup by Google or MicroG and @gtvzu says he’s using “clear LineageOS” without any Android services. So the weird thing is not that he’s not getting notifications from DC, but the fact he’s getting perfect notifications from WhatsApp, Telegram and Element.
then he should disable battery optimisations for dc, also maybe the persistent notification, if that all does not work, then send us the log, must be a bug in DC then. I don’t think WhatsApp supports unified push with custom servers.
Exactly. That’s why I don’t understand how @gtvzu gets notifications “perfectly to both WhatsApp and Telegram and even to Element from Matrix” on a “phone without any Android services (clear LineageOS)”. It doesn’t make sense to me.
