extensions.md

IRC protocol extensions

Original IRC protocol

• grawity's collected docs

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:

• Jilles' IRC protocol documentation
• IRCv3 Working Group

Server-server protocol:

• TSora (Hybrid, Charybdis)
  • Current version: TS6 v8
  • Old versions: TS1 → TS3 → TS5 → with UIDs: TS6 v?, TS6 v7
  • Extensions: ENCAP, various CAPAB's
  • TS6-specific: EUID, SAVE
  • Some TS6 ircds (Plexus) have mutated incompatible versions :(
  • TS4 (FAQ) was an attempt to add many features; wasn't popular. TS5 is a direct update of TS3.
• Undernet TSpre (ircu)
  • Current version: P10
  • Old versions: TSpre7, TSpre8
• UnrealIRCd (? DreamForge variant?)
• SASL encapsulation in various link protocols

CTCP and DCC

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.

• Later CTCP draft (no known implementations)
• Later CTCP/2 draft (no known implementations)

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

• DCC protocol as implemented by IRCII
• Turbo DCC (entire file as bytestream)
• Reverse DCC (receiver listens for connection)
• FSERV (opens a chat session with FTP-like commands)
• XDCC

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

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

User identification

• SASL (current, IRCv3 style) – client proto, server proto
• SASL (obsolete, IRCX style) – client proto
• /msg to privileged bots – NickServ, Q
• RFC 1459 server password (PASS command)
• Nefarious "Login On Connect" (extended PASS)
• Ident (OS-level authentication)

Capability negotiation

• The 005 numeric, aka RPL_ISUPPORT
• IRCv3 CAP
• Dancer/Hyperion CAPAB
• PROTOCTL
• 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:

• E. Brocklesby, 2004
• Lee Hardy, 2005

Known extensions:

• List of common extensions
• CALLERID
• MONITOR and WATCH
• WHOX

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.

Features:

• 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:

• account notification (Charybdis, InspIRCd, Unreal)
• away notification (Charybdis, InspIRCd, Unreal)
• extended JOIN (Charybdis, InspIRCd, Unreal)
• multi-prefix NAMES – equivalent to NAMESX (many!)
• message tags (ZNC, Weechat)
• metadata
• server time (ZNC, Weechat)
• SASL authentication (Atheme, Anope, X3)
• STARTTLS (InspIRCd, Unreal)
• userhost-in-names – equivalent to UHNAMES (InspIRCd, Unreal)

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

Nonstandard capabilities:

• identify-msg (Charybdis)

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

Features:

• Server acknowledges successful requests.

Downsides:

• 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

Downsides:

• 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):

• CHARSET
• LANGUAGE
• NAMESX – identical to CAP multi-prefix

Features:

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

Downsides:

• 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.

Features:

• 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:

• mIRC (the most common format)
• improved, by EPIC
• ANSI colors in EPIC