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.

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.freenode.net/#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.