mirror of
https://github.com/binwiederhier/ntfy.git
synced 2026-05-09 08:26:00 +02:00
[GH-ISSUE #159] Synchronize between devices #127
Labels
No labels
ai-generated
android-app
android-app
android-app
🪲 bug
build
build
dependencies
docs
enhancement
enhancement
🔥 HOT
in-progress 🏃
ios
prio:low
prio:low
pull-request
question
🔒 security
server
server
unified-push
web-app
website
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ntfy#127
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @alexzeitgeist on GitHub (Mar 12, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/159
Hi,
Like others I am looking for ways to replace Pushbullet. I've been using Pushbullet as a cross-platform tool to share links, infos, etc that need my attention at a later time. One feature I would like to see nfty to get is to have topic operations synchronize between devices. So for example, if I delete a notification in the web client, the Android client should delete that notification as well. And vice versa.
Cheers,
Alex
@binwiederhier commented on GitHub (Mar 12, 2022):
I like the idea. It all relies on #43 i think, or were you thinking synchronized settings as well. Because that would be much harder. That would imply that you have a user account and that you log in and all that.
@alexzeitgeist commented on GitHub (Mar 12, 2022):
Yes exactly, #43 would cover that. 👍
@arminus commented on GitHub (Apr 10, 2022):
IMHO, the delete propagation should be optional, there might be reasons to keep the message readable on other devices.
@binwiederhier commented on GitHub (Apr 10, 2022):
I think that could be an option in the clients. Enabled = delete messages remotely, disabled = only delete locally like today
@arminus commented on GitHub (Apr 10, 2022):
For me this would not be a client setting but message specific. e.g. you could add this as an option to the already existing delete confirmation dialog?
@binwiederhier commented on GitHub (Nov 24, 2022):
While this ticket was originally about synchronizing message contents, I have been sending people here to upvote for the "synchronize user accounts and topic subscriptions" to this ticket. So I think this is what it's about now.
@notDavid commented on GitHub (Nov 27, 2022):
I assume "notification dismissal sync" will still be implemented as well? (as the first comment describes...)
@binwiederhier commented on GitHub (Nov 28, 2022):
I think this ticket has become conflated, as I said, with the user account feature (+ subscription sync), and that is my fault. Because I've sent people here, it's not clear if those people want a user account sync and/or message deletion sync.
My guess is that people want the full package, just like in any other modern app: the web app looks the same as the Android app.
To achieve that, the "devices" need to have an identity, and the "client-only" nature (everything is stored in the client, like today) has to be changed to a "server-side account" for this feature. This is tricky, but ultimately necessary to implement a proper sync between devices. I don't think I want to get rid of the "client-only" approach, but for full account sync, it is required to invent a user account on the server.
One could do a cheap "message delete sync" without the settings or subscription sync, but I don't think that's what people want. I think it's part of it.
Sooo, long story short: I kinda think I need to split the tickets. I do think that the order of tickets should be:
I'll leave this for comments, and will eventually create tickets for this stuff.
@etfz commented on GitHub (Nov 28, 2022):
2 is what I was looking for, but I realise definitely 3, as well. 1 I guess is simply a prerequisite for the rest?
@arminus commented on GitHub (Nov 28, 2022):
Here's my main and original gripe in that area: I have a notification channel to which I subscribe from 3 devices, mobile, tablet, desktop. Since I don't carry around all 3 permanently ;-) it's pure chance which I pick up first and subsequently delete the notification there.
Now I have to delete the same notifications again on the other 2 devices - which is kind of annoying.
I'm not sure this is covered in the above 3 bullets...
Nevertheless, as always, keep up the good work, I highly appreciate it!
@etfz commented on GitHub (Nov 28, 2022):
I believe 3 (which is the original post) should cover exactly that.
@daedric7 commented on GitHub (Nov 28, 2022):
If i set ntfy.example.com as the default, could i still use ntfy.sample.com/justthistopic?
Meaning, can i have a account in ServerA, sync to ServerA, but still get notifications from ServerB? How will ServerB handle 3. ?
@nwithan8 commented on GitHub (Nov 28, 2022):
I would imagine each server I stance would have its own sync settings. I believe Bin mentioned something about each message having a unique ID; I would imagine the server GUID would be a part of that ID to differentiate it from a message from another server.
@daedric7 commented on GitHub (Nov 28, 2022):
So, we would access, auth and sync with ServerA, but still be able to access and auth with ServerB? And ServerA would keep the link, with user and pass to ServerB?
@arminus commented on GitHub (Nov 28, 2022):
Here's where things get confusing. "my" sync scenario/issue is with multiple clients/devices (as the title of this ticket also suggests), the latest discussion here is about multiple servers ?
2 separate aspects I think...?
@daedric7 commented on GitHub (Nov 28, 2022):
I believe it's one. I have 3 ntfy i use regularly.
I access the 3 of them, via multiple PCs and smartphones.
I assume the 1st/main server will have my "account", but it will also have to keep the settings for the other 2.
@wunter8 commented on GitHub (Nov 28, 2022):
I like the idea of synchronizing subscriptions and settings between devices. It could definitely be done using 1, 2, and 3 as described above. However, I think cmeis proposed an interesting "account-less" alternative:
Synchronization control messages will need to be sent to all devices in any case.
ntfydoes a great job already of sending messages from one device to any other device that is listening for the messages 😄 So instead of creating a special user account and auth saved in the server, why not subscribe to a special topic that handles all the sync control messages?@daedric7 commented on GitHub (Nov 28, 2022):
I like this line of thought. Simple yet efective.
@binwiederhier commented on GitHub (Nov 28, 2022):
Thank you all for jumping in and commenting. It looks like we all want the same thing, and that generally the 1+2+3 approach (what a great name 😄) is well-liked, though I also kinda love the approach that @cmeis suggested (via @wunter8's comment above). I like how it's reusing ntfy's core pubsub feature for the sync feature itself.
However, I must admit that I do have an ulterior motive for the "user account" feature itself, which is that (as I mentioned on Discord/Matrix) I'd like to offer a ntfy Pro version with increased rate limits and reserved topics and such. And for such a feature to work, we'll need a user account, too. (Don't get upset, ntfy with all its features will be 100% open source and self-hostable. I'll just host it for people that don't want to self-host and charge for it, I think.)
That said, even without my ulterior motive, @cmeis's idea (while clever) might get unwieldy if it transports the actual settings data. Think of scenarios such as "device offline for > 12h" or "sum of bytes for subscriptions+settings is greater than ntfy message size". I think using a secret topic for signalling ("hey, your account has been changed") is still a great idea. But I believe that not having an actual "give me all the settings + subscriptions for this user" API endpoint is not going to work.
@cmeis commented on GitHub (Nov 28, 2022):
Yep, as I wrote (on Discord I think) there will be edge cases where my idea will fail, like devices offline for too long. Probably - while I still like my own idea 😂 - it won't work here.
The signalling part could work, but there would have to be an active polling routine anyway if the client has been offline too long.
@don-dolarson commented on GitHub (Jun 19, 2023):
It's something I'd like to see too in future updates. A bit annoying to have to delete the same notification on all devices.
@arminus commented on GitHub (Jul 14, 2024):
Being one of the early adopters, this missing feature remains to be my only gripe. I have an alert topic to which I subscribe from my laptop and my mobile, depending on where I am I deleted something I've taken care of on that device. Back to the other device some time later, meeh... Granted, this is just annoying, but if messages heap up, you also have to remember which ones you actually took care of (e.g. while being away) and are garbage and which are still "hot" in a multi subscriber device environment.
@ForceConstant commented on GitHub (Sep 30, 2025):
I was thinking about this, and how to do message read/delete sync without an account, and was thinking it could work like this. Just like we send a message by publishing to a topic, you could send another anti-message to the same topic url, with the message id, that gets published to all subscribers that tells all the clients to mark that message-id as read, or deleted.
Also it would allow the client to be configured to send this reply message or not.
@Alloc86 commented on GitHub (Oct 26, 2025):
Probably the feature missing the most to me. I am trying to replace using a Telegram bot to notify me of all kinds of events - which meant I had the same state between all devices running my Telegram client on (currently seven devices) - including subscribed topics (i.e. chats) and most importantly read state of individual messages. It was not necessary to mark messages as read on each client individually, having to look at which might have actually been new or not.
For me it would be fine requiring user accounts on the server for this, as the private Ntfy instance is already set up for authenticated users only anyway. But I think there are some creative ideas above that would work too, like the special topics used with some kind of username to share events between devices.
Not sure how sharing subscribed topics would work in that case as a device might be added way after others so there would be no messages for that new device that lists the subscribed topics - maybe that could be solved by new devices asking for a list of subscriptions in that channel though that the other devices could send a reply to with all channels they are subscribed to.
@arminus commented on GitHub (Feb 1, 2026):
No that we have updating and deleting notifications which seems to be the the required basic function, is there any chance this issue gets tackled? i.e. put a "delete everywhere" button or option into notifications?
@binwiederhier commented on GitHub (Feb 1, 2026):
I actually yolo-implemented this with Cursor about a month ago, so yes, it's very high on the list, though to me the "notification sync" is different than the "topics and settings" sync. Highest priority would be the topics and settings.
Edit: I appear to have outlined this 3 years ago: https://github.com/binwiederhier/ntfy/issues/159#issuecomment-1328448159
More thoughts on the "how" or "what" would be welcome.
https://github.com/user-attachments/assets/210675d7-74f5-475b-9db8-b438788710df
@arminus commented on GitHub (Feb 1, 2026):
Maybe just to outline my usecase and gripe: I have an alert channel which I subscribe to from 3 different devices, depending on the time of the day etc. the "in front of my eyes" device changes. So I get an alert on my PC at 14:36, take care of it and delete it. As it is, the alert still "hangs" on my mobile and my iPad and at around 21:30 on the couch, I need to remember if I actually had resolved and thus cleared the alert from 14:36 just to have a clean slate.
Being able to delete optionally the alert for all devices would really be highly convenient, the options I see
I think I would prefer option 3
@binwiederhier commented on GitHub (Feb 1, 2026):
Your use case is "Synchronize notification actions (this ticket, i.e. delete notifications, etc.)" in https://github.com/binwiederhier/ntfy/issues/159#issuecomment-1328448159. There was some thought around this when developing the "updating/deleting" feature (see https://github.com/binwiederhier/ntfy/issues/303#issuecomment-3726747379).
The main issue in my book is that these user actions will now trigger remote actions, which will potentially cause rate limit issues. I also have been very diligent to not allow bulk actions that convert one action into multiple things (e.g. "clear all" causing 200 "message_clear" events). This has to be thought about/of.
For me, the first step (as shown in the video) would be to sync subscriptions across devices, though arguably the "sync deletes/read state across devices" feature is much easier to implement and adds more value, so I may pivot.
I think it's important to SEE the full picture before implementing parts of it.
@binwiederhier commented on GitHub (Feb 2, 2026):
For the record, https://github.com/binwiederhier/ntfy/issues/159#issuecomment-3831030142 is implemented in https://github.com/binwiederhier/ntfy-android/pull/157
@Petemir commented on GitHub (Feb 25, 2026):
Hello, thanks for the great app! Just recently started using/testing it. I was curious -- is it expected to implement this change also in ntfy-ios? Cheers!
@shadowjig commented on GitHub (Apr 20, 2026):
I'm confused on what this issue is and is not. I'd like my login to my self hosted ntfy server to pull all topics I've subscribed too. So for instance, if I use the browser and subscribe to topic "abc", I can to also have that happen on my Android client. That way if I get a new phone, I can just login and I see my topics.
I'd also like the delivery and dismissal of the notifications to also be synced between devices. I.e. if I dismiss on the Android client, it should be dismissed on the web app when I login.