[GH-ISSUE #994] Rationale for current topic name's allowed characters and size ? #698

New issue

Closed

opened 2026-05-07 00:26:40 +02:00 by BreizhHardware · 2 comments

BreizhHardware commented

2026-05-07 00:26:40 +02:00

Owner

Originally created by @vaab on GitHub (Dec 31, 2023).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/994

❓ Question

What is the rationale to limit to 64 characters and only alphanumerical (plus - and _) ?
I would have loved to not feel limited here... or at least less limited.

Some characters might not play well with some implementation with url for instance, but URL encode is still a thing ;-)

I was at least hoping for "." or "/" and up to at least 256 chars (why not 1024 ?), but ":" or actually any UTF-8 chars should be available (like chinese characters, accented ones... etc...). Would this really hit the performance of the over-whole system ?
You could keep topic patterns in the command line by interpreting \, \*, \\.

Using one server to host a lot of topic feels very constrained with the current limitations, without really understanding the reason behind. I guess there's one you have thought through, so I was curious.

I get that you seem to aim at efficiency, and short names are slick and easy to remember, to type... but people will only subscribe once to a topic, so is it this cumbersome to, at least, allow some people to enjoy longer are more complicated set of topics ?

Originally created by @vaab on GitHub (Dec 31, 2023). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/994 :question: **Question** What is the rationale to limit to 64 characters and only alphanumerical (plus `-` and `_`) ? I would have loved to not feel limited here... or at least less limited. Some characters might not play well with some implementation with url for instance, but URL encode is still a thing ;-) I was at least hoping for "." or "/" and up to at least 256 chars (why not 1024 ?), but ":" or actually any UTF-8 chars should be available (like chinese characters, accented ones... etc...). Would this really hit the performance of the over-whole system ? You could keep topic patterns in the command line by interpreting `\`, `\*`, `\\`. Using one server to host a lot of topic feels very constrained with the current limitations, without really understanding the reason behind. I guess there's one you have thought through, so I was curious. I get that you seem to aim at efficiency, and short names are slick and easy to remember, to type... but people will only subscribe once to a topic, so is it this cumbersome to, at least, allow some people to enjoy longer are more complicated set of topics ?

BreizhHardware

2026-05-07 00:26:40 +02:00

closed this issue
added the
question
label

BreizhHardware commented

2026-05-07 00:26:41 +02:00

Author

Owner

@binwiederhier commented on GitHub (Feb 5, 2026):

More than 2 years too late, but the reason is that I made this choice and now this is what it is :-) Maybe I should have allowed 128 characters or more characters, but this is what I chose, and because I won't ever break the API, I'll never implement this change. Feel free to fork and make a change to that.

@binwiederhier commented on GitHub (Feb 5, 2026): More than 2 years too late, but the reason is that I made this choice and now this is what it is :-) Maybe I should have allowed 128 characters or more characters, but this is what I chose, and because I won't ever break the API, I'll never implement this change. Feel free to fork and make a change to that.

BreizhHardware commented

2026-05-07 00:26:41 +02:00

Author

Owner

@saksmt commented on GitHub (Apr 9, 2026):

More than 2 years too late, but the reason is that I made this choice and now this is what it is :-) Maybe I should have allowed 128 characters or more characters, but this is what I chose, and because I won't ever break the API, I'll never implement this change. Feel free to fork and make a change to that.

@binwiederhier , sorry for necro-posting, but that may be better than opening a new issue.

I somewhat understand the limitation to restrict:

/ - since that is a part of url and whatnot, and don't get me started what an awful idea it would be to encode it as %2F (hi, hashicorp!)
: may also complicate some kind of very optimized parser (since : is treated as a separator between username and password, and host and port), though I could not find such parser in the codebase (not that I extensively tried to)
quotes (all their varieties) are a nightmare in url, command line, json, ... everywhere
braces may fall into the same category as quotes
64 ASCII may also be reasonable due to some very heavy bucket/hash optimizations

But what have dot (.) ever done to you?) It feels like a perfectly reasonable separator for "namespaces", for example: server.fs.backups or ha.locks.front-door.

Is there really some limitation and/or potential for backward incompatible change on client level (old clients not working with newer server) if those restrictions on topic name are relaxed?

P.S. Those limitations should at least be better documented (or I need an ophthalmologist) - the only place I've found what is actually allowed to be topic name is source code after attempting to use / as a namespace separator

@saksmt commented on GitHub (Apr 9, 2026): > More than 2 years too late, but the reason is that I made this choice and now this is what it is :-) Maybe I should have allowed 128 characters or more characters, but this is what I chose, and because I won't ever break the API, I'll never implement this change. Feel free to fork and make a change to that. @binwiederhier , sorry for necro-posting, but that may be better than opening a new issue. I somewhat understand the limitation to restrict: - `/` - since that is a part of url and whatnot, and don't get me started what an awful idea it would be to encode it as `%2F` (hi, hashicorp!) - `:` may also complicate some kind of very optimized parser (since `:` is treated as a separator between username and password, and host and port), though I could not find such parser in the codebase (not that I extensively tried to) - quotes (all their varieties) are a nightmare in url, command line, json, ... everywhere - braces may fall into the same category as quotes - 64 ASCII may also be reasonable due to some very heavy bucket/hash optimizations But what have dot (`.`) ever done to you?) It feels like a perfectly reasonable separator for "namespaces", for example: `server.fs.backups` or `ha.locks.front-door`. Is there really some limitation and/or potential for backward incompatible change on client level (old clients not working with newer server) if those restrictions on topic name are relaxed? P.S. Those limitations should at least be better documented (or I need an ophthalmologist) - the only place I've found what is actually allowed to be topic name is source code after attempting to use `/` as a namespace separator

BreizhHardware referenced this issue

2026-05-07 01:01:51 +02:00

[PR #699] [MERGED] fixes #698 #1382