RFC 2812
Internet Relay Chat: Client Protocol
Internet Relay Chat: Client Protocol 🦋
Okay bestie, this is RFC 2812 and it's giving "Internet Relay Chat: Client Protocol" 💬. It was written by C. Kalt for the Network Working Group and dated April 2000. It's Informational, which means it's sharing info for the Internet community, not an Internet standard 📚. It updates RFC 1459 and doesn't list anything it obsoletes. The distribution is unlimited, so share it with everyone 💖
Status of this Memo ✨
This memo is here to provide information for the Internet community. It is not an Internet standard of any kind, and distribution of it is unlimited 🌸
Copyright Notice 🎀
Copyright (C) The Internet Society (2000). All Rights Reserved. Mine? Nope, it's the Internet Society's 💅
IESG NOTE 🚨
IRC lets clients send data to each other, and just like email, the receiver has to be careful about how that data gets handled 👀 For more info on security issues with the IRC protocol, check out http://www.irchelp.org/irchelp/security/ 🔐
Abstract 🌷
The IRC (Internet Relay Chat) protocol is for text based conferencing, and the simplest client is literally any socket program that can connect to the server 💻
This document defines the Client Protocol, and it assumes you already know the IRC Architecture [IRC-ARCH] 🧚
Table of Contents 🗂️
1. Labels ..................................................... 3
1.1 Servers ................................................ 3
1.2 Clients ................................................ 3
1.2.1 Users ............................................. 4
1.2.1.1 Operators .................................... 4
1.2.2 Services .......................................... 4
1.3 Channels ............................................... 4
2. The IRC Client Specification ............................... 5
2.1 Overview ............................................... 5
2.2 Character codes ........................................ 5
2.3 Messages ............................................... 5
2.3.1 Message format in Augmented BNF ................... 6
2.4 Numeric replies ........................................ 8
2.5 Wildcard expressions ................................... 9
3. Message Details ............................................ 9
3.1 Connection Registration ................................ 10
3.1.1 Password message .................................. 10
3.1.2 Nick message ...................................... 10
3.1.3 User message ...................................... 11
3.1.4 Oper message ...................................... 12
3.1.5 User mode message ................................. 12
3.1.6 Service message ................................... 13
3.1.7 Quit .............................................. 14
3.1.8 Squit ............................................. 15
3.2 Channel operations ..................................... 15
3.2.1 Join message ...................................... 16
3.2.2 Part message ...................................... 17
3.2.3 Channel mode message .............................. 18
3.2.4 Topic message ..................................... 19
3.2.5 Names message ..................................... 20
3.2.6 List message ...................................... 21
3.2.7 Invite message .................................... 21
3.2.8 Kick command ...................................... 22
3.3 Sending messages ....................................... 23
3.3.1 Private messages .................................. 23
3.3.2 Notice ............................................ 24
3.4 Server queries and commands ............................ 25
3.4.1 Motd message ...................................... 25
3.4.2 Lusers message .................................... 25
3.4.3 Version message ................................... 26
3.4.4 Stats message ..................................... 26
3.4.5 Links message ..................................... 27
3.4.6 Time message ...................................... 28
3.4.7 Connect message ................................... 28
3.4.8 Trace message ..................................... 29
3.4.9 Admin command ..................................... 30
3.4.10 Info command ...................................... 31
3.5 Service Query and Commands ............................. 31
3.5.1 Servlist message .................................. 31
3.5.2 Squery ............................................ 32
3.6 User based queries ..................................... 32
3.6.1 Who query ......................................... 32
3.6.2 Whois query ....................................... 33
3.6.3 Whowas ............................................ 34
3.7 Miscellaneous messages ................................. 34
3.7.1 Kill message ...................................... 35
3.7.2 Ping message ...................................... 36
3.7.3 Pong message ...................................... 37
3.7.4 Error ............................................. 37
4. Optional features .......................................... 38
4.1 Away ................................................... 38
4.2 Rehash message ......................................... 39
4.3 Die message ............................................ 39
4.4 Restart message ........................................ 40
4.5 Summon message ......................................... 40
4.6 Users .................................................. 41
4.7 Operwall message ....................................... 41
4.8 Userhost message ....................................... 42
4.9 Ison message ........................................... 42
5. Replies .................................................... 43
5.1 Command responses ...................................... 43
5.2 Error Replies .......................................... 53
5.3 Reserved numerics ...................................... 59
6. Current implementations .................................... 60
7. Current problems ........................................... 60
7.1 Nicknames .............................................. 60
7.2 Limitation of wildcards ................................ 61
7.3 Security considerations ................................ 61
8. Current support and availability ........................... 61
9. Acknowledgements ........................................... 61
10. References ................................................ 62
11. Author's Address .......................................... 62
12. Full Copyright Statement .................................. 631. Labels 🏷️
This section defines the identifiers used for the different components of the IRC protocol, so everyone's on the same page ✨
1.1 Servers 🖥️
Servers are uniquely identified by their name, which can be up to sixty three (63) characters long. For what may and may not go into a server name, see the protocol grammar rules (section 2.3.1) 📜
1.2 Clients 💁♀️
For each client, all servers MUST have two things on file: a netwide unique identifier (the format depends on what kind of client it is) and the server that introduced the client 🫶
1.2.1 Users 👑
Each user is told apart from other users by a unique nickname that's at most nine (9) characters long. For what may and may not go into a nickname, see the protocol grammar rules (section 2.3.1) 💖
Even though the max is nine characters, clients SHOULD accept longer strings, because they may get used in future evolutions of the protocol 🔮
1.2.1.1 Operators 🛠️
To keep a reasonable amount of order on the IRC network, there's a special class of users called operators who can do general maintenance on the network. Operator powers can honestly sound 'dangerous' 😬 but they're still often necessary. Operators SHOULD be able to do basic network stuff like disconnecting and reconnecting servers when needed. Because of that need, this protocol gives only operators the ability to do those things. See sections 3.1.8 (SQUIT) and 3.4.7 (CONNECT) 🔌
A more controversial operator power is removing a user from the connected network by 'force', meaning operators can close the connection between any client and server. The justification for this is very delicate, since abusing it is both destructive and annoying, and its benefits are close to inexistent 🙈 For more on this kind of action, see section 3.7.1 (KILL) ⚠️
1.2.2 Services 🧚
Each service is told apart from other services by a service name made of a nickname and a server name. Just like users, the nickname is at most nine (9) characters. For what may and may not go into a nickname, see the protocol grammar rules (section 2.3.1) 🌈
1.3 Channels 📣
Channel names are strings that begin with a &, #, + or ! character, and they can be up to fifty (50) characters long 🌸 Apart from the first character being one of &, #, + or !, the only restriction on a channel name is that it SHALL NOT contain any spaces (' '), a control G (^G or ASCII 7), or a comma (','). Space is the parameter separator, and command is used as a list item separator by the protocol). A colon (':') can also be used as a delimiter for the channel mask. Channel names are case insensitive 🫠
For the exact syntax of a channel name, see the protocol grammar rules (section 2.3.1) 📖
Each prefix tells you a different channel type. What those types mean isn't relevant to the client-server protocol, so it's beyond the scope of this document. You can read more in "Internet Relay Chat: Channel Management" [IRC-CHAN] 🦋
2. The IRC Client Specification 💌
2.1 Overview 🌟
The protocol described here is only for client to server connections, and only when the client registers as a user 💜
2.2 Character codes 🔤
No specific character set is specified. The protocol is based on a set of codes made of eight (8) bits, which together make up an octet. Each message can be made of any number of these octets. However, some octet values are used for control codes, which act as message delimiters 🧩
Even though it's an 8-bit protocol, the delimiters and keywords are set up so the protocol is mostly usable from a US-ASCII terminal and a telnet connection 💻
Because of IRC's Scandinavian origin, the characters {}|^ are considered to be the lower case equivalents of the characters []\~, respectively. This is a critical issue when working out whether two nicknames or channel names are the same, so don't skip it 🚨🎀
2.3 Messages 💌
okay so servers and clients are always sending each other messages, and those messages may or may not get a reply, bestie 🦋. if a message has a valid command (more on those in the later sections), the client should expect a reply like it's described, but it is not advised to wait forever for one 😭. client to server and server to server communication is basically asynchronous by nature, so just vibe and keep moving 🌸
every IRC message can have up to three main parts: the prefix (OPTIONAL) 🎀, the command, and the command parameters (max fifteen (15) of them 💅). the prefix, command, and all the parameters are separated by one ASCII space character (0x20) each. cute and tidy 🧚
so the prefix is shown by a single leading ASCII colon (':', 0x3b). that colon MUST be the very first character of the message itself. and there MUST be NO gap (whitespace) between the colon and the prefix, no exceptions 🙈 servers use the prefix to show the true origin of the message. if the prefix is missing, it's assumed the message came from the connection it was received on 💜 clients SHOULD NOT use a prefix when they send a message. if they do use one, the only valid prefix is the registered nickname linked to that client 💖
the command MUST either be a valid IRC command or a three (3) digit number written in ASCII text 🍓
now the wild part: IRC messages are always lines of characters ended by a CR-LF (Carriage Return - Line Feed) pair ✨ and these messages SHALL NOT exceed 512 characters in length, counting every character including that trailing CR-LF. so that leaves 510 characters max for the command and its parameters 😭 there's no provision for continuing a message line onto another one, and section 6 has more about how current implementations handle this 🫶
2.3.1 Message format in Augmented BNF 🧩
okay so protocol messages have to be pulled out of the continuous stream of octets 🌊 the current way to do it is to use two characters, CR and LF, as message separators. empty messages get silently ignored, which means you can use the CR-LF sequence between messages with no extra drama 💅
once extracted, the message gets parsed into a <prefix>, a <command>, and a list of parameters (<params>) ✨
here's the Augmented BNF representation for all of that:
message = [ ":" prefix SPACE ] command [ params ] crlf
prefix = servername / ( nickname [ [ "!" user ] "@" host ] )
command = 1*letter / 3digit
params = *14( SPACE middle ) [ SPACE ":" trailing ]
=/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]
nospcrlfcl = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF
; any octet except NUL, CR, LF, " " and ":"
middle = nospcrlfcl *( ":" / nospcrlfcl )
trailing = *( ":" / " " / nospcrlfcl )
SPACE = %x20 ; space character
crlf = %x0D %x0A ; "carriage return" "linefeed"NOTES, because they matter 📝
- once the parameter list is extracted, every parameter counts the same whether it's matched by <middle> or <trailing>. <trailing> is just a syntactic trick that lets a parameter contain SPACE 🧠
- the NUL (%x00) character isn't special in message framing, so technically it could end up inside a parameter. but that would cause extra headaches in normal C string handling, so NUL is not allowed within messages 🚫
most protocol messages add extra meaning and syntax for the extracted parameter strings, based on where they sit in the list. for example, lots of server commands assume the first parameter after the command is the list of targets, which can be described like this:
target = nickname / server
msgtarget = msgto *( "," msgto )
msgto = channel / ( user [ "%" host ] "@" servername )
msgto =/ ( user "%" host ) / targetmask
msgto =/ nickname / ( nickname "!" user "@" host )
channel = ( "#" / "+" / ( "!" channelid ) / "&" ) chanstring
[ ":" chanstring ]
servername = hostname
host = hostname / hostaddr
hostname = shortname *( "." shortname )
shortname = ( letter / digit ) *( letter / digit / "-" )
*( letter / digit )
; as specified in RFC 1123 [HNAME]
hostaddr = ip4addr / ip6addr
ip4addr = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit
ip6addr = 1*hexdigit 7( ":" 1*hexdigit )
ip6addr =/ "0:0:0:0:0:" ( "0" / "FFFF" ) ":" ip4addr
nickname = ( letter / special ) *8( letter / digit / special / "-" )
targetmask = ( "$" / "#" ) mask
; see details on allowed masks in section 3.3.1
chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B
chanstring =/ %x2D-39 / %x3B-FF
; any octet except NUL, BELL, CR, LF, " ", "," and ":"
channelid = 5( %x41-5A / digit ) ; 5( A-Z / 0-9 )Other parameter syntaxes are:
user = 1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF )
; any octet except NUL, CR, LF, " " and "@"
key = 1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F )
; any 7-bit US_ASCII character,
; except NUL, CR, LF, FF, h/v TABs, and " "
letter = %x41-5A / %x61-7A ; A-Z / a-z
digit = %x30-39 ; 0-9
hexdigit = digit / "A" / "B" / "C" / "D" / "E" / "F"
special = %x5B-60 / %x7B-7D
; "[", "]", "\", "`", "_", "^", "{", "|", "}"more NOTES, the fine print is cute too 💅
- the <hostaddr> syntax is only here to show what IP addresses should look like. the only implementations available for this protocol use TCP/IP as the underlying network protocol, but this doesn't stop other protocols from being used 🌐
- <hostname> has a maximum length of 63 characters. this is a protocol limit, because internet hostnames (in particular) can be longer. the restriction is needed because IRC messages are capped at 512 characters 🫣 clients connecting from a host whose name is longer than 63 characters get registered using the host's numeric address instead of its host name 💖
- some parameters used in the following sections of this document aren't defined here, because there's nothing specific about them besides the name used for convenience. these parameters follow the general syntax defined for <params> 🧚
2.4 Numeric replies 🔢
most messages sent to the server generate some kind of reply. the most common one is the numeric reply, and it's used for both errors and normal replies 🫶 the numeric reply MUST be sent as one message made up of the sender prefix, the three-digit numeric, and the target of the reply. a numeric reply is NOT allowed to come from a client 🚫 otherwise, a numeric reply is basically just a normal message, except the keyword is made of 3 numeric digits instead of a string of letters 🎀 a list of the different replies is in section 5 (Replies) 📋
2.5 Wildcard expressions 🃏
when wildcards are allowed in a string, the string is called a "mask" 🎭
for string matching, the protocol lets you use two special characters: '?' (%x3F) to match one and only one character, and '*' (%x2A) to match any number of any characters 💜 you can escape these two characters with the character '' (%x5C) 🫠
the Augmented BNF syntax for this is:
mask = *( nowild / noesc wildone / noesc wildmany )
wildone = %x3F
wildmany = %x2A
nowild = %x01-29 / %x2B-3E / %x40-FF
; any octet except NUL, "*", "?"
noesc = %x01-5B / %x5D-FF
; any octet except NUL and "\"
matchone = %x01-FF
; matches wildone
matchmany = *matchone
; matches wildmanyExamples 🌈
a?c ; Matches any string of 3 characters in length starting
with "a" and ending with "c"
a*c ; Matches any string of at least 2 characters in length
starting with "a" and ending with "c"3. Message Details 📬
on the following pages there are descriptions of each message the IRC server and client recognize 💅 all commands described in this section MUST be implemented by any server for this protocol 👑
whenever the reply ERR_NOSUCHSERVER comes back, it means the target of the message couldn't be found. the server MUST NOT send any other replies after this error for that command ❌
the server a client is connected to is required to parse the complete message and return any appropriate errors 🔍
if multiple parameters are presented, then each MUST be checked for validity, and appropriate responses MUST be sent back to the client. for incorrect messages that use parameter lists with a comma as the item separator, a reply MUST be sent for each item 🫶
3.1 Connection Registration 🎟️
the commands here are used to register a connection with an IRC server as a user, and also to disconnect properly 👋
a "PASS" command isn't required for a client connection to be registered, but it MUST come before the latter of the NICK/USER combination (for a user connection) or the SERVICE command (for a service connection) 🔐 the RECOMMENDED order for a client to register is as follows:
1. Pass message
2. Nick message 2. Service message
3. User messageon success, the client gets an RPL_WELCOME (for users) or RPL_YOURESERVICE (for services) message, which says the connection is now registered and known to the entire IRC network 🎉 the reply message MUST contain the full client identifier that the registration was done with 💖
3.1.1 Password message 🔑
Command: PASS
Parameters: <password>the PASS command is used to set a 'connection password' ✨ the optional password can be set, and MUST be set, before any attempt to register the connection is made. right now this means the user has to send a PASS command before sending the NICK/USER combination 🙈
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTREDExample:
PASS secretpasswordhere3.1.2 Nick message 🐣
Command: NICK
Parameters: <nickname>the NICK command gives a user a nickname or changes the existing one 💅
Numeric Replies:
ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
ERR_NICKNAMEINUSE ERR_NICKCOLLISION
ERR_UNAVAILRESOURCE ERR_RESTRICTEDExamples:
NICK Wiz ; Introducing new nick "Wiz" if session is
still unregistered, or user changing his
nickname to "Wiz"
:WiZ!jto@tolsun.oulu.fi NICK Kilroy
; Server telling that WiZ changed his
nickname to Kilroy.3.1.3. User message ✨
Command: USER
Parameters: <user> <mode> <unused> <realname>okay so USER is the command a new connection sends right at the start to tell the server its username, hostname and realname 🎀 it's like introducing yourself at the door of the party
The <mode> parameter should be a numeric 🔢 and it can be used to automatically set user modes when you register with the server. It's a bitmask, and only 2 bits actually mean anything: if bit 2 is set, the user mode w gets switched on, and if bit 3 is set, the user mode i gets switched on. (See Section 3.1.5 "User Modes" 💅)
The <realname> is allowed to have space characters in it, so you can be as extra as you want with your name 💖
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTREDExample:
USER guest 0 * :Ronnie Reagan ; User registering themselves with a
username of "guest" and real name
"Ronnie Reagan".
USER guest 8 * :Ronnie Reagan ; User registering themselves with a
username of "guest" and real name
"Ronnie Reagan", and asking to be set
invisible.the second one is giving "I want to be invisible, but make it aesthetic" 🙈✨
3.1.4. Oper message 👑
Command: OPER
Parameters: <name> <password>so a regular user uses OPER to try and get operator privileges 😤 the combo of <name> and <password> is REQUIRED to unlock operator powers. If it works, you get a MODE message (see section 3.1.5) showing your new user modes 🔥
Numeric Replies:
ERR_NEEDMOREPARAMS RPL_YOUREOPER
ERR_NOOPERHOST ERR_PASSWDMISMATCHExample:
OPER foo bar ; Attempt to register as an operator
using a username of "foo" and "bar"
as the password.3.1.5. User mode message 🦋
Command: MODE
Parameters: <nickname>
*( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) )user MODEs are usually changes that affect either how other people see you, or what "extra" messages you get sent 👀 main character settings, basically
A user MODE command MUST only be accepted if the sender of the message and the nickname given as the parameter are the same person. If you don't give any other parameter, the server will just show you the current settings for your nick 💜
The available modes are:
a - user is flagged as away;
i - marks a users as invisible;
w - user receives wallops;
r - restricted user connection;
o - operator flag;
O - local operator flag;
s - marks a user for receipt of server notices.More modes might show up later on ✨
The flag a SHALL NOT be toggled by the user using the MODE command 🙅♀️ instead, using the AWAY command is REQUIRED.
If a user tries to make themselves an operator with +o or +O, the attempt SHOULD be ignored, because otherwise users could sneak past the authentication mechanisms of the OPER command 🚫 no cheating allowed bestie. There's no restriction, though, on anyone deopping themselves (using -o or -O) 🫶
On the other hand, if a user tries to make themselves unrestricted with the -r flag, the attempt SHOULD be ignored. There's no restriction on anyone deopping themselves (using +r) 💅 This flag is usually set by the server when you connect, for administrative reasons. What the restrictions actually are is up to the implementation, but it's typical that a restricted user isn't allowed to change nicknames or use channel operator status on channels 🙈
The flag s is obsolete but MAY still be used 🕰️
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_USERSDONTMATCH
ERR_UMODEUNKNOWNFLAG RPL_UMODEISExamples:
MODE WiZ -w ; Command by WiZ to turn off
reception of WALLOPS messages.
MODE Angel +i ; Command from Angel to make herself
invisible.
MODE WiZ -o ; WiZ 'deopping' (removing operator
status).Angel really said "make herself invisible" and honestly iconic 🧚
3.1.6. Service message 🧚♀️
Command: SERVICE
Parameters: <nickname> <reserved> <distribution> <type>
<reserved> <info>the SERVICE command is how you register a brand new service 💫 its parameters tell everyone the service's nickname, distribution, type and info
The <distribution> parameter controls how visible a service is. The service may only be known to servers whose name matches the distribution. For a matching server to know about the service, the network path between that server and the server the service is connected to MUST be made up only of servers whose names all match the mask 🗺️
The <type> parameter is reserved for future use right now 🔮
Numeric Replies:
ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
ERR_ERRONEUSNICKNAME
RPL_YOURESERVICE RPL_YOURHOST
RPL_MYINFOExample:
SERVICE dict * *.fr 0 0 :French Dictionary ; Service registering
itself with a name of "dict". This
service will only be available on
servers which name matches "*.fr".a French dictionary that only shows up on French servers is just so specific and I love it 🇫🇷📖
3.1.7. Quit 👋
Command: QUIT
Parameters: [ <Quit Message> ]a client session ends with a quit message 🚪 the server acknowledges it by sending an ERROR message back to the client
Numeric Replies:
None.Example:
QUIT :Gone to have lunch ; Preferred message format.
:syrk!kalt@millennium.stealth.net QUIT :Gone to have lunch ; User
syrk has quit IRC to have lunch."gone to have lunch" is the most relatable IRC moment ever 🍓
3.1.8. Squit 🔌
Command: SQUIT
Parameters: <server> <comment>SQUIT is only available to operators 👑 it's used to disconnect server links. Servers can also generate SQUIT messages themselves when there are error conditions. A SQUIT message may also target a remote server connection. In that case, the SQUIT message is just sent on to the remote server without affecting the servers in between the operator and the remote server 🧵
The <comment> SHOULD be supplied by every operator who runs a SQUIT for a remote server. The server that gets told to disconnect its peer generates a WALLOPS message with the <comment> included, so other users know why it happened 📣
Numeric replies:
ERR_NOPRIVILEGES ERR_NOSUCHSERVER
ERR_NEEDMOREPARAMSExamples:
SQUIT tolsun.oulu.fi :Bad Link ? ; Command to uplink of the server
tolson.oulu.fi to terminate its
connection with comment "Bad Link".
:Trillian SQUIT cm22.eng.umd.edu :Server out of control ; Command
from Trillian from to disconnect
"cm22.eng.umd.edu" from the net with
comment "Server out of control".the "Server out of control" energy is giving Trillian's whole main character arc 💀🔥
3.2. Channel operations 🌈
This group of messages is all about manipulating channels 🏠 their properties (channel modes) and their contents (usually users). Because of that, these messages SHALL NOT be made available to services 🙅♀️
All of these messages are requests that the server will either grant or not 🤞 The server MUST send a reply telling the user whether the request was granted, denied or caused an error. When the server grants the request, the message usually gets sent back to the user (sometimes reformatted) with the prefix set to the user themselves 🪞
The servers enforce the rules for how channels are managed 👮♀️ those rules are beyond the scope of this document. More details are in "Internet Relay Chat: Channel Management" [IRC-CHAN] 📚
3.2.1. Join message 🚪✨
Command: JOIN
Parameters: ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] )
/ "0"the JOIN command is how a user asks to start listening to a specific channel 🎧 Servers MUST be able to parse arguments in the form of a list of targets, but they SHOULD NOT use lists when they send JOIN messages to clients 💅
Once a user has joined a channel, they get information about all the commands their server receives that affect the channel 👀 That includes JOIN, MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. This lets channel members keep track of each other, as well as the channel modes 🫶
If a JOIN works, the user gets a JOIN message as confirmation, and then they're sent the channel's topic (using RPL_TOPIC) and the list of users on the channel (using RPL_NAMREPLY). That list MUST include the user who's joining 🙌
Quick note: this message accepts a special argument ("0"), which means "leave all the channels I'm currently in" 🧹 The server handles it as if the user had sent a PART command (See Section 3.2.2) for each channel they're in 🍃
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE
RPL_TOPICExamples:
JOIN #foobar ; Command to join channel #foobar.
JOIN &foo fubar ; Command to join channel &foo using
key "fubar".
JOIN #foo,&bar fubar ; Command to join channel #foo using
key "fubar" and &bar using no key.
JOIN #foo,#bar fubar,foobar ; Command to join channel #foo using
key "fubar", and channel #bar using
key "foobar".
JOIN #foo,#bar ; Command to join channels #foo and
#bar.
JOIN 0 ; Leave all currently joined
channels.
:WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone ; JOIN message from WiZ
on channel #Twilight_zone#Twilight_zone and WiZ walking in like "we're here" is so cinematic 🌙✨
3.2.2. Part message 👋🌸
Command: PART
Parameters: <channel> *( "," <channel> ) [ <Part Message> ]the PART command removes the user who sent it from the list of active members for every channel listed in the parameter string 🏃♀️ If you give a "Part Message", that gets sent instead of the default message, which is the nickname. The server always grants this request 💖
Servers MUST be able to parse arguments in the form of a list of targets, but they SHOULD NOT use lists when they send PART messages to clients 🫶
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_NOTONCHANNELExamples:
PART #twilight_zone ; Command to leave channel
"#twilight_zone"
PART #oz-ops,&group5 ; Command to leave both channels
"&group5" and "#oz-ops".
:WiZ!jto@tolsun.oulu.fi PART #playzone :I lost
; User WiZ leaving channel
"#playzone" with the message "I
lost"."I lost" as a PART message is the most dramatic exit in all of IRC 😭🎀
3.2.3 Channel mode message ✨
Command: MODE
Parameters: <channel> *( ( "-" / "+" ) *<modes> *<modeparams> )okay so MODE is the command that lets you peek at a channel's settings or change them 💅 The fuller story on what each mode does lives in "Internet Relay Chat: Channel Management" [IRC-CHAN], so go read that if you're curious 🎀
⚠️ Heads up: for modes that take a parameter, you get a maximum of three (3) changes per command. Don't try to cram in more or it won't work the way you want 😭
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_KEYSET
ERR_NOCHANMODES ERR_CHANOPRIVSNEEDED
ERR_USERNOTINCHANNEL ERR_UNKNOWNMODE
RPL_CHANNELMODEIS
RPL_BANLIST RPL_ENDOFBANLIST
RPL_EXCEPTLIST RPL_ENDOFEXCEPTLIST
RPL_INVITELIST RPL_ENDOFINVITELIST
RPL_UNIQOPISThese examples are here to help you get the MODE syntax down 🧚 Just remember that the actual modes are defined in "Internet Relay Chat: Channel Management" [IRC-CHAN] 💖
Examples:
MODE #Finnish +imI *!*@*.fi ; Command to make #Finnish channel
moderated and 'invite-only' with user
with a hostname matching *.fi
automatically invited.
MODE #Finnish +o Kilroy ; Command to give 'chanop' privileges
to Kilroy on channel #Finnish.
MODE #Finnish +v Wiz ; Command to allow WiZ to speak on
#Finnish.
MODE #Fins -s ; Command to remove 'secret' flag
from channel #Fins.
MODE #42 +k oulu ; Command to set the channel key to
"oulu".
MODE #42 -k oulu ; Command to remove the "oulu"
channel key on channel "#42".
MODE #eu-opers +l 10 ; Command to set the limit for the
number of users on channel
"#eu-opers" to 10.
:WiZ!jto@tolsun.oulu.fi MODE #eu-opers -l
; User "WiZ" removing the limit for
the number of users on channel "#eu-
opers".
MODE &oulu +b ; Command to list ban masks set for
the channel "&oulu".
MODE &oulu +b *!*@* ; Command to prevent all users from
joining.
MODE &oulu +b *!*@*.edu +e *!*@*.bu.edu
; Command to prevent any user from a
hostname matching *.edu from joining,
except if matching *.bu.edu
MODE #bu +be *!*@*.edu *!*@*.bu.edu
; Comment to prevent any user from a
hostname matching *.edu from joining,
except if matching *.bu.edu
MODE #meditation e ; Command to list exception masks set
for the channel "#meditation".
MODE #meditation I ; Command to list invitations masks
set for the channel "#meditation".
MODE !12345ircd O ; Command to ask who the channel
creator for "!12345ircd" is3.2.4 Topic message ✨
Command: TOPIC
Parameters: <channel> [ <topic> ]TOPIC is how you check out or change a channel's topic 🌸 If you leave out the <topic>, you just get the current one back. If you include a <topic>, the channel's topic gets updated, but only if you're actually allowed to do that 🔥 And if the <topic> is an empty string, the topic gets wiped entirely 🧹
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
RPL_NOTOPIC RPL_TOPIC
ERR_CHANOPRIVSNEEDED ERR_NOCHANMODESExamples:
:WiZ!jto@tolsun.oulu.fi TOPIC #test :New topic ; User Wiz setting the
topic.
TOPIC #test :another topic ; Command to set the topic on #test
to "another topic".
TOPIC #test : ; Command to clear the topic on
#test.
TOPIC #test ; Command to check the topic for
#test.3.2.5 Names message ✨
Command: NAMES
Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]With NAMES, you can see every nickname that's visible to you 👀 For the full rundown on what counts as visible and what doesn't, check "Internet Relay Chat: Channel Management" [IRC-CHAN] 🦋 The <channel> parameter tells it which channel(s) you want info on. Fun fact: there's no error reply for bad channel names, so it just won't yell at you 🙈
If you don't pass a <channel>, you get a list of every channel and who's in it. At the very end, you'll see the users who are visible but either aren't in any channel or aren't in a visible one. Those get listed under channel "*" 🧚
If you include a <target>, the request gets forwarded to that server, and that server is the one that sends back the reply 🌈
Wildcards are allowed in the <target> parameter ✨
Numerics:
ERR_TOOMANYMATCHES ERR_NOSUCHSERVER
RPL_NAMREPLY RPL_ENDOFNAMESExamples:
NAMES #twilight_zone,#42 ; Command to list visible users on
#twilight_zone and #42
NAMES ; Command to list all visible
channels and users3.2.6 List message ✨
Command: LIST
Parameters: [ <channel> *( "," <channel> ) [ <target> ] ]LIST is how you browse channels and their topics 🍓 If you give it a <channel>, you only get that one channel's status back 💅
If you include a <target>, the request is forwarded to that server, and the server sends the reply 🫶
Wildcards are allowed in the <target> parameter 🌸
Numeric Replies:
ERR_TOOMANYMATCHES ERR_NOSUCHSERVER
RPL_LIST RPL_LISTENDExamples:
LIST ; Command to list all channels.
LIST #twilight_zone,#42 ; Command to list channels
#twilight_zone and #423.2.7 Invite message ✨
Command: INVITE
Parameters: <nickname> <channel>INVITE is how you invite someone to a channel 💌 The <nickname> is whoever you want to invite, and <channel> is the channel they're being invited to. The channel doesn't have to exist or even be a valid channel name. But if it does exist, only people who are already members of that channel are allowed to invite others 🙅♀️ And when the channel has the invite-only flag set, only channel operators may issue an INVITE command 👑
Only the person doing the inviting and the person getting invited get told about the invitation. The other channel members don't get a notification. (This is different from MODE changes, and honestly it causes drama for users sometimes 😭)
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
ERR_NOTONCHANNEL ERR_USERONCHANNEL
ERR_CHANOPRIVSNEEDED
RPL_INVITING RPL_AWAYExamples:
:Angel!wings@irc.org INVITE Wiz #Dust
; Message to WiZ when he has been
invited by user Angel to channel
#Dust
INVITE Wiz #Twilight_Zone ; Command to invite WiZ to
#Twilight_zone3.2.8 Kick command ✨
Command: KICK
Parameters: <channel> *( "," <channel> ) <user> *( "," <user> )
[<comment>]The KICK command is for forcibly removing a user from a channel 👢 It makes the <user> PART from the <channel> whether they like it or not 😤 For the message to be syntactically correct, there MUST be either one channel parameter and multiple user parameters, or as many channel parameters as there are user parameters. If a "comment" is included, it gets sent in place of the default message, which is the nickname of whoever issued the KICK 🎀
🚫 The server MUST NOT send KICK messages with multiple channels or users to clients. This is needed to keep backward compatibility with old client software, so it's not optional, bestie 💀
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
ERR_USERNOTINCHANNEL ERR_NOTONCHANNELExamples:
KICK &Melbourne Matthew ; Command to kick Matthew from
&Melbourne
KICK #Finnish John :Speaking English
; Command to kick John from #Finnish
using "Speaking English" as the
reason (comment).
:WiZ!jto@tolsun.oulu.fi KICK #Finnish John
; KICK message on channel #Finnish
from WiZ to remove John from channel3.3 Sending messages ✨
The whole point of IRC is giving clients a way to talk to each other 🗣️💕 PRIVMSG, NOTICE and SQUERY (covered in Section 3.5 on Service Query and Commands) are the only messages that actually deliver a text message from one client to another. Everything else just makes that possible and tries to make sure it happens in a reliable, structured way 🧚🫶
3.3.1. Private messages 💌
Command: PRIVMSG
Parameters: <msgtarget> <text to be sent>okay so PRIVMSG is how you slide into someone's DMs 💅 or drop a message in a channel. The <msgtarget> is usually the recipient's nickname, or a channel name.
The <msgtarget> can also be a host mask (#<mask>) or a server mask ($<mask>). Either way, the server only sends the PRIVMSG to people whose server or host matches the mask. The mask MUST have at least 1 (one) "." in it and no wildcards following the last ".". This is so nobody can blast "#" or "$" and reach literally everyone 🙅♀️. Wildcards are the '*' and '?' characters. This extension to PRIVMSG is only available to operators 👑.
Numeric Replies:
ERR_NORECIPIENT ERR_NOTEXTTOSEND
ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
ERR_NOSUCHNICK
RPL_AWAYExamples:
:Angel!wings@irc.org PRIVMSG Wiz :Are you receiving this message ?
; Message from Angel to Wiz.
PRIVMSG Angel :yes I'm receiving it !
; Command to send a message to Angel.
PRIVMSG jto@tolsun.oulu.fi :Hello !
; Command to send a message to a user
on server tolsun.oulu.fi with
username of "jto".
PRIVMSG kalt%millennium.stealth.net@irc.stealth.net :Are you a frog?
; Message to a user on server
irc.stealth.net with username of
"kalt", and connected from the host
millennium.stealth.net.
PRIVMSG kalt%millennium.stealth.net :Do you like cheese?
; Message to a user on the local
server with username of "kalt", and
connected from the host
millennium.stealth.net.
PRIVMSG Wiz!jto@tolsun.oulu.fi :Hello !
; Message to the user with nickname
Wiz who is connected from the host
tolsun.oulu.fi and has the username
"jto".
PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.
; Message to everyone on a server
which has a name matching *.fi.
PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions
; Message to all users who come from
a host which has a name matching
*.edu.3.3.2. Notice 🔔
Command: NOTICE
Parameters: <msgtarget> <text>NOTICE is basically PRIVMSG's chill cousin 🧚. The big difference is that automatic replies MUST NEVER be sent in response to a NOTICE. Servers are included too: they MUST NOT send any error reply back to the client on receipt of a notice. The whole point is to stop clients from auto-replying to each other forever and getting stuck in a loop 🔁.
This command is available to services as well as users.
It's typically used by services, and automatons (clients with either an AI or other interactive program controlling their actions) 🤖.
See PRIVMSG for more details on replies and examples.
3.4. Server queries and commands 🔍
The server query group of commands is designed to return information about any server connected to the network. Think of it as asking the network "wassup with you?" 🌐
In these queries, where a parameter appears as <target>, wildcard masks are usually valid. For each parameter, however, only one query and set of replies is to be generated. In most cases, if a nickname is given, it means the server the user is connected to.
These messages typically have little value for services, so it is therefore RECOMMENDED to forbid services from using them 🙅♀️.
3.4.1. Motd message 📜
Command: MOTD
Parameters: [ <target> ]MOTD gets the "Message Of The Day" of the given server, or the current server if <target> is omitted ☀️.
Wildcards are allowed in the <target> parameter.
Numeric Replies:
RPL_MOTDSTART RPL_MOTD
RPL_ENDOFMOTD ERR_NOMOTD3.4.2. Lusers message 📊
Command: LUSERS
Parameters: [ <mask> [ <target> ] ]LUSERS gets statistics about the size of the IRC network 📈. If no parameter is given, the reply is about the whole net. If a <mask> is specified, the reply only concerns the part of the network formed by the servers matching the mask. Finally, if the <target> parameter is specified, the request is forwarded to that server, which generates the reply.
Wildcards are allowed in the <target> parameter.
Numeric Replies:
RPL_LUSERCLIENT RPL_LUSEROP
RPL_LUSERUNKOWN RPL_LUSERCHANNELS
RPL_LUSERME ERR_NOSUCHSERVER3.4.3. Version message 🏷️
Command: VERSION
Parameters: [ <target> ]VERSION is how you check what version of the server program is running 🧾. The optional <target> parameter lets you query the version of a server program that the client is not directly connected to.
Wildcards are allowed in the <target> parameter.
Numeric Replies:
ERR_NOSUCHSERVER RPL_VERSIONExamples:
VERSION tolsun.oulu.fi ; Command to check the version of
server "tolsun.oulu.fi".3.4.4. Stats message 📈
Command: STATS
Parameters: [ <query> [ <target> ] ]STATS is the tea on a certain server's stats 🍵. If the <query> parameter is omitted, only the end of stats reply is sent back.
A query may be given for any single letter. It's only checked by the destination server, and is otherwise passed on by intermediate servers, ignored and unaltered.
Wildcards are allowed in the <target> parameter.
Except for the ones below, the list of valid queries is implementation dependent. The standard queries below SHOULD be supported by the server:
l - returns a list of the server's connections, showing how
long each connection has been established and the
traffic over that connection in Kbytes and messages for
each direction;
m - returns the usage count for each of commands supported
by the server; commands for which the usage count is
zero MAY be omitted;
o - returns a list of configured privileged users,
operators;
u - returns a string showing how long the server has been
up.It is also RECOMMENDED that client and server access configuration be published this way 🔓.
Numeric Replies:
ERR_NOSUCHSERVER
RPL_STATSLINKINFO RPL_STATSUPTIME
RPL_STATSCOMMANDS RPL_STATSOLINE
RPL_ENDOFSTATSExamples:
STATS m ; Command to check the command usage
for the server you are connected to3.4.5. Links message 🔗
Command: LINKS
Parameters: [ [ <remote server> ] <server mask> ]With LINKS, a user can list all the servernames known by the server answering the query 🗺️. The returned list of servers MUST match the mask, or if no mask is given, the full list is returned.
If <remote server> is given in addition to <server mask>, the LINKS command is forwarded to the first server found that matches that name (if any), and that server is then required to answer the query.
Numeric Replies:
ERR_NOSUCHSERVER
RPL_LINKS RPL_ENDOFLINKSExamples:
LINKS *.au ; Command to list all servers which
have a name that matches *.au;
LINKS *.edu *.bu.edu ; Command to list servers matching
*.bu.edu as seen by the first server
matching *.edu.3.4.6. Time message ⏰
Command: TIME
Parameters: [ <target> ]TIME is used to query the local time from the specified server 🕰️. If the <target> parameter is not given, the server receiving the command must reply to the query.
Wildcards are allowed in the <target> parameter.
Numeric Replies:
ERR_NOSUCHSERVER RPL_TIMEExamples:
TIME tolsun.oulu.fi ; check the time on the server
"tolson.oulu.fi"3.4.7. Connect message 🔌
Command: CONNECT
Parameters: <target server> <port> [ <remote server> ]CONNECT lets you ask a server to try to establish a brand new connection to another server, right now ⚡. CONNECT is a privileged command and SHOULD be available only to IRC Operators 👑. If a <remote server> is given and its mask doesn't match the name of the parsing server, the CONNECT attempt is sent to the first match of remote server. Otherwise, the CONNECT attempt is made by the server processing the request.
The server receiving a remote CONNECT command SHOULD generate a WALLOPS message describing the source and target of the request 📣.
Numeric Replies:
ERR_NOSUCHSERVER ERR_NOPRIVILEGES
ERR_NEEDMOREPARAMSExamples:
CONNECT tolsun.oulu.fi 6667 ; Command to attempt to connect local
server to tolsun.oulu.fi on port 66673.4.8 Trace message ✨
Command: TRACE
Parameters: [ <target> ]Okay bestie, TRACE is how you find the route to a specific server and peek at who it's connected to 🧚 Every server that handles this command MUST report back to the sender about itself. The replies from the pass-through links stack up into a chain that shows the route to the destination. After sending that reply back, the query MUST be sent on to the next server, and this keeps going until the given <target> server is reached 🛤️
Again, the whole point is finding the route to one server. Each server that processes this message MUST tell the sender about itself by sending a reply that says it's a pass-through link, so the replies form a chain 🔗 After sending that reply back, it MUST then send the TRACE message to the next server, until the given server is reached. If the <target> parameter is left out, it's RECOMMENDED that TRACE sends a message to the sender saying which servers the local server has a direct connection to 💅
If the destination given by <target> is an actual server, that destination server is REQUIRED to report all servers, services and operators connected to it. If the command was issued by an operator, the server MAY also report all users connected to it 👑 If the destination given by <target> is a nickname, then you only get a reply for that nickname. If the <target> parameter is omitted, it's RECOMMENDED that the TRACE command is treated as targeted at the server processing it 🫶
Wildcards are allowed in the <target> parameter 🌈
Numeric Replies:
ERR_NOSUCHSERVERIf the TRACE message is destined for another server, all intermediate servers must return a RPL_TRACELINK reply to show that the TRACE passed through them and where it's going next 🦋
RPL_TRACELINKA TRACE reply can be made up of any number of the following numeric replies 🎀
RPL_TRACECONNECTING RPL_TRACEHANDSHAKE
RPL_TRACEUNKNOWN RPL_TRACEOPERATOR
RPL_TRACEUSER RPL_TRACESERVER
RPL_TRACESERVICE RPL_TRACENEWTYPE
RPL_TRACECLASS RPL_TRACELOG
RPL_TRACEENDExamples:
TRACE *.oulu.fi ; TRACE to a server matching
*.oulu.fi3.4.9 Admin command 🍓
Command: ADMIN
Parameters: [ <target> ]The admin command is how you find info about the administrator of a given server, or the current server if the <target> parameter is left out 🧑💻 Each server MUST have the ability to forward ADMIN messages to other servers 📨
Wildcards are allowed in the <target> parameter 🌸
Numeric Replies:
ERR_NOSUCHSERVER
RPL_ADMINME RPL_ADMINLOC1
RPL_ADMINLOC2 RPL_ADMINEMAILExamples:
ADMIN tolsun.oulu.fi ; request an ADMIN reply from
tolsun.oulu.fi
ADMIN syrk ; ADMIN request for the server to
which the user syrk is connected3.4.10 Info command 🧚
Command: INFO
Parameters: [ <target> ]The INFO command is REQUIRED to return info that describes the server: its version, when it was compiled, the patchlevel, when it was started, and any other miscellaneous stuff that might be relevant 🔥
Wildcards are allowed in the <target> parameter 💜
Numeric Replies:
ERR_NOSUCHSERVER
RPL_INFO RPL_ENDOFINFOExamples:
INFO csd.bu.edu ; request an INFO reply from
csd.bu.edu
INFO Angel ; request info from the server that
Angel is connected to.3.5 Service Query and Commands ✨
The service query group of commands is designed to return information about any service connected to the network 🦋
3.5.1 Servlist message 💅
Command: SERVLIST
Parameters: [ <mask> [ <type> ] ]The SERVLIST command lists services that are currently connected to the network and visible to the user who issued the command. The optional parameters can narrow the results down (by matching service names and service type) 🎀
Numeric Replies:
RPL_SERVLIST RPL_SERVLISTEND3.5.2 Squery 🫶
Command: SQUERY
Parameters: <servicename> <text>SQUERY works similarly to PRIVMSG. The only difference is that the recipient MUST be a service. This is the only way for a text message to be delivered to a service 📬
See PRIVMSG for more details on replies and examples 🌈
Examples:
SQUERY irchelp :HELP privmsg
; Message to the service with
nickname irchelp.
SQUERY dict@irc.fr :fr2en blaireau
; Message to the service with name
dict@irc.fr.3.6 User based queries 🌸
User queries are a group of commands mainly about finding details on a particular user or a group of users. When you use wildcards with any of these commands, and they match, you only get info on users who are 'visible' to you. A user's visibility is decided by a combination of the user's mode and the common set of channels you're both on 👀
Although services SHOULD NOT be using this class of message, they're allowed to 🙈
3.6.1 Who query 🍓
Command: WHO
Parameters: [ <mask> [ "o" ] ]The WHO command generates a query that returns a list of info which 'matches' the <mask> parameter the client gave. If the <mask> parameter is left out, all visible users (users who aren't invisible, user mode +i, and who don't share a common channel with the requesting client) are listed. You can get the same result with a <mask> of "0" or any wildcard that ends up matching every visible user 🧚
The <mask> passed to WHO is matched against users' host, server, real name and nickname if the channel <mask> can't be found 💖
If the "o" parameter is passed, only operators are returned according to the <mask> supplied 👑
Numeric Replies:
ERR_NOSUCHSERVER
RPL_WHOREPLY RPL_ENDOFWHOExamples:
WHO *.fi ; Command to list all users who match
against "*.fi".
WHO jto* o ; Command to list all users with a
match against "jto*" if they are an
operator.3.6.2 Whois query 🔍
Command: WHOIS
Parameters: [ <target> ] <mask> *( "," <mask> )This command queries info about a particular user. The server answers with several numeric messages showing different statuses of each user that matches the mask (if you're entitled to see them). If there's no wildcard in the <mask>, you get any info about that nick that you're allowed to see 💅
If the <target> parameter is specified, the query is sent to a specific server. This is useful if you want to know how long a user has been idle, since only the local server (the server the user is directly connected to) knows that, while everything else is known globally ⏰
Wildcards are allowed in the <target> parameter 🌈
Numeric Replies:
ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
RPL_WHOISUSER RPL_WHOISCHANNELS
RPL_WHOISCHANNELS RPL_WHOISSERVER
RPL_AWAY RPL_WHOISOPERATOR
RPL_WHOISIDLE ERR_NOSUCHNICK
RPL_ENDOFWHOISExamples:
WHOIS wiz ; return available user information
about nick WiZ
WHOIS eff.org trillian ; ask server eff.org for user
information about trillian3.6.3 Whowas 🦋
Command: WHOWAS
Parameters: <nickname> *( "," <nickname> ) [ <count> [ <target> ] ]WHOWAS asks for info about a nickname that no longer exists. That might be because of a nickname change or because the user left IRC 👻 The server searches its nickname history for any nicks that are lexically the same (no wildcard matching here). The history is searched backward, so the most recent entry comes back first. If there are multiple entries, up to <count> replies are returned (or all of them if no <count> parameter is given). If a non-positive number is passed as <count>, a full search is done 📜
Wildcards are allowed in the <target> parameter 💜
Numeric Replies:
ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
RPL_WHOWASUSER RPL_WHOISSERVER
RPL_ENDOFWHOWASExamples:
WHOWAS Wiz ; return all information in the nick
history about nick "WiZ";
WHOWAS Mermaid 9 ; return at most, the 9 most recent
entries in the nick history for
"Mermaid";
WHOWAS Trillian 1 *.edu ; return the most recent history for
"Trillian" from the first server
found to match "*.edu".3.7 Miscellaneous messages 🎀
Messages in this category don't fit into any of the above categories, but they're still part of the protocol and REQUIRED by it 🫶
3.7.1 Kill message 💀
Command: KILL
Parameters: <nickname> <comment>okay so KILL is how a server basically boots a client's connection off the network 💀 Servers generate KILL messages when there's a nickname collision, and it MAY also be available to users who have operator status 👑
Clients with automatic reconnect algorithms make this kinda useless ngl 🙄 since the disconnect is only brief. It does break the flow of data though, so it can stop big floods from abusive users or from accidents 🚫 Abusive users usually don't care, because they just reconnect and keep going 😤 To stop KILL from being abused, any user can choose to receive the KILL messages generated for others, so they can keep an 'eye' on the potential trouble spots 👀
In a setup where nicknames are REQUIRED to be globally unique at all times, KILL messages get sent whenever 'duplicates' are detected (that's an attempt to register two users with the same nickname). The hope is that both of them disappear and only one reappears 🤞
When a client gets removed because of a KILL, the server SHOULD add the nickname to the list of unavailable nicknames. That way nobody can grab the name right away, since that instant reuse is usually the pattern in abusive behaviour that leads to useless "KILL loops" 🔁 See the "IRC Server Protocol" document [IRC-SERVER] for more info on this procedure.
The comment MUST reflect the actual reason for the KILL 📝 For server-generated KILLs, it's usually made up of details about where the two conflicting nicknames came from. For users, it's up to them to give a reason that's good enough to satisfy everyone who sees it. To stop fake KILLs from being generated to hide who the KILLer is, the comment also shows a 'kill-path' 🕵️ Each server it passes through updates the path by prepending its name to it.
Numeric Replies:
ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
ERR_NOSUCHNICK ERR_CANTKILLSERVERNOTE: It is RECOMMENDED that only Operators be allowed to kill other users with the KILL command. This command has been the subject of many controversies over the years, and along with the above recommendation, it's also widely recognised that not even operators should be allowed to kill users on remote servers 🚨
3.7.2 Ping message 🏓
Command: PING
Parameters: <server1> [ <server2> ]PING is how you check that the active client or server at the other end of the connection is still there 🫶 Servers send a PING at regular intervals if they don't detect any other activity coming from a connection. If a connection fails to respond to a PING within a set amount of time, that connection gets closed. A PING MAY be sent even if the connection is active ✨
When a PING arrives, the appropriate PONG MUST be sent as a reply to <server1> (the server that sent the PING out) as soon as possible 🏃 If the <server2> parameter is specified, it's the target of the ping, and the message gets forwarded there 💌
Numeric Replies:
ERR_NOORIGIN ERR_NOSUCHSERVERExamples:
PING tolsun.oulu.fi ; Command to send a PING message to
; server
PING WiZ tolsun.oulu.fi ; Command from WiZ to send a PING
; message to server "tolsun.oulu.fi"
PING :irc.funet.fi ; Ping message sent by server
; "irc.funet.fi"3.7.3 Pong message 🏸
Command: PONG
Parameters: <server> [ <server2> ]PONG is the reply to a PING 💕 If the parameter <server2> is given, this message MUST be forwarded to that target. The <server> parameter is the name of the entity that responded to the PING and generated this message.
Numeric Replies:
ERR_NOORIGIN ERR_NOSUCHSERVERExample:
PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to
; tolsun.oulu.fi3.7.4 Error 🚨
Command: ERROR
Parameters: <error message>ERROR is for servers reporting a serious or fatal error to their peers 😭 It can also be sent from one server to another, but it MUST NOT be accepted from any normal unknown clients.
Only an ERROR message SHOULD be used for reporting errors that happen on a server-to-server link. The ERROR message gets sent to the server at the other end, which reports it to the appropriate local users and logs. It also goes to the appropriate local users and logs. A server must not pass it on to any other servers if it was received from a server 🚫
The ERROR message is also used before a client connection is terminated 👋
When a server sends a received ERROR message to its operators, the message SHOULD be encapsulated inside a NOTICE message. That tells them the client wasn't responsible for the error 🙅♀️
Numerics:
None.Examples:
ERROR :Server *.fi already exists ; ERROR message to the other server
; which caused this error.
NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
; Same ERROR message as above but
; sent to user WiZ on the other server.4. Optional features 🎁
This section describes OPTIONAL messages 🌸 They're not required in a working server implementation of the protocol described here. If the feature is absent, an error reply message MUST be generated, or an unknown command error. If the message is destined for another server to answer, then it MUST be passed on (elementary parsing REQUIRED). The allocated numerics for these are listed with the messages below 🧚
From this section, only the USERHOST and ISON messages are available to services 💅
4.1 Away 🌙
Command: AWAY
Parameters: [ <text> ]With AWAY, clients can set an automatic reply string for any PRIVMSG commands directed at them (not to a channel they're on) 💬 The server sends the automatic reply to the client that sent the PRIVMSG. The only replying server is the one the sending client is connected to.
The AWAY command is used either with one parameter, to set an AWAY message, or with no parameters, to remove it.
Because of its high cost in memory and bandwidth, the AWAY message SHOULD only be used for client-server communication. A server MAY choose to silently ignore AWAY messages received from other servers. To update the away status of a client across servers, the user mode 'a' SHOULD be used instead. (See Section 3.1.5) 🧠
Numeric Replies:
RPL_UNAWAY RPL_NOWAWAYExample:
AWAY :Gone to lunch. Back in 5 ; Command to set away message to
; "Gone to lunch. Back in 5".4.2 Rehash message 🔄
Command: REHASH
Parameters: NoneREHASH is an administrative command that an operator can use to force the server to re-read and process its configuration file 🛠️
Numeric Replies:
RPL_REHASHING ERR_NOPRIVILEGESExample:
REHASH ; message from user with operator
; status to server asking it to reread
; its configuration file.4.3 Die message 💀
Command: DIE
Parameters: NoneAn operator can use DIE to shut the server down 🪦 This message is optional, since it may be viewed as a risk to let arbitrary people connect to a server as an operator and run this command.
The DIE command MUST always be fully processed by the server the sending client is connected to, and MUST NOT be passed onto other connected servers 🙅
Numeric Replies:
ERR_NOPRIVILEGESExample:
DIE ; no parameters required.4.4 Restart message 🔁
Command: RESTART
Parameters: NoneAn operator can use RESTART to force the server to restart itself ⚡ This message is optional, since it may be viewed as a risk to let arbitrary people connect to a server as an operator and run this command, which would cause (at least) a disruption to service.
The RESTART command MUST always be fully processed by the server the sending client is connected to, and MUST NOT be passed onto other connected servers 🚧
Numeric Replies:
ERR_NOPRIVILEGESExample:
RESTART ; no parameters required.4.5 Summon message 📣
Command: SUMMON
Parameters: <user> [ <target> [ <channel> ] ]SUMMON can be used to give users who are on a host running an IRC server a message asking them to please join IRC 🥺 This message is only sent if the target server (a) has SUMMON enabled, (b) the user is logged in, and (c) the server process can write to the user's tty (or similar) 🖥️
If no <server> parameter is given, the server the client is connected to is assumed to be the target.
If summon is not enabled on a server, it MUST return the ERR_SUMMONDISABLED numeric 🙈
Numeric Replies:
ERR_NORECIPIENT ERR_FILEERROR
ERR_NOLOGIN ERR_NOSUCHSERVER
ERR_SUMMONDISABLED RPL_SUMMONINGExamples:
SUMMON jto ; summon user jto on the server's
; host
SUMMON jto tolsun.oulu.fi ; summon user jto on the host which a
; server named "tolsun.oulu.fi" is
; running.4.6 Users 👥
Command: USERS
Parameters: [ <target> ]USERS returns a list of users logged into the server, in a format similar to the UNIX commands who(1), rusers(1) and finger(1) 🦋 If it's disabled, the correct numeric MUST be returned to indicate that.
Because of the security implications of a command like this, it SHOULD be disabled by default in server implementations. Enabling it SHOULD require recompiling the server or some equivalent change, rather than simply toggling an option and restarting the server. The procedure to enable this command SHOULD also include suitable large comments. Be careful out there, bestie 🔐
Numeric Replies:
ERR_NOSUCHSERVER ERR_FILEERROR
RPL_USERSSTART RPL_USERS
RPL_NOUSERS RPL_ENDOFUSERS
ERR_USERSDISABLEDDisabled Reply:
ERR_USERSDISABLEDExample:
USERS eff.org ; request a list of users logged in
; on server eff.org4.7. Operwall message 📢
Command: WALLOPS
Parameters: <Text to be sent>okay so WALLOPS is how you blast a message to everyone who has set the 'w' user mode for themselves 📣 (peek Section 3.1.5 "User modes" if you want the deets 🧐). Lowkey messy history though 💀: once WALLOPS was a user command, people totally abused it to spam a bunch of folks at once. So it is RECOMMENDED that implementations allow and recognize only servers as the originators of WALLOPS 🙅♀️🔥.
Numeric Replies:
ERR_NEEDMOREPARAMSExample:
:csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua ; WALLOPS
message from csd.bu.edu announcing a
CONNECT message it received from
Joshua and acted upon.4.8. Userhost message 🌸
Command: USERHOST
Parameters: <nickname> *( SPACE <nickname> )USERHOST takes a list of up to 5 nicknames, each separated by a space character 💅, and hands back info about each nickname it actually found ✨. The replies come back in a list too, with each reply separated by a space 🦋.
Numeric Replies:
RPL_USERHOST ERR_NEEDMOREPARAMSExample:
USERHOST Wiz Michael syrk ; USERHOST request for information on
nicks "Wiz", "Michael", and "syrk"
:ircd.stealth.net 302 yournick :syrk=+syrk@millennium.stealth.net
; Reply for user syrk4.9. Ison message 🧚
Command: ISON
Parameters: <nickname> *( SPACE <nickname> )ISON exists so you can quickly check whether a nickname is online right now 👀💖. It only takes one kind of parameter: a space-separated list of nicks 🎀. For every nick in the list that's present, the server adds it to the reply string. So the reply might come back empty (nobody's around 😭), as an exact copy of what you sent (everyone's here 🥳), or as any subset in between 🌈. The only limit on how many nicks you can check is that the combined length MUST NOT be so large that the server chops it off to fit in 512 characters 🚫.
ISON only gets processed by the server local to the client sending the command, so it is not passed on to other servers for further processing 🙈.
Numeric Replies:
RPL_ISON ERR_NEEDMOREPARAMSExample:
ISON phone trillian WiZ jarlek Avalon Angel Monstah syrk
; Sample ISON request for 7 nicks.5. Replies 🎀
The next part is the numeric replies that get generated in response to the commands we just covered 💅. Each numeric is listed with its number, its name, and its reply string 🦋, so you always know exactly what you're looking at ✨.
5.1. Command responses 👑
Numerics from 001 to 099 are only for client-server connections and should never travel between servers 🙅♀️. Replies generated in response to commands live in the 200 to 399 range 💜.
001 RPL_WELCOME
"Welcome to the Internet Relay Network
<nick>!<user>@<host>"
002 RPL_YOURHOST
"Your host is <servername>, running version <ver>"
003 RPL_CREATED
"This server was created <date>"
004 RPL_MYINFO
"<servername> <version> <available user modes>
<available channel modes>"- The server sends Replies 001 to 004 to a user upon successful registration 🎉.
005 RPL_BOUNCE
"Try server <server name>, port <port number>"- Sent by the server to a user to suggest an alternative server 🔁. This is often used when the connection is refused because the server is already full 😬.
302 RPL_USERHOST
":*1<reply> *( " " <reply> )"- Reply format used by USERHOST to list replies to the query list 📋. The reply string is composed as follows:
reply = nickname [ "*" ] "=" ( "+" / "-" ) hostname- The '*' indicates whether the client has registered as an Operator 👑. The '-' or '+' characters represent whether the client has set an AWAY message or not 💅 (so '-' means away, '+' means not away 🌸).
303 RPL_ISON
":*1<nick> *( " " <nick> )"- Reply format used by ISON to list replies to the query list 🧚.
301 RPL_AWAY
"<nick> :<away message>"
305 RPL_UNAWAY
":You are no longer marked as being away"
306 RPL_NOWAWAY
":You have been marked as being away"- These replies are used with the AWAY command (if allowed) 🙋♀️. RPL_AWAY is sent to any client sending a PRIVMSG to a client which is away 💬. RPL_AWAY is only sent by the server to which the client is connected 🔌. Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the client removes and sets an AWAY message 🌈.
311 RPL_WHOISUSER
"<nick> <user> <host> * :<real name>"
312 RPL_WHOISSERVER
"<nick> <server> :<server info>"
313 RPL_WHOISOPERATOR
"<nick> :is an IRC operator"
317 RPL_WHOISIDLE
"<nick> <integer> :seconds idle"
318 RPL_ENDOFWHOIS
"<nick> :End of WHOIS list"
319 RPL_WHOISCHANNELS
"<nick> :*( ( "@" / "+" ) <channel> " " )"- Replies 311 - 313, 317 - 319 are all replies generated in response to a WHOIS message 🕵️♀️. Given that there are enough parameters present, the answering server MUST either formulate a reply out of the above numerics (if the query nick is found) or return an error reply 🚨. The '*' in RPL_WHOISUSER is there as the literal character and not as a wild card 🌟. For each reply set, only RPL_WHOISCHANNELS may appear more than once (for long lists of channel names) 📜. The '@' and '+' characters next to the channel name indicate whether a client is a channel operator or has been granted permission to speak on a moderated channel 🍓. The RPL_ENDOFWHOIS reply is used to mark the end of processing a WHOIS message 🏁.
314 RPL_WHOWASUSER
"<nick> <user> <host> * :<real name>"
369 RPL_ENDOFWHOWAS
"<nick> :End of WHOWAS"- When replying to a WHOWAS message, a server MUST use the replies RPL_WHOWASUSER, RPL_WHOISSERVER or ERR_WASNOSUCHNICK for each nickname in the presented list 🪄. At the end of all reply batches, there MUST be RPL_ENDOFWHOWAS (even if there was only one reply and it was an error) 🫶.
321 RPL_LISTSTART
Obsolete. Not used.
322 RPL_LIST
"<channel> <# visible> :<topic>"
323 RPL_LISTEND
":End of LIST"- Replies RPL_LIST, RPL_LISTEND mark the actual replies with data and end of the server's response to a LIST command 📃. If there are no channels available to return, only the end reply MUST be sent 🫥.
325 RPL_UNIQOPIS
"<channel> <nickname>"
324 RPL_CHANNELMODEIS
"<channel> <mode> <mode params>"
331 RPL_NOTOPIC
"<channel> :No topic is set"
332 RPL_TOPIC
"<channel> :<topic>"- When sending a TOPIC message to determine the channel topic, one of two replies is sent 📌. If the topic is set, RPL_TOPIC is sent back, else RPL_NOTOPIC 💅.
341 RPL_INVITING
"<channel> <nick>"- Returned by the server to indicate that the attempted INVITE message was successful and is being passed onto the end client 💌.
342 RPL_SUMMONING
"<user> :Summoning user to IRC"- Returned by a server answering a SUMMON message to indicate that it is summoning that user 📣.
346 RPL_INVITELIST
"<channel> <invitemask>"
347 RPL_ENDOFINVITELIST
"<channel> :End of channel invite list"- When listing the 'invitations masks' for a given channel, a server is required to send the list back using the RPL_INVITELIST and RPL_ENDOFINVITELIST messages 🎟️. A separate RPL_INVITELIST is sent for each active mask 🔑. After the masks have been listed (or if none present) a RPL_ENDOFINVITELIST MUST be sent 🏁.
348 RPL_EXCEPTLIST
"<channel> <exceptionmask>"
349 RPL_ENDOFEXCEPTLIST
"<channel> :End of channel exception list"- When listing the 'exception masks' for a given channel, a server is required to send the list back using the RPL_EXCEPTLIST and RPL_ENDOFEXCEPTLIST messages 🦋. A separate RPL_EXCEPTLIST is sent for each active mask 🌷. After the masks have been listed (or if none present) a RPL_ENDOFEXCEPTLIST MUST be sent 🫶.
351 RPL_VERSION
"<version>.<debuglevel> <server> :<comments>"- Reply by the server showing its version details 🧾. The <version> is the version of the software being used (including any patchlevel revisions), and the <debuglevel> is used to indicate if the server is running in "debug mode" 🐛.
- The "comments" field may contain any comments about the version or further version details 💬.
352 RPL_WHOREPLY
"<channel> <user> <host> <server> <nick>
( "H" / "G" > ["*"] [ ( "@" / "+" ) ]
:<hopcount> <real name>"
315 RPL_ENDOFWHO
"<name> :End of WHO list"- The RPL_WHOREPLY and RPL_ENDOFWHO pair are used to answer a WHO message 🔍. The RPL_WHOREPLY is only sent if there is an appropriate match to the WHO query 🎯. If there is a list of parameters supplied with a WHO message, a RPL_ENDOFWHO MUST be sent after processing each list item, with <name> being the item 🌈.
353 RPL_NAMREPLY
"( "=" / "*" / "@" ) <channel>
:[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )- "@" is used for secret channels, "*" for private channels, and "=" for others (public channels) 🕶️💜.
366 RPL_ENDOFNAMES
"<channel> :End of NAMES list"- To reply to a NAMES message, a reply pair consisting of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the server back to the client 📇. If there is no channel found as in the query, then only RPL_ENDOFNAMES is returned 🫥. The exception to this is when a NAMES message is sent with no parameters, and all visible channels and contents are sent back in a series of RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark the end 🏳️🌈.
364 RPL_LINKS
"<mask> <server> :<hopcount> <server info>"
365 RPL_ENDOFLINKS
"<mask> :End of LINKS list"- In replying to the LINKS message, a server MUST send replies back using the RPL_LINKS numeric and mark the end of the list using an RPL_ENDOFLINKS reply 🔗.
367 RPL_BANLIST
"<channel> <banmask>"
368 RPL_ENDOFBANLIST
"<channel> :End of channel ban list"Okay so, bestie, when a server gets asked for the active bans on a channel, it's required to send them back using RPL_BANLIST and RPL_ENDOFBANLIST 🚫✨ Every active banmask gets its own RPL_BANLIST, and then the list ends with an RPL_ENDOFBANLIST. Even if there are zero bans, you still get the end message, and that MUST be sent 💅
371 RPL_INFO
":<string>"
374 RPL_ENDOFINFO
":End of INFO list"INFO is giving "tell me everything about yourself" 🧚 A server answering an INFO message has to send all of its 'info' as a series of RPL_INFO messages, then close it off with RPL_ENDOFINFO so you know the gossip is done 🫶
375 RPL_MOTDSTART
":- <server> Message of the day - "
372 RPL_MOTD
":- <text>"
376 RPL_ENDOFMOTD
":End of MOTD command"MOTD time 🌸 When the MOTD file exists, the server shows it line by line, and every line has to be 80 characters or less. Each line goes out as an RPL_MOTD. These MUST be wrapped in an RPL_MOTDSTART at the beginning and an RPL_ENDOFMOTD at the end. Very organised, very iconic 💖
381 RPL_YOUREOPER
":You are now an IRC operator"RPL_YOUREOPERis sent to a client right after it successfully sends an OPER message and becomes an operator 👑
382 RPL_REHASHING
"<config file> :Rehashing"- If the REHASH option gets used and an operator sends a REHASH message, the operator gets an
RPL_REHASHINGback 🔥
383 RPL_YOURESERVICE
"You are service <servicename>"- The server sends this to a service once it's registered successfully 🎀
391 RPL_TIME
"<server> :<string showing server's local time>"- When replying to the TIME message, a server MUST send the reply in the
RPL_TIMEformat above 🕰️ The time string only needs to show the correct day and time. There's no extra requirement on the time string beyond that, so no stress 💅
392 RPL_USERSSTART
":UserID Terminal Host"
393 RPL_USERS
":<username> <ttyline> <hostname>"
394 RPL_ENDOFUSERS
":End of users"
395 RPL_NOUSERS
":Nobody logged in"- If a server handles the USERS message, it uses
RPL_USERSSTART,RPL_USERS,RPL_ENDOFUSERSandRPL_NOUSERS.RPL_USERSSTARTMUST be sent first, followed by either a run ofRPL_USERSor a singleRPL_NOUSER. After that comesRPL_ENDOFUSERS🌈
200 RPL_TRACELINK
"Link <version & debug level> <destination>
<next server> V<protocol version>
<link uptime in seconds> <backstream sendq>
<upstream sendq>"
201 RPL_TRACECONNECTING
"Try. <class> <server>"
202 RPL_TRACEHANDSHAKE
"H.S. <class> <server>"
203 RPL_TRACEUNKNOWN
"???? <class> [<client IP address in dot form>]"
204 RPL_TRACEOPERATOR
"Oper <class> <nick>"
205 RPL_TRACEUSER
"User <class> <nick>"
206 RPL_TRACESERVER
"Serv <class> <int>S <int>C <server>
<nick!user|*!*>@<host|server> V<protocol version>"
207 RPL_TRACESERVICE
"Service <class> <name> <type> <active type>"
208 RPL_TRACENEWTYPE
"<newtype> 0 <client name>"
209 RPL_TRACECLASS
"Class <class> <count>"
210 RPL_TRACERECONNECT
Unused.
261 RPL_TRACELOG
"File <logfile> <debug level>"
262 RPL_TRACEEND
"<server name> <version & debug level> :End of TRACE"TRACE replies are a whole vibe 🦋 Every RPL_TRACE* reply comes back from the server in response to the TRACE message. How many you get depends on the TRACE message itself and on whether it came from an operator. There's no set order for which one shows up first ✨
RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and RPL_TRACEHANDSHAKE are for connections that aren't fully established yet. They're either unknown, still trying to connect, or in the middle of finishing the 'server handshake' 🤝
RPL_TRACELINK gets sent by any server that handles a TRACE message and has to pass it along to another server. The list of RPL_TRACELINKs sent back for a TRACE command travelling across the IRC network should match the actual connectivity of the servers along that path. Honest reflection energy 🪞
RPL_TRACENEWTYPE is for any connection that doesn't fit the other categories but is getting displayed anyway 🍓
RPL_TRACEEND is how the server tells you the list is over 🫶
211 RPL_STATSLINKINFO
"<linkname> <sendq> <sent messages>
<sent Kbytes> <received messages>
<received Kbytes> <time open>"- This one reports statistics on a connection 📊
<linkname>names the particular connection.<sendq>is how much data is queued up and waiting to be sent.<sent messages>is the number of messages sent, and<sent Kbytes>is how much data was sent, in Kbytes.<received messages>and<received Kbytes>are the same thing as<sent messages>and<sent Kbytes>, just for received data.<time open>says how long ago the connection was opened, in seconds ⏱️
212 RPL_STATSCOMMANDS
"<command> <count> <byte count> <remote count>"- Reports statistics on command usage 💜
219 RPL_ENDOFSTATS
"<stats letter> :End of STATS report"
242 RPL_STATSUPTIME
":Server Up %d days %d:%02d:%02d"RPL_STATSUPTIMEreports how long the server has been up ⭐
243 RPL_STATSOLINE
"O <hostmask> * <name>"- Reports the allowed hosts a user can become an IRC operator from 👑
221 RPL_UMODEIS
"<user mode string>"- If someone asks what their own mode is,
RPL_UMODEISis sent back 🙈
234 RPL_SERVLIST
"<name> <server> <mask> <type> <hopcount> <info>"
235 RPL_SERVLISTEND
"<mask> <type> :End of service listing"- When services are listed in reply to a SERVLIST message, a server is required to send the list back using
RPL_SERVLISTandRPL_SERVLISTEND. A separateRPL_SERVLISTgoes out for each service. After the services have been listed (or if there aren't any), anRPL_SERVLISTENDMUST be sent 🧚
251 RPL_LUSERCLIENT
":There are <integer> users and <integer>
services on <integer> servers"
252 RPL_LUSEROP
"<integer> :operator(s) online"
253 RPL_LUSERUNKNOWN
"<integer> :unknown connection(s)"
254 RPL_LUSERCHANNELS
"<integer> :channels formed"
255 RPL_LUSERME
":I have <integer> clients and <integer>
servers"- When processing an LUSERS message, the server sends a set of replies from
RPL_LUSERCLIENT,RPL_LUSEROP,RPL_USERUNKNOWN,RPL_LUSERCHANNELSandRPL_LUSERME. When replying, a server MUST send backRPL_LUSERCLIENTandRPL_LUSERME. The other replies only get sent back if a non-zero count is found for them 📈
256 RPL_ADMINME
"<server> :Administrative info"
257 RPL_ADMINLOC1
":<admin info>"
258 RPL_ADMINLOC2
":<admin info>"
259 RPL_ADMINEMAIL
":<admin info>"- When replying to an ADMIN message, a server is expected to use the replies
RPL_ADMINMEthrough toRPL_ADMINEMAIL, and to give a text message with each one 🏫 ForRPL_ADMINLOC1, it's expected to say what city, state and country the server is in. Then comesRPL_ADMINLOC2with the details of the institution. Finally,RPL_ADMINEMAILcarries the administrative contact for the server, and an email address here is REQUIRED 📧
263 RPL_TRYAGAIN
"<command> :Please wait a while and try again."- If a server drops a command without processing it, it MUST use the
RPL_TRYAGAINreply to let the originating client know 🥺💅
5.2 Error Replies 💅
okay bestie, error replies live in the 400 to 599 range, so if a numeric lands in there, something went sideways 😭
401 ERR_NOSUCHNICK
"<nickname> :No such nick/channel"this one shows up when the nickname you gave a command isn't in use right now 👻
402 ERR_NOSUCHSERVER
"<server name> :No such server"this means the server name you typed doesn't exist 🫠
403 ERR_NOSUCHCHANNEL
"<channel name> :No such channel"the channel name you used is invalid, so the server can't find it 🙈
404 ERR_CANNOTSENDTOCHAN
"<channel name> :Cannot send to channel"this is for a user who is trying to send a PRIVMSG to a channel and either:
- (a) isn't on a channel that's mode
+n, or - (b) isn't a chanop (or mode
+v) on a channel that has mode+mset, or is banned from it
so basically you're locked out of the chat, bestie 🔒
405 ERR_TOOMANYCHANNELS
"<channel name> :You have joined too many channels"you've hit the max number of channels you're allowed, and you're trying to join one more. the limit is the limit 💅
406 ERR_WASNOSUCHNICK
"<nickname> :There was no such nickname"WHOWAS sends this when it has no history for that nickname. no receipts, no tea ☕
407 ERR_TOOMANYTARGETS
"<target> :<error code> recipients. <abort message>"this one comes up in three different situations, and honestly they're all a lot:
- a client tries to send a PRIVMSG/NOTICE using the user@host destination format, and that user@host has several occurrences
- a client tries to send a PRIVMSG/NOTICE to too many recipients
- a client tries to JOIN a safe channel using the shortname when there's more than one such channel
way too many people in the room 🌸
408 ERR_NOSUCHSERVICE
"<service name> :No such service"you sent a SQUERY to a service that doesn't exist. the service is gone, babe 👋
409 ERR_NOORIGIN
":No origin specified"a PING or PONG message showed up without its originator parameter. rude 🙄
411 ERR_NORECIPIENT
":No recipient given (<command>)"
412 ERR_NOTEXTTOSEND
":No text to send"
413 ERR_NOTOPLEVEL
"<mask> :No toplevel domain specified"
414 ERR_WILDTOPLEVEL
"<mask> :Wildcard in toplevel domain"
415 ERR_BADMASK
"<mask> :Bad Server/host mask"- 412 to 415 come back from PRIVMSG to say the message didn't get delivered for some reason.
- ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are the ones you get when someone tries an invalid
PRIVMSG $<server>orPRIVMSG #<host>. not it, sweetie 🙅♀️
421 ERR_UNKNOWNCOMMAND
"<command> :Unknown command"a registered client sent a command the server doesn't know. the server is lost fr fr 🤷♀️
422 ERR_NOMOTD
":MOTD File is missing"the server couldn't open its MOTD file. no welcome message, no vibes 🥲
423 ERR_NOADMININFO
"<server> :No administrative info available"the server sends this in response to an ADMIN message when it can't find the right info. the info is ghosting us 👻
424 ERR_FILEERROR
":File error doing <file op> on <file>"this is the generic one for a failed file operation while the server was handling a message. the file is cooked 💀
431 ERR_NONICKNAMEGIVEN
":No nickname given"a command needed a nickname parameter and it just wasn't there. the bare minimum, please 🥺
432 ERR_ERRONEUSNICKNAME
"<nick> :Erroneous nickname"you sent a NICK with characters that aren't in the defined set. see section 2.3.1 for what counts as a valid nickname 📖
433 ERR_NICKNAMEINUSE
"<nick> :Nickname is already in use"when you try to switch to a nickname that already exists, this is what you get back. someone already has that name, sis 💅
436 ERR_NICKCOLLISION
"<nick> :Nickname collision KILL from <user>@<host>"a server sends this to a client when it spots a nickname collision (a registered NICK that already exists on another server). it's a whole drama 🎭
437 ERR_UNAVAILRESOURCE
"<nick/channel> :Nick/channel is temporarily unavailable"- a server sends this to a user trying to join a channel that's blocked by the channel delay mechanism
- a server sends this to a user trying to change nickname when the nickname they want is blocked by the nick delay mechanism
temporarily unavailable, not forever. chill for a sec ⏳
441 ERR_USERNOTINCHANNEL
"<nick> <channel> :They aren't on that channel"the target of your command isn't on the channel you named. they're not there, bestie 🫥
442 ERR_NOTONCHANNEL
"<channel> :You're not on that channel"a client tried to do something channel-related but isn't a member of that channel. you gotta join first 🚪
443 ERR_USERONCHANNEL
"<user> <channel> :is already on channel"you tried to invite someone to a channel they're already in. they're already here, babe 🙃
444 ERR_NOLOGIN
"<user> :User not logged in"the summon after a SUMMON command couldn't go through because that user wasn't logged in. they're offline, no summoning 📵
445 ERR_SUMMONDISABLED
":SUMMON has been disabled"this is the reply to the SUMMON command. any server that doesn't implement SUMMON MUST return this one 🚫
446 ERR_USERSDISABLED
":USERS has been disabled"this is the reply to the USERS command. any server that does not implement USERS MUST return this one 🚫
451 ERR_NOTREGISTERED
":You have not registered"the server is telling the client it MUST be registered before the server will parse it in detail. registration first, main character later 📝
461 ERR_NEEDMOREPARAMS
"<command> :Not enough parameters"lots of commands send this when the client didn't give enough parameters. more info, pretty please 🥹
462 ERR_ALREADYREGISTRED
":Unauthorized command (already registered)"the server sends this to any link that tries to change part of its registered details, like the password or the user details from a second USER message. one registration per customer 🔐
463 ERR_NOPERMFORHOST
":Your host isn't among the privileged"this goes to a client trying to register with a server that hasn't been set up to allow connections from the host it's connecting from. not on the guest list 🚫
464 ERR_PASSWDMISMATCH
":Password incorrect"a password was needed to register the connection, and it was either missing or wrong. wrong key, no entry 🔑
465 ERR_YOUREBANNEDCREEP
":You are banned from this server"this one is for when you try to connect and register with a server that has been set up to explicitly deny your connections. banned, bestie 🚷
466 ERR_YOUWILLBEBANNEDthe server sends this to a user to say access is about to be denied. the warning shot 🔫
467 ERR_KEYSET
"<channel> :Channel key already set"
471 ERR_CHANNELISFULL
"<channel> :Cannot join channel (+l)"
472 ERR_UNKNOWNMODE
"<char> :is unknown mode char to me for <channel>"
473 ERR_INVITEONLYCHAN
"<channel> :Cannot join channel (+i)"
474 ERR_BANNEDFROMCHAN
"<channel> :Cannot join channel (+b)"
475 ERR_BADCHANNELKEY
"<channel> :Cannot join channel (+k)"
476 ERR_BADCHANMASK
"<channel> :Bad Channel Mask"
477 ERR_NOCHANMODES
"<channel> :Channel doesn't support modes"
478 ERR_BANLISTFULL
"<channel> <char> :Channel list is full"this whole group is the channel-side drama: a key already set, a full room, invite-only, banned, bad key, bad mask, no modes allowed, and a full ban list. the velvet rope is out here 🎟️
481 ERR_NOPRIVILEGES
":Permission Denied- You're not an IRC operator"any command that needs operator privileges MUST return this error when the attempt doesn't work. nope, not an operator 🛑
482 ERR_CHANOPRIVSNEEDED
"<channel> :You're not channel operator"any command that needs 'chanop' privileges (like MODE messages) MUST return this error if the client trying it isn't a chanop on that channel. you gotta be the mod 👑
483 ERR_CANTKILLSERVER
":You can't kill a server!"any attempt to use KILL on a server gets refused, and this error goes straight back to the client. servers are not for killing 😤
484 ERR_RESTRICTED
":Your connection is restricted!"the server sends this to a user when they connect, to show the connection is restricted (user mode +r). a little limited, but still iconic 🧊
485 ERR_UNIQOPPRIVSNEEDED
":You're not the original channel operator"any MODE that needs "channel creator" privileges MUST return this error if the client making the attempt isn't a chanop on that channel. the OG owner only, sorry 👑
491 ERR_NOOPERHOST
":No O-lines for your host"if a client sends an OPER message and the server hasn't been configured to let that client's host connect as an operator, this error MUST be returned. no O-lines for you 🙅♀️
501 ERR_UMODEUNKNOWNFLAG
":Unknown MODE flag"the server sends this when a MODE message came in with a nickname parameter and the mode flag in it wasn't recognized. what even is that flag 🤨
502 ERR_USERSDONTMATCH
":Cannot change mode for other users"this goes to anyone who tries to view or change the user mode of somebody who isn't them. eyes on your own mode, babe 👀
5.3 Reserved numerics 🎀
these numerics aren't described above, because they fall into one of these categories:
- no longer in use;
- reserved for future planned use;
- in current use but are part of a non-generic 'feature' of the current IRC server.
here's the full list, no notes, just vibes 🦋
231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES
233 RPL_SERVICE
300 RPL_NONE 316 RPL_WHOISCHANOP
361 RPL_KILLDONE 362 RPL_CLOSING
363 RPL_CLOSEEND 373 RPL_INFOSTART
384 RPL_MYPORTIS
213 RPL_STATSCLINE 214 RPL_STATSNLINE
215 RPL_STATSILINE 216 RPL_STATSKLINE
217 RPL_STATSQLINE 218 RPL_STATSYLINE
240 RPL_STATSVLINE 241 RPL_STATSLLINE
244 RPL_STATSHLINE 244 RPL_STATSSLINE
246 RPL_STATSPING 247 RPL_STATSBLINE
250 RPL_STATSDLINE
492 ERR_NOSERVICEHOSTand that's the whole error and reserved lineup, bestie 💖🌈
6. Current implementations 💅
okay so the IRC software, version 2.10, is the only complete implementation of the IRC protocol, client and server 🫶 that's it, that's the list. 😭 The client protocol hasn't changed much since RFC 1459 [IRC] came out, so implementations that follow it are likely to be compliant with this protocol already, or only need a small amount of changes to get there ✨
7. Current problems 🙈
ngl there are a bunch of known problems with the IRC Client Protocol, and more broadly with the IRC Server Protocol 💀 the reason it's so messy is that they wanted to keep old clients working, so this protocol has barely evolved since RFC 1459 [IRC] dropped. that's the tea ☕
7.1 Nicknames 💖
the nickname is SO convenient for talking to people outside of a channel, but the nickname space is finite, and of course people all want the same cute nick 😭 if two people pick the same nickname using this protocol, one of them won't succeed, or both of them get removed by a server KILL (See Section 3.7.1). mood 🥲
7.2 Limitation of wildcards 🦋
there's no way to escape the escape character \ (%x5C) 🙃 usually that's fine, but it means you can't build a mask with a backslash \ sitting in front of a wildcard, and that's a real vibe killer 💅
7.3 Security considerations 🔥
security issues for this protocol live in the "IRC Server Protocol" [IRC-SERVER] doc, because they're mostly a problem for the server side of the connection. go read that one, bestie, it's serious 🔒
8. Current support and availability 🌈
here's where to find the IRC crew:
Mailing lists for IRC related discussion:
General discussion: ircd-users@irc.org
Protocol development: ircd-dev@irc.org
Software implementations:
ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://ftp.irc.org/irc/clients
Newsgroup: alt.irc9. Acknowledgements 🫶
parts of this doc were copied from RFC 1459 [IRC], which was the first one to formally document the IRC Protocol 👑 it also got polished by lots of rounds of review and comments, and these people really carried the vibe 💜
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
10. References 📚
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
- [HNAME] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
- [IRC] Oikarinen, J. & D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
- [IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
- [IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
- [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
11. Author's Address 🧚
Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
USA
EMail: kalt@stealth.net12. Full Copyright Statement 🎀
Copyright (C) The Internet Society (2000). All Rights Reserved. 🌸
this doc and its translations can be copied and shared with others, and derivative works that comment on it, explain it, or help with implementing it can be written, copied, published, and distributed, in whole or in part, with no restrictions at all. the only catch is that the copyright notice and this paragraph have to stay on every copy and derivative work 📝 this document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. the exceptions are for developing Internet standards, where the Internet Standards process copyright procedures must be followed, or translating it into languages other than English.
the limited permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns ✨
this document and the information in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭
Acknowledgement
funding for the RFC Editor function is currently provided by the Internet Society 💖🦋
📦 where this page comes from
- ietf: rfc2812 2000-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms