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 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 v3.1 Capability Negotiation spec conveys the basic listing and requesting of capabilities, and lays the framework which most IRCv3 specs use.
The v3.2 Capability Negotiation spec clarifies how to list large numbers of capabilities (which is needed as we add more useful features to IRCv3!). It also allows capabilities to be listed with values, improving the implementation of features like SASL.
allows clients to be sent notifications when caps are added to or removed from
the server. This is useful in cases like SASL when the authentication layer
disconnects (and thus, SASL authentication is no longer possible). This
extension is automatically enabled if clients request v3.2 capability
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 core Message Tags spec covers the required message changes, how tag data is formatted and escaped, and how they are named.
covers allowing clients to send capabilities directly between each other,
allowing for new features to be developed and implemented independently from
the IRCd itself (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.
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.
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
token, as well as outlining the general restriction of account names not being
* (as this is used to indicate logging out of accounts).
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.
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
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.
describes how to sign up for these notifications and the
AWAY message to
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.
batch spec describes
the naming of new batch types, the semantics of batches and how clients should
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 IRCv3 defines:
netjoinbatch type, to allow clients to collapse netsplits and netjoins more effectively.
chathistorybatch type [draft], for replaying message history.
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.
describes the new
CHGHOST message which this extension uses, and how clients
see these changes.
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.
A specification describing message IDs will be proposed soon. This should allow clients to make full use of this spec and automatically hide duplicate messages as appropriate, which come as a result of this extension.
describes which messages are echo’d, and how they are interpreted by clients.
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.
describes the new
INVITE reply which this extension uses, and how clients
interpret these notifications.
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.
draft/label tag, and how clients should send and will receive
message-ids extension allows servers to provide a network-unique
identifier on messages (including
NOTICE). This allows clients to
build new features that refer to specific messages, with the knowledge that
these identifiers will be unique.
draft/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 command acts as a standardized way for clients to be alerted when
other clients enter or exit the network. This is in opposition to
does this through polling, and
WATCH, which differs between vendor
The Monitor spec details this
command, the relevant
RPL_ISUPPORT token and the commands used with it.
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.
details the exact messages these changes apply to and how exactly it’s used.
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
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.
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.
time tag, how to specify timestamps and how clients should
parse incoming timestamps.
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.
STARTTLS allows clients to upgrade their plaintext connections to use TLS encryption. It is recommended that clients instead implement STS support when that is ratified as a stable IRCv3 standard.
tls spec describes how
STARTTLS command works, as well as how connection registration is changed
by the introduction of this capability.
STS allows clients to be automatically upgraded to use TLS encryption and
prevents downgrade attacks. STS is intended as a replacement for the
command with better security qualities.
sts capability, how it operates, and various implementation
details for both clients and servers.
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.
describes how the
NAMES message changes with this capability active, and how
clients should interpret the changes.
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.
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.