Live data from Hacker News

Push Notifications for Decentralized Services

unifiedpush.org

21–30 of 54 posts

Re: Push Notifications for Decentralized Services

#21

This looks very over engineered and complicated, we don't need more push notifications. Just use or improve upon email or RSS (recommended). It's anonymous, fast, privacy friendly (no device registrations or whatever), open and already decentralised so no need for anything else.

The purpose of this standard is to replace Google's FCM push notifications so that you can receive push notifications on a mobile device for a bunch of services while only needing to maintain a single low-overhead connection. This exists to improve battery life and decrease data usage for android users who don't use google services or prefer to host their own. And generally it exists to provide a standardised, indepe…

> The purpose of this standard is to replace Google's FCM push notifications so that you can receive push notifications on a mobile device for a bunch of services while only needing to maintain a single low-overhead connection.

Isn't the purpose of Google's push service that you can receive notifications for a bunch of services with only a single connection?

I don't quite understand how adding a different service helps, although having an alternative when Google's push is unavailable could be useful, and if there's some way to share that alternate service among many apps, that would reduce overhead of having two notification channels where each app with two channels has their own alternate channel?

Re: Push Notifications for Decentralized Services

#22
post #7

If I understand the notifications flow correctly: a device (typically mobile phone) will get a "registration" with a "push url" from its platform/provider (eg android/google or iphone/apple), which it hands to an application server (eg IMAP server), which then uses that to send notifications to the push url, "authenticating" with vapid. And due to vapid, no special account/preregistration is required for the applicat…

Android is very simple. All their notifications are internally supported by a TCP connection to a Firebase endpoint. So when you need to send a notification, you ping the central (and Google-controlled) Firebase endpoint with a device ID. Firebase then pushes a message over the TCP connection that is permanently open between the phone and the Firebase.

On the phone, the Play Services are exempted from the battery optimizations, so the socket connection stays up. And once a notification is received, Play Services unmarshall it, and route it to the correct application ("activity"), possibly waking it up.

From the notifier's side, you need to have the credentials for Firebase interaction and the device's token (that Google Play Services make available to the application during the notification setup).

iOS works in an exactly similar fashion, except that the endpoint is controlled by Apple. To send it, you need to set up an "APN".

Re: Push Notifications for Decentralized Services

#23
post #21

Earlier quoted context omitted.

The purpose of this standard is to replace Google's FCM push notifications so that you can receive push notifications on a mobile device for a bunch of services while only needing to maintain a single low-overhead connection. This exists to improve battery life and decrease data usage for android users who don't use google services or prefer to host their own. And generally it exists to provide a standardised, indepe…

> The purpose of this standard is to replace Google's FCM push notifications so that you can receive push notifications on a mobile device for a bunch of services while only needing to maintain a single low-overhead connection. Isn't the purpose of Google's push service that you can receive notifications for a bunch of services with only a single connection? I don't quite understand how adding a different service hel…

Yes that is the goal of google's push service.

The benefit of this service is mainly for people who can't or don't want to use google's push service. Namely for users of de-googled devices and for users of android devices that google blocks from using play services (ex: users of Huawei devices).

But also it's worth noting that unified push provides an optional google FCM fallback so that apps can use google's push services (provided they are available on the device) when a unifiedpush distributor isn't available or configured. So in this sense it means supporting a single push notification standard instead of multiple and the underlying system can switch between which provider to use.

And of course for users of completely self hosted services this means you get all the benefits of a proper push aggregator like google's FCM without having to configure firebase with your services. This is particularly appealing if you self host locally and don't already use cloud services.

Re: Push Notifications for Decentralized Services

#24

Earlier quoted context omitted.

I receive content from E-mail all the time and I am also notified about it and it doesn't drain my battery.

