Set up unified push messaging using the ntfy docker. Rework notifications.

[dessalines]

This would be trivial to do, since we already send live messages over websockets.

Then mobile clients like Jerboa could subscribe to them.

https://docs.ntfy.sh/install/

https://f-droid.org/2022/12/18/unifiedpush.html

edit: also as part of this, I should rework notifications a bit.

• Not joining multiple rooms, let the back end handle that. Just a single websocket join based on your JWT.
• Add correlation ids add support for correlation ids to websocket messages #993

[Nutomic]

If i understand correctly, to make push notifications work with this unified push requires installing a separate application, and manually disabling battery optimizations for it. Some users who care about privacy a lot might do this, but the average user will find it much too complicated. So in practice we might have to support Googles push notification service as well.

But personally, I dont think that push notifactions are really necessary for Lemmy. If you open the app once a day, you will see notifications in time. Besides, we want to avoid functionality which gets users addicted, and push notifications are definitely one of them.

[dessalines]

You're correct, it does require installing an additional app, the ntfy one, definitely an annoyance.

At the same time tho, I kind of want to encourage using unified push as a long-term, less google-reliant solution to notifs. Google's FCM requires google play services, which a lot of android variants, as well as open source enthusiasts would rather not use. So we'd make notifications optional on both the server and client side.

Using FCM might also be a security concern, so we'd almost certainly want to e2ee encrypt the message content (not super difficult), to avoid letting google hoover up all the data. If we used a self-hosted NTFY ( or even the one offered ), we wouldn't have to do that work.

The mastodon android app has notifs, and I must say they are pretty useful, but they're using FCM.

[karmanyaahm]

There is a library for UnifiedPush that can automatically fall back to FCM when UP is not available: https://unifiedpush.org/developers/embedded_fcm/

[krestenlaust]

I think E2E with FCM is many times better than installing an extra app to get it working. Wouldn't it achieve the same?

[Stumblinbear]

I wouldn't underestimate how much battery usage would rise if you had to have a persistent connection. It would also be terrible for servers due to the 24/7 load it would put them under.

Additionally, almost more importantly, you must have proper push notifications for iOS since it does not allow backgrounded apps to stay alive indefinitely in any case.

[Nutomic]

Web Push API would be an alternative solution to this.

[uniquePWD]

I wouldn't underestimate how much battery usage would rise if you had to have a persistent connection. It would also be terrible for servers due to the 24/7 load it would put them under.

Additionally, almost more importantly, you must have proper push notifications for iOS since it does not allow backgrounded apps to stay alive indefinitely in any case.

Were these concerns addressed?

[dessalines]

I use ntfy every day, and its battery usage is <1%. If there are battery concerns, it'd have to be opened on their repo.

[karmanyaahm]

Since WebPush is a subset of UnifiedPush, implementing WebPush is a great way to solve this since then you get push on both the web, and on FOSS Android (using ntfy or other distributors).

[LazaroFilm]

Let's keep this ticket alive. This really needs to happen to keep Lemmy usable for most. The lack of a decent push notification system can be a deterrent for new users.

[BigPebble123]

Hi, any updates on this?

[LazaroFilm]

I am using Arctic client which supports Push notifications on iOS. A native push would be much better but at least it's something.

[Fmstrat]

My 2 cents here, dont use ntfy, pushbullet, pushover, or any other non-normalized system. You will rule out 90% of users if it's not standardized to the OS.

To me, a two-fold solution makes the most sense:

• Add an option for users, like the "Send notifications to email", but as "Send notification to webhook" with a URL. This means people can use whatever system they want to configure from above, including options like Matrix or.. Slack (ugh), or anything else that then has a native push notification.

  • Ideally, this would use a standard JSON layout of title/from/server/body (all elements of inbox) with an open text field and template you can use with things like %title to configure the POST body for the service.
  • If usage grows for any given service, this could be modified to use the brands mentioned above directly.
  • This will solve it for any techys following this issue, regardless of platform.

• Aftrr that, add a rate-limited notification API so that apps that wish to do this internally can have a worker check every N minutes (configurable) for notifications. While not push, it handles the multi-server credential issue that comes with many apps and many servers, and gives server operators a way to control the traffic if someone tries to abuse the endpoint.

[dessalines]

@seang96 please don't downthumb ppl on here, they took time to write that.

