Hacker News Reader

Comment by dboreham | Hacker News Reader

Quick note that this is for Android and gets rid of the centralized gateway talking to the centralized Google service. Leaving only the centralized Google service. There's no decentralized way to get a push notification onto a Google/Android phone. Except perhaps if you hack something up using EAS.

View on HN

? I think I'm misunderstanding your comment. This replaces the entire push notification infrastructure.

The "distributor" receives notifications onto the device and sends them to the apps via a standardized API.

The apps themselves then post the notifications to the user via the android on-device notification API.

The "gateway" receives the notifications from the services over a standardized API and sends them to the distributor.

How the gateways actually distribute the notifications is actually completely up to the gateways. The main gateway (ntfy) uses websocket, another (nextpush) piggybacks off of nextcloud, and the new kid on the block (sunup) uses the Mozilla Push Service behind the scenes.

Nothing in this is restricted or locked in to a centralised platform.

Is this true even with some deep integration of UnifiedPush with something like microG?

> There's no decentralized way to get a push notification onto a Google/Android phone

What is a "push notification" exactly?

A notification delivered “by” a phone application when that application is not necessarily running.

They’re “notifications” in common speech but there’s also stuff like “now playing” and live activities and rich content that are also “notifications” but do require the app to run.

That's not really what I mean. The person I was replying to was saying that I can't get push notifications without Google's centralized stuff. ntfy/UnifiedPush appears to do just that, so I'm wondering what is missing here.

They are doing that by polling private servers, which is sometimes less efficient power-wise, and sometimes notifications are being delivered slower than in case of using Google-provided mechanism (FCM). We've been using ntfy for alerting, using our private server and running ntfy client in polling mode, and I do not see significantly increased battery usage by the ntfy client; Android 15.

So ntfy Android app polls a ntfy service. (Which is more efficient than each app polling separately) What does Google's Android library do if not also poll? Does it run a server on the phone? Does it get special signals from cell towers that most apps don't have access to?

It also polls, it just does it as part of the OS. Power saving by the OS can often interfere with apps like nfty that want a long-running background process, especially if they haven’t been opened in a while.

Okay, thank you.

From what you're saying, it doesn't sound like the OS-based polling would be more power efficient, as someone in this chain suggested, just more reliable. Though, I think you can just turn off battery optimization for the ntfy app, in which case I'd expect them to be on par.

If that's right, it seems like ntfy with battery optimization turned off is effectively a "real" push notification system.

Reply on news.ycombinator.com