But what is your email client using for notifications? If it's using intermittent/timed fetch, that runs into the latency problem (taking longer to receive notifications). Push notifications exist to solve that problem. If it's using IMAP's IDLE, MAPI's push, or JMAP's push, that's just another long-running HTTP or websocket connection. And this protocol (along with the proprietary push notif aggregation services it…

> But what is your email client using for notifications?

Local notifications?

I don't see the problem here with email, it seems to work well that it is great for my use case.

When you're offline with push notifications only the latest notification gets sent, not the previous notifications. This seems by design for notifications.

At least with E-mail I can see a history of emails that was sent to me.

I just see push notifications as a flawed concept that doesn't make sense for decentralised services.

Re: Push Notifications for Decentralized Services

#25
post #22
post #7

If I understand the notifications flow correctly: a device (typically mobile phone) will get a "registration" with a "push url" from its platform/provider (eg android/google or iphone/apple), which it hands to an application server (eg IMAP server), which then uses that to send notifications to the push url, "authenticating" with vapid. And due to vapid, no special account/preregistration is required for the applicat…

Android is very simple. All their notifications are internally supported by a TCP connection to a Firebase endpoint. So when you need to send a notification, you ping the central (and Google-controlled) Firebase endpoint with a device ID. Firebase then pushes a message over the TCP connection that is permanently open between the phone and the Firebase. On the phone, the Play Services are exempted from the battery opt…

[deleted]

Re: Push Notifications for Decentralized Services

#26

Earlier quoted context omitted.

But what is your email client using for notifications? If it's using intermittent/timed fetch, that runs into the latency problem (taking longer to receive notifications). Push notifications exist to solve that problem. If it's using IMAP's IDLE, MAPI's push, or JMAP's push, that's just another long-running HTTP or websocket connection. And this protocol (along with the proprietary push notif aggregation services it…

> But what is your email client using for notifications? Local notifications? I don't see the problem here with email, it seems to work well that it is great for my use case. When you're offline with push notifications only the latest notification gets sent, not the previous notifications. This seems by design for notifications. At least with E-mail I can see a history of emails that was sent to me. I just see push n…

I don't know what you mean by local notifications, but if you get a notification when a mail arrives, it's most probably because your mail client uses Google or Apple's push service if you use a regular mobile device, or if you installed and configured microG.

And here's your issue: your app that has nothing to do with Google relies on a centralised Google service, and depends on a proprietary library that speaks to some proprietary code running on your device.

Alternatively, your app isn't doing this, but then it risks being unreliable and stop notifying you if the system kills your app because it's been inactive for some time to save battery, or to reclaim memory, and/or it uses more battery than it could.

This post is not about a way to have more notifications: it is an answer to these issues.

Re: Push Notifications for Decentralized Services

#27

Earlier quoted context omitted.

But what is your email client using for notifications? If it's using intermittent/timed fetch, that runs into the latency problem (taking longer to receive notifications). Push notifications exist to solve that problem. If it's using IMAP's IDLE, MAPI's push, or JMAP's push, that's just another long-running HTTP or websocket connection. And this protocol (along with the proprietary push notif aggregation services it…

> But what is your email client using for notifications? Local notifications? I don't see the problem here with email, it seems to work well that it is great for my use case. When you're offline with push notifications only the latest notification gets sent, not the previous notifications. This seems by design for notifications. At least with E-mail I can see a history of emails that was sent to me. I just see push n…

Push notifications work with any app. It is nicer to group notifications by app, and have app specific behavior. Emails add an extra step to get to the content in the app.

Gmail does push notifications. Otherwise, have to wait for the client to poll the server.

Re: Push Notifications for Decentralized Services

#28

Earlier quoted context omitted.

> But what is your email client using for notifications? Local notifications? I don't see the problem here with email, it seems to work well that it is great for my use case. When you're offline with push notifications only the latest notification gets sent, not the previous notifications. This seems by design for notifications. At least with E-mail I can see a history of emails that was sent to me. I just see push n…

Push notifications work with any app. It is nicer to group notifications by app, and have app specific behavior. Emails add an extra step to get to the content in the app. Gmail does push notifications. Otherwise, have to wait for the client to poll the server.

> Push notifications work with any app...

What if I don't want to use an app?

Email works with every email client that has been ever made.

It is already universal.

Re: Push Notifications for Decentralized Services

#29

Earlier quoted context omitted.

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?
Post reply on HN