IRCv3.2 Client Capability Negotiation

Copyright © 2004-2012 Kevin L. Mitchell <>

Copyright © 2004-2012 Perry Lorier <>

Copyright © 2004-2012 Lee Hardy <>

Copyright © 2009-2012 William Pitcock <>

Copyright © 2014 Attila Molnar <>

Unlimited redistribution and modification of this document is allowed provided that the above copyright notice and this permission notice remains intact.

Updates: Capability Negotiation 3.1

Extended by: cap-notify Extension

New in version 3.2

Version in CAP LS

The LS subcommand now has an additional argument which is the raw version number of the latest capability negotiation protocol supported by the client.

This document describes version 302.

Servers MUST NOT send messages described by this document if the client only supports version 3.1.

The client SHOULD send the latest raw version of the capability negotiation protocol it supports as the next argument of the command after LS. If no other arguments are present, version 3.1 is assumed.

Capabilities with values

Servers MAY specify additional data for each capability using the <name>[=<value>] format for CAP LS and CAP NEW.

The meaning of the value (if present) depends on the capability in question.

Multiline replies to CAP LS and CAP LIST

Servers MAY reply with multiple lines in response to CAP LS. If the reply consists of multiple lines (due to IRC line length limitations) all but the last subcommand MUST have a parameter containing only an asterisk (*) preceding the capability list.

The same applies for replies generated by CAP LIST. The client MUST handle multi-line CAP LIST replies if it has claimed 3.2 or later support in the initial CAP LS.


Two new CAP subcommands are introduced: NEW and DEL. Refer to the specification of cap-notify for details about them.

Deprecation of sticky (=) and ack-required (~) capability modifiers

Servers SHOULD NOT denote capabilities which are sticky with the = capability modifier. Instead, they should send a NAK to any request which would disable the sticky capability.

Capabilities MUST NOT require an ACK from the client to be activated.


Example where the client uses CAP 3.2 and the reply contains a cap with a value:

Client: CAP LS 302
Server: CAP * LS :multi-prefix sasl=EXTERNAL
Client: CAP REQ :sasl multi-prefix

Example where the client uses CAP 3.2 and gets a multiline reply:

Client: CAP LS 302
Server: CAP * LS * :multi-prefix extended-join account-notify batch invite-notify tls
Server: CAP * LS * :cap-notify server-time

Example where a 3.2-supporting client uses CAP LIST and gets a multiline reply:

Client: CAP LIST
Server: CAP modernclient LIST * account-notify
Server: CAP modernclient LIST :invite-notify batch


A previous version of this specification did not specify when to use the <name>[=<value>] format. This was clarified to limit capability values to CAP LS and CAP NEW replies.