We’re chartered to prototype, develop and test changes to the IRC client protocol. This defines our rules and goals.



We contain participants from many top IRC networks and projects. Here’s how you can participate with the WG.



All of our projects and code (including even this website) can be found and contributed to on the IRCv3 GitHub team.



We’re the IRCv3 Working Group – a collection of IRC software developers and network staff that develop extensions to the IRC client protocol. We’re always interested in new viewpoints, so check out our participation page if you’re interested!

If you’re interested in talking with us, our discussion channel is #ircv3 on Libera.Chat [webchat].

Working Group Updates RSS

Below you can see the latest updates to specifications, new proposals, and generally what’s going on with the IRCv3 Working Group.


Our roadmap [link] always contains info on our direction moving forward, the sort of features we have planned and our priorities.

2022 Spec round-up 20 Nov 2022

Following our tradition of the annual update, here’s a summary of everything that’s been happening since Nov 2021.

Specs ratified 🔗

  • Feb 2022 WHOX - Allows clients to request additional information on other clients.
  • Apr 2022 Bot mode - Allows identifying clients presenting themselves as bot to other clients
  • Oct 2022 Extended monitor - Extends monitor to more commands and notifications

New drafts 🔗

  • Jun 2022 channel-context client tag - Allows sending private messages to clients, while displaying them in the same buffer as a channel
  • Jun 2022 Read marker - Allows several clients of the same user connected to a server or bouncer to tell each other about which messages have been read in each buffer (channel or query)

Specs updated 🔗

On the Roadmap 🔗

Highlights from our ongoing roadmap milestone

  • ratify CHATHISTORY #437
  • userip-tag and userhost-tag #418
  • Add draft account-extban spec #464
  • Message editing and deletion #425
  • Display name client tag spec #452

Other 🔗

We have reorganized the main specifications page to group related specs together in a more logical manner given the recent additions.

Finally, do check the support tables to see how adoption of our specs is coming along, there’ve been a bunch of busy implementations over the past year; especially Goguma, a new Android client spearheading many draft specifications.

Spec round-up 17 Nov 2021

Following our tradition of the annual update, here’s a summary of everything that’s been happening since Feb 2020.

Specs ratified 🔗

New drafts 🔗

Specs updated 🔗

On the Roadmap 🔗

Highlights from our ongoing roadmap milestone

  • ratify CHATHISTORY #437
  • userip-tag and userhost-tag #418
  • Add draft account-extban spec #464
  • Message editing and deletion #425
  • Display name client tag spec #452

Other 🔗

We’ve tidied up the spec structure; making URLs, titles, etc more consistent #441. And we’ve also made a lot of clarifications, improvements and typo fixes to specs that don’t materially affect compatibility, too many to list here.

In Aug 2021, The charter page had an update to better reflect our loose governance structure, deprecating the concept of the “technical board” and clarifying what it means to be listed as a “contributor” #399

Finally, do check the support tables to see how adoption of our specs is coming along, there’ve been a lot of busy implementations over the past year.

Replies and responses 03 Feb 2020

We’ve finalised the Standard Replies extension which lets us respond with information, warnings, and command errors in a more consistent way. It’s already in use by the SETNAME draft and will enable further development of proposals such as the CHATHISTORY extension which we’re still developing.

We’ve also ratified the Labeled responses spec, which lets client software properly track and handle responses to their commands. Check the support tables to see which software is already prepared for this extension.

Capability negotiation received some clarifying updates around dealing with version numbers (or the lack thereof) as well as how to handle requesting loads of capabilities at once.

Other specs from the roadmap we’re continuing to work on include:

  • Message editing and deletion, which lets users fix typos, and gives moderators a new way to deal with spam and abuse.
  • Multiline messages, which lets users post messages that exceed the traditional single line of byte limited text.

Caps, Tags, IDs and WebIRC 05 Jun 2019

Time for our annual blog post! There’s been a lot going on so we’ll summarize what we’ve been up to lately.

First, we’ve rewritten the Capability Negotiation spec. Previously, capabilities were described in three separate documents, which made things pretty hard-to-understand for implementers. The updated document makes it a lot easier to understand and write software that negotiates capabilities.

We’ve ratified the Message Tags spec, which merges the two separate tag-describing documents we used to have. The final version includes a boosted size limit for tags and defines the ERR_INPUTTOOLONG (417) numeric, so clients can send more data and know when they’ve reached the limit. Clients can also exchange tag data between themselves with the new TAGMSG message.

We’ve also ratified the Message IDs spec, which lets servers assign IDs to chat messages and any other events sent to clients. This, for example, lets users react or refer to specific messages.

The WebIRC command has been documented and extended as a formal standard, letting gateways now flag when an incoming connection is using TLS.

The STARTTLS command has been deprecated in favour of sts. The Strict Transport Security extension is recommended as it can also protect connections after the initial one. We’re also exploring options around preload lists and other ways of protecting users’ connections before plaintext hits the wire.

The proposed SETNAME command is now an IRCv3 draft. This command lets users change their realname on the fly, which is especially useful for clients that use this value as a display name or to link to avatars.

The proposed typing client tag is now an IRCv3 draft. This feature allows clients to send and receive typing notifications, which can make conversations richer

On our roadmap, we’re working on:

  • The Standard Replies extension which lets us respond with information, warnings, and command errors in a more consistent way.
  • The Account Management Framework which lets users register for accounts using clean, consistent interfaces rather than having to message services bots.
  • The labeled-response extension, which lets client software properly track and handle responses to their commands.
  • The resume extension, which lets users reconnect and get back to chatting more quickly and cleanly if their connection drops.

