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.
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.
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)
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.
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?
That would be a killer app for IPv6 if mobile networks were up to it...