I’ve been using schildichat and fluffychat (two clients for matrix) with unifiedpush for a while now, and also fedilab (a client for mastodon), and I have to say it seems to work very well.
Unifiedpush is a floss alternative to google’s gcm/fcm to receive push notifications.
Honestly I think it’s a very interesting project and I hope it will be used by as many apps as possible so that it becomes a “standard” for receiving push notifications on android devices without google services.
Currently the only thing we use centralised push notifications for is the heartbeat we send to iPhones to wake up DeltaChat that it can look for new messages. This is only needed if the device constantly kills/pauses DeltaChat so that it cannot be woken up by imap push. So if you control your device you could just let DeltaChat run in the background to keep the imap connection open so imap push works. so no real need for remote push notifications.
Though one could make a mailserver plugin that sends push notifications to the user… but normally messages are encrypted so the message would be “x send you a message” not very useful. maybe there is also support for silent push notifications that could wake up DC to check for new messages, but then again you could just let DeltaChat run in the background - its the easier solution and you don’t even have access to the mailserver in many cases anyway, except for self-hosting of course.
Thank you for your response. I was coming to cancel the proposal because after becoming better informed about how notifications via imap servers work I realized that this type of implementation is unnecessary and would require support from providers anyway.
There was a standard proposal for using centralized push server in Dovecot: coi-specs/webpush-spec.md at master · coi-dev/coi-specs · GitHub
The source code for Dovecot plugin is here: GitHub - dovecot/coi: Chat over IMAP plugin for dovecot
COI was a Delta Chat fork with such kinds of Dovecot integrations, now discontinued.
But I am not convinced this kind of centralized push server is needed at all. We all somehow get away without using this kind of “service” on our laptops, and Delta Chat for Android works well for me maintaining its own connection.
One of the valid reasons mobile OS vendors are making developers to use centralized push notifications is to prevent low quality apps from “app stores” from polling their servers every 5 seconds in the background and eating the battery. But as long as the app is using a proper “push” strategy, like Delta Chat with IMAP IDLE, there is no reason to switch to centralized server unless you have 50 messengers that actively push new messages to you in parallel, improvement in battery life is close to zero.
I made the proposal on the wave of enthusiasm seeing that unifiedpush works well with both schildichat and fluffychat (two matrix clients) and now unifiedpush support has been added to fedilab (a mastodon client). Since I use a lot of apps that require push notifications (delta chat, schildichat, conversations, fedilab, k9mail) I was thinking that if they all used unifiedpush there could be advantages for both battery consumption and ram usage having the need of a single service active in the background. But chatting in the support group of conversations on xmpp they explained to me that both xmpp and mail have their own system of push notifications that actually works well so there is no real need to implement another that among other things involves the use of an additional server. I don’t have great technical knowledge so sometimes maybe I make proposals that are not very sensible from a technical point of view or difficult to implement but I always do it because I care about the project and thanks to your feedback I learn.
Many programs now use Unified Push / NTFY to replace Googles FCM in the ungoogled version.
It would be great if Delta Chat did the same.
At least on the chatmail servers this should probably not be an administrative problem. 
You can see which projects support Unified Push / NTFY here: Apps using UnifiedPush | UnifiedPush
thanks for the reminder. we know about “unified push” and probably will reconsider on the next iteration.
in general, however, on de-googled-phones also IMAP IDLE usually works using a background connection, so that https://dontkillmyapp.com is less an issue as on googled-phones.
Yes, of course.
You’re right, with custom ROMS, the case where you often don’t use FCM but a background service within the app, reliability is not really an issue.
That’s the case for me too, with LineageOS 21 (Android 14) the notifications from Delta Chat work very well.
I’m therefore more concerned with battery optimization, (deep) sleep and avoiding further permanent background connections if NTFY is installed as a push service for other apps anyway (e.g. Element, Amethyst, FindMyDevice).
Delta Chat could remain on the battery optimized setting and would no longer run constantly in the background, which would save battery. There would also be no further background connection (IMAP idle), which would again save battery (and traffic).
I hope I was able to make it somewhat clear what I mean regarding the use of Unified Push and NTFY.
Anyway, thank you for the great program and the work you do. 
Link to a comparable argument: How to Use IMAP IDLE on Mobile Networks
Upvoting here. +1
The “background connections are killing the battery” trope needs to die. Not a single one of these claims were backed by actual data. I don’t use UnifiedPush because the apps I use are proper, I let them run in the background constantly and the battery usage is so low android reports it at 0%.
We need actual pros and cons, not myths:
You may consider it a “myth” but after I configured every app on my de-Googled phone which supports UnifiedPush to use it, I noticed a very perceptible increase in battery life. Not every user is going to have the same experience you do. 
Good ! Do you have some numbers ? Maybe the apps you used ? Or the usage pattern ? I’d love to see more on that
I would also like to know what apps you configured to use UnifiedPush. This sounds like some app that has inefficient connection maintenance or polling consuming battery, replacing it with another app that does it better such as ntfy.sh could indeed improve it.
I use Molly and Delta Chat and Conversations and Briar without UnifiedPush on my phone, and even when I mostly use the laptop most of the battery on my phone is consumed by using the screen it seems. Briar uses 7% (even when I don’t open it and don’t receive messages there, I guess it maintains Tor connection), Delta Chat uses 2% (but this is because I actually open it and scroll the chats and read there, so I doubt offloading push notifications to another app will save much), Conversations and Molly use <1% according to the battery usage screen.
EDIT: I now tried to understand how UnifiedPush works from the user perspective. Installed Sunup for a distributor, but when I tried to set Molly to use UnifiedPush, it said “To use UnifiedPush, you need access to a MollySocket server to link your Signal account.” In Conversations I did not find a way to make it use Sunup, Conversations itself wants to be an UnifiedPush distributor, so others will receive notifications over XMPP but not Conversations over Sunup. Briar does not support UnifiedPush. The list of apps that actually support receiving makes me wonder even more what are these apps that save battery by switching to UnifiedPush, most of them are Matrix or fediverse clients. Which of them drain the battery without UnifiedPush?
I however discovered that I have Element X installed, opened it and it silently registered with Sunup, now it is displayed in Sunup. So there is no UI needed if Delta Chat implements it like this. I also still don’t know if this can be implemented: we have strict constraints that we don’t want Delta Chat to talk to any servers other than the chatmail relay (email server) and we don’t want the chatmail relay to see unencrypted token, so if there is interactivity in the protocol it can be a problem. Current flow is unidirectional, token is given to Delta Chat from the OS, Delta Chat uploads (encrypted) token to the chatmail relay, chatmail relay gives encrypted token to the notification server that does not know which email address it belongs to.
Hi, S1m, UnifiedPush dev here.
I’m planning to add support for UnifiedPush to DeltaChat very soon, this is part of my grant with NLnet. And happy to discuss the feature in private if you want. Nami got my DC contact.
Then, regarding your tests:
* Here we can see that the push protocol gain interest for the user with the number of applications supporting it. This is also why I think it would be great having DeltaChat in that list: this is a common app in the FOSS ecosystem which would increase the protocol interest for users. And the number of users increases interest for other projects to offer an alternative to FCM.
Regarding the battery consumption:
** I’m also perfectly aware that projects have to prioritize things, and prioritizing development for regular user is in my opinion a good strategy. So I understand when a project with an efficient background connection doesn’t prioritize UnifiedPush. And this is also why I implement it
** This is very simplified, I don’t think it’s linear like this. It is likely possible that having too many apps constantly connected increase the possibility of being killed or put in standby - which increases time with an active CPU to restart a connection. Moreover, the “percent per apps” are also very simplified, the OS doesn’t necessarily attribute some work to the applications, so with a single app the OS can show 1.5% for the app with an effective 2% (1.5+0.5) of battery drain, and with 2 apps 1.5% for each and an effective 5% (1.5+1.5+2) of battery drain.
***And we’re not talking about the number of foreground notifications required
It may be worth reading these blog posts regarding push notifications:
PS: Do you have some WIP with JMAP? It supports web push out of the box, and may be a good solution for a web DC client (and KaiOS DC client)
PPS: I’m very happy to contribue to DeltaChat soon!
Just regarding the jmap part: deltachat does all interaction through a thing called chatmail core, that manages everything (storing data, queues, telling the client what to refresh etc) so that any app can be built just talking with this thing. A web client would probably integrate it to not have to redo all the logic, so jmap won’t help here.
Even if a web client integrates Chatmail Core, there’s no way to make raw TCP connections (therefore, one can’t use IMAP or SMTP). So there would either have to be a proxy over HTTP that would then carry the IMAP/SMTP traffic, or one could use JMAP.