We’ve cleaned up and refreshed our support tables, and the footer of each specification now shows which software supports it.

Lastly, some changes to our technical board. We aim to maintain an active, broad and representative mix of board members to steer the working group. NoOneButMe from the Colloquy project has had other priorities outside of IRCv3 lately, and has stepped down. In their place we’re welcoming justjanne from Quassel onto the board.

There’s been a lot of progress this past year, and even more to come. Thanks to our wonderful contributors for the help, and to the IRC community in general.

We’re always looking for help with our roadmap, as well as more general suggestions! If you’re interested in chatting, we hang out on

New Design, Reactions, and WEBIRC 21 Jan 2018

Happy New Year! It’s been a while since we’ve updated, so there’s a heap of changes to go through.

First off, in WG news, we’ve introduced a new site design and a new logo for IRCv3, thanks primarily to dan- and jwheare! Here’s our new logo, in a variety of formats:

IRCv3 Logos

On the spec side, we’ve added the new message-tags draft [link] which introduces the TAGMSG message, allowing clients to pass metadata to each other freely. This spec also increases the size limit on tags from 512 to 4607 bytes, letting clients have more room to pass each other data.

The reply client tag draft [link] has been added, which allows clients to specify that a message is in reply to another specific message. There’s also an extended post about it here on the IRCCloud blog. This allows for things like the new client tag below!

The react client tag draft [link] allows clients to send a ‘reaction’ to another message. This is similar to how users in other chat systems can reply to specific messages with emoji and other characters.

The preload key was added to STS [link], which allows servers to advertise that clients can include it in bundled STS preload lists. We’ve also ratified STS, so it’s fine to implement and use in production!

We’ve also added a draft specifying the widespread WEBIRC command [link]. This command is used by web-based IRC clients to pass through the real IP address of a connecting user, and having a concrete specification should help this command stay standard in the future – as well as allowing us to extend it in a backwards-compatible way.

We’ve also gotten some brand new proposals in! First off there’s the editmsg PR, which allows clients to edit their messages after sending them!

The migrate PR allows servers to cleanly migrate clients from one server to another, ensuring no message history is lost. This makes server maintenance much less impactful, allowing network operators to migrate clients away from a troubled server or portion of the network.

The message-status PR lets clients indicate that they’re typing, and whether a message has been delivered/read.

The rename PR lets users rename channels. This is especially useful on networks with stricter naming guidelines like Freenode.

The resume PR allows clients to better handle when they accidentally disconnect from the network and need to reconnect. It lets them avoid having to NS GHOST their old nickname, and instead simply take over from where they left off (with some missing chat history).

Labels, Message IDs and History 11 Jan 2017

There’s been a bunch of newly-submitted proposals recently, looking at everything from history retrieval with bouncers to message reactions. Let’s go over the holiday changes.

The labeled-response draft [link] was added. This draft links sent commands to returned numerics/messages much more effectively for clients, allowing more complete implementations of echo-message.

The message-ids draft [link] was added. This draft provides a network-unique identifier on messages, which allows many new and exciting features to be built! This includes the reply, reaction, and chathistory proposals below.

The sts draft is getting an upgrade with the preload key [link], which should allow IRC networks to specify whether they want their STS policy added into preload lists shipped with clients. In addition to what STS already provides, this contributes towards helping make clients more secure.

The new message tags specification is also getting an update [link]. Currently being looked at is exactly how to specify client-only tags, and increasing the current minimum-bound of 512 bytes for tag space.

In terms of proposals, a reaction PR has been submitted, which allows clients to add their ‘reactions’ to specific messages. This feature is already widely-implemented in other messaging protocols, and puts IRC on a more equal footing against them.

As well, a chathistory PR has been submitted, which allows clients to query servers/bouncers for chat history. This feature has been desired in bouncers for a while, and should also make it possible for certain clients to implement infinite-scroll style history retrieval.

A reply PR has also been submitted. It allows clients to note that a message is intended as a reply to another sent message. In addition to allowing features such as the reaction tag above, it also brings up the possibility of a more thread-like view of conversations.

Specification Update 20 Nov 2016

We’ve got a lot done recently! Let’s go through all of the latest changes.

First off, the message intents draft was replaced with message-tags[spec]. The new draft message-tags cap and semantics are more useful than intents, allowing features to be implemented by clients themselves (similar to CTCP) and also codifying some of the existing meta around clients/servers parsing all well-formed tags.

If you’ve missed it, the Strict Transport Security (STS) draft [link] is also on the site, and some testnets have support for it as draft/sts. The aim of STS is to allow clients to automatically upgrade their plaintext connections to TLS and to subsequently prevent downgrade attacks.

On a related note, the SNI draft [link] is also now on the site, and should help servers present the right certificate to connecting clients.

It was clarified that all message tag / capability / batch names must be handled as opaque identifiers [pr]. This was already assumed by most, but is a useful clarification to make for implementors.

Draft capability names now use the draft/ prefix to denote their status, and to improve transition if specs change before being merged in proper [pr].

IRCv3.2 Metadata has been deprecated [pr]. The new version of Metadata will extend the rate-limiting and notification capabilities of this spec, letting it be implemented in a much more efficient way by the larger IRC servers.

And for proposals, an rfc7700 casemapping PR has been submitted, which would allow nicknames and channel names to contain Unicode characters. As well, an extended message length PR has been submitted, which would allow servers to accept and send larger IRC messages.