IRCv3 specifications build on top of the core IRC protocol. The primary core IRC protocol specifications are RFC1459, RFC2812 and RFC7194. To fully understand IRCv3, please read the core IRC protocol specifications followed by the IRCv3 specifications.

Note: The core IRC protocol specifications have been widely acknowledged to be old, out-of-date, and to not fully or accurately describe how the IRC client protocol works today. One of our members has been working on updated core protocol specifications here which you may find useful to consult. Look at core protocol specifications and the IRC ecosystem itself for a complete picture of how the IRC protocol works today. If you have any questions on the core IRC protocol, please feel free to ask us directly or with an issue in our feedback GitHub repository.

The IRCv3 specifications are released when they are stable and have been widely tested. In the past the WG released specifications as versioned bundles (IRCv3.1, IRCv3.2), but we no longer do this.

Errata updates may be submitted for our specifications. To do so, simply see our contribution document.


Capability Negotiation ๐Ÿ”—

Capability negotiation is a vital part of IRCv3. Capabilities let us implement protocol changes in backwards-compatible ways, as well as convey various information on joining a server.

CAPs are the primary way that IRCv3 features are enabled. As such, most software implementing IRCv3 extensions will want to implement capability negotiation.

The Capability Negotiation spec conveys the basic listing and requesting of capabilities, and lays the framework which most IRCv3 specs use. It also goes over the 302 extensions, and cap-notify โ€“ย a feature to make clients aware when capabilities are removed from and added to the server (for example, if the SASL authentication layer disconnects, the associated capability may be disabled for a time).

Message Tags ๐Ÿ”—

Message tags extend the core framing used with IRC messages, and allow extended data to be sent with messages.

Message tags are widely used in the IRCv3 specifications. As such, most software implementing IRCv3 extensions will want to to implement the core Message Tags specification.

The Message Tags spec covers the new message format, how tag data is formatted and escaped, and how they are named. In addition, it extends the message length and lets clients send tags directly between each other, allowing new features to be developed and implemented independently from the IRC servers themselves (similar to extensions based on CTCP).

Note: Message tags themselves are used as a foundation for other extensions and do not themselves offer any user-facing features. Specific message tags are defined in the various IRCv3 specifications.


Account Tracking ๐Ÿ”—

IRCv3 extensions allow clients to much more easily know when other users are logged into accounts. This allows for much greater integration between client bots and the networkโ€™s authentication system, as well as better general display and authentication of client identities.

The account-notify spec defines a way for clients to be notified when other clients login to accounts. This spec defines the ACCOUNT message to enable this, use of the a WHOX token, as well as outlining the general restriction of account names not being * (as this is used to indicate logging out of accounts).

The account-tag spec defines a way for clients to receive a message tag on messages specifying the current account that other client is logged into (or that they arenโ€™t logged into one at all). This is especially useful for letting bots make use of the networkโ€™s authentication and account mechanisms.

The extended-join spec defines a way to request that extra client information (including that clientโ€™s account) is sent when clients join a given channel. This allows better tracking of accounts, particularly when used with account-notify.

Away Notifications ๐Ÿ”—

The away-notify extension provides a way for clients to instantly know when other clients go away or come back. This improves responsiveness and the display of channels for IRC clients that display this information.

The away-notify spec describes how to sign up for these notifications and the AWAY message to enable this.

Batches ๐Ÿ”—

The batch extension provides a way for servers to mark certain messages as related. This can simplify the display of this information in clients as well as allow better post-processing on them.

The batch spec describes the naming of new batch types, the semantics of batches and how clients should process them.

The work-in-progress client initiated batch extension describes client-to-server batches.

Note: Batches themselves are used as a foundation for other extensions and do not themselves offer any user-facing features.

Here are the standalone batch types the IRCv3 WG defines:

Bot Mode ๐Ÿ”—

The Bot mode lets bots mark themselves as such. Other users will see the client as a bot in various ways, and should see a tag on that clientโ€™s messages if they have requested the message-tags capability.

