View Issue Details

IDProjectCategoryView StatusLast Update
0004018unrealircdpublic2012-01-22 16:12
Reporterkatsklaw Assigned Tosyzop  
Status resolvedResolutionfixed 
Fixed in Version3.2.10-rc1 
Summary0004018: [Feature] Add CAPAB Support
DescriptionAdd CAPAB support, at least for clients:
this makes it easier for clients to discover features before they are fully connected. Think of features like STARTTLS.

** katslaw' text, regarding server-to-server (see comments later on): **
As we have seen in Inspircd and U4, CAPAB lends a great deal of flexibility when communicating to other servers, namely services about our functionality.

Case in point, Anope's proto module for Inspircd allows the ircd to tell services which modules are loaded so the services protocol can load the correct features. If a feature is added or removed, simply restart and they are both back in sync again.

It should go without saying that it's vital for services and all ircds on the network to be on the same page when it comes to features. CAPAB is perfect for such a task. With CAPAB in hand it will be easier to create a more dynamic ircd and make more feature and commands optional. Unreal is a modular IRCd for sure, but not very dynamic when communicating which features are enabled or disabled.

I can easily make the channel modes +aq or even +h optional in just a few minutes, but this will now mess up services unless I also alter it's proto module as well. This is still very static and not endorsing our already modular nature. Adding CAPAB will help solve this.
TagsNo tags attached.
3rd party modules


has duplicate 0004066 resolvedsyzop [patch] Add IRCv3 client capability negotiation 



2011-04-06 04:48

reporter   ~0016636

This is a feature, not a minor bug, for some reason I keep forgetting to set it :/


2011-04-06 06:34

reporter   ~0016637

katsklaw: set to feature ;-).

I only have the vaguest idea of what capab is, but I think it'd probably be a good thing to have.


2011-04-07 03:58

reporter   ~0016638

Last edited: 2011-04-07 04:02

View 3 revisions

Didn't know I had access to change it, sorry ;P

The way I understand it is it works along the same lines as raw 005 does, Inspircd uses it to tell Anope which modules are loaded so Anope can load it's matching counterpart. Lets say for a minute that chanmodes +aq were optional and net1 disabled it, as-is we would have to edit anope's proto module to disable it. With capab we can tell anope if we have the aq module loaded so that it can set it's internals to match.

CAPAB is sent during burst, so if we enable +aq then restart both the ircd and Anope, services will be informed at burst that +aq is now used.

