[g_p]

I was involved in designing a POC that proved this many years ago now (but after Doze appeared on Android, causing power saving issues). Note this was all for Android though, and I think Apple's restrictions make it very difficult to do this there.

There is a nice model for federating push services, and it worked. If you give apps a push "token" that takes the form of a URI or email-like address, the token can be namespaced by the push server provider. That can be self-hosted. An application can send push messages via websockets or a similar transport to the user's token-defined push server, and the user's apps can listen to it.

The long and short of it was that an app implementing the "push client library" would be able to do push messaging in a power efficient way, and it meant you could still only query 1 source server, that was configured well for long-lived connections. The trade-off is that you need app developers to really want to use it, and be willing to send the push messages to servers identified by the push token/URI.

[chrismorgan]

That sounds to be exactly what the Push API (https://w3c.github.io/push-api/) is for the web: code can ask the user agent, “please give me a push endpoint”, and the UA gives it a URL, and then the code sends that URL to its backend server, which can then push to that endpoint, and messages will end up back at the user agent and be handed to the relevant code. On desktop platforms, Firefox defaults to using a Mozilla-operated push service, but on Android it could in theory use FCM, or Samsung’s equivalent, &c. if they supported the API.

I really don’t understand why mobile OSes don’t just adopt the Push API wholesale. Android especially. It’s such a mess having each app do its own thing and then have all kinds of problems with power saving measures; why not instead let the OS declare the push service to use (Google phones use FCM, Samsung phones use a Samsung push service, &c.), and apps just use what they’re given?