The work-in-progress Bot Mode spec describes the mode and how to see bots that have set the mode on themselves.

Channel renaming ๐Ÿ”—

The channel-rename extension adds a new command sent by clients and servers that enables renaming a channel without closing it down and redirecting to a new one.

The work-in-progress channel-rename spec describes how to use the RENAME command to achieve this.

Chathistory ๐Ÿ”—

The chathistory extension standardizes a mechanism for clients to request message history from servers or bouncers.

The work-in-progress chathistory spec describes the syntax and semantics of the new CHATHISTORY command.

Changing Usernames and Hostnames ๐Ÿ”—

The chghost extension lets clients more easily see when other clientsโ€™ usernames and/or hostnames are changed. This replaces the clunky method of sending a fake QUIT, and then one or more fake JOIN messages instead.

The chghost spec describes the new CHGHOST message which this extension uses, and how clients see these changes.

Client-Only Tags ๐Ÿ”—

Client-only tags are message tags that are sent directly between clients with no server involvement. Theyโ€™re special in IRCv3 as they only apply to clients, and as such we detail them in their own section here.

Here are the client-only tags the IRCv3 WG defines:

Echo Message ๐Ÿ”—

The echo-message extension lets clients confirm when messages are sent, and see messages that other clients on their connection (say, via an IRC bouncer) have sent. It does this by echoing messages back to clients after they are sent, allowing for these extra features.

The echo-message spec describes which messages are echoโ€™d, and how they are interpreted by clients.

Invite Notify ๐Ÿ”—

The invite-notify extension allows privileged channel users to see when someone is invited to their channel. This can help chanops better run their channels and see better information about whatโ€™s going on.

The invite-notify spec describes the new INVITE reply which this extension uses, and how clients interpret these notifications.

Labeled Responses ๐Ÿ”—

The labeled-response extension allows clients to link returned numerics with sent commands. This allows for much richer/accurate implementations of echo-message, and lets clients generally corrolate sent and received messages.

Additionally, this should also assist bouncers with correctly directing responses to the right connected client.

The labeled-response spec covers the label tag, and how clients should send and will receive labels.

Message IDs ๐Ÿ”—

The message-ids extension allows servers to provide a network-unique identifier on messages (including PRIVMSG/NOTICE). This allows clients to build new features that refer to specific messages, with the knowledge that these identifiers will be unique.

The message-ids spec covers the msgid tag, how servers should generate message IDs and how clients should treat them.

Note: Message IDs themselves are used as a foundation for other extensions and do not themselves offer any user-facing features. Specific IRCv3 extensions will note their use of (and dependency on) message IDs.

Monitor ๐Ÿ”—

The MONITOR command acts as a standardized way for clients to be alerted when other clients enter or exit the network. This is in opposition to ISON, which does this through polling, and WATCH, which differs between vendor implementations.

The Monitor spec details this command, the relevant RPL_ISUPPORT token and the commands used with it.

The work-in-progress Extended Monitor spec builds upon the Monitor spec, and extends it to various events.

Multiple Prefixes ๐Ÿ”—

The multi-prefix extension allows clients to see all the statuses (i.e. voice, chanop) that other clients have in a channel rather than just the highest. This improves data tracking for clients and bots, and allows clients to display the privilege level of other clients more correctly.

The multi-prefix spec details the exact messages these changes apply to and how exactly itโ€™s used.

Multiline messages ๐Ÿ”—

The multiline extension adds a new batch type and tag sent by clients and servers to send messages that can exceed the usual byte length limit and that can contain line breaks.

The work-in-progress multiline spec describes how to use the draft/multiline batch type and draft/multiline-concat tag to achieve this.

Authentication and Registration ๐Ÿ”—

SASL allows users to authenticate in a standardised way across different IRC networks. This is in opposition to logging in with โ€˜servicesโ€™ such as NickServ, and provides a pre-registration way to authenticate. Because SASL allows authentication before registration, it allows clients to join certain types of restricted channels much more effectively.

The v3.1 SASL spec defines the AUTHENTICATE command and sasl cap, which work together to allow clients to authenticate to the network.

The v3.2 SASL spec defines a way to advertise the authentication methods available to clients, allows for clients to re-authenticate after services is lost and reconnects, and defines what to do if the authentication layer is disconnected or reconnected.

IRC SASL authentication primarily uses the same mechanisms as SASL in other protocols. Most commonly:

For further information on SASL mechanism support, see the SASL Mechanisms page.

The work-in-progress Account Registration spec allows users to register accounts in a standardized way, without sending messages to service bots.

Server Time ๐Ÿ”—

The server-time extension allows clients to see the exact time that messages were sent and received. This allows bouncers to replay information with more accurate time tracking.

The server-time spec describes the time tag, how to specify timestamps and how clients should parse incoming timestamps.

Server Name Indication (SNI) ๐Ÿ”—

SNI makes it easier for servers to send the correct TLS certificate to connecting clients.

The work-in-progress SNI spec provides guidelines for clients and servers, allowing them to better detect the TLS certificate to send based on the serverโ€™s hostname.

Setname ๐Ÿ”—

Setname allows clients to update their realname (gecos) after connecting to the server. This is especially useful as some clients use the realname information for avatars and an additional name field.

The setname spec describes how this is implemented, and how clients can update their names and see updates from other users.

Standard Replies ๐Ÿ”—

Standard Replies establishes a clean way to send notes, warnings, and errors to users. This helps server/bouncer developers avoid creating new (possibly conflicting) numerics, and ensures clients will be able to display these messages to users nicely.

The standard replies spec describes the format of these messages, how to use them, and guidance on creating useful descriptions for users.

Strict Transport Security (STS) ๐Ÿ”—

STS allows clients to be automatically upgraded to use TLS encryption and prevents downgrade attacks. STS is intended as a replacement for the STARTTLS command with better security qualities.

The sts spec describes the sts capability, how it operates, and various implementation details for both clients and servers.

Userhosts in NAMES ๐Ÿ”—

The userhost-in-names extension allows clients to more easily see the user/hostnames of other clients when joining channels. This allows clients to better track info and automate client features more easily.

The userhost-in-names spec describes how the NAMES message changes with this capability active, and how clients should interpret the changes.

UTF8ONLY ๐Ÿ”—

The UTF8ONLY ISUPPORT token lets servers indicate that they only support UTF-8 traffic, allowing clients to set their incoming/outgoing encodings automatically.

The UTF8ONLY spec details the RPL_ISUPPORT token and associated messages and functionality.

WebIRC ๐Ÿ”—

The WEBIRC command is widely used to provide the real IP address of users to the server when connecting through a gateway. This is common for current web-based IRC clients.

The WEBIRC spec describes how this command works, how to use it, and some best practices to keep in mind while implementing this feature.

WebSocket ๐Ÿ”—

The work-in-progress WebSocket spec describes conventions for transporting IRC lines over the WebSocket protocol. This is necessary for browser-based clients, which cannot make conventional TCP connections to IRC servers.


Deprecated Extensions ๐Ÿ”—

These extensions have been explicitly deprecated. We no longer recommend implementing them. Generally, these extensions have either been superseded, or other major implementation issues have been discovered with them.

v3.2 Metadata ๐Ÿ”—

The v3.2 METADATA command was found to have issues related to rate-limiting and excessive notifications, which made it impossible for servers in widespread use to implement. A new Metadata specification is being written to address these issues and overhaul the notification system, so we do not recommend implementing this spec.

STARTTLS ๐Ÿ”—

STARTTLS allows clients to upgrade their plaintext connections to use TLS encryption. In alignment with RFC8314, it is recommended that IRC networks use listeners designed for implicit TLS (such as those that operate on port 6697) and clients instead implement STS support.

The tls spec is still available for reference. It describes how the STARTTLS command works, as well as how connection registration is changed by the introduction of this capability.