[HN Gopher] Push Notifications for Decentralized Services
___________________________________________________________________
Push Notifications for Decentralized Services
Author : notmine1337
Score : 116 points
Date : 2025-02-01 09:33 UTC (3 days ago)
(HTM) web link (unifiedpush.org)
(TXT) w3m dump (unifiedpush.org)
| orblivion wrote:
| 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 wrote:
| > 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!
| orblivion wrote:
| 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.
| EGreg wrote:
| 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 it
| use capnproto etc
| dboreham wrote:
| 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.
| jraph wrote:
| Is this true even with some deep integration of UnifiedPush
| with something like microG?
| orblivion wrote:
| > There's no decentralized way to get a push notification onto
| a Google/Android phone
|
| What is a "push notification" exactly?
| freeone3000 wrote:
| 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.
| orblivion wrote:
| 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.
| YarickR2 wrote:
| 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.
| orblivion wrote:
| 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? Does it get special signals from cell towers
| that most apps don't have access to?
| jacoblambda wrote:
| ? 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.
| jraph wrote:
| 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- wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| colesantiago wrote:
| 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.
| jacoblambda wrote:
| 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.
| colesantiago wrote:
| I receive content from E-mail all the time and I am also
| notified about it and it doesn't drain my battery.
| jacoblambda wrote:
| 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.
| colesantiago wrote:
| > 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.
| jraph wrote:
| 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.
| ianburrell wrote:
| 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.
| colesantiago wrote:
| > 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.
| toast0 wrote:
| > 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?
| jacoblambda wrote:
| 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.
| nicoco wrote:
| 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).
| EGreg wrote:
| Yeah but how does it work with iOS? I thought Apple has APNS and
| that's it!
___________________________________________________________________
(page generated 2025-02-04 23:00 UTC)