Skip to content
Switch branches/tags
Go to file
Cannot retrieve contributors at this time

IRC protocol extensions

Original IRC protocol

Original protocol (IRCv2): RFC 1459

Later updated by RFC 2810, RFC 2811, RFC 2812, RFC 2813, but few servers follow these completely. IRCnet is probably the most complete implementation.

Client-server protocol:

Server-server protocol:


Client-To-Client Protocol (CTCP) messages are carried over standard PRIVMSGs and NOTICEs. The original specification allows for quoting special characters, sending "extended data" and commands.

However, most clients do not implement the quoting, and only recognize messages consisting entirely of a single "extended data" command.

IRCII introduced the Direct Client Connection (DCC) subprotocol. Often, "DCC" refers specifically to the file transfer part.

IRCX had commands DATA and REQUEST/REPLY to replace CTCP.

IRCv3 has "message tags" which could act as a replacement.

User identification

Capability negotiation

  • The 005 numeric, aka RPL_ISUPPORT
  • IRCv3 CAP
  • Dancer/Hyperion CAPAB
  • Microsoft IRCX

ISUPPORT (current)

Implemented by almost all servers. Only advertises extensions; they are assumed to be always enabled, unless declared otherwise. (For example, UHNAMES has to enabled by client.) Many extensions in ISUPPORT deal with core IRC features; for example, supported channel types (e.g. CHANTYPES=#&) or the longest permitted nickname (NICKLEN).

Draft specifications:

Known extensions:

CAP and IRCv3 (current)

The IRCv3 Working Group defines a standard set of extensions to IRCv2. The central part of IRCv3 is capability negotiation using CAP, which is implemented by all current servers.


  • Server acknowledges successful and failed requests.
  • Can disable extensions (using CAP REQ -foo).
  • Can list extensions during registration (using CAP LS).

Some IRCv3-specified extensions:

Note that this list is not up-to-date; visit the main IRCv3 repository for a full list.

Nonstandard capabilities:

CAPAB (obsolete; Hybrid, Dancer, Hyperion)

Known extensions:

  • IDENTIFY-MSG (Dancer, Hyperion) – identical to the later CAP identify-msg
  • IDENTIFY-CTCP (Dancer) – merged into IDENTIFY-MSG by Hyperion


  • Server acknowledges successful requests.


  • Server does not acknowledge failed requests.
  • Cannot disable extensions once enabled.
  • Extensions are only advertised after registration (in ISUPPORT).

PROTOCTL (deprecated; Dreamforge, UnrealIRCd)

Known extensions:

  • UHNAMES – identical to CAP userhost-in-names
  • NAMESX – identical to CAP multi-prefix


  • Server does not acknowledge requests.
  • Cannot disable extensions once enabled.
  • Extensions are only advertised after registration (in ISUPPORT).

HANDSHAKE (obsolete; never used)

Draft specification.

Known extensions (listed in draft):


  • Extensions can be enabled during registration.
  • Server acknowledges successful requests.


  • Cannot request extensions after registration.
  • Cannot disable extensions once enabled.
  • Supported extensions are not advertised by the server (the client must request all extensions it wants).

IRCX (obsolete; Microsoft)

An extension of the IRC protocol as a whole, used by Microsoft Chat client as well as Microsoft Exchange Chat server.

Edited draft specification exists; it describes several new commands implemented by IRCX-compatible servers, as well as modes and privilege levels. Adds SASL support using AUTH, predating CAP.

There are plans to add several IRCX features to IRCv3.


  • Extension must be enabled during registration (using IRCX).
  • All supported extensions are part of the specification.
  • Supported SASL mechanisms are advertised by server during registration.

Other extensions

Color codes: