ntfy
ntfy copied to clipboard
binwiederhier
Synchronize between devices
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
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.
IMHO, the delete propagation should be optional, there might be reasons to keep the message readable on other devices.
I think that could be an option in the clients. Enabled = delete messages remotely, disabled = only delete locally like today
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?
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.
I assume "notification dismissal sync" will still be implemented as well? (as the first comment describes...)
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:
- Server-side user account, with registration + login (in web app + Android)
- Synchronize subscriptions (+ settings, to an extent)
- Synchronize notification actions (this ticket, i.e. delete notifications, etc.)
I'll leave this for comments, and will eventually create tickets for this stuff.
2 is what I was looking for, but I realise definitely 3, as well. 1 I guess is simply a prerequisite for the rest?
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!
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. ?
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. ?
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.
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. ?
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.
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?
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...?
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.
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:
Regarding the settings sync between devices - how about something like this: You choose an email address plus password. A topic name is generated as sync-<whateverhashalgorithm(email + password)>. Settings on device are encrypted with the password. And the device subscribes to the same topic. Every change in config triggers a publish of encrypted settings, which is read and applied by the subscribed clients.
Synchronization control messages will need to be sent to all devices in any case. ntfy does 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?
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:
Regarding the settings sync between devices - how about something like this: You choose an email address plus password. A topic name is generated as sync-<whateverhashalgorithm(email + password)>. Settings on device are encrypted with the password. And the device subscribes to the same topic. Every change in config triggers a publish of encrypted settings, which is read and applied by the subscribed clients.
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?
I like this line of thought. Simple yet efective.
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 :smile:) 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.
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.
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.
