starred/ntfy

Fork 0

mirror of https://github.com/binwiederhier/ntfy.git synced 2026-05-09 08:26:00 +02:00

[GH-ISSUE #58] Publish message on new subscriptions #50

New issue

Closed

opened 2026-05-07 00:19:09 +02:00 by BreizhHardware · 8 comments

BreizhHardware commented

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

Owner

Originally created by @arjan-s on GitHub (Dec 15, 2021).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/58

I'd like to receive a ping on my devices when a new device/browser subscribes to a topic. Ideally this would be configurable per topic.

Btw: awesome tool you have created!

Originally created by @arjan-s on GitHub (Dec 15, 2021). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/58 I'd like to receive a ping on my devices when a new device/browser subscribes to a topic. Ideally this would be configurable per topic. Btw: awesome tool you have created!

BreizhHardware

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

closed this issue
added the
enhancement
label

BreizhHardware commented

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

Author

Owner

@binwiederhier commented on GitHub (Dec 15, 2021):

@arjan-s I think that should be achievable. I have an idea for a design, though I'm not sure if it is what you want.

Can you elaborate on your reasoning? Is this just about the fact that a topic is unprotected and that you want to protect it? If so, maybe auth is the better solution for that (#19).

If it is indeed about knowing when people subscribe/unsubscribe, I could see this working: Basically, when you subscribe to a topic, you pick what events you're interested in. By default, it's open,keepalive,message, and you can either specify a comma-separated list (e.g. message,subscribe) or you can add/remove events from the default list (e.g. +subscribe,+unsubscribe translates to open,keepalive,message,subscribe,unsubscribe):

$ curl "ntfy.sh/mytopic/json?events=+subscribe,+unsubscribe,+poll"
{"id":"...","event":"open"}
{"id":"...","event":"poll"}
{"id":"...","event":"subscribe"}
{"id":"...","event":"unsubscribe"}

@binwiederhier commented on GitHub (Dec 15, 2021): @arjan-s I think that should be achievable. I have an idea for a design, though I'm not sure if it is what you want. Can you elaborate on your reasoning? Is this just about the fact that a topic is unprotected and that you want to protect it? If so, maybe auth is the better solution for that (#19). If it is indeed about knowing when people subscribe/unsubscribe, I could see this working: Basically, when you subscribe to a topic, you pick what events you're interested in. By default, it's `open,keepalive,message`, and you can either specify a comma-separated list (e.g. `message,subscribe`) or you can add/remove events from the default list (e.g. `+subscribe,+unsubscribe` translates to `open,keepalive,message,subscribe,unsubscribe`): ``` $ curl "ntfy.sh/mytopic/json?events=+subscribe,+unsubscribe,+poll" {"id":"...","event":"open"} {"id":"...","event":"poll"} {"id":"...","event":"subscribe"} {"id":"...","event":"unsubscribe"} ```

BreizhHardware commented

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

Author

Owner

@arjan-s commented on GitHub (Dec 15, 2021):

Thanks for your quick answer! Yes, my reasoning is mainly that everything is unprotected and unencrypted right now, so I'd like to know when someone subscribes to a topic. But (disregarding implementation complexity for now) what I would really want is auth and e2e encryption. :)

@arjan-s commented on GitHub (Dec 15, 2021): Thanks for your quick answer! Yes, my reasoning is mainly that everything is unprotected and unencrypted right now, so I'd like to know when someone subscribes to a topic. But (disregarding implementation complexity for now) what I would really want is auth and e2e encryption. :)

BreizhHardware commented

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

Author

Owner

@arjan-s commented on GitHub (Dec 15, 2021):

Anyway, your design idea sounds very usable! And probably a lot easier to implement than auth and encryption.

@arjan-s commented on GitHub (Dec 15, 2021): Anyway, your design idea sounds very usable! And probably a lot easier to implement than auth and encryption.

BreizhHardware commented

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

Author

Owner

@binwiederhier commented on GitHub (Dec 15, 2021):

Yes, my reasoning is mainly that everything is unprotected and unencrypted right now

So I've had a number of conversations about this, and it's funny how people feel about this. I bet if the design was curl ntfy.sh/mytopic/json?token=this-is-a-long-secret-string, then people would be perfectly fine with it, but somehow doing curl ntfy.sh/this-is-a-long-secret-string/json doesn't seem secure to people.

I think I will have to address it in the auth ticket somehow, but for what it's worth, just choosing a long topic is equally secure. You obviously won't get end-to-end encryption (something that is hard to implement if your client is curl), but it's pretty good nonetheless.

That said, I think this ticket in particular is pretty low on my list, given that your actual intentions are auth, and I feel like the benefits are marginal anyway.

@binwiederhier commented on GitHub (Dec 15, 2021): > Yes, my reasoning is mainly that everything is unprotected and unencrypted right now So I've had a number of conversations about this, and it's funny how people feel about this. I bet if the design was `curl ntfy.sh/mytopic/json?token=this-is-a-long-secret-string`, then people would be perfectly fine with it, but somehow doing `curl ntfy.sh/this-is-a-long-secret-string/json` doesn't seem secure to people. I think I will have to address it in the auth ticket somehow, but for what it's worth, just choosing a long topic is equally secure. You obviously won't get end-to-end encryption (something that is hard to implement if your client is curl), but it's pretty good nonetheless. That said, I think this ticket in particular is pretty low on my list, given that your actual intentions are auth, and I feel like the benefits are marginal anyway.

BreizhHardware commented

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

Author

Owner

@arjan-s commented on GitHub (Dec 15, 2021):

I definitely understand your reasoning. However, making the topic long and secret isn't very good for usability. Short descriptive topics are better in that regard, not in the least because the topic name is used in Android notification titles (which are also used by smartwatches/wearables).

@arjan-s commented on GitHub (Dec 15, 2021): I definitely understand your reasoning. However, making the topic long and secret isn't very good for usability. Short descriptive topics are better in that regard, not in the least because the topic name is used in Android notification titles (which are also used by smartwatches/wearables).

BreizhHardware commented

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

Author

Owner

@binwiederhier commented on GitHub (Dec 15, 2021):

topic long and secret isn't very good for usability

I agree. I'll address this in the auth ticket (#19). IIRC there is a suggestion in there already, but I have some other thoughts. Feel free to comment there as well if you have more thoughts.

@binwiederhier commented on GitHub (Dec 15, 2021): > topic long and secret isn't very good for usability I agree. I'll address this in the auth ticket (#19). IIRC there is a suggestion in there already, but I have some other thoughts. Feel free to comment there as well if you have more thoughts.

BreizhHardware commented

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

Author

Owner

@arjan-s commented on GitHub (Dec 15, 2021):

Thanks, I've subscribed to that issue as well. Shall I close this one?

@arjan-s commented on GitHub (Dec 15, 2021): Thanks, I've subscribed to that issue as well. Shall I close this one?

BreizhHardware commented

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

Author

Owner

@binwiederhier commented on GitHub (Dec 15, 2021):