[GH-ISSUE #81] UnifiedPush Linux distributor #64

New issue

Closed

opened 2026-05-07 00:19:28 +02:00 by BreizhHardware · 5 comments

BreizhHardware commented

2026-05-07 00:19:28 +02:00

Owner

Originally created by @binwiederhier on GitHub (Jan 2, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/81

See #75

Originally created by @binwiederhier on GitHub (Jan 2, 2022). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/81 See #75

BreizhHardware

2026-05-07 00:19:28 +02:00

closed this issue
added the
enhancement

server
labels

BreizhHardware commented

2026-05-07 00:19:28 +02:00

Author

Owner

@binwiederhier commented on GitHub (Jan 2, 2022):

@karmanyaahm I briefly looked at the code and I have a few issues with it; not because of style or anything, but because I think you're doing the legwork for stuff that the CLI should provide.

Persistence: For instance, you are implementing persistence for connections, and you're doing all of that in the cmd package. IMHO this should probably live in the client package. Just like the Android implementation, this should handle persistence of topics and messages, which would make deduping trivial. It is admirable that you did this stuff, but I think it should live in a different place, and also without an ORM. 😬 If you like, we can discuss designs and you can work on it; or I can do it eventually (may take longer, obviously).
Side note "deduping": I had planned to implement ?since=<messageID>, but I never got around to doing that. That should greatly simplify deduping without having to store all message IDs
Dynamic topics vs config file: Right now the ntfy subscribe command is purely an "edit config file and restart" kinda thing as opposed to "here's an API to dynamically
Magical "unifiedpush" command: I'm not sure if I like this, Does this not feel like a hack to you? I don't have a better way though.
General use case: Excuse my ignorance, but I'm struggling with the general use case a little: You made a distributor struct with public methods, but I don't see Register() and Unregister() being used anywhere. Is there something missing? Will other applications be able to use the distributor via dbus?
General use case (follow up): Wouldn't it be better for apps to just use the ntfy Client to subscribe to messages directly instead of the indirection via the distributor and such? With Android I see the reasoning with battery savings due to a shared connection, but for a normal Linux system, I am struggling a little with why this is necessary at all.

@binwiederhier commented on GitHub (Jan 2, 2022): @karmanyaahm I briefly looked at the code and I have a few issues with it; not because of style or anything, but because I think you're doing the legwork for stuff that the CLI should provide. 1. Persistence: For instance, you are implementing persistence for connections, and you're doing all of that in the `cmd` package. IMHO this should probably live in the `client` package. Just like the Android implementation, this should handle persistence of topics _and_ messages, which would make deduping trivial. It is admirable that you did this stuff, but I think it should live in a different place, and also without an ORM. :grimacing: If you like, we can discuss designs and you can work on it; or I can do it eventually (may take longer, obviously). 2. Side note "deduping": I had planned to implement `?since=<messageID>`, but I never got around to doing that. That should greatly simplify deduping without having to store all message IDs 3. Dynamic topics vs config file: Right now the `ntfy subscribe` command is purely an "edit config file and restart" kinda thing as opposed to "here's an API to dynamically 4. Magical "unifiedpush" command: I'm not sure if I like this, Does this not feel like a hack to you? I don't have a better way though. 5. General use case: Excuse my ignorance, but I'm struggling with the general use case a little: You made a `distributor` struct with public methods, but I don't see `Register()` and `Unregister()` being used anywhere. Is there something missing? Will other applications be able to use the distributor via dbus? 6. General use case (follow up): Wouldn't it be better for apps to just use the ntfy `Client` to subscribe to messages directly instead of the indirection via the distributor and such? With Android I see the reasoning with battery savings due to a shared connection, but for a normal Linux system, I am struggling a little with why this is necessary at all.

BreizhHardware commented

2026-05-07 00:19:29 +02:00

Author

Owner

@karmanyaahm commented on GitHub (Jan 3, 2022):

I can rewrite it in raw SQL. Is it fine if this is an external library (like unifiedpush.org/go/database-something), since then all the other UP distributors that have mostly the same basics can also benefit from it? If not, I'll move the db stuff to client or a client/db
I'll implement 1. which should solve deduping
That's true, but it's kinda required for UP. Though if you'd like me to do it another specific way, I can do that.
Maybe calling it --enable-unifiedpush or --distributor or --distribute could be better? I didn't really put much thought into the naming of the options originally; I just picked --unifiedpush because it was simple
The distributor struct is passed to a library which exposes those methods onto dbus and handles some boilerplate around dbus and error handling [1]. This lets other apps register over dbus using the UnifiedPush dbus spec [2]
The goal is for this to be used on Linux phones. It's meant to be an analog for the Android spec but on Linux.

[1] https://github.com/NoProvider2Push/dbus/blob/main/distributor/distributor.go
[2] https://unifiedpush.org/spec/dbus/

@karmanyaahm commented on GitHub (Jan 3, 2022): 1. I can rewrite it in raw SQL. Is it fine if this is an external library (like unifiedpush.org/go/database-something), since then all the other UP distributors that have mostly the same basics can also benefit from it? If not, I'll move the db stuff to `client` or a `client/db` 2. I'll implement 1. which should solve deduping 3. That's true, but it's kinda required for UP. Though if you'd like me to do it another specific way, I can do that. 4. Maybe calling it `--enable-unifiedpush` or `--distributor` or `--distribute` could be better? I didn't really put much thought into the naming of the options originally; I just picked `--unifiedpush` because it was simple 5. The distributor struct is passed to a library which exposes those methods onto dbus and handles some boilerplate around dbus and error handling [1]. This lets other apps register over dbus using the UnifiedPush dbus spec [2] 6. The goal is for this to be used on Linux phones. It's meant to be an analog for the Android spec but on Linux. [1] https://github.com/NoProvider2Push/dbus/blob/main/distributor/distributor.go [2] https://unifiedpush.org/spec/dbus/

BreizhHardware commented

2026-05-07 00:19:29 +02:00

Author

Owner

@karmanyaahm commented on GitHub (Jan 13, 2022):

Just want to let you know I've been really busy the past few weeks, but I'll get back to this soon.

@karmanyaahm commented on GitHub (Jan 13, 2022): Just want to let you know I've been really busy the past few weeks, but I'll get back to this soon.

BreizhHardware commented

2026-05-07 00:19:29 +02:00

Author

Owner

@binwiederhier commented on GitHub (Jun 3, 2022):

@karmanyaahm Shall we close this and re-open when you get to it?

@binwiederhier commented on GitHub (Jun 3, 2022): @karmanyaahm Shall we close this and re-open when you get to it?

BreizhHardware commented

2026-05-07 00:19:29 +02:00

Author

Owner

@karmanyaahm commented on GitHub (Jun 3, 2022):