@Fmstrat We'll definitely keep email notifs as a part of this rework. I need to finish my work on #2444 before I start on this.

Webhooks might be possible, but it'd be alongside ntfy. It might also be difficult because we'd need to add a lot of custom fields per-user as to where they'd want these sent. The JSON serialization wouldn't be the tough part, and that definitely won't be customizeable whichever way we do it.

Webhooks aren't really made to be a mobile / OS notification system tho in the same way ntfy is.

Matrix also uses ntfy for its push notifs btw, in addition to google fcm. Its the best self-hostable cross-platform notification system that's also not tied to google, so I'm def going to stick with it.

[seang96]

It seemed like it was off topic trying to target official centralized solutions when the purpose of the fediverse and Lemmy is to be decentralized. I didn't mean any harm by it, I guess I should have commented with my thoughts, but I also didn't want to diverge into a conversation arguing the best options, and it also wasn't at a good time for me to write a full blown comment. That being said the webhook suggestion is a good universal suggestion.

[Fmstrat]

Webhooks might be possible, but it'd be alongside ntfy. It might also be difficult because we'd need to add a lot of custom fields per-user as to where they'd want these sent. The JSON serialization wouldn't be the tough part, and that definitely won't be customizeable whichever way we do it.

That makes total sense, thank you for the context.

Webhooks aren't really made to be a mobile / OS notification system tho in the same way ntfy is.

Certainly agree here, I just mean that most of these push systems support an API/web hook call to send a notification, giving users choice.

Matrix also uses ntfy for its push notifs btw, in addition to google fcm.

I had not realized this. My biggest issue with ntfy is the lack of e2e encryption: binwiederhier/ntfy#69

Many other providers have this, and it's the only reason I have a Matrix API call setup to send notifications to me that way.

So, I'll update my request to be: Please don't send the content in the notification for privacy reasons.

Unfortunately, I dont think this is possible unless Matrix figured out a way to do an post notification poll via SSL? With FCM they send a ping telling the app to grab the notification from the server. Or maybe I'm just misinterpreting the whole setup, if so, apologies for wasting time.

[dessalines]

This comment highlights that its probably not going to be too much of an issue for us, since we'll likely prefer a self-hosted ntfy alongside lemmy. Which means that sender -> NTFY will be local on the server, and NTFY -> receiver will be transport encrypted.

So the lemmy server is the only 3rd party who will know about those messages, and it already has everything unencrypted in its DB anyway, and we don't implement any E2EE even for private messages (I have a big warning in lemmy-ui to use matrix instead).

[seang96]

Ntfy is only one distributor that provides unified push notifications. There are other distributors that can be E2EE like conversations assuming the XMPP server supports it. Link to distributors

[BigPebble123]

My biggest issue with ntfy is the lack of e2e encryption

There is no need to literally include a message in the notification. Just send a blank notification to wake up the app. It's like saying “hey, you have work to do!”. The app then checks what it's about, retrieves the actual message content directly from the server and displays the notifications to the user. This is something Signal messenger does, using Google's centralized Firebase to deliver notifications.

By the way, I don't think this is needed, since on Lemmy all posts are public and unencrypted anyway. In this case, the owner of the ntfy server is the party that receives the notification content in plain text, but it could just as well do the same by accessing any instance of Lemmy that hasn't defederated with the instance where the user has an account.

[Fmstrat]

@BigPebble123

By the way, I don't think this is needed, since on Lemmy all posts are public and unencrypted anyway.

DMs are in the inbox, so they're in notifications as well. Also while content is public, accout-to-device ownership is not. What you describe for wake-up is what Matrix does for FCM and Ntfy, which I am an advocate for as well.

@dessalines I've installed a self-hosted Ntfy instance with Matrix so I could be a bit more educated in this discussion. Thank you for correcting my earlier thoughts.

Based on what I've seen, the process you're thinking is something like:

• Add Ntfy to docker-compose
• A "write-only" user in Ntfy used by Lemmy server to write notifications
• up* to be allowed read-only by "everyone"
• Lemmy API to return an up* topic for each user at login (static across all logins)

Do I have that right? If this is the case, my only remaining concern would be the enumeration of URLs would allow for viewing of other user's notification content. On small servers it would be near impossible to guess, but on large ones it could be easier.

Given that, using ntfy to send a wake-up blank-content notification that tells the app that it should poll the Lemmy API for content would make that mostly work well. Theoretically an attacker could learn a notification was sent, but not what the content was (like Matrix).

This same method would make the FCM fallback in the above mentioned library more palatable, too

[BigPebble123]

Do I have that right?

No. The lemmy instance should not have its own ntfy instance, rather each client (user) should be able to tell the server what URL to send notifications to.

For example, I am a user of aaa.tld instance and I have a server at my home with an ntfy instance at ntfy.myhomelab.tld. At this point, I give the Lemmy server the address of my instance along with the topic to which notifications should be sent to me.

My phone is constantly connected via websocket to my ntfy instance, so the ntfy mobile app will receive a notification and forward it to my Lemmy Client app when the Lemmy server decides to send a notification to my ntfy topic.

[Nutomic]

Notifications are one of the use cases described in my RFC for Lemmy plugins (work in progress). I believe its better to implement notification support in that way, which allows trying different approaches and avoids breaking changes to Lemmy.

[Fmstrat]

@BigPebble123

No. The lemmy instance should not have its own ntfy instance, rather each client (user) should be able to tell the server what URL to send notifications to.

While I agree that is a way that should be focused on since the idea behind ntfy is you use one server, and then there's one connection, this is not what @dessalines has laid out in previous responses that I was commenting on:

binwiederhier/ntfy#69 (comment) highlights that its probably not going to be too much of an issue for us, since we'll likely prefer a self-hosted ntfy alongside lemmy. Which means that sender -> NTFY will be local on the server, and NTFY -> receiver will be transport encrypted.

Personally, I think if ntfy is used, then ntfy.sh should be the default, with a user-configurable alternative, and a wake-up ping notification that tells the Lemmy App worker to grab the notification from the Lemmy server, as we've both described, and just as Matrix does.

@Nutomic I'm active in that issue as well, but figured there was quite a bit of discussion here, so stuck with it. Implementing ntfy as a plugin would be nice, however if it's not a default element of the system, it may confuse users and 3rd-party devs down the line. It's already difficult for the average user to understand federated server choice, and once features diverge between servers, especially core ones like notifications, it's going to be worse.

And divergence makes it tough on Mobile App developers, too. Let's take Thunder, for example (because I'm biased and I contribute there ;) ). If some servers use a ntfy plugin, others use an fcm plugin, and others use some other plugin, there may not be a standard in place for how Thunder should interact, meaning some systems/servers may get supported vs others. Then we get divergence of app features on top of server features on top of server choice.

[aeharding]

Interesting new post here on push notifications for decentralized services: https://unifiedpush.org/news/20250131_push_for_decentralized/

Worth highlighting the end:

This gives another reason to embrace the standards and implement webpush (and UnifiedPush) !

Mastodon 4.4 will follow the standard webpush specifications. JMAP is an email standard that support webpush, we can have an RFC to add webpush support to IMAP. A proposal to add webpush to Matrix specifications is opened.

We are looking for other decentralized, and centralized, services to support it too. Maybe we’ll lose these gateways one day.

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

Regarding webpush for iOS apps: While you can't truly support webpush directly (yet), you can fairly easily set up a web push relay. This is how Mastodon does it: https://github.com/mastodon/webpush-apn-relay

---

So, in summary, with webpush:

• Web apps: Push notifications out-of-the-box, which is great for desktop devices and those that don't want to use an app
• Google Play Android: Truly decentralized Android (Play Store) push notifications - the app can configure webpush so the lemmy instance directly pushes to FCM
• Fdroid/FOSS Android: Of course, truly decentralized degoogled Android push notifications via either ntfy.sh, lemmy-instance-hosted ntfy, or power user's own ntfy server even!
• iOS: webpush->APN relay for iOS push notifications

p.s. gotosocial just added support for webpush: superseriousbusiness/gotosocial#3587 maybe a helpful reference for lemmy folks

[mdecourcy]

Note for when this does get worked on and out to mainstream, ntfy app isn't actively maintained and is out of spec and is missing raise_to_foreground permissions for subscribed apps, meaning battery optimization needs to be off on the target app for the app wake to fetch notifications.

Might be better to recommend sunup which utilizes mozilla's autopush-rs.

Note that the user in the above ntfy PR that has been sitting since November 2024 appears to be a maintainer for the unified push spec, and may be able to help guide your implementation for android/iOS users