No matter how good the push implementation is, it is still best to only have one connection that the phone has maintain. 5 great push services still takes 5 times the battery that 1 great push service would take.

> 5 great push services still takes 5 times the battery that 1 great push service would take.

This is true with current implementations, but it doesn't have to be true.

Coordinated CPU wakeups and radio packet timings would mean the power consumption from waking the radio would be not much larger with 5 apps than 1.

It needs coordination, but the coordination doesn't have to be done inside a service daemon as it is now, and it doesn't have to go through one shared cloud service provider as it is now.

> It needs coordination, but the coordination doesn't have to be done inside a service daemon as it is now, and

It more-or-less does need to go through a single daemon, or it would be nearly impossible to coordinate the requests.

> it doesn't have to go through one shared cloud service provider as it is now.

This is more true, for example you could have an open protocol and an app could register with the push daemon. It would be impossible to consolidate push notifications or throttle them for bad actors though.

> It more-or-less does need to go through a single daemon, or it would be nearly impossible to coordinate the requests.

A single daemon, or a single kernel, it doesn't really matter which.

I'm thinking a few socket() options. The kernel already coordinates coarse-grained timer wakeups between processes; it's not that outrageous to think it could nudge multiple pinging sockets towards each other then coalesce timings.

The underlying mobile network registration for notifications is already quite low level.

> It would be impossible to consolidate push notifications or throttle them for bad actors though

At least at the moment, I don't think there's a need to consolidate push notifications into the same packet for different apps. The rate of notifications isn't high enough to matter.

For keepalive pings (if the underlying radio network can't provide events to piggyback on), and consolidating pushes (if that is needed), voluntary cooperation on timings among good actors would allow incoming packets to arrive around the same time, and the mobile base station could, if a protocol was agreed, queue and coordinate the transmission time of those packets as a group, or coalesce them into a specially-addressed packet representing the group.

For throttling bad actor pushers, the device itself (kernel or daemon) could block sockets and source IPs that are sending too fast.

Presumably there's already some mechanism in place for things like SYN attacks. If there isn't, bad actors already have a way to drain your battery.

It's not that linear.

The savings are from letting radio go to idle. If you have more than one (ideally non-cooperating) services that are keeping the radio permamently on, you won't ever get to idling and say good bye to battery.

I'm skeptical that Microsoft, Apple, and Google have all failed at this, but some dude on HN has a simple solution. I think you need to expand on your concept a bit before I take it seriously.

What does the software solution look like that distinguishes between a crypto miner and a media player?

How can you tell when an app legitimately needs access to files from another app versus being malware of some sort?

Not sure if you're a programmer, but you can have a centralised local service that listens multiple channels over a standard API and wakes up the respective app. Some quota management on top can ensure fair share. And of course, allow the user to prioritise any app they want.

Could you implement something like this in pine phone? I’m not a programmer but if it’s easy as you say, I’m excited!

It's not even that, simply having open sockets with heartbeats (and then re-opening them once the connection breaks or you switch networks) isnt efficient with 5+ different sockets always open listening for notifications, and that's if every app is coded the same way to operate extremely efficiently.

It would not be technically impossible to have all 5+ wake up at the same time and activate the radio at the same time, even with different packets to different destinations.

And it would not be impossible to coordinate the return timings to match either.

Or even better, to have just one low-level packet shared among them all, with a mobile operator or backbone protocol that fans them out and in, analogous to multicast and IGMP but designed for push/keepalive systems.

There are no insurmountable technical obstacles. Just challenges.

There is negligible consequence for power consumption too, with a suitable API.

But rather than design for everyone, as we would have seen in the utopian days of the internet, it's much easier to run a single walled-garden service, and it fits with the "you must go through us for everything" model used by many of the device's other services.

Utopian days of the internet? Where a bug in a prank can spread a worm that takes down most of the known internet? The same security mindset that allowed for the utopian days is not only long gone, it could survive in an age where my banking and medical info is online.

The attitude that different vendors can create independently run services is still alive, now with better security.

But not on major mobile devices, at the moment.

In the banking world, it appears to be getting slightly more open. There are more independent feeds and open standards than there used to be. This is a mixed benefit as there are also more "middleman" sites that want to read your banking data to help you visualise it better, and some of them might not be doing it just for the benefit of the account holder.

I’m looking forward to your white paper and demo of this increasing either usability or battery life without sacrificing the other.