Back

Push Notifications for Decentralized Services

164 points11 daysunifiedpush.org
orblivion8 days 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.

kirimita7 days 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

ryukafalz8 days 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!

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

EGreg8 days ago

What would you say the main points are for sandstorm?

Is it about hosting apps on different domains and using a powerbox between them? Or is it something more? Why does sandstorm use capnproto for instance?

In our framework for instance, instead of capabilities, we implemented "invites", which people can send to each other. If an invite grants you readLevel access to a document, you'll be able to see it even before you log in and create a user account. But if you want to get the full access to write etc, you'll have to create a user account and accept the invite as that user.

https://github.com/Qbix/Streams/blob/main/classes/Streams/St...

ocdtrekkie8 days ago

Well, first and foremost, Sandstorm uses Cap'n Proto because Cap'n Proto was built, first and foremost, to enable Sandstorm. :) Though of course, now it also powers Cloudflare Workers and a bunch of other things.

My favorite explainer on the object capability model is... the first half of this exceptionally long page: http://habitatchronicles.com/2017/05/what-are-capabilities/ It's worth the read, but read it when you have time to sit down.

So access to apps or documents by users, as well as those apps and documents being able to reach out to other resources, is all generally wrapped in capabilities.

I think as a self-hosting platform, the biggest advantages of Sandstorm is that we force developers to provide a no-config-file, no-sysadmin-required experience, so Sandstorm is probably the only self-hosting platform currently intended to be used by people who are not tech people. This naturally flows into some other things: If you don't have a sysadmin running it, it needs to be really secure (capabilities) and very good at self-managing it's own performance.

So Sandstorm apps do not consume any resources unless you are accessing them. Everything is spun up and closed down on demand. And the platform's security model not only means vulnerabilities in apps mostly aren't exploitable and apps don't need to be patched, but Sandstorm strives to safely allow non-technical users to install and run potentially even malicious apps without risk.

ferfumarma8 days ago

I'm your example it sounds like invites are a form of capability based security, which is what sandstorm uses.

I'm not an expert, but my understanding is that sandstorm takes all of the system calls from your apps, and uses capn proto to serialize those calls to the powerbox. The powerbox then checks to see if that operation is allowed for that user, and if so it executes the call, and serializes it back to the app (which then displays it to the user, for example).

Sandstorm uses CapnP because it's technically sound, battle tested, and efficient.

You could just make http requests back and forth (that's kinda if the default for web apps) but there is latency overhead and way more surface area with http.

nicoco8 days 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).

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

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

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

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

mjl-8 days 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)?

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

pull_my_finger8 days 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?

kirimita7 days 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

stefanha8 days 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?

kirimita7 days 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...)

stefanha7 days 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?

alberth8 days ago

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

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

kragen8 days ago

This is great news and very timely!

EGreg8 days ago

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

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

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

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

jraph8 days ago

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

orblivion8 days ago

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

What is a "push notification" exactly?

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

orblivion8 days ago

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.

+1
YarickR28 days ago
colesantiago8 days 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.

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

toast08 days 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?

jacoblambda8 days ago

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.

rcMgD2BwE72F7 days ago

>I don't quite understand how adding a different service help

I simply don't like having two monopolies (Google and Apple) handling every single push notification for all mobile users everywhere on Earth – except in China, maybe.

There's so much you privacy risks and they can easily infer many things from the meta data alone.

I thought we were in the post-Snowden phase already.

colesantiago8 days ago

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

jacoblambda8 days ago

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.

+3
colesantiago8 days ago
crtasm8 days 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.