-
-
Notifications
You must be signed in to change notification settings - Fork 892
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set up unified push messaging using the ntfy docker. Rework notifications. #2631
Comments
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. |
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. |
There is a library for UnifiedPush that can automatically fall back to FCM when UP is not available: https://unifiedpush.org/developers/embedded_fcm/ |
I think E2E with FCM is many times better than installing an extra app to get it working. Wouldn't it achieve the same? |
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. |
Web Push API would be an alternative solution to this. |
Were these concerns addressed? |
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. |
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). |
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. |
Hi, any updates on this? |
I am using Arctic client which supports Push notifications on iOS. A native push would be much better but at least it's something. |
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:
|
@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. |
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. |
That makes total sense, thank you for the context.
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.
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. |
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). |
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 |
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. |
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:
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 |
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. |
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. |
While I agree that is a way that should be focused on since the idea behind
Personally, I think if @Nutomic I'm active in that issue as well, but figured there was quite a bit of discussion here, so stuck with it. Implementing 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 |
Interesting new post here on push notifications for decentralized services: https://unifiedpush.org/news/20250131_push_for_decentralized/ Worth highlighting the end:
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:
p.s. gotosocial just added support for webpush: superseriousbusiness/gotosocial#3587 maybe a helpful reference for lemmy folks |
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.
The text was updated successfully, but these errors were encountered: