Live data from Hacker News

Push Notifications for Decentralized Services

unifiedpush.org

11–20 of 54 posts

Re: Push Notifications for Decentralized Services

#11

Earlier quoted context omitted.

> 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.

Re: Push Notifications for Decentralized Services

#13
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.

Re: Push Notifications for Decentralized Services

#14

I was surprised how easy it was to integrate. I'm on GrapheneOS/FDroid. I installed the ntfy app and connected it to my ntfy server. I wanted to set it up for Tusky (Mastodon app). I was confused about the lack of instructions. What do I set on Tusky? What do I set on all my Mastodon servers? It turned out there were no instructions. I was already configured for Tusky. Tusky found the ntfy app, got my ntfy server's U…

> BTW I'm working on porting ntfy to Sandstorm. Oh this would be really handy, I'd love to run it on my Sandstorm server!

Awesome.

One major caveat is that because of Sandstorm's draconian security (I mean this in a good way), a handful of ntfy's features won't work because they use special headers. Mastodon works so I'm assuming they use the json API. One of my tasks is to go through major services and test them.

Another one is protected topics. "Users" use auth headers (there's a GET string option, but the Android app source code indicates that it opts for headers). Sandstorm does give you the benefit of randomized API URLs that you can revoke, which protects you from random actors, but any service (Mastodon, Matrix, etc) you connect to will need to see that URL so they may in principle snoop on easy-to-guess topics.

If you're curious you can see my tangled mess of notes: https://github.com/orblivion/ntfy/blob/sandstorm/.sandstorm/... Don't get too invested in understanding it if it's confusing, it's a fucking mess.

Re: Push Notifications for Decentralized Services

#15
post #3

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.

? 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.

Re: Push Notifications for Decentralized Services

#16

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, independent, privacy preserving option for users and app developers.

Neither RSS nor email solve this problem and actually this specific service would be the exact type of service you'd use to notify the user's device that the apps that use RSS or email have new content to fetch.

Re: Push Notifications for Decentralized Services

#17

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…

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

Re: Push Notifications for Decentralized Services

#19

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…

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 is aiming to replace) exists to deduplicate those many long-running connections into a single connection out to some hardwired server that manages the many services/connections for it.

Re: Push Notifications for Decentralized Services

#20

Earlier quoted context omitted.

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