View Issue Details

IDProjectCategoryView StatusLast Update
0000771unrealircdpublic2023-05-22 12:30
ReporterCoNfOuNd Assigned Tosyzop  
Status resolvedResolutionfixed 
PlatformN/AOSN/AOS VersionN/A
Product Version3.2-beta15 
Fixed in Version6.1.1-rc1 
Summary0000771: maxchannelsperuser class block
Descriptionwould it be a possible idea to add maxchannelsperuser in the class block so you can stop certain classes mis-using it while allowing certain classes to well, join more channels..
Additional Informatione.g.

class clients {
pingfreq 90;
maxclients 500;
maxchannelsperuser 15;
sendq 100000;
TagsNo tags attached.
3rd party modules


has duplicate 0002415 closed Move set::maxchannelsperuser to class::maxchannelsperuser 



2003-03-06 16:38

administrator   ~0001780

Hm, well IMO it's a good idea.


2003-03-06 17:26

reporter   ~0001781

I would use the class block to class various TLD's..

class .ALL
        pingfreq 90;
        maxclients 60;
        sendq 100000;

class .COM
        pingfreq 90;
        maxclients 40;
        sendq 200000;

so I would find it handy, as right now I would like to allow .BE connections to join extra channels, or certain bots to join more channels than users who are likely to flood etc.


2003-03-06 20:48

reporter   ~0001790

imho it is better suited to allow {}
Reason is, class {} applies to servers as well, since servers don't join channels, what need is there for them to have such a feature? On the other hand, allow {} is specific for users.


2004-03-01 14:49

reporter   ~0005263

I second this feature request. My main intention for it is to allow certain bots to join more channels than the global limit.


2004-03-02 00:28

reporter   ~0005267

@aragon: opers can join unlimited chans

I think, helpops should also be allowed to join unlimited chans. Because sometimes I dont want to give operator rights to a bot.


2005-03-09 18:09

reporter   ~0009549

is it just me, or does the history of this bug note not add up to the actuall replies etc? and i like the idea of this too


2005-03-10 08:37

reporter   ~0009554

Good idea if you ask me:)


2007-04-27 05:57

reporter   ~0013850

Bump. Do we need this?


2007-04-27 06:17

reporter   ~0013864

yes, need!


2023-05-19 20:04

administrator   ~0022866

Last edited: 2023-05-19 20:05

I think we can throw this in the set::anti-flood block, so do it by security group. That way you can have different limits for known-users (like identified users) vs unknown-users.

...Even though most anti-flood settings are about rates and not limits (well max-concurrent-conversations is sorta in-between i guess)

PS: Sorry for missing the 20th anniversary of this bug two weeks ago.


2023-05-20 14:35

administrator   ~0022868

Done in

Also docs updated in (and the set:: setting too)

commit 3652940c2ca7c8000253e26cfb9fe5c1abaf97bd (HEAD -> unreal60_dev, origin/unreal60_dev, origin/HEAD)
Author: Bram Matthys <[email protected]>
Date: Fri May 19 21:40:33 2023 +0200

    Add set::anti-flood::<secgroup>::max-channels-per-user setting to override
    the default set::max-channels-per-user (also called set::maxchannelsperuser).
    This way you can give known-users a higher max-channels-per-user,
    or even a special security group for trusted users (that you may
    already have given a more lax flood setting and lower lag-penalty
    etc. etc. so that fits in nicely)
    And yeah this also:
    * Makes it both in set and the anti-flood block accept both
      maxchannelsperuser and max-channels-per-user.
    * Removes old MAXCHANNELS= in 005, as we already have CHANLIMIT=
    This does not:
    * Re-announce the 005 CHANLIMIT= if someone transitions from a security
      group with a different max-channels-per-user. We don't do that for
      IRCOps either, and I think no IRCd does that actually...
      To be honest i wonder if sending the limit in 005 is useful at all,
      do client really track this and limit their GUI based on it?? Doubt it!


2023-05-22 12:30

administrator   ~0022882

Correction, this is now in set blocks for security groups (not in anti-flood):

Issue History

Date Modified Username Field Change
2004-03-01 14:49 aragon Note Added: 0005263
2004-03-02 00:28 DukePyrolator Note Added: 0005267
2005-03-09 11:19 codemastr Relationship added has duplicate 0002415
2005-03-09 18:09 White_Magic Note Added: 0009549
2005-03-10 08:37 vonitsanet Note Added: 0009554
2007-04-27 05:57 stskeeps Note Added: 0013850
2007-04-27 05:57 stskeeps Status new => feedback
2007-04-27 06:17 Bock Note Added: 0013864
2023-05-19 20:04 syzop Note Added: 0022866
2023-05-19 20:04 syzop Assigned To => syzop
2023-05-19 20:04 syzop Status feedback => assigned
2023-05-19 20:05 syzop Note Edited: 0022866
2023-05-20 14:35 syzop Status assigned => resolved
2023-05-20 14:35 syzop Resolution open => fixed
2023-05-20 14:35 syzop Fixed in Version => 6.1.1-rc1
2023-05-20 14:35 syzop Note Added: 0022868
2023-05-22 12:30 syzop Note Added: 0022882