Except that push notifications also require work on telco's side to make sure they don't accidentally cause large battery use.

E.g. there was a long time after Apple introduced push messages where iPhone battery would drain pretty fast because many telcos would have very short connection timeouts on their routing equipment. This forced the phone to wakeup the radio a lot to reestablish connection.

This was "fixed" by whitelisting Apple/Google endpoints, so I wonder how that would work in federated environment.

> This forced the phone to wakeup the radio a lot to reestablish connection.

Perhaps, but if you can tolerate some latency, you might not have to wake the radio all that much. A huge majority of notification use cases can be delivered "late" (at least if the phone is in sleep mode) and still be useful.

Yes, and I believe both GCM and APNS perform cross-app notification coalescing, whereby a low priority notification (e.g. a news article, or some other content update) will picky-back on a high priority notification (incoming call, text message).

This is extremely valuable in reducing power usage.

(Notifications both exhibit radio usage, but also will typically turn on the display, which is a huge battery sink)

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.

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?

The most efficient decentralized way would be direct end-to-end connections. One could assign an IPv6 address to each application and have the notifications just sent there, no middleman necessary. If an application takes up too much battery, just kill it by changing the address.

That would be a killer app for IPv6 if mobile networks were up to it...

Many LTE networks are IPv6 first, with IPv4 only services generally performing much worse or being unreachable. All 3 US Cell carriers have made this jump, though you see people complaining about IPv4 only sites and services not loading or working poorly through CGNAT.

Yes, but for my approach to work, the device would have to be able to use multiple addresses that are preferrably randomized. Not sure that that will work everywhere.