Push Notifications for Decentralized Services

https://unifiedpush.org/news/20250131_push_for_decentralized/

by notmine1337 • 1 year ago

164 52 1 year ago

orblivion6• 1 year ago

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 URL from it, and passed it on to the Mastodon servers.

Now, I actually think this is a little too easy. What if I want to keep my ntfy server private for certain at-home uses? But still, very impressive. Element does it right, it at least asks you when you open the app (or it's in a setting or something). But I think UnifiedPush or ntfy instructions should make these steps more clear (or I failed to find it), even if just to say "it's actually that easy" to save our time looking.

BTW I'm working on porting ntfy to Sandstorm. Already works, I just have a handful of loose ends.

ryukafalz• 1 year ago

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!

orblivion6• 1 year ago

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.

kirimita3• 1 year ago

But I think UnifiedPush or ntfy instructions should make these steps more clear (or I failed to find it), even if just to say "it's actually that easy" to save our time looking.

We are working on the documentation: https://codeberg.org/UnifiedPush/documentation/pulls/16

dboreham• 1 year ago

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.

jraph5• 1 year ago

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

orblivion6• 1 year ago

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

What is a "push notification" exactly?

freeone30002• 1 year ago

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.

CuriousCosmic5• 1 year ago

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

jraph5• 1 year ago

If this encourages more open source applications to use standards and an open source library for push notification,that's quite cool. Extra bonus if it allows users not to rely on Google server.

mjl-• 1 year ago

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 application server to talk to the provider, hence decentralized (good!). The platform/provider behind the push url makes the notification appear at the device. It is quite a complicated way to get a message from server to device...

The post says it is about Android. But I'm online searches turns up documents about VAPID at apple/ios. Will it work there too? What about other platforms (eg non-google android-likes)?

cyberax• 1 year ago

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

ahmedfromtunis• 1 year ago

Push notifications are a powerful concept, but I feel like their potential has been stifled by Google's and Apple's near-total control over them on their respective OSes.

And while I'm not fun of heavy-handed government intervention, I hope the EU compels both companies to adopt a more open approach; provided that security remains uncompromised.

methuselah_in• 1 year ago

There is no too much talk started happening around this. Google will soon I guess going to cut off this like Apple in the be name of battery saving.

colesantiago6• 1 year ago

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.

CuriousCosmic5• 1 year ago

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.

colesantiago6• 1 year ago

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

toast0• 1 year ago

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?

crtasm2• 1 year ago

I would like all my push notifications to not rely on Google so this seems good to me.

Signal sending me an email to tell me I have a new message would be a bad system.

nicoco• 1 year ago

It's worth noting that there are self-hostable XMPP-based implementations for this: https://unifiedpush.org/users/distributors/conversations/

What is old is new again (Google used XMPP for Android Push Notifications before they switched to something else).

EGreg2• 1 year ago

Yeah but how does it work with iOS? I thought Apple has APNS and that's it!

pvo50555• 1 year ago

Regarding iOS, they have made some progress in adopting webpush, but it does not seem possible to push for mobile applications with it yet.

This is a key point right at the very end. It has always been much easier to implement push notifications to Android devices, even when only Web Push is implemented. Google has been the main force behind the adoption of PWAs as Native apps on devices, even by immediately showing a "Install this app?" popup when navigating to a PWA-enabled website/web app.

iOS permits "Installing to home screen" but there is no popup shown natively, nor any indication from the OS that the website you're visiting is a PWA. The user has to go through several steps to add the app to his device.

Once it is added, it's possible for the device to receive web push notifications and show them as native push notifications (IIRC), even with the app is closed, however the reliability is inconsistent. Sometimes you get them, sometimes you don't. At least that was my experience still about 6 months ago when I tried implementing web push with PWA for iOS.

I gave up trying to go the pure PWA route and instead wrapped my web app with PWABuilder into a native app, and went through the whole process of submitting to the App Store, getting APN, registering the web app in Firebase, then sending the push notifications to the native app via Firebase Messaging. Works great then, but it's a lot more work than keeping everything simply as a web app and using web push.

wruza• 1 year ago

https://news.ycombinator.com/item?id=38430581

Web push is basically useless because Google hasn't prioritized fixing the issues causing Android to delay the notifications by 10 minutes or more. They are basically only useful for "re-engagement" spam, nothing time critical.

pull_my_finger• 1 year ago

So would I be correct to say the distributor is a a 3rd party "satellite" app, that your app pulls from and the notification server pushes to? So end users would need to install this distributor app in addition to your own app?

kirimita3• 1 year ago

That's already how it works, the 3rd app is usually the Google services. The setup described on the blog post allows user to use the Google services OR another service

kragen• 1 year ago

This is great news and very timely!

stefanha2• 1 year ago

In this direct to FCM model, does the application running on the untrusted user's device need to embed any sensitive credentials?

What prevents someone else from impersonating my app or other users on my app?

kirimita3• 1 year ago

If you are interested, you can read the specifications: https://unifiedpush.org/developers/spec/android/. The same question actually exists for firebase-messaging (Google) too (answer here: https://github.com/firebase/firebase-android-sdk/blob/cf5fe2...)

stefanha2• 1 year ago

I'm not familiar with this stuff and don't have time to fully read the specs plus the required background reading. Here is my guess based on skimming the spec:

The application may embed the VAPID public key while the VAPID private key is kept secret by the app developer. That way only the app developer can send valid push notifications. This approach doesn't work when the app running on an untrusted device sends push notifications directly though?

I guess the trick is for the app to treat the push notification purely as a hint to go fetch the latest state from the app server. Do not trust anything in the push notification message. Then it doesn't matter whether the messages are spoofed.

You linked to some Android Intents code in the firebase-message code. I guess that is related to preventing Intent spoofing, but I'm not sure?

alberth• 1 year ago

OT: anyone have experience with pushover.net, if so - how is it?

rolobio• 1 year ago

I have Pushover. I love it. I have a bash alias that I use to notify me when some command completes. I get a notification on my phone, and a tap on my wrist letting me know some hours long task is complete, and I can do the next step.

I have a Octoprint integration which lets me know when 3d prints have completed.

You can also modify the priority of a message, so I can send "critical" events if I need to, although I use that rarely.

Push Notifications for Decentralized Services

Related Stories