While I imagine it's no priority, nor a solution for everyone, I wish more apps would support UnifiedPush[1]. The notification limitation is purely an Apple/Google one, and there's no "hub" setup you can easily configure with either.
This would solve the notification problem for many self-hosted applications, also allow for non-Apple/non-Google deployments if you want to avoid sending PII or other sensitive data through those servers (though Android apps could use UnifiedPush/fcm-distributor to combine the advantages of FCM with the advantages of UP).
I get that there's not a lot of business interest in this solution but when it comes to open source stuff, I really wish this would pick up more steam.
Conversations (the XMPP client) has also figured out a way to receive notifications without using centralized servers by keeping an TCP open thus avoiding any centralized servers for push notifications. Modern XMPP servers can be instructed to only use the TCP connection when a notifying message arrives to avoid radio and battery consumption. Conversations also can act as a UnifiedPush distributor for other apps which don't want to maintain their own TCP connection.
How does this handle frequent network/tower changes (think high-speed train) and such?
There are also the privacy implications, if you have separate connections to a server for every single app, every single app knows exactly when you get home and go to work (by monitoring when you're connected to WiFi and connecting from a broadband operator and when you're on mobile.)
The goal or Unified Push is that you have one push provider you install (Conversations, NextCloud, ntfy) that ofher apps integrate you. Apps register a callback URL through the provider on your phone, report that to their own servers, and when it becomes time to notify the user, the server submits a POST request to the app server.
If set up right, there will be two persistent connections at most: one to Google/Apple, one to the provider you have registered. The app will inform the other applications on the phone of the notification, so there is no need for any other individual connections back home.
This is an alternative for what happens now when apps can't make contact with platform notification services (either because of network failures or because of the push service being disabled): suddenly, every app falls back to their own custom notification socket, or notifications stop showing at all.
The mobile platforms really need to provide an API like "the radio is now on, please do your thing", so all apps can coordinate when they're active, and save battery.
QUIC makes changing IPs cheap & trivial, send one packet to server to poll for new messages, server responds with one or more packets to get pending messages delivered, and will push messages to that IP from there on.
I'm not quite sure how it handles network changes, but Conversations has worked well for me even on trains and cars in the last 2 years. Maybe this? https://xmpp.org/extensions/xep-0198.html
Yes, XEP-0198 is how reconnects (network changes, train tunnels, etc.) are handled. When the client reconnects to the server they exchange where each received up to before the disconnect and each side resends anything that was dropped.
This blog post covers some more recent improvements at https://blog.prosody.im/fast-auth/ - it makes XMPP (and therefore Unified Push) even smoother on lossy and high latency networks.
Android, Windows, macOS, Linux, any platform but iOS, really. There's little stopping you from taking the Java library and stuffing it into a desktop application for a single everything-but-iOS notification service.
I'm not sure where the restriction lies, but with AltStore being easily accessible and Apple being rumoured to allow users to install their own apps like normal, it's quite possible that we will have an iOS version soon. Of course nobody will work on it until Apple fixes their restrictions, but I wouldn't be so pessimistic as the authors of the website.
"Fix" is a strong word. I was of the opinion that both Google and Apple have limited background services heaps of the years for the purpose of saving user battery life. Why should this one be an exception?
This would solve the notification problem for many self-hosted applications, also allow for non-Apple/non-Google deployments if you want to avoid sending PII or other sensitive data through those servers (though Android apps could use UnifiedPush/fcm-distributor to combine the advantages of FCM with the advantages of UP).
I get that there's not a lot of business interest in this solution but when it comes to open source stuff, I really wish this would pick up more steam.
[1]: https://unifiedpush.org/