Roadmap
Our roadmap [link] always contains info on our direction moving forward, the sort of features we have planned and our priorities.
We’re chartered to prototype, develop and test changes to the IRC client protocol. This defines our rules and goals.
ViewWe contain participants from many top IRC networks and projects. Here’s how you can participate with the WG.
ViewAll of our projects and code (including even this website) can be found and contributed to on the IRCv3 GitHub team.
ViewWe’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].
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.
Following our tradition of the annual update, here’s a summary of everything that’s been happening since Nov 2021.
ACCOUNT_REQUIRED
fail code #481Highlights from our ongoing roadmap milestone
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.
Highlights from our ongoing roadmap milestone
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:
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:
labeled-response
extension, which lets client software properly track and handle responses to their commands.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.