This site contains documents describing the IRC protocol and related technologies. The documents hosted here are intended to be useful to software developers working with IRC. They contain existing behaviour and what we consider best-practices for new software.
If something written in these documents isn’t correct for or interoperable with an IRC client / server / network you know of, please open an issue or send me an email. Pull requests are appreciated.
These documents SHOULD NOT describe brand new behaviour, but existing behaviour present in IRC software and/or networks. These documents should be useful to IRC developers today, not in 10 years time.
The behaviour and constants described in these documents SHOULD converge, and/or be interoperable with the majority of IRC software. These documents should allow a client or server author to build software which can communicate with almost any other piece of IRC software it interacts with.
Where external, up-to-date and authoritative specifications exist for commands/messages/behaviours, we prefer to link to those rather than needlessly rewrite them (see the Client Protocol’s
CAP message for an example of this).
These document are not RFCs. Writing an RFC and putting it through the IETF process is the job of someone else, and whoever does it is free to use anything from these documents. Just respect the authors section at the top of the document if a decent amount of text is used from it. Look at ircv3-harmony for something which aims to be an RFC.
We consider the documents on this site to be ‘living specifications’. This means they are updated as feedback is received for them and as the protocol is extended and grows. Bugs can be fixed, incorrect behaviours in the specifications can be corrected, and they can be extended as new behaviour becomes widespread.
This term and our use of it is based on the WHATWG definition of a ‘living standard’.
Are these documents standards or signed off by multiple vendors?
These documents are explicitly not standards and not signed off by a collection of vendors. These documents are signed off by the editor of that document (though we gladly accept contributors and PRs).
Regardless, I hope you find these documents useful and investigate protocol extensions with the IRCv3 Working Group.
What are your plans for these documents?
There have been questions about doing this work with IRCv3, the IETF, etc. I’m keeping it separate for now, and this section explains why.
I started writing the Modern doc on my own site because I like being able to work at my own pace. When you introduce standards orgs like IRCv3 and the IETF, changes end up having to get signed-off by multiple people. This slows things down, and as a result I lose interest and stop putting time into it. Having the documents here lets me (and any other editors) work at their own pace, and put changes online without needing to worry about getting them approved or having to argue for them.
That slower, multiple-people signoff process is necessary for new standards, and those other standards groups are great. However, I feel like those processes don’t work as well for these documents in particular, with where they are right now and their aim.
This work will probably end up being integrated into one of those groups down the line, and be submitted as some sort of RFC. However, for now I’m happy working on them, productively, with this sort of editor-focused process.