[GH-ISSUE #486] Support thread identifiers #371

New issue

Closed

opened 2026-05-07 00:23:35 +02:00 by BreizhHardware · 4 comments

BreizhHardware commented

2026-05-07 00:23:35 +02:00

Owner

Originally created by @nicois on GitHub (Nov 10, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/486

In some situations, a message should supersede some previous messages. This is helpful when the notification describes a state, rather than an event - for example, the current temperature, or battery level of a device, etc.

If a message includes a particular header, any subscribed clients should automatically dismiss previous notifications sharing the same identifier.

Originally created by @nicois on GitHub (Nov 10, 2022). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/486 In some situations, a message should supersede some previous messages. This is helpful when the notification describes a state, rather than an event - for example, the current temperature, or battery level of a device, etc. If a message includes a particular header, any subscribed clients should automatically dismiss previous notifications sharing the same identifier.

BreizhHardware closed this issue

2026-05-07 00:23:35 +02:00

BreizhHardware commented

2026-05-07 00:23:36 +02:00

Author

Owner

@binwiederhier commented on GitHub (Nov 11, 2022):

This is related to (if not duplicate) of #303 (with #187 + #43), while obviously your idea of a Thread-ID or Group-ID is different. I'd much rather use Tags for this purpose, and I vaguely remember that I even implemented it as part of #303 when I dabbled with that.

So for now I'll assume this is a duplicate and close this ticket. Feel free to comment on the other one with your thread ID idea.

@binwiederhier commented on GitHub (Nov 11, 2022): This is related to (if not duplicate) of #303 (with #187 + #43), while obviously your idea of a `Thread-ID` or `Group-ID` is different. I'd much rather use `Tags` for this purpose, and I vaguely remember that I even implemented it as part of #303 when I dabbled with that. So for now I'll assume this is a duplicate and close this ticket. Feel free to comment on the other one with your thread ID idea.

BreizhHardware commented

2026-05-07 00:23:36 +02:00

Author

Owner

@leandroribeir0 commented on GitHub (Nov 11, 2022):

So if I pass an tag, messages with same tag will be grouped?

@leandroribeir0 commented on GitHub (Nov 11, 2022): So if I pass an tag, messages with same tag will be grouped?

BreizhHardware commented

2026-05-07 00:23:36 +02:00

Author

Owner

@binwiederhier commented on GitHub (Nov 11, 2022):

Nope. None of this is implemented. I couldn't find an API that I liked. I mainly wanted notifications to be updatable and deletable. There were many ideas of how to do that, but none that I found good enough. One idea is to update everything with the same tag.

I never meant for this to be a grouping mechanism, more so to update existing notifications with new content (think progress bar, battery status, download progress, ...)

@binwiederhier commented on GitHub (Nov 11, 2022): Nope. None of this is implemented. I couldn't find an API that I liked. I mainly wanted notifications to be updatable and deletable. There were many ideas of how to do that, but none that I found good enough. One idea is to update everything with the same tag. I never meant for this to be a grouping mechanism, more so to update existing notifications with new content (think progress bar, battery status, download progress, ...)

BreizhHardware commented

2026-05-07 00:23:36 +02:00

Author

Owner

@nicois commented on GitHub (Nov 13, 2022):

That was how I envisaged it: if a notification had been assigned a certain value for the thread-group tag, subsequent notifications with the same tag value would dismiss or delete previous ones, as they could safely be considered obsolete.

This doesn't really require any changes on the server, beyond documentation; it's only each client which would need a small change when the message is received. I looked at the Android code and it might be just a few lines. I will create a PR there at least to elicit feedback.

@nicois commented on GitHub (Nov 13, 2022): That was how I envisaged it: if a notification had been assigned a certain value for the `thread-group` tag, subsequent notifications with the same tag value would dismiss or delete previous ones, as they could safely be considered obsolete. This doesn't really require any changes on the server, beyond documentation; it's only each client which would need a small change when the message is received. I looked at the Android code and it might be just a few lines. I will create a PR there at least to elicit feedback.