Heres a snippet from protocol/inspircd12.c

   } else if (strcasecmp(av[0], "CAPABILITIES") == 0) {
        char *h = strstr(av[1], "HALFOP");
        if (h && h[7] == '1') {
            has_halfop = 1;
    } else if (strcasecmp(av[0], "MODULES") == 0) {
        if (strstr(av[1], "")) {
            has_globopsmod = 1;
        if (strstr(av[1], "")) {
            has_servicesmod = 1;
        if (strstr(av[1], "")) {
            has_svsholdmod = 1;
        if (strstr(av[1], "")) {
            has_chghostmod = 1;
        if (strstr(av[1], "")) {
            has_chgidentmod = 1;

Anope can use CAPAB in much the same way clients like mIRC can use raw 005 to set various settings, like mode stacking, topic lengths, supported chanmodes, etc ..


2011-04-09 15:23

administrator   ~0016639

Not commenting on CAPAB itself, but:
Note that for channel modes we send the CHANMODES= line in PROTOCTL. I started doing that (many versions ago) so f.e. services could see which channel modes are in use. I don't think any of them ever did something with it though.


2012-01-09 22:50

reporter   ~0016854


PROTOCTL and CAPAB do the same exact thing, so i think this bug can be closed.

inspircd just has a more complex capability negotiation because their product is considerably more complex due to over-modularity.


2012-01-20 10:06

administrator   ~0016873

I presume you were speaking to katsklaw, and not me ;)

Anyway this bug shouldn't be closed, you just made a patch for exactly this feature request in 0004066! I've marked that one as duplicate because it should have been posted here.
Of course, thanks for the patch, I'll take a look at it, hopefully this weekend. If it's good, I'll apply it. I just haven't had a chance to read it in-depth, and I didn't see any comments from binki about it either.

Once that patch is applied, we'd also need STARTTLS support. I mean, UHNAMES and NAMESX in CAPAB is nice... as it fixes some issues that PROTOCTL can not, to be more specific: enabling that capability before auto-join's take effect[*], but CAPAB gets a lot more useful when STARTTLS is added IMO.

I saw some conversation somewhere regarding whether an SSL session should start immediately or not when signalling STARTTLS capability from the client to the server. I tend to an explicit STARTTLS command, but there are really two perspectives here... I don't know what other ircd(s) and clients such as kvirc do.

[*] I'd refer to a conversation from me and codemastr on the bugtracker more than 7 years ago about a need for capability indication, but can't find it that quickly.


2012-01-20 18:59

reporter   ~0016874


no. this CAPAB is for server-to-server notification, specifically the protocol lines katsklaw posted were part of inspircd's handshake process. 0004066 is for client-to-server.

i think PROTOCTL is ok for server-to-server. CAPAB in TS5/TS6 are basically the same thing as what PROTOCTL is doing here, and unreal does not have the level of configure ability inspircd has, so there is no need for an inspircd CAPAB in my opinion.


2012-01-20 20:56

administrator   ~0016875

I already edited this issue back in December to make it client CAPAB. If you read the first few sentences of the description, you'll see ;)
And I agree, there's no need for s2s CAPAB at this point AFAICT, there's no reason to use CAPAB over PROTOCTL.


2012-01-20 21:29

administrator   ~0016877

- Add CAP support. Currently implemented are: multi-prefix (NAMESX), and
  userhost-in-names (UHNAMES). Patch from nenotopia (0004018, 0004066).

Only slightly edited/enhanced. Thanks for the patch!

To do:
* Do some CAP testing
* Verify Windows (compile, run)
* Possibly some more...

After STARTTLS (advertising) support has been added, this bug can be closed.


2012-01-22 10:06

reporter   ~0016880


please apply the patch in 0004077 to fix some last-minute regressions found when using the NOSPOOF feature.


2012-01-22 10:33

reporter   ~0016881


the patch in 0004081 switches on the 'tls' capability for starttls, as used by inspircd. this seems to be the best solution as inspircd has already used this keyword for some time and it was agreed upon by various client and server authors etc.


2012-01-22 16:12

administrator   ~0016885

I've applied both patches, thanks!

This bugid can now be closed, from my side it's purpose was getting CAP support with at least STARTTLS, which has now been completed.
(For s2s CAPAB see comment 0004018:0016875)

Issue History

Date Modified Username Field Change
2011-04-06 04:10 katsklaw New Issue
2011-04-06 04:48 katsklaw Note Added: 0016636
2011-04-06 06:34 ohnobinki Note Added: 0016637
2011-04-06 06:34 ohnobinki Severity minor => feature
2011-04-07 03:58 katsklaw Note Added: 0016638
2011-04-07 04:01 katsklaw Note Edited: 0016638 View Revisions
2011-04-07 04:02 katsklaw Note Edited: 0016638 View Revisions
2011-04-09 15:23 syzop Note Added: 0016639
2011-12-21 10:39 syzop Description Updated View Revisions
2012-01-09 22:50 nenotopia Note Added: 0016854
2012-01-20 09:52 syzop Relationship added has duplicate 0004066
2012-01-20 10:06 syzop Note Added: 0016873
2012-01-20 18:59 nenotopia Note Added: 0016874
2012-01-20 20:56 syzop Note Added: 0016875
2012-01-20 21:29 syzop Note Added: 0016877
2012-01-22 10:06 nenolod Note Added: 0016880
2012-01-22 10:33 nenolod Note Added: 0016881
2012-01-22 16:12 syzop Note Added: 0016885
2012-01-22 16:12 syzop Status new => resolved
2012-01-22 16:12 syzop Fixed in Version => 3.2.10-rc1
2012-01-22 16:12 syzop Resolution open => fixed
2012-01-22 16:12 syzop Assigned To => syzop