View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004692||unreal||ircd||public||2016-05-24 10:22||2019-01-30 17:56|
|Fixed in Version||4.2.2-rc1|
|Summary||0004692: Allow adjusting topic length in configuration file|
|Description||Please allow the end user to set their own topic lengths, such as set::topiclength 450; or ideally set the default topic length bigger, since 307 is rather small.|
Allow an option for hosts-in-topics if possible, eg. user!ident@cloakhostname
|Tags||No tags attached.|
|3rd party modules|
You can change the maximum topic length in the struct.h file. As far as the hostname in the topic, do you mean like
* 29Topic for #GTAXLnet 29set by GBot1 29at Wed Feb 3 22:09:37 2016
on the by part show GBot1's hostmask as well like other ircds? I think that would be nice but should be in the unrealircd.conf as toggleable that way if people just want the nick to show they can.
Yeah and that 'nick' vs 'nick!user@host' thing too is configurable via TOPIC_NICK_IS_NUHOST in include/setup.h
Guess this issue is about making both settable in the conf. Mostly matters to Windows users. Fine with me, though.
Yes perhaps I should of mentioned "for windows users", If it compiled correctly, maybe I could have altered them myself, but since I keep getting errors, it isnt.
Also it would be of benefit to *ALL* windows users if more configurable options were enabled in the config file, which is the main reason I posted it
It's possible to set a larger topic length, but it can potentially get cut off if it's above 363 characters.
Server to server is not the limiting factor, but client to server in the TOPIC broadcast is:
:nick!user@host TOPIC #channel :text
The characters before the topic text can take up to NICKLEN + USERLEN + HOSTLEN + CHANNELLEN + 12 = 147 characters.
Thus leaving room for 510 - 147 = 363 characters.
I could have made a mistake and be off 1 or 2 characters, but it's more or less that.
Now, one could argue, is it a problem if this is cut off? After all, for PRIVMSG we have a similar situation, where similarly you can send longer messages if you have a short nick and host and can only write shorter messages if your nick is longer (or your host, or your ident, or the channelname, ..). And we "don't care" about this.
Still, I think for TOPIC the situation is different than for a message. The TOPIC is "channel state" and is stored. In more practical terms, it would mean that if someone sets a large topic, the TOPIC message broadcast to all channel members would be cut off (shorter) than what is actually set. Then if you do '/TOPIC #chan' later you get to see a larger topic. That would be confusing and is, strictly speaking, a client desynch.
MODE would be a similar situation, but for MODE we fix this by rewriting the MODE and spreading it over 2 commands in such as case. This is one of the reasons why the mode setting routines are so complicated ;)
Another option would be to calculate the limitation on a case-by-case basis. Calculate everything to see if it hits the buffer limit or not, shorten it to a certain length, ensuring that the topic is the same in the TOPIC broadcast and if you do later "/TOPIC #chan". So no desynch. Still, that would mean someone with a longer nick cannot edit a topic and change 1 character (like change a '1' to a '2'). Well, that is: he can edit it but the topic would be cut off. This, while someone else with a shorter nick or host could do it just fine. This would be too confusing I think. It would also violate the advertised TOPICLEN, more or less, since we say in 005 that we can store XYZ fine, but it actually gets cut off.
* willing to extend the default TOPICLEN, from say 307 to 360 [*]
* in favor of providing it as an option in the configuration file
* against allowing users to go past a limit so that things get potentially desynched (not allowing to set it higher)
[*] If the new option to store nick-user-host of topic setters is enabled, then s2s becomes the limiting factor (instead of c2s) and the limit would actually be 341 instead of 363.
There are other ircds that apparently don't care about a desynch, but I think as the major ircd vendor we have a responsibility to not allow client desynchs. Of course we can't stop users from modifying the source, but we can enforce the limit in the configuration file limit. I also think most, if not all, admins setting it too high never realized the problem in the first place.
||Yeah its roughly about 360 like you said, I have seen networks which have set it higher, and certainly mIRC does not appear to go rogue if the topic is chopped off at the end, not tried other clients however, but yes maybe 360 or thereabouts is a more reasonable figure.|
Thanks for the suggestion and the feedback. Done! -- https://github.com/unrealircd/unrealircd/commit/6cbd2744d7d500c16b8db8b0f5310bd222d4bfbe
commit 6cbd2744d7d500c16b8db8b0f5310bd222d4bfbe (HEAD -> unreal42, origin/unreal42, origin/HEAD)
Author: Bram Matthys <email@example.com>
Date: Wed Jan 30 17:50:17 2019 +0100
* The default maximum topic length has been increased from 307 to 360.
* You can now set more custom limits. The default settings are shown below:
topic-length 360; /* maximum: 360 */
away-length 307; /* maximum: 360 */
quit-length 307; /* maximum: 395 */
kick-length 307; /* maximum: 360 */
* A new 005 token has been added: QUITLEN. Works similar to KICKLEN.
The ability to adjust the topic length in the configuration file was
requested by Amiga600 in https://bugs.unrealircd.org/view.php?id=4692
At that place is also additional information on why there is a
"maximum" for topic length.
Just for the record, the other option with regards to nick!user@host setby information for TOPIC was handled in 0004372.
|2016-05-24 10:22||Amiga600||New Issue|
|2016-05-24 16:40||GTAXL||Note Added: 0019287|
|2016-05-24 21:11||syzop||Summary||Please allow Topic Adjustments => Allow adjusting topic length in configuration file|
|2016-05-24 21:13||syzop||Note Added: 0019290|
|2016-05-25 12:54||Amiga600||Note Added: 0019295|
|2016-06-04 19:27||syzop||Status||new => acknowledged|
|2019-01-28 18:34||syzop||Note Added: 0020469|
|2019-01-28 20:34||Amiga600||Note Added: 0020470|
|2019-01-30 17:53||syzop||Assigned To||=> syzop|
|2019-01-30 17:53||syzop||Status||acknowledged => resolved|
|2019-01-30 17:53||syzop||Resolution||open => fixed|
|2019-01-30 17:53||syzop||Fixed in Version||=> 4.2.2-rc1|
|2019-01-30 17:53||syzop||Note Added: 0020471|
|2019-01-30 17:56||syzop||Note Edited: 0020471||View Revisions|