We’re a collection of IRC developers and network staff working to enhance the IRC protocol We’re a collection of IRC developers and network staff working to enhance the IRC protocol

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

2023 had been a slow year, so we skipped on our traditional annual update, but it is back this year. here’s a summary of everything that’s been happening since Nov 2022. Most of the progress these last two years have been around making chathistory more suitable for the real world, and reducing bandwidth usage for mobile clients.

Specs ratified 🔗

Sadly, none during this time span. We’ll try to do better next year.

New drafts 🔗

• Aug 2023 pre-away - Allows clients to update - or not update - their AWAY status early in the connection, when connecting to a bouncer or server that supports multiple connections per user #514
• Oct 2023 no-implicit-names - Allows clients to opt out from receiving the user list when joining a channel. This is useful for clients with limited bandwith, to defer loading the user list to the time it is needed, or the connection is less busy; or to avoid redundancy with WHOX #527
• Apr 2024 message-redaction- Allows removing messages from the chat history, or to ask other clients to hide a message #524, #538
• Jul 2024 account-extban - Standardizes support most servers already had for banning accounts (rather than hostmasks), through a new ISUPPORT token #464
• Sep 2024 metadata-2 - Latest incarnation of a specification meant to support arbitrary public information on users. The previous version of this specification was deprecated in 2016 due to performance issues #501

Specs updated 🔗

• Feb 2023 Standard Replies - Added standard-replies capability, indicating clients support arbitrary FAIL/WARN/NOTE messages, even when not explicitly allowed by another capability #506
• Feb 2023 chathistory - Added MSGREFTYPES ISUPPORT token for servers to signal whether they support/prefer message ids or timestamps to refer to points in the history. This was done because in practice, most server implementations have a strong preference for one or the other. #510
• Sep 2023 Capability negotiation - Clarified that servers may add trailing spaces at the end of capability lists #530
• Sep 2023 away-notify - Clarified that clients should not be sent notifications for their own changes in AWAY status #531

On the Roadmap 🔗

Highlights from our ongoing roadmap milestone

• ratify CHATHISTORY #437
• ratify websocket #548, after resolving the issue of encoding #551
• Message editing and deletion #425

Other 🔗

We now have an account on the Fediverse, follow us at @ircv3@mastodon.social.

We updated the specifications page to replace RFC1459, RFC2812 and RFC7194 with “Modern IRC” as the base specification IRCv3 builds upon. The latter has matured enough in recent years that we are confident it is a strict improvement over the RFCs in terms of accuracy and completeness. #469

Finally, we recommend you check out Sable, an interesting new IRCd developed by Libera.Chat, with built-in services and gossiping instead of a spanning-tree.

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 🔗

• Nov 2021 Account registration - Added ACCOUNT_REQUIRED fail code #481
• Oct 2022 account-tag - Relaxed requirement that the tag be set on all messages #505

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.

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

Specs ratified 🔗

• Feb 2020 setname - Allows users to change their realname without reconnecting
• May 2020 Typing notifications - Displays to others when you’re typing
• Apr 2021 UTF8ONLY isupport key - Indicates that server will only accept UTF8 encoded messages #432

New drafts 🔗

• Apr 2020 Multiline messages - Allows multiple lines per message #398
• Sep 2020 Channel renaming - Enables channel renaming #420
• Nov 2020 chathistory - Allows fetching historical messages from a channel #393
• Apr 2021 Bot mode - Indicates that a user is a bot via a mode and WHOIS numeric, and adds a tag to their messages #439
• Sep 2021 WebSocket - Allows web clients to connect to IRC servers directly #342
• Nov 2021 Client batches - This was split off from multiline into its own framework for use by other specs #454
• Nov 2021 Account registration - Allows account registration without non-standard bot or services messaging #435
• Nov 2021 Extended monitor - Extends monitor to more commands and notifications #466

Specs updated 🔗

• May 2020 Message tags - CLIENTTAGDENY isupport token #412
• Nov 2021 WebIRC - Client certificate fingerprint options #463

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.

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.

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 irc.libera.chat/#ircv3.

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:

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

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.

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.