I get excited every time I learn about another E2EE messaging app where the server can be self-hosted. But as I understand it, the server that triggers push notifications for any android app must be hard-coded into the app's binary. Are there any good architectural workarounds for this? I've read a little bit about VAPID[1] but I don't know if it is actually a viable approach and I don't think I've ever seen it promoted in an E2EE messaging app with a self-hosted server.
[1] (Disclosure: the AI gave me this link) https://unifiedpush.org/news/20250131_push_for_decentralized...
It's possible for the app to poll the server for new messages. iOS also supports light background work that can poll server from time to time and trigger notification on the device, rather than using apple's push notification infra.
The trade off is that you gain some extra privacy with simpler architecture and accept that some notifications will be delayed as ios decides when to run the bg job for the app.
source: I develop e2e app with self-hostable server (145 lines of zero deps python for the whole server).
Conversations is a XMPP client, it's essentially the same protocol that delivers reliable notifications to every Android, Nintendo switch, etc. Unless you have an Android distro that kills every background app indiscriminately, you will be fine with Conversations delivering messages and notifications to you.
Interestingly, the link you posted relates to Unified Push, which is a protocol that relies on a "distributor" app which acts as a proxy, receiving reliable notifications on behalf of other applications. And it happens that Conversations can be configured as a UP distributor, because of how good it is at that/how well the XMPP protocol lends itself to it.
Long way to say you should give XMPP a shot, it really works well!