RFC 1459
Internet Relay Chat Protocol
Part 1 of 12 🎀
Title Block 💖
okay so this is RFC 1459, the Internet Relay Chat Protocol 🦋 it was written by J. Oikarinen and D. Reed and it's dated May 1993. It's an Experimental Protocol (that's its category/status), and the title block doesn't list anything it obsoletes or updates. so it's a fresh start, no drama 💅
Status of This Memo ✨
this memo defines an Experimental Protocol for the Internet community, and they're literally asking for discussion and suggestions for improvement 🫶 for the actual standardization state and status of this protocol, you'd check the current edition of the "IAB Official Protocol Standards." and distribution of this memo is unlimited, so share it with everyone 🌸
Abstract 🦋
okay the IRC protocol was built over the last 4 years, and it started as a way for people on a BBS to chat with each other 💬 now it's a worldwide network of servers and clients, and it's stringing to cope with growth 😭 over the past 2 years, the average number of users connected to the main IRC network has grown by a factor of 10. TEN. 🔥
the IRC protocol is text-based, and the simplest client can be literally any socket program that can connect to the server 🧚 no fancy app required, iconic.
Table of Contents 🍓
1. INTRODUCTION ............................................... 4
1.1 Servers ................................................ 4
1.2 Clients ................................................ 5
1.2.1 Operators .......................................... 5
1.3 Channels ................................................ 5
1.3.1 Channel Operators .................................... 6
2. THE IRC SPECIFICATION ....................................... 7
2.1 Overview ................................................ 7
2.2 Character codes ......................................... 7
2.3 Messages ................................................ 7
2.3.1 Message format in 'pseudo' BNF .................... 8
2.4 Numeric replies ......................................... 10
3. IRC Concepts ................................................ 10
3.1 One-to-one communication ................................ 10
3.2 One-to-many ............................................. 11
3.2.1 To a list .......................................... 11
3.2.2 To a group (channel) ............................... 11
3.2.3 To a host/server mask .............................. 12
3.3 One to all .............................................. 12
3.3.1 Client to Client ................................... 12
3.3.2 Clients to Server .................................. 12
3.3.3 Server to Server ................................... 12
4. MESSAGE DETAILS ............................................. 13
4.1 Connection Registration ................................. 13
4.1.1 Password message ................................... 14
4.1.2 Nickname message ................................... 14
4.1.3 User message ....................................... 15
4.1.4 Server message ..................................... 16
4.1.5 Operator message ................................... 17
4.1.6 Quit message ....................................... 17
4.1.7 Server Quit message ................................ 18
4.2 Channel operations ...................................... 19
4.2.1 Join message ....................................... 19
4.2.2 Part message ....................................... 20
4.2.3 Mode message ....................................... 21
4.2.3.1 Channel modes ................................. 21
4.2.3.2 User modes .................................... 22
4.2.4 Topic message ...................................... 23
4.2.5 Names message ...................................... 24
4.2.6 List message ....................................... 24
4.2.7 Invite message ..................................... 25
4.2.8 Kick message ....................................... 25
4.3 Server queries and commands ............................. 26
4.3.1 Version message .................................... 26
4.3.2 Stats message ...................................... 27
4.3.3 Links message ...................................... 28
4.3.4 Time message ....................................... 29
4.3.5 Connect message .................................... 29
4.3.6 Trace message ...................................... 30
4.3.7 Admin message ...................................... 31
4.3.8 Info message ....................................... 31
4.4 Sending messages ........................................ 32
4.4.1 Private messages ................................... 32
4.4.2 Notice messages .................................... 33
4.5 User-based queries ...................................... 33
4.5.1 Who query .......................................... 33
4.5.2 Whois query ........................................ 34
4.5.3 Whowas message ..................................... 35
4.6 Miscellaneous messages .................................. 35
4.6.1 Kill message ....................................... 36
4.6.2 Ping message ....................................... 37
4.6.3 Pong message ....................................... 37
4.6.4 Error message ...................................... 38
5. OPTIONAL MESSAGES ........................................... 38
5.1 Away message ............................................ 38
5.2 Rehash command .......................................... 39
5.3 Restart command ......................................... 39
5.4 Summon message .......................................... 40
5.5 Users message ........................................... 40
5.6 Operwall command ........................................ 41
5.7 Userhost message ........................................ 42
5.8 Ison message ............................................ 42
6. REPLIES ..................................................... 43
6.1 Error Replies ........................................... 43
6.2 Command responses ....................................... 48
6.3 Reserved numerics ....................................... 56
7. Client and server authentication ............................ 56
8. Current Implementations Details ............................. 56
8.1 Network protocol: TCP ................................... 57
8.1.1 Support of Unix sockets ............................ 57
8.2 Command Parsing ......................................... 57
8.3 Message delivery ........................................ 57
8.4 Connection 'Liveness' ................................... 58
8.5 Establishing a server-client connection ................. 58
8.6 Establishing a server-server connection ................. 58
8.6.1 State information exchange when connecting ......... 59
8.7 Terminating server-client connections ................... 59
8.8 Terminating server-server connections ................... 59
8.9 Tracking nickname changes ............................... 60
8.10 Flood control of clients ............................... 60
8.11 Non-blocking lookups ................................... 61
8.11.1 Hostname (DNS) lookups ............................ 61
8.11.2 Username (Ident) lookups .......................... 61
8.12 Configuration file ..................................... 61
8.12.1 Allowing clients to connect ....................... 62
8.12.2 Operators ......................................... 62
8.12.3 Allowing servers to connect ....................... 62
8.12.4 Administrivia ..................................... 63
8.13 Channel membership ..................................... 63
9. Current problems ............................................ 63
9.1 Scalability ............................................. 63
9.2 Labels .................................................. 63
9.2.1 Nicknames .......................................... 63
9.2.2 Channels ........................................... 64
9.2.3 Servers ............................................ 64
9.3 Algorithms .............................................. 64
10. Support and availability ................................... 64
11. Security Considerations .................................... 65
12. Authors' Addresses ......................................... 651. INTRODUCTION ✨
okay so IRC (Internet Relay Chat) has been designed over a bunch of years for text-based conferencing 💬 this document describes the current IRC protocol, bestie 🧚
the IRC protocol has been developed on systems that use the TCP/IP network protocol, but there's no requirement that TCP/IP stays the only place it can run 🌈 it's giving flexibility.
IRC itself is a teleconferencing system, and thanks to the client-server model it's super well-suited to running on lots of machines in a distributed way 🔥 a typical setup has one process (the server) acting as the central point for clients (or other servers) to connect to, and it handles the message delivery/multiplexing and other functions. main character energy for the server, ngl 👑
1.1 Servers
the server is the backbone of IRC 🦴 it gives clients a place to connect so they can talk to each other, and a place for other servers to connect so they form an IRC network 🌸 the only network configuration allowed for IRC servers is a spanning tree [see Fig. 1], where each server is a central node for the rest of the net it can see. so it's like a tree, not a messy web, and that's lowkey so organized 🍓
[ Server 15 ] [ Server 13 ] [ Server 14]
/ \ /
/ \ /
[ Server 11 ] ------ [ Server 1 ] [ Server 12]
/ \ /
/ \ /
[ Server 2 ] [ Server 3 ]
/ \ \
/ \ \
[ Server 4 ] [ Server 5 ] [ Server 6 ]
/ | \ /
/ | \ /
/ | \____ /
/ | \ /
[ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ]
:
[ etc. ]
:
[ Fig. 1. Format of IRC server network ]1.2 Clients
a client is anything connecting to a server that isn't another server 💅 every client gets told apart from the others by a unique nickname, and nicknames have a maximum length of nine (9) characters 🎀 the protocol grammar rules say what may and may not be used in a nickname, so check those if you're picking a name.
and here's the important bit: all servers must have the following info about all clients 🫶 the real name of the host that the client is running on, the username of the client on that host, and the server the client is connected to. no cap, that's the whole client identity situation 🔥
1.2.1 Operators 👑
Okay so, to keep some order on the IRC network, there's a special class of clients called operators (opers) who get to do general maintenance stuff across the whole network. ngl their powers are kinda 'dangerous' 💀 but they're nonetheless required, bestie. Operators SHOULD be able to do basic network chores like disconnecting and reconnecting servers when needed, so bad network routing doesn't stick around forever 🔧. That's why the protocol only lets operators do these things. See sections 4.1.7 (SQUIT) and 4.3.5 (CONNECT).
A more controversial power of operators is the ability to remove a user from the connected network by 'force' 😤, aka operators can close the connection between any client and server. The justification for this is delicate, since its abuse is both destructive and annoying 🙈. For more details on this type of action, see section 4.6.1 (KILL).
1.3 Channels 🦋
A channel is a named group of one or more clients who will ALL get messages addressed to that channel 💌. It's created implicitly when the first client joins, and it ceases to exist when the last client leaves. While the channel exists, any client can reference it using the channel's name.
Channel names are strings beginning with a '&' or '#' character, up to 200 characters long 🎀. Apart from the first character being either '&' or '#', the only restriction is that the name may not contain any spaces (' '), a control G (^G or ASCII 7), or a comma (','), which the protocol uses as a list item separator.
There are two types of channels allowed by this protocol 🌈. One is a distributed channel, which is known to all the servers connected to the network. These channels are marked by the first character being a '#'. The other is a local channel, which only clients on the server where it exists may join. These are distinguished by a leading '&' character. On top of these two types, there are the various channel modes available to alter the characteristics of individual channels. See section 4.2.3 (MODE command) for more details on this.
To create a new channel or become part of an existing one, a user is REQUIRED to JOIN the channel ✨. If the channel doesn't exist prior to joining, the channel is created and the creating user becomes a channel operator 👑. If the channel already exists, whether or not your request to JOIN is honoured depends on the channel's current modes. For example, if the channel is invite-only (+i), you may only join if you've been invited. A user may be a part of several channels at once, but a limit of ten (10) channels is RECOMMENDED as being ample for both experienced and novice users. See section 8.13 for more information on this.
If the IRC network becomes disjoint because of a split between two servers, the channel on each side is only composed of those clients connected to servers on the respective sides of the split, and it might cease to exist on one side of the split 💔. When the split is healed, the connecting servers announce to each other who they think is in each channel and what mode that channel is in. If the channel exists on both sides, the JOINs and MODEs are interpreted in an inclusive manner, so that both sides of the new connection agree about which clients are in the channel and what modes the channel has 🫶.
1.3.1 Channel Operators 💅
The channel operator (also referred to as a "chop" or "chanop") on a given channel is considered to 'own' that channel 👑. In recognition of this status, channel operators get certain powers that let them keep control and some sort of sanity in their channel 🧚. As the owner of a channel, a channel operator is not required to have reasons for their actions. Still, if their actions are generally antisocial or otherwise abusive, it might be reasonable to ask an IRC operator to step in, or for the users to just leave and go form their own channel 🏃♀️.
The commands which may only be used by channel operators are:
KICK - Eject a client from the channel
MODE - Change the channel's mode
INVITE - Invite a client to an invite-only channel (mode +i)
TOPIC - Change the channel topic in a mode +t channelA channel operator is identified by the '@' symbol next to their nickname whenever it is associated with a channel (ie replies to the NAMES, WHO and WHOIS commands) 🎀.
2. The IRC Specification 📜
2.1 Overview 🌸
The protocol as described herein is for use both with server to server and client to server connections. There are, however, more restrictions on client connections (which are considered to be untrustworthy 🙅♀️) than on server connections.
2.2 Character codes 🔤
No specific character set is specified. The protocol is based on a set of codes composed of eight (8) bits, making up an octet. Each message may be composed of any number of these octets. However, some octet values are used for control codes which act as message delimiters 🚦.
Regardless of being an 8-bit protocol, the delimiters and keywords are such that the protocol is mostly usable from a USASCII terminal and a telnet connection 💻.
Because of IRC's scandanavian origin 🇸🇪, the characters {}| are considered to be the lower case equivalents of the characters []\, respectively. This is a critical issue when determining the equivalence of two nicknames 🚨.
2.3 Messages 💌
Servers and clients send each other messages which may or may not generate a reply. If the message contains a valid command, as described in later sections, the client SHOULD expect a reply as specified. It's not advised to wait forever for the reply though, since client to server and server to server communication is essentially asynchronous in nature ⏳.
Each IRC message may consist of up to three main parts: the prefix (optional), the command, and the command parameters (of which there may be up to 15) 🧩. The prefix, command, and all parameters are separated by one (or more) ASCII space character(s) (0x20).
The presence of a prefix is indicated with a single leading ASCII colon character (':', 0x3b), which MUST be the first character of the message itself. There MUST be no gap (whitespace) between the colon and the prefix. The prefix is used by servers to indicate the true origin of the message 🕵️♀️. If the prefix is missing from the message, it is assumed to have originated from the connection it was received on. Clients SHOULD NOT use a prefix when sending a message from themselves. If they do use one, the only valid prefix is the registered nickname associated with the client. If the source identified by the prefix cannot be found in the server's internal database, or if the source is registered from a different link than the one the message arrived on, the server MUST ignore the message silently 🤫.
The command MUST either be a valid IRC command or a three (3) digit number represented in ASCII text 🔢.
IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and these messages SHALL NOT exceed 512 characters in length, counting all characters including the trailing CR-LF 📏. Thus, there are 510 characters maximum allowed for the command and its parameters. There is no provision for continuation message lines. See section 7 for more details about current implementations.
2.3.1 Message format in 'pseudo' BNF 🧁
The protocol messages MUST be extracted from the contiguous stream of octets. The current solution is to designate two characters, CR and LF, as message separators. Empty messages are silently ignored, which permits use of the sequence CR-LF between messages without extra problems 🎉.
The extracted message is parsed into the components <prefix>, <command> and list of parameters, matched either by <middle> or <trailing> components.
The BNF representation for this is:
<message> ::= [':' <prefix> <SPACE> ] <command> <params> <crlf>
<prefix> ::= <servername> | <nick> [ '!' <user> ] [ '@' <host> ]
<command> ::= <letter> { <letter> } | <number> <number> <number>
<SPACE> ::= ' ' { ' ' }
<params> ::= <SPACE> [ ':' <trailing> | <middle> <params> ]
<middle> ::= <Any *non-empty* sequence of octets not including SPACE
or NUL or CR or LF, the first of which may not be ':'>
<trailing> ::= <Any, possibly *empty*, sequence of octets not including
NUL or CR or LF>
<crlf> ::= CR LFNOTES:
<SPACE>consists only of SPACE character(s) (0x20). Specially notice that TABULATION, and all other control characters, are considered NON-WHITE-SPACE 🙋♀️.- After extracting the parameter list, all parameters are equal, whether matched by
<middle>or<trailing>.<trailing>is just a syntactic trick to allow SPACE within a parameter 🪄. - The fact that CR and LF cannot appear in parameter strings is just an artifact of the message framing. This might change later.
- The NUL character is not special in message framing, and basically could end up inside a parameter. But it would cause extra complexities in normal C string handling, so NUL is not allowed within messages 🚫.
- The last parameter may be an empty string.
- Use of the extended prefix (
['!' <user> ] ['@' <host> ]) MUST NOT be used in server to server communications. It's only intended for server to client messages, to give clients more useful information about who a message is from without the need for additional queries 🔍.
Most protocol messages specify additional semantics and syntax for the extracted parameter strings, dictated by their position in the list. For example, many server commands will assume that the first parameter after the command is the list of targets, which can be described with:
<target> ::= <to> [ "," <target> ]
<to> ::= <channel> | <user> '@' <servername> | <nick> | <mask>
<channel> ::= ('#' | '&') <chstring>
<servername> ::= <host>
<host> ::= see RFC 952 [DNS:4] for details on allowed hostnames
<nick> ::= <letter> { <letter> | <number> | <special> }
<mask> ::= ('#' | '$') <chstring>
<chstring> ::= <any 8bit code except SPACE, BELL, NUL, CR, LF and
comma (',')>Other parameter syntaxes are:
<user> ::= <nonwhite> { <nonwhite> }
<letter> ::= 'a' ... 'z' | 'A' ... 'Z'
<number> ::= '0' ... '9'
<special> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'
<nonwhite> ::= <any 8bit code except SPACE (0x20), NUL (0x0), CR
(0xd), and LF (0xa)>2.4 Numeric replies 🎀
Most of the messages sent to the server generate a reply of some sort. The most common reply is the numeric reply, which is used for both errors and normal replies 🔢. The numeric reply MUST be sent as one message consisting of the sender prefix, the three digit numeric, and the target of the reply. A numeric reply is not allowed to originate from a client, so any such messages received by a server are silently dropped 🙅♀️. In all other respects, a numeric reply is just like a normal message, except that the keyword is made up of 3 numeric digits rather than a string of letters. A list of different replies is supplied in section 6 💖.
3. IRC Concepts ✨
okay so this section is where we get into how IRC is actually organised 🫶 it's all about how the servers and clients pass messages around, and how different implementations deliver the different kinds of messages. main character energy for sure 💅
Here's a little map of a sample small network, bestie:
1--\
A D---4
2--/ \ /
B----C
/ \
3 E
Servers: A, B, C, D, E Clients: 1, 2, 3, 4 [ Fig. 2. Sample small IRC network ]3.1 One-to-one communication
okay so one-to-one chats are mostly a client thing 💖 servers don't usually just chat with each other all day. to keep private convos safe, it is REQUIRED that all servers can send a message in exactly one direction along the spanning tree so it can reach any client 🌸 and the path a message takes is the shortest path between any two points on that spanning tree ✨
The examples below all use Figure 2, obviously 🧚
Example 1: a message between clients 1 and 2 is only seen by server A, which sends it straight to client 2 💌
Example 2: a message between clients 1 and 3 is seen by servers A & B, and client 3. no other clients or servers are allowed to see it 🙈
Example 3: a message between clients 2 and 4 is seen by servers A, B, C & D and client 4 only 🫣
3.2 One-to-many
the whole point of IRC is to be a forum where people can easily and efficiently have group convos (one to many) 🎀 there are a few ways to do this, and each one has its own purpose 🦋
3.2.1 To a list
the least efficient way to do one-to-many is by talking to a 'list' of users 💀 it's pretty self explanatory: the client hands over a list of destinations, and the server splits it up and sends a separate copy to each one. it's not as efficient as a group because the list gets broken up and the copies get sent without checking whether duplicates are going down the same path 😭
3.2.2 To a group (channel)
okay this one is giving 🔥 a channel is basically IRC's version of a multicast group. channels come and go as people join and leave, and the actual convo is only sent to the servers that are looking after users in that channel 💜 if a server has several users in the same channel, the message text is sent to that server only once, and then it gets delivered to each client in the channel from there ✨ this keeps going for each client-server pair until the message has fanned out and reached every member 🌈
The following examples all use Figure 2 🦋
Example 4: any channel with 1 client in it. messages to the channel go to the server and then nowhere else 🍓
Example 5: 2 clients in a channel. every message travels the same path as a private message between those two clients would, outside a channel 🫶
Example 6: clients 1, 2 and 3 in a channel. all messages to the channel go to all clients, and only through the servers that a private message to a single client would have to pass through 👑 if client 1 sends a message, it goes back to client 2 and then via server B to client 3 💅
3.2.3 To a host/server mask
so IRC operators need a way to message a big group of related users at once, which is where host and server masks come in 🌸 these messages go to users whose host or server info matches the mask. they only get sent to places where those users actually are, kind of like how channels work 💖
3.3 One-to-all
one-to-all messages are really just broadcasts, sent to all clients, all servers, or both 📣 on a big network, one message can create a LOT of traffic as it tries to reach every destination 😩
some messages have no choice but to get broadcast to all servers, so that the state info each server holds stays pretty consistent across the network ✨
3.3.1 Client-to-Client
there is no kind of message that, from one single message, ends up being sent to every other client 🙅♀️
3.3.2 Client-to-Server
most commands that change state info (things like channel membership, channel mode, user status, and so on) MUST be sent to all servers by default, and the client MAY not change this distribution 🔒
3.3.3 Server-to-Server.
most messages between servers get distributed to all the 'other' servers 🧚 but this is only REQUIRED for messages that affect a user, channel or server. since those are the basic building blocks of IRC, basically every message that starts from a server gets broadcast to all the other connected servers 💜
4. Message details ✨
okay this is the fun part, bestie 🎀 this section describes each message that the IRC server and client recognise. every command in here MUST be implemented by any server for this protocol 💪
if the reply ERR_NOSUCHSERVER is listed for a command, it means the <server> parameter couldn't be found 💀 and after that the server MUST NOT send any other replies for that command 🙈
the server a client is connected to is REQUIRED to parse the whole message and return any appropriate errors 🔍 if it runs into a fatal error while parsing, an error MUST be sent back to the client and the parsing stops there 🛑 a fatal error can be things like an incorrect command, a destination the server doesn't know about (server, nick or channel names fall into this), not enough parameters, or incorrect privileges 😭
if a full set of parameters is given, then each one MUST be checked for validity, and the right responses get sent back to the client 💖 for messages that use comma-separated parameter lists, a reply MUST be sent for each item 🫶
in some of the examples below, messages show up in the full format:
:Name COMMAND parameter listthese examples show a message from "Name" in transit between servers 🦋 including the original sender's name is super important, so remote servers can send a reply back along the correct path 🧚
4.1 Connection Registration
these commands are used to register a connection with an IRC server, either as a user or as a server, and also to disconnect properly 💅
a "PASS" command is not REQUIRED for a client or server connection to get registered, BUT it MUST come before the server message or the later of the NICK/USER combo ✨ it is strongly RECOMMENDED that all server connections have a password, for some security on those connections 🔐 the RECOMMENDED order for a client to register goes like this:
- Pass message
- Nick message
- User message
4.1.1 Password message
Command: PASS
Parameters: <password>the PASS command sets a 'connection password' 🔑 the password can and MUST be set before any attempt to register the connection is made 💜 right now that means clients MUST send a PASS command before the NICK/USER combination, and servers MUST send a PASS command before any SERVER command 🫶 the password supplied MUST match the one in the C/N lines (for servers) or the I lines (for clients) ✅ you can send multiple PASS commands before registering, but only the last one sent is used for verification, and it MAY not be changed once you're registered 🙅♀️ Numeric Replies:
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTREDExample:
PASS secretpasswordhere4.1.2 Nick message
Command: NICK
Parameters: <nickname> [ <hopcount> ]the NICK message gives a user a nickname or changes their previous one 🎀 the <hopcount> parameter is only used by servers to show how far away a nick is from its home server 🗺️ a local connection has a hopcount of 0, and if a client sends one, it MUST be ignored 🙈
if a NICK message reaches a server that already knows about an identical nickname for another client, that's a nickname collision 💀 when that happens, every instance of the nickname gets removed from the server's database, and a KILL command is issued to remove the nickname from every other server's database too 😱 if the NICK causing the collision was a nickname change, then the original (old) nick MUST be removed as well 🧹
if the server gets an identical NICK from a client that's directly connected, it MAY issue an ERR_NICKCOLLISION to the local client, drop the NICK command, and skip generating any kills 🫣
Numeric Replies:
ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
ERR_NICKNAMEINUSE ERR_NICKCOLLISIONExample:
NICK Wiz ; Introducing new nick "Wiz".
:WiZ NICK Kilroy ; WiZ changed his nickname to Kilroy.4.1.3 User message
Command: USER
Parameters: <username> <hostname> <servername> <realname>the USER message is sent at the start of a connection to set the username, hostname, servername and realname of a new user 🌷 servers also use it to tell each other about a new user arriving on IRC 🛰️ a user only becomes registered after both USER and NICK have been received from a client 🎉
between servers, USER MUST to be prefixed with the client's NICKname 💅 hostname and servername are normally ignored by the IRC server when USER comes from a directly connected client (for security reasons), but they get used in server to server communication 🔐 this means a NICK MUST always be sent to a remote server when a new user is being introduced to the rest of the network, before the matching USER is sent 🫶
It MUST be noted that the realname parameter MUST be the last parameter, because it MAY contain space characters and MUST be prefixed with a colon (':') so it's recognised as such 🌈
since it's super easy for a client to lie about its username just by using the USER message, an "Identity Server" is RECOMMENDED 🕵️♀️ if the host a user connects from has one enabled, the username gets set to whatever the "Identity Server" replies with ✨
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTREDExamples:
USER guest tolmoon tolsun :Ronnie Reagan
; User registering themselves with a
username of "guest" and real name
"Ronnie Reagan".:testnick USER guest tolmoon tolsun :Ronnie Reagan
; message between servers with the
nickname for which the USER command
belongs to4.1.4 Server message ✨
Command: SERVER
Parameters: <servername> <hopcount> <info>okay so the SERVER message is how you tell a server that the other end of a brand new connection is ALSO a server 🖥️ it's giving introduction energy 💅 it's also how server data gets passed around the whole net. when a new server joins, its info gets broadcast to the entire network, bestie 🌐 <hopcount> gives every server some internal info about how far away everyone is. with a full server list you could literally map the whole server tree 🗺️ but hostmasks stop that from happening, so no full map for you 🙈
the SERVER message can only be accepted from either (a) a connection that hasn't registered yet and is trying to register as a server, or (b) an existing connection to another server. in case (b), the SERVER message is introducing a new server sitting behind that server 🧚
most errors when a SERVER command gets received end with the connection being terminated by the destination host (the target SERVER) 💀 error replies are usually sent with the "ERROR" command instead of a numeric, since ERROR has a few useful properties that make it perfect here ✨
now the big drama 😭 if a SERVER message tries to introduce a server that the receiving server already knows about, the connection that message came in on has to be closed (following the correct procedures). why? because a duplicate route to a server just formed, and the acyclic nature of the IRC tree got broken 💔
Numeric Replies:
ERR_ALREADYREGISTREDExample:
SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server
; New server test.oulu.fi introducing
itself and attempting to register. The
name in []'s is the hostname for the
host running test.oulu.fi.
:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
; Server tolsun.oulu.fi is our uplink
for csd.bu.edu which is 5 hops away.4.1.5 Oper 👑
Command: OPER
Parameters: <user> <password>the OPER message is how a normal user levels up to operator privileges 🔥 you need BOTH the <user> and the <password> to unlock it, no shortcuts 🔐
if the client sends the correct password for the given user, the server tells the rest of the network about the new operator by issuing a "MODE +o" for that client's nickname 🌟 the whole network gets to see the glow-up 💖
the OPER message is client-server only, so it doesn't travel between servers 🚫
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.4.1.6 Quit 👋
Command: QUIT
Parameters: [<Quit message>]a client session ends with a quit message, bestie 🫶 the server must close the connection to any client that sends a QUIT message. if a "Quit Message" is given, that gets sent instead of the default message, which is just the nickname 🎀
when a netsplit happens (two servers disconnecting from each other), the quit message is made from the names of the two servers involved, separated by a space. the first name is the server that's still connected, and the second name is the server that just got disconnected 🌊
if a client connection closes for some other reason without the client sending a QUIT (like the client just dies and EOF happens on the socket) 💀, the server is required to fill in the quit message with something that reflects what caused it ✨
Numeric Replies:
None.Examples:
QUIT :Gone to have lunch ; Preferred message format.4.1.7 Server quit message 🧨
Command: SQUIT
Parameters: <server> <comment>the SQUIT message is needed to tell everyone about servers that are quitting or dead ☠️ if a server wants to break its connection to another server, it has to send a SQUIT message to the other server, using that other server's name as the server parameter. then the other server closes its connection to the quitting one 🔌
this command is also available to operators, so they can help keep a network of IRC servers connected in an orderly way 👑 operators can even issue a SQUIT for a remote server connection. in that case, the SQUIT has to be parsed by each server in between the operator and the remote server, and each one updates its view of the network as explained below 🗺️
the <comment> should be supplied by every operator who runs a SQUIT on a remote server (one that isn't connected to the server they're currently on), so the other operators know why it happened 📝 servers can also fill in the <comment> with an error or similar message 🚨
both servers on either side of the connection being closed are required to send out a SQUIT message (to all of their other server connections) for every other server that's considered to be behind that link 💥
it's the same deal for clients: a QUIT message has to be sent to the rest of the network on behalf of all the clients behind that link. on top of that, every channel member of a channel that lost someone due to the split must be sent a QUIT message too 😭
if a server connection gets terminated prematurely (like the server on the other end of the link died), the server that notices the disconnection is required to tell the rest of the network that the connection has closed, and fill in the comment field with something appropriate 💅
Numeric replies:
ERR_NOPRIVILEGES ERR_NOSUCHSERVERExample:
SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has
been terminated because of "Bad Link".
:Trillian SQUIT cm22.eng.umd.edu :Server out of control
; message from Trillian to disconnect
"cm22.eng.umd.edu" from the net
because "Server out of control".4.2 Channel operations 🌸
this group of messages is all about channels: manipulating them, changing their properties (channel modes), and handling their contents (usually clients) 🦋 when clients at opposite ends of a network send commands that end up clashing, a bunch of race conditions are basically inevitable 💀 that's just the vibe of distributed chaos, periodt.
it's also required that servers keep a nickname history. that way, wherever a <nick> parameter is given, the server can check its history in case that nickname was recently changed 🙈
4.2.1 Join message 🎀
Command: JOIN
Parameters: <channel>{,<channel>} [<key>{,<key>}]the JOIN command is how a client starts listening to a specific channel 👂 whether a client is allowed in is checked ONLY by the server that client is connected to. all the other servers automatically add the user to the channel when they receive the JOIN from other servers 🌐 the conditions that affect this are:
- the user must be invited if the channel is invite-only;
- the user's nick/username/hostname must not match any active bans;
- the correct key (password) must be given if it is set.
these get discussed in more detail under the MODE command (see section 4.2.3 for more details) 🔍
once a user has joined a channel, they get notice about all commands their server receives that affect the channel. that includes MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE 📣 the JOIN command needs to be broadcast to all servers so each server knows where to find the users on the channel. this is what allows optimal delivery of PRIVMSG/NOTICE messages to the channel 💌
if a JOIN is successful, the user is then sent the channel's topic (using RPL_TOPIC) and the list of users who are on the channel (using RPL_NAMREPLY). that list must include the user who just joined 🫶
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
RPL_TOPICExamples:
JOIN #foobar ; join channel #foobar.
JOIN &foo fubar ; join channel &foo using key "fubar".
JOIN #foo,&bar fubar ; join channel #foo using key "fubar"
and &bar using no key.
JOIN #foo,#bar fubar,foobar ; join channel #foo using key "fubar".
and channel #bar using key "foobar".
JOIN #foo,#bar ; join channels #foo and #bar.
:WiZ JOIN #Twilight_zone ; JOIN message from WiZ4.2.2 Part message 🦋
Command: PART
Parameters: <channel>{,<channel>}the PART message makes the client sending it get removed from the list of active users for every channel listed in the parameter string 👋 bye bye, channel 💅
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_NOTONCHANNELExamples:
PART #twilight_zone ; leave channel "#twilight_zone"
PART #oz-ops,&group5 ; leave both channels "&group5" and
"#oz-ops".4.2.3 Mode message 🔮
Command: MODEthe MODE command is a dual-purpose command in IRC ✨ it lets BOTH usernames and channels have their modes changed. the rationale behind that is that one day nicknames will be obsolete, and the equivalent property will be the channel 🌈 the future is channels, bestie.
when parsing MODE messages, it is recommended that the entire message gets parsed first, and then the changes that resulted get passed on 🧠
4.2.3.1 Channel modes 💜
Parameters: <channel> {[+|-]|o|p|s|i|t|n|b|v} [<limit>] [<user>]
[<ban mask>]the MODE command exists so channel operators can change the characteristics of "their" channel 👑 it's also required that servers be able to change channel modes, so that channel operators can be created 🫶
the various modes available for channels are:
o - give/take channel operator privileges;
p - private channel flag;
s - secret channel flag;
i - invite-only channel flag;
t - topic settable by channel operator only flag;
n - no messages to channel from clients on the outside;
m - moderated channel;
l - set the user limit to channel;
b - set a ban mask to keep users out;
v - give/take the ability to speak on a moderated channel;
k - set a channel key (password).okay, here's a little heads-up 🚨 when using the 'o' and 'b' options, there's a restriction of a total of three per mode command. that means any combination of 'o' and
4.2.3.2 User modes
Parameters: <nickname> {[+|-]|i|w|s|o}
okay so user modes are basically the settings that change how everyone else sees you, or what extra messages you get sent 💅 A user MODE command is only accepted if the sender and the nickname in the parameter are the SAME person. No touching someone else's vibe 🙅♀️
The available modes are:
i- marks a users as invisible;s- marks a user for receipt of server notices;w- user receives wallops;o- operator flag.
More modes might show up later on 🦋
If a user tries to make themselves an operator with "+o", the attempt should be ignored. That's a hard no 🙈 BUT anyone is totally free to deop themselves with "-o", no restrictions there. Main character energy, but in reverse 💀
Numeric Replies:
ERR_NEEDMOREPARAMS RPL_CHANNELMODEIS
ERR_CHANOPRIVSNEEDED ERR_NOSUCHNICK
ERR_NOTONCHANNEL ERR_KEYSET
RPL_BANLIST RPL_ENDOFBANLIST
ERR_UNKNOWNMODE ERR_NOSUCHCHANNEL
ERR_USERSDONTMATCH RPL_UMODEIS
ERR_UMODEUNKNOWNFLAGExamples:
Use of Channel Modes:
MODE #Finnish +im ; Makes #Finnish channel moderated and
'invite-only'.
MODE #Finnish +o Kilroy ; Gives 'chanop' privileges to Kilroy on
channel #Finnish.
MODE #Finnish +v Wiz ; Allow WiZ to speak on #Finnish.
MODE #Fins -s ; Removes 'secret' flag from channel
#Fins.
MODE #42 +k oulu ; Set the channel key to "oulu".
MODE #eu-opers +l 10 ; Set the limit for the number of users
on channel to 10.
MODE &oulu +b ; list ban masks set for channel.
MODE &oulu +b *!*@* ; prevent all users from joining.
MODE &oulu +b *!*@*.edu ; prevent any user from a hostname
matching *.edu from joining.Use of user Modes:
:MODE WiZ -w ; turns reception of WALLOPS messages
off for WiZ.
:Angel MODE Angel +i ; Message from Angel to make themselves
invisible.
MODE WiZ -o ; WiZ 'deopping' (removing operator
status). The plain reverse of this
command ("MODE WiZ +o") must not be
allowed from users since would bypass
the OPER command.4.2.4 Topic message
Command: TOPIC Parameters: <channel> [<topic>]
The TOPIC message is how you change or peek at a channel's topic 👀 If you don't give a <topic>, you just get the current topic for <channel> back. If you DO include a <topic>, it gets changed, but only if the channel modes allow it 🫶
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
RPL_NOTOPIC RPL_TOPIC
ERR_CHANOPRIVSNEEDEDExamples:
:Wiz TOPIC #test :New topic ;User Wiz setting the topic.
TOPIC #test :another topic ;set the topic on #test to "another
topic".
TOPIC #test ; check the topic for #test.4.2.5 Names message
Command: NAMES Parameters: [<channel>{,<channel>}]
With NAMES, you can list every nickname you're allowed to see on any channel you can see 🔍 A channel is visible to you if it isn't private (+p) or secret (+s), or if you're actually in it. The <channel> parameter tells it which channel(s) to look at, if they're valid. There's no error reply for bad channel names, so it just... doesn't show anything, no drama 🙃
If you don't give a <channel> parameter, you get a list of all channels and who's in them. At the very end, there's a list of users who are visible but aren't on any channel, or aren't on a visible channel. Those get listed under channel "*" 🌸
Numerics:
RPL_NAMREPLY RPL_ENDOFNAMESExamples:
NAMES #twilight_zone,#42 ; list visible users on #twilight_zone
and #42 if the channels are visible to
you.
NAMES ; list all visible channels and users4.2.6 List message
Command: LIST Parameters: [<channel>{,<channel>} [<server>]]
The list message is for listing channels and their topics 📋 If you use the <channel> parameter, you only see the status of that one channel. Private channels show up as channel "Prv" with no topic, unless the person asking is actually in that channel 🔒 Secret channels don't show up at all unless you're a member of them. Shh 🤫
Numeric Replies:
ERR_NOSUCHSERVER RPL_LISTSTART
RPL_LIST RPL_LISTENDExamples:
LIST ; List all channels.
LIST #twilight_zone,#42 ; List channels #twilight_zone and #424.2.7 Invite message
Command: INVITE Parameters: <nickname> <channel>
INVITE is how you invite people to a channel 💌 The <nickname> is the person you're inviting to the target channel <channel>. The target channel doesn't have to exist or even be a valid channel name, so no stress there ✨ BUT if the channel is invite only (MODE +i), the one sending the invite has to be recognised as a channel operator on that channel 👑
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
ERR_NOTONCHANNEL ERR_USERONCHANNEL
ERR_CHANOPRIVSNEEDED
RPL_INVITING RPL_AWAYExamples:
:Angel INVITE Wiz #Dust ; User Angel inviting WiZ to channel
#Dust
INVITE Wiz #Twilight_Zone ; Command to invite WiZ to
#Twilight_zone4.2.8 Kick command
Command: KICK Parameters: <channel> <user> [<comment>]
KICK is for forcibly removing someone from a channel. Basically it "kicks them out" of the channel, which is a forced PART 🥾 Rude but iconic 💀
Only a channel operator can kick another user out of a channel 👑 Every server that receives a KICK message checks that it's valid (ie the sender is actually a channel operator) before removing the victim from the channel. Double-checking, no cap 🧐
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
ERR_NOTONCHANNELExamples:
KICK &Melbourne Matthew ; Kick Matthew from &Melbourne
KICK #Finnish John :Speaking English
; Kick John from #Finnish using
"Speaking English" as the reason
(comment).
:WiZ KICK #Finnish John ; KICK message from WiZ to remove John
from channel #FinnishNOTE:
It is possible to extend the KICK command parameters to the following: <channel>{,<channel>} <user>{,<user>} [<comment>]
4.3 Server queries and commands
The server query group of commands is designed to return information about any server connected to the network 🌐 All connected servers must respond to these queries, and respond correctly. Any invalid response (or lack thereof) must be considered a sign of a broken server, and it must be disconnected/disabled as soon as possible until the situation is remedied. Yikes, no mercy 😭
When a parameter says "<server>", it will usually mean it can be a nickname, a server, or some sort of wildcard name. For each parameter, though, only one query and set of replies is supposed to be generated 🎀
4.3.1 Version message
Command: VERSION Parameters: [<server>]
The VERSION message is for checking the version of the server program 🧚 An optional <server> parameter lets you query the version of a server program that you aren't directly connected to.
Numeric Replies:
ERR_NOSUCHSERVER RPL_VERSIONExamples:
:Wiz VERSION *.se ; message from Wiz to check the version
of a server matching "*.se"
VERSION tolsun.oulu.fi ; check the version of server
"tolsun.oulu.fi".4.3.2 Stats message
Command: STATS Parameters: [<query> [<server>]]
STATS is for querying statistics of a certain server 📊 If the <server> parameter is left out, you only get the end of stats reply back. How this command works depends a LOT on which server replies, though the server still has to be able to supply the information described by the queries below (or something similar) 💖
A query can be any single letter. Only the destination server checks it (if it's given as the <server> parameter). Otherwise it's passed along by intermediate servers, ignored, and left unaltered 🦋 The queries below are the ones in the current IRC implementation, and they cover a big chunk of the setup info for that server. Other versions might not support them the same way, but all servers should be able to give a valid reply to a STATS query that's consistent with the reply formats currently used and the purpose of the query ✨
The currently supported queries are:
c- returns a list of servers which the server may connect to or allow connections from;h- returns a list of servers which are either forced to be treated as leaves or allowed to act as hubs;i- returns a list of hosts which the server allows a client to connect from;k- returns a list of banned username/hostname combinations for that 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 bytes and messages for each direction;m- returns a list of commands supported by the server and the usage count for each if the usage count is non zero;o- returns a list of hosts from which normal clients may become operators;y- show Y (Class) lines from server's configuration file;u- returns a string showing how long the server has been up.
Numeric Replies:
ERR_NOSUCHSERVER
RPL_STATSCLINE RPL_STATSNLINE
RPL_STATSILINE RPL_STATSKLINE
RPL_STATSQLINE RPL_STATSLLINE
RPL_STATSLINKINFO RPL_STATSUPTIME
RPL_STATSCOMMANDS RPL_STATSOLINE
RPL_STATSHLINE RPL_ENDOFSTATSExamples:
STATS m ; check the command usage for the server
you are connected to
:Wiz STATS c eff.org ; request by WiZ for C/N line
information from server eff.org4.3.3 Links message ✨
Command: LINKS
Parameters: [[<remote server>] <server mask>]okay so LINKS is basically your "show me the whole server family tree" 🌳 With it, a user can list every server the answering server knows about. The list has to match the mask you give it, and if you don't give a mask, you get the full list 💅
If you pass a <remote server> along with the <server mask>, the LINKS command gets forwarded to the first server that matches that name (if there is one). That server is then required to answer the query 🫶
Numeric Replies:
ERR_NOSUCHSERVER
RPL_LINKS RPL_ENDOFLINKSExamples:
LINKS *.au ; list all servers which have a name
that matches *.au;
:WiZ LINKS *.bu.edu *.edu ; LINKS message from WiZ to the first
server matching *.edu for a list of
servers matching *.bu.edu.4.3.4 Time message 🕰️
Command: TIME
Parameters: [<server>]The TIME message is how you ask a server what time it thinks it is 💖 You query the local time from whichever server you name. If you leave out the server parameter, the server handling your command has to reply to the query. No ghosting allowed 👻
Numeric Replies:
ERR_NOSUCHSERVER RPL_TIMEExamples:
TIME tolsun.oulu.fi ; check the time on the server
"tolson.oulu.fi"
Angel TIME *.au ; user angel checking the time on a
server matching "*.au"4.3.5 Connect message 🔌
Command: CONNECT
Parameters: <target server> [<port> [<remote server>]]The CONNECT command lets you force a server to try and set up a brand new connection to another server, right now, no waiting 🔥 It's a privileged command, so it's only available to IRC Operators (the bouncers of the network 👑). If you name a remote server, then that server is the one that makes the CONNECT attempt to <target server> and <port>.
Numeric Replies:
ERR_NOSUCHSERVER ERR_NOPRIVILEGES
ERR_NEEDMOREPARAMSExamples:
CONNECT tolsun.oulu.fi ; Attempt to connect a server to
tolsun.oulu.fi
:WiZ CONNECT eff.org 6667 csd.bu.edu
; CONNECT attempt by WiZ to get servers
eff.org and csd.bu.edu connected on port
6667.4.3.6 Trace message 🦋
Command: TRACE
Parameters: [<server>]TRACE is giving traceroute vibes 🗺️ It's how you find the route to a specific server. Every server that processes this message has to tell the sender about itself by sending back a reply that marks it as a pass-through link. Those replies stack up into a chain, kind of like what you'd get from using "traceroute" ✨ After sending that reply, the server must then pass the TRACE message on to the next server, and keep going until the given server is reached.
If you leave out the <server> parameter, it is recommended that the TRACE command send a message back to the sender listing the servers the current server has a direct connection to 💅
If the destination you gave in "<server>" is an actual server, then that server is required to report all the servers and users connected to it. The catch is that only operators are allowed to see users 🙈 If the destination given by <server> is a nickname, then they only get a reply for that nickname.
Numeric Replies:
ERR_NOSUCHSERVERIf the TRACE message is headed for another server, all the 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_TRACECLASSExamples:
TRACE *.oulu.fi ; TRACE to a server matching *.oulu.fi
:WiZ TRACE AngelDust ; TRACE issued by WiZ to nick AngelDust4.3.7 Admin command 🎀
Command: ADMIN
Parameters: [<server>]ADMIN is how you find out who the admin of a server is 🫶 You get the name of the administrator of the given server, or of the current server if you leave out the <server> parameter. Every server has to be able to forward ADMIN messages on to other servers.
Numeric Replies:
ERR_NOSUCHSERVER
RPL_ADMINME RPL_ADMINLOC1
RPL_ADMINLOC2 RPL_ADMINEMAILExamples:
ADMIN tolsun.oulu.fi ; request an ADMIN reply from
tolsun.oulu.fi
:WiZ ADMIN *.edu ; ADMIN request from WiZ for first
server found to match *.edu.4.3.8 Info command 🌟
Command: INFO
Parameters: [<server>]The INFO command is required to return information that describes the server 🔍 That covers its version, when it was compiled, its patchlevel, when it was started, and any other miscellaneous info that might be considered relevant. It's the server's full little bio 💜
Numeric Replies:
ERR_NOSUCHSERVER
RPL_INFO RPL_ENDOFINFOExamples:
INFO csd.bu.edu ; request an INFO reply from
csd.bu.edu
:Avalon INFO *.fi ; INFO request from Avalon for first
server found to match *.fi.
INFO Angel ; request info from the server that
Angel is connected to.4.4 Sending messages 💌
okay the main point of IRC is giving clients a base to actually talk to each other 💬 Only PRIVMSG and NOTICE really deliver a text message from one client to another. Everything else just makes it possible and tries to make sure it happens in a reliable, structured way 🫶
4.4.1 Private messages 💖
Command: PRIVMSG
Parameters: <receiver>{,<receiver>} <text to be sent>PRIVMSG is for sending private messages between users 💌 <receiver> is the nickname of whoever's getting the message. <receiver> can also be a list of names or channels, separated with commas.
The <receiver> parameter can also be a host mask (#mask) or a server mask ($mask) 👀 In both cases the server only sends the PRIVMSG to people who have a server or host matching the mask. The mask must have at least 1 (one) "." in it, and no wildcards after the last ".". This rule exists so nobody can send messages to "#" or "$", which would broadcast to everyone. From experience, that's abused way more than it's used properly 💀 Wildcards are the '*' and '?' characters. This extension to the PRIVMSG command is only available to Operators 👑
Numeric Replies:
ERR_NORECIPIENT ERR_NOTEXTTOSEND
ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
ERR_NOSUCHNICK
RPL_AWAYExamples:
:Angel PRIVMSG Wiz :Hello are you receiving this message ?
; Message from Angel to Wiz.
PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ;
Message to Angel.
PRIVMSG jto@tolsun.oulu.fi :Hello !
; Message to a client on server
tolsun.oulu.fi with username of "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.4.4.2 Notice 🔔
Command: NOTICE
Parameters: <nickname> <text>NOTICE works a lot like PRIVMSG 💕 The big difference is that automatic replies must never be sent in response to a NOTICE message. This rule covers servers too, which must not send any error reply back to the client when they receive a notice. The point is to avoid loops where a client automatically sends something back in response to something it just received 🔁 This matters most for automatons (clients where an AI or some other interactive program controls their actions), which always look like they're replying, so they don't end up stuck in a loop with another automaton 🤖
See PRIVMSG for more details on replies and examples ✨
4.5 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, only users who are 'visible' to you get returned, if they match. A user's visibility is decided by a combination of the user's mode and the common set of channels you're both on 🫣
4.5.1 Who query 💅
Command: WHO
Parameters: [<name> [<o>]]WHO is how a client asks for a list of info that 'matches' the <name> parameter it gave 💁 If you leave out the <name> parameter, all visible users get listed. Visible means users who aren't invisible (user mode +i) and who don't share a common channel with the requesting client. You can get the same result with a <name> of "0", or any wildcard that ends up matching every possible entry 🌈
The <name> passed to WHO is matched against users' host, server, real name and nickname, if the channel <name> can't be found 🧐
If you pass the "o" parameter, only operators are returned, according to the name mask you supplied 👑
Numeric Replies:
ERR_NOSUCHSERVER
RPL_WHOREPLY RPL_ENDOFWHOExamples:
WHO *.fi ; List all users who match against
"*.fi".
WHO jto* o ; List all users with a match against
"jto*" if they are an operator.4.5.2 Whois query 🕵️♀️
Command: WHOIS
Parameters: [<server>] <nickmask>[,<nickmask>[,...]]WHOIS is for querying info about a particular user 💖 The server answers with several numeric messages showing different statuses for each user that matches the nickmask (if you're allowed to see them). If there's no wildcard in the <nickmask>, you get any info about that nick that you're allowed to see. You can give a comma (',') separated list of nicknames 🫶
The latter version sends the query to a specific server, which is handy if you want to know how long someone's been idle. Only the local server (ie. the server the user is directly connected to) knows that, while everything else is globally known ⏳
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 trillian4.5.3 Whowas 🦋
Command: WHOWAS
Parameters: <nickname> [<count> [<server>]]okay so WHOWAS is for when you're looking for a nick that doesn't exist anymore 👀. Maybe they changed it, or maybe they left IRC entirely. The server digs through its nickname history and looks for anything lexically the same (no wild card matching here, bestie 🙅♀️). It searches backward, so the most recent entry comes first 💅. If there are multiple entries, you get up to <count> replies, or all of them if you don't pass a count. And if you pass a non-positive number as <count>, that means a full search 🔥.
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".4.6 Miscellaneous messages 🧚
these don't fit into any of the categories above, but they're still a part of the protocol and still required by it. Main character energy, no cap ✨.
4.6.1 Kill message 💀
Command: KILL
Parameters: <nickname> <comment>the KILL message is how you make a client-server connection get closed, by the server that actually holds the connection. Servers use it when they find a duplicate entry in the list of valid nicknames, and it removes both entries. Operators can use it too 👑.
Clients with automatic reconnect algorithms kind of make this useless, since the disconnect is only brief. It does break the flow of data though, and it can be used to stop a lot of abuse. Any user may also choose to receive KILL messages generated for others, to keep an 'eye' on would-be trouble spots 👀.
In an arena where nicknames have to be globally unique at all times, KILL messages get sent whenever 'duplicates' are detected (that is, an attempt to register two users with the same nickname). The hope is that both of them disappear and only one reappears 🙏.
The comment has to reflect the actual reason for the KILL. For server-generated KILLs, it usually has details about where the two conflicting nicknames came from. For users, it's up to them to give a good enough reason that others who see it are satisfied 💅. To prevent or discourage fake KILLs being used 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_CANTKILLSERVERKILL David (csd.bu.edu <- tolsun.oulu.fi)
; Nickname collision between csd.bu.edu
and tolson.oulu.fiNOTE: It is recommended that only Operators be allowed to kill other users with KILL message. In an ideal world not even operators would need to do this, and it would be left to servers to deal with 🥺.
4.6.2 Ping message 🏓
Command: PING
Parameters: <server1> [<server2>]the PING message tests whether an active client is still there at the other end of the connection 👋. A PING message gets sent at regular intervals if no other activity is detected coming from a connection. If a connection doesn't respond to a PING command within a set amount of time, that connection gets closed 😭.
Any client that receives a PING message must respond to <server1> (the server that sent the PING) as quickly as possible, with an appropriate PONG message to show it's still there and alive 🌈. Servers should not respond to PING commands. They rely on PINGs from the other end of the connection to show the connection is alive 🧠. If the <server2> parameter is specified, the PING message gets forwarded there.
Numeric Replies:
ERR_NOORIGIN ERR_NOSUCHSERVERExamples:
PING tolsun.oulu.fi ; server sending a PING message to
another server to indicate it is still
alive.
PING WiZ ; PING message being sent to nick WiZ4.6.3 Pong message 🏓
Command: PONG
Parameters: <daemon> [<daemon2>]PONG is the reply to a ping message. If parameter <daemon2> is given, this message must be forwarded to that daemon. The <daemon> parameter is the name of the daemon that responded to the PING message and generated this message 💖.
Numeric Replies:
ERR_NOORIGIN ERR_NOSUCHSERVERExamples:
PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to
tolsun.oulu.fi4.6.4 Error 🚨
Command: ERROR
Parameters: <error message>the ERROR command is for servers reporting a serious or fatal error to their operators. It can also be sent from one server to another, but it must not be accepted from any normal unknown clients 🙅♀️.
An ERROR message is for reporting errors that happen with a server-to-server link only. It gets sent to the server at the other end (which sends it on to all of its connected operators), and to all operators currently connected. A server must not pass it on to any other servers if it was received from a server 🛑.
When a server sends a received ERROR message to its operators, the message should be wrapped inside a NOTICE message. That shows 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.5. OPTIONALS 🎀
This section describes OPTIONAL messages. They aren't required in a working server implementation of the protocol described here. If the option is absent, an error reply message must be generated, or an unknown command error. If the message is destined for another server to answer, it must be passed on (elementary parsing required). The allocated numerics for these are listed with the messages below 🍓.
5.1 Away 🌸
Command: AWAY
Parameters: [message]with the AWAY message, 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 command. The only replying server is the one the sending client is connected to 💌.
The AWAY message is used either with one parameter (to set an AWAY message) or with no parameters (to remove it).
Numeric Replies:
RPL_UNAWAY RPL_NOWAWAYExamples:
AWAY :Gone to lunch. Back in 5 ; set away message to "Gone to lunch.
Back in 5".
:WiZ AWAY ; unmark WiZ as being away.5.2 Rehash message 🔄
Command: REHASH
Parameters: Nonethe rehash message lets an operator force the server to re-read and process its configuration file 👑.
Numeric Replies:
RPL_REHASHING ERR_NOPRIVILEGESExamples:
REHASH ; message from client with operator
status to server asking it to reread its
configuration file.5.3 Restart message 🔁
Command: RESTART
Parameters: Nonethe restart message can only be used by an operator to force a server to restart itself. This message is optional, since it could be seen 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_NOPRIVILEGESExamples:
RESTART ; no parameters required.5.4 Summon message 📣
Command: SUMMON
Parameters: <user> [<server>]the SUMMON command can be used to give users 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 as the target.
If summon is not enabled in a server, it must return the ERR_SUMMONDISABLED numeric and pass the summon message onwards 🙅♀️.
Numeric Replies:
ERR_NORECIPIENT ERR_FILEERROR
ERR_NOLOGIN ERR_NOSUCHSERVER
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.5.5 Users 👀
Command: USERS
Parameters: [<server>]the USERS command returns a list of users logged into the server, in a similar format to who(1), rusers(1) and finger(1). Some people may disable this command on their server for security reasons. If it's disabled, the correct numeric must be returned to indicate that 🔒.
Numeric Replies:
ERR_NOSUCHSERVER ERR_FILEERROR
RPL_USERSSTART RPL_USERS
RPL_NOUSERS RPL_ENDOFUSERS
ERR_USERSDISABLEDDisabled Reply:
ERR_USERSDISABLEDExamples:
USERS eff.org ; request a list of users logged in on
server eff.org
:John USERS tolsun.oulu.fi ; request from John for a list of users
logged in on server tolsun.oulu.fi5.6 Operwall message 📢
Command: WALLOPS
Parameters: Text to be sent to all operators currently onlinesends a message to all operators currently online 👑. After WALLOPS was implemented as a user command, it was found to be often and commonly abused as a way to send a message to lots of people (much like WALL). Because of this, it is recommended that the current implementation of WALLOPS be used as an example, by allowing and recognising only servers as the senders of WALLOPS 🫶.
Numeric Replies:
ERR_NEEDMOREPARAMSExamples:
:csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua; WALLOPS
message from csd.bu.edu announcing a
CONNECT message it received and acted
upon from Joshua.5.7 Userhost message ✨
Command: USERHOST Parameters: <nickname>{<space><nickname>}
okay so USERHOST is giving "tell me about these people" 💅 You send it a list of up to 5 nicknames, each one separated by a space, and the server sends back info on every nickname it actually finds 🔍 The reply list is also space-separated, so it's all super tidy 🎀
Numeric Replies:
RPL_USERHOST ERR_NEEDMOREPARAMSExamples:
USERHOST Wiz Michael Marty p ;USERHOST request for information on
nicks "Wiz", "Michael", "Marty" and "p"5.8 Ison message 🦋
Command: ISON Parameters: <nickname>{<space><nickname>}
bestie, ISON was made for one job: checking whether a nickname is online right now, and doing it fast and efficiently ⚡ It only takes one parameter, which is a space-separated list of nicks. For each nick in that list that's around, the server tacks it onto the reply string 🫶 So the reply can come back totally empty (nobody's here 💀), exactly the same as what you sent (everyone's here 🙌), or any subset in between, lowkey iconic 👑 The only real limit is length: the combined string has to stay small enough that the server doesn't chop it off to fit in 512 characters 📏
ISON is only processed by the server local to the client sending the command. It is NOT passed onto other servers for further processing, so it stays local 🏠
Numeric Replies:
RPL_ISON ERR_NEEDMOREPARAMSExamples:
ISON phone trillian WiZ jarlek Avalon Angel Monstah
; Sample ISON request for 7 nicks.6. REPLIES 🌈
okay so this part is the numeric reply roster 📋 Everything below is a list of the numeric replies that get generated in response to the commands we just covered. Each numeric shows up with its number, its name, and its reply string, so you always know exactly what you're getting back 💜
6.1. Error Replies 💅
Okay bestie, these are the error replies, the server's way of saying "nope, not today" 🙈 Each one has a number, a name, and the text that gets sent back.
401 ERR_NOSUCHNICK
"<nickname> :No such nick/channel"Lowkey the classic. This tells you the nickname you gave a command isn't in use right now 💀
402 ERR_NOSUCHSERVER
"<server name> :No such server"This one means the server name you typed doesn't exist. Rude, but fair 🫶
403 ERR_NOSUCHCHANNEL
"<channel name> :No such channel"The channel name you gave is invalid. Sorry bestie, it's giving "not a real channel" 🌸
404 ERR_CANNOTSENDTOCHAN
"<channel name> :Cannot send to channel"This one is serious drama 😭 It goes to someone who is either (a) not on a channel that's mode +n, or (b) not a chanop (or mode +v) on a channel with mode +m set, and they're trying to send a PRIVMSG to it. Blocked, babe 🚫
405 ERR_TOOMANYCHANNELS
"<channel name> :You have joined too many \
channels"Sent when you've already joined the maximum number of allowed channels and you try to join one more. Too much main character energy 👑
406 ERR_WASNOSUCHNICK
"<nickname> :There was no such nickname"WHOWAS sends this back when there's no history information for that nickname. The nickname has left no trace, not even a shadow 👻
407 ERR_TOOMANYTARGETS
"<target> :Duplicate recipients. No message \
delivered"This goes to a client trying to send a PRIVMSG/NOTICE using the user@host destination format, when that user@host has several occurrences. Duplicate recipients, no message delivered. Ate and left no crumbs 💅
409 ERR_NOORIGIN
":No origin specified"A PING or PONG message is missing the originator parameter. It's required because these commands must work without valid prefixes 🧚
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"Okay, these four are the PRIVMSG squad 🎀 412 to 414 get returned by PRIVMSG when the message wasn't delivered for some reason. ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are the errors you get when someone tries an invalid use of "PRIVMSG $<server>" or "PRIVMSG #<host>". Not the vibe ✨
421 ERR_UNKNOWNCOMMAND
"<command> :Unknown command"Returned to a registered client when the server doesn't know the command they sent. Literally who is this 🙈
422 ERR_NOMOTD
":MOTD File is missing"The server couldn't open its MOTD file. No welcome message for you today 🥀
423 ERR_NOADMININFO
"<server> :No administrative info available"A server sends this in reply to an ADMIN message when it runs into an error finding the right information. Info not found, sorry hun 💜
424 ERR_FILEERROR
":File error doing <file op> on <file>"This is the generic one 😭 It reports a failed file operation while a message is being processed.
431 ERR_NONICKNAMEGIVEN
":No nickname given"A command expected a nickname parameter and didn't find one. Where's the name, bestie? 🍓
432 ERR_ERRONEUSNICKNAME
"<nick> :Erroneus nickname"This comes back after a NICK message contains characters that aren't in the defined set. See section x.x.x for the details on valid nicknames 📖
433 ERR_NICKNAMEINUSE
"<nick> :Nickname is already in use"Returned when a NICK message tries to change you to a nickname that already exists. Someone got there first 💅
436 ERR_NICKCOLLISION
"<nick> :Nickname collision KILL"A server sends this to a client when it detects a nickname collision, meaning a NICK that's already in use by another server. Collision = KILL 💀
441 ERR_USERNOTINCHANNEL
"<nick> <channel> :They aren't on that channel"The target user of the command isn't on the given channel. Not in the group chat 🫠
442 ERR_NOTONCHANNEL
"<channel> :You're not on that channel"Returned whenever a client tries a channel-affecting command when they aren't a member. You gotta be in it to win it 🏆
443 ERR_USERONCHANNEL
"<user> <channel> :is already on channel"Someone tried to invite a user to a channel they're already in. Iykyk 🙄
444 ERR_NOLOGIN
"<user> :User not logged in"Returned by SUMMON after a summon for a user couldn't be carried out, because they weren't logged in. Sleeping, not summonable 😴
445 ERR_SUMMONDISABLED
":SUMMON has been disabled"A response to the SUMMON command. Must be returned by any server which does not implement it. 🔒
446 ERR_USERSDISABLED
":USERS has been disabled"A response to the USERS command. Must be returned by any server which does not implement it. 🔒
451 ERR_NOTREGISTERED
":You have not registered"The server is telling you that you must be registered before it will allow your message to be parsed in detail. Register first, then slay 💖
461 ERR_NEEDMOREPARAMS
"<command> :Not enough parameters"Numerous commands return this to show the client didn't supply enough parameters. Feed me more info 🍰
462 ERR_ALREADYREGISTRED
":You may not reregister"Returned 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 era only, bestie ✨
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 the attempt is coming from. Not on the list 🚪
464 ERR_PASSWDMISMATCH
":Password incorrect"A failed attempt to register a connection where a password was required and either wasn't given or was wrong. 🔑
465 ERR_YOUREBANNEDCREEP
":You are banned from this server"Returned after you try to connect and register with a server that has been set up to explicitly deny your connections. Banned, babe 🚫💀
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"
473 ERR_INVITEONLYCHAN
"<channel> :Cannot join channel (+i)"
474 ERR_BANNEDFROMCHAN
"<channel> :Cannot join channel (+b)"
475 ERR_BADCHANNELKEY
"<channel> :Cannot join channel (+k)"The channel-join drama 🎭 467 is the key already set. 471 is full (+l). 472 is an unknown mode char. 473 is invite only (+i). 474 is banned (+b). 475 is the wrong key (+k). Not getting in, no cap 🙅♀️
481 ERR_NOPRIVILEGES
":Permission Denied- You're not an IRC operator"Any command that needs operator privileges has to return this when the attempt doesn't work. Operator-only, sis 👑
482 ERR_CHANOPRIVSNEEDED
"<channel> :You're not channel operator"Any command needing 'chanop' privileges (like MODE messages) must return this if the client trying isn't a chanop on that channel. 🛡️
483 ERR_CANTKILLSERVER
":You cant kill a server!"Any attempt to use KILL on a server gets refused, and this error goes straight back to the client. Absolutely not 😤
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. 🚷
501 ERR_UMODEUNKNOWNFLAG
":Unknown MODE flag"Returned when a MODE message comes with a nickname parameter and the mode flag sent isn't recognized. Flag not it 🚩
502 ERR_USERSDONTMATCH
":Cant change mode for other users"Any user trying to view or change the user mode of someone other than themselves gets this error. Mind your own modes 🫶
6.2. Command responses 🦋
Now the happy stuff, the command responses ✨ These are the replies that come back when things go right (or at least when they go as planned).
300 RPL_NONE
Dummy reply number. Not used.A dummy reply number. It's not used 🧸
302 RPL_USERHOST
":[<reply>{<space><reply>}]"This is the reply format USERHOST uses to list the replies to the query list. Each reply string is put together like this:
<reply> ::= <nick>['*'] '=' <'+'|'-'><hostname>The '*' tells you whether the client has registered as an Operator 👑 The '-' or '+' tells you whether the client has set an AWAY message or not. '-' means away, '+' means not away. Tiny symbols, big info 🔍
303 RPL_ISON
":[<nick> {<space><nick>}]"This is the reply format ISON uses to list the 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 go with the AWAY command (if it's allowed). RPL_AWAY goes to any client that sends a PRIVMSG to a client who's away. RPL_AWAY is only sent by the server the client is connected to. RPL_UNAWAY and RPL_NOWAWAY are sent when a client removes or sets an AWAY message. Out of office, but make it aesthetic 🌙
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><space>}"okay so the WHOIS replies are giving detective energy 🕵️♀️✨ replies 311 to 313 and 317 to 319 are all generated when someone sends a WHOIS message. bestie, if there are enough parameters, the answering server must either put together a reply out of those numerics (when the query nick is found) or send back an error reply. 💅
the * in RPL_WHOISUSER is literal, NOT a wild card. (it's giving "I am a character, not a pattern" 🙈) and for each reply set, only RPL_WHOISCHANNELS may show up more than once, because that's how long channel lists get handled 🧚
the @ and + next to a channel name tell you whether someone is a channel operator, or has been given permission to talk in a moderated channel. so iconic 👑 and RPL_ENDOFWHOIS is the little "that's all, folks" that marks the end of processing a WHOIS message 🎀
314 RPL_WHOWASUSER
"<nick> <user> <host> * :<real name>"
369 RPL_ENDOFWHOWAS
"<nick> :End of WHOWAS"for WHOWAS, the server must use RPL_WHOWASUSER, RPL_WHOISSERVER or ERR_WASNOSUCHNICK for each nickname in the list that was sent. and at the end of all the reply batches there must be RPL_ENDOFWHOWAS, even if there was only one reply and it was an error. no cap, the end marker is non-negotiable 💀🫶
321 RPL_LISTSTART
"Channel :Users Name"
322 RPL_LIST
"<channel> <# visible> :<topic>"
323 RPL_LISTEND
":End of /LIST"RPL_LISTSTART, RPL_LIST and RPL_LISTEND mark the start, the actual data replies, and the end of the server's response to a LIST command 🌸 if there are no channels to return, then only the start and end replies must be sent. (that's a whole lot of nothing, but make it official 🙃)
324 RPL_CHANNELMODEIS
"<channel> <mode> <mode params>"
331 RPL_NOTOPIC
"<channel> :No topic is set"
332 RPL_TOPIC
"<channel> :<topic>"when a TOPIC message is sent to find out a channel's topic, exactly one of two replies comes back 🦋 if the topic is set, the server sends RPL_TOPIC, otherwise it sends RPL_NOTOPIC. simple, clean, slay ✨
341 RPL_INVITING
"<channel> <nick>"RPL_INVITING gets sent back by the server to say the INVITE message worked and is being passed on to the end client. invite accepted, bestie 💌
342 RPL_SUMMONING
"<user> :Summoning user to IRC"a server answering a SUMMON message sends RPL_SUMMONING to show that it is summoning that user 📣 (the summon era, it's giving vintage 📼)
351 RPL_VERSION
"<version>.<debuglevel> <server> :<comments>"RPL_VERSION is the server showing off its version details 💅 the <version> is the version of the software being used, including any patchlevel revisions, and the <debuglevel> shows whether the server is running in "debug mode". the "comments" field can hold any comments about the version or any further version details, so the server can really spill the tea 🍵
352 RPL_WHOREPLY
"<channel> <user> <host> <server> <nick> \
<H|G>[*][@|+] :<hopcount> <real name>"
315 RPL_ENDOFWHO
"<name> :End of /WHO list"RPL_WHOREPLY and RPL_ENDOFWHO are a pair that answers a WHO message 🎀 RPL_WHOREPLY only gets sent if there's an appropriate match to the WHO query. if a list of parameters came with the WHO message, then RPL_ENDOFWHO must be sent after each list item is processed, with <name> being that item. so every item gets its own closing bow 🫶
353 RPL_NAMREPLY
"<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]"
366 RPL_ENDOFNAMES
"<channel> :End of /NAMES list"to reply to a NAMES message, the server sends a pair: RPL_NAMREPLY and then RPL_ENDOFNAMES 🧚 if no channel is found for the query, then only RPL_ENDOFNAMES comes back. the exception is when a NAMES message is sent with no parameters. then all visible channels and their contents get sent back in a series of RPL_NAMEREPLY messages, and RPL_ENDOFNAMES marks the end. it's a whole guest list moment 🌈
364 RPL_LINKS
"<mask> <server> :<hopcount> <server info>"
365 RPL_ENDOFLINKS
"<mask> :End of /LINKS list"when replying to the LINKS message, a server must send its replies using the RPL_LINKS numeric and mark the end of the list with RPL_ENDOFLINKS. no skipping the closer, periodt 💖
367 RPL_BANLIST
"<channel> <banid>"
368 RPL_ENDOFBANLIST
"<channel> :End of channel ban list"when a server lists the active 'bans' for a channel, it is required to send the list back using RPL_BANLIST and RPL_ENDOFBANLIST. a separate RPL_BANLIST goes out for each active banid. after the banids have been listed (or if there aren't any), RPL_ENDOFBANLIST must be sent. 🚫🌸 a little bit dramatic, but we love a clear structure
371 RPL_INFO
":<string>"
374 RPL_ENDOFINFO
":End of /INFO list"a server responding to an INFO message is required to send all of its 'info' in a series of RPL_INFO messages, and then RPL_ENDOFINFO indicates the end of the replies 🧾✨
375 RPL_MOTDSTART
":- <server> Message of the day - "
372 RPL_MOTD
":- <text>"
376 RPL_ENDOFMOTD
":End of /MOTD command"okay the MOTD (message of the day) vibes 🌞 when someone sends MOTD and the MOTD file is found, the file gets displayed line by line, with each line no longer than 80 characters, using RPL_MOTD format replies. those lines should be wrapped by RPL_MOTDSTART (before the RPL_MOTDs) and RPL_ENDOFMOTD (after). it's a little announcement with a proper intro and outro 🎤💜
381 RPL_YOUREOPER
":You are now an IRC operator"RPL_YOUREOPER goes to a client that has just successfully sent an OPER message and gained operator status. crown on, bestie 👑🔥
382 RPL_REHASHING
"<config file> :Rehashing"if the REHASH option is used and an operator sends a REHASH message, RPL_REHASHING is sent back to that operator 🔄 fresh config, fresh start 🌷
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_TIME format above. the time string only needs to contain the correct day and time there. there's no further requirement for the time string, so it can be as simple as that 🕰️💕
392 RPL_USERSSTART
":UserID Terminal Host"
393 RPL_USERS
":%-8s %-9s %-8s"
394 RPL_ENDOFUSERS
":End of users"
395 RPL_NOUSERS
":Nobody logged in"if a server handles the USERS message, the replies RPL_USERSSTART, RPL_USERS, RPL_ENDOFUSERS and RPL_NOUSERS are used. RPL_USERSSTART must be sent first, followed by either a sequence of RPL_USERS or a single RPL_NOUSER. after that comes RPL_ENDOFUSERS. so it's either a full roll call or a very quiet room 🦗🫧
200 RPL_TRACELINK
"Link <version & debug level> <destination> \
<next server>"
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>"
208 RPL_TRACENEWTYPE
"<newtype> 0 <client name>"
261 RPL_TRACELOG
"File <logfile> <debug level>"the RPL_TRACE* replies all come back from the server in response to the TRACE message 🗺️✨ how many get returned depends on the TRACE message, and on whether it was sent by an operator or not. there's no set order for which one shows up first. RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and RPL_TRACEHANDSHAKE are for connections that haven't been fully established yet. they're either unknown, still trying to connect, or in the middle of completing the 'server handshake' 🤝 RPL_TRACELINK is sent by any server that handles a TRACE message and has to pass it on to another server. the list of RPL_TRACELINKs sent back for a TRACE command travelling across the IRC network should reflect the actual connectivity of the servers along that path, so no fake map, just the real tea 🍵 and RPL_TRACENEWTYPE is for any connection that doesn't fit the other categories but is being displayed anyway. it's the "idk what this is but here it is" category 🧚💅
💖 Okay, the stats replies keep going, so let's look at the rest of the STATS and LINKS family 🌸
211 RPL_STATSLINKINFO
"<linkname> <sendq> <sent messages> \
<sent bytes> <received messages> \
<received bytes> <time open>"
212 RPL_STATSCOMMANDS
"<command> <count>"
213 RPL_STATSCLINE
"C <host> * <name> <port> <class>"
214 RPL_STATSNLINE
"N <host> * <name> <port> <class>"
215 RPL_STATSILINE
"I <host> * <host> <port> <class>"
216 RPL_STATSKLINE
"K <host> * <username> <port> <class>"
218 RPL_STATSYLINE
"Y <class> <ping frequency> <connect \
frequency> <max sendq>"
219 RPL_ENDOFSTATS
"<stats letter> :End of /STATS report"
241 RPL_STATSLLINE
"L <hostmask> * <servername> <maxdepth>"
242 RPL_STATSUPTIME
":Server Up %d days %d:%02d:%02d"
243 RPL_STATSOLINE
"O <hostmask> * <name>"
244 RPL_STATSHLINE
"H <hostmask> * <servername>"✨ RPL_UMODEIS is the one you send when someone asks about their own mode:
221 RPL_UMODEIS
"<user mode string>"- To answer a query about a client's own mode,
RPL_UMODEISis sent back. 🦋
Now the LUSERS numerics, which are giving "how big is this network" energy 👑
251 RPL_LUSERCLIENT
":There are <integer> users and <integer> \
invisible 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"- So when a server processes an
LUSERSmessage, it sends a set of replies fromRPL_LUSERCLIENT,RPL_LUSEROP,RPL_USERUNKNOWN,RPL_LUSERCHANNELSandRPL_LUSERME. 📊 - When replying, a server MUST send back
RPL_LUSERCLIENTandRPL_LUSERME. These two are non-negotiable, bestie 🫶 - The other replies are only sent back if a non-zero count is found for them. So no empty drama 🙈
And the ADMIN replies, which are basically the server's little bio 🧚
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 replies
RLP_ADMINMEthrough toRPL_ADMINEMAILand provide a text message with each. 📝 - For
RPL_ADMINLOC1, a description of what city, state and country the server is in is expected. Then comes the university and department inRPL_ADMINLOC2, and finally the administrative contact inRPL_ADMINEMAIL. That one's the big finale 💌 - The administrative contact (an email address here is REQUIRED) goes in
RPL_ADMINEMAIL. No email, no slay 💀
6.3 Reserved numerics
These numerics aren't described above because they fall into one of these categories, so don't go looking for them 🙈
- 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.
209 RPL_TRACECLASS 217 RPL_STATSQLINE
231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES
233 RPL_SERVICE 234 RPL_SERVLIST
235 RPL_SERVLISTEND
316 RPL_WHOISCHANOP 361 RPL_KILLDONE
362 RPL_CLOSING 363 RPL_CLOSEEND
373 RPL_INFOSTART 384 RPL_MYPORTIS
466 ERR_YOUWILLBEBANNED 476 ERR_BADCHANMASK
492 ERR_NOSERVICEHOST7. Client and server authentication 🔐
Okay, big security vibes now. Clients and servers both get the same level of authentication, no VIP treatment 👑 For both, an IP number to hostname lookup (and reverse check on this) is performed for all connections made to the server. Then both connections get a password check, if there's a password set for that connection. These checks are possible on all connections, although the password check is only commonly used with servers. 🛡️
There's also an extra check that's getting more and more common, which is checking the username responsible for making the connection. Finding the username of the other end usually means connecting to an authentication server such as IDENT, as described in RFC 1413. 🕵️♀️
Now the real tea: without passwords, it's not easy to reliably figure out who is on the other end of a network connection. So use of passwords is strongly RECOMMENDED on inter-server connections, on top of any other measures like using an ident server. Please do not skip this, bestie 😭🔥
8. Current implementations 🦋
The only current implementation of this protocol is the IRC server, version 2.8. Earlier versions MAY implement some or all of the commands described by this document, with NOTICE messages replacing many of the numeric replies. 📨 Unfortunately, due to backward compatibility requirements, the implementation of some parts of this document varies from what's laid out. One notable difference is:
- recognition that any LF or CR anywhere in a message marks the end of that message (instead of requiring CR-LF);
The rest of this section deals with issues that are mostly important to people who want to implement a server, but some parts also apply directly to clients. 🧩
8.1 Network protocol: TCP - why it is best used here.
IRC has been implemented on top of TCP since TCP supplies a reliable network protocol, which is well suited to this scale of conferencing. 🌐 Multicast IP is an alternative, but it's not widely available or supported at the present time, so TCP is the main character here ✨
8.1.1 Support of Unix sockets
Since Unix domain sockets allow listen/connect operations, the current implementation can be configured to listen and accept both client and server connections on a Unix domain socket. These are recognized as sockets where the hostname starts with a '/'. 🧦
When providing any information about the connections on a Unix domain socket, the server is REQUIRED to supplant the actual hostname in place of the pathname, unless the actual socket name is being asked for. 🙅♀️
8.2 Command Parsing
To provide useful 'non-buffered' network IO for clients and servers, each connection gets its own private 'input buffer', where the results of the most recent read and parsing are kept. 📦 A buffer size of 512 bytes is used so it can hold 1 full message, although it'll usually hold several commands. The private buffer is parsed after every read operation for valid messages.
When dealing with multiple messages from one client in the buffer, care SHOULD be taken in case one happens to cause the client to be 'removed'. Bestie, watch your step 😬
8.3 Message delivery
It's super common for network links to be saturated, or for hosts you're sending data to to be unable to take it. 🚧 Unix usually handles this through the TCP window and internal buffers. But the server often has a huge amount of data to send (especially when a new server-server link forms), and the small buffers in the kernel just aren't enough for the outgoing queue. So a "send queue" is used as a FIFO queue for data to be sent. A typical "send queue" may grow to 200 Kbytes on a large IRC network with a slow network connection when a new server connects. 📈
When polling its connections, a server first reads and parses all incoming data, queuing any data to be sent out. When all available input is processed, the queued data is sent. This reduces the number of write() system calls and helps TCP make bigger packets. Efficiency, periodt 🚀
8.4 Connection 'Liveness'
To detect when a connection has died or become unresponsive, the server MUST ping each of its connections that it doesn't get a response from in a given amount of time. 💓
If a connection doesn't respond in time, it gets closed using the appropriate procedures. A connection is also dropped if its sendq grows beyond the maximum allowed, because it's better to close a slow connection than have a server process block. Rest in peace, slow connection 🕊️
8.5 Establishing a server to client connection
When you connect to an IRC server, you're sent the MOTD (if present) as well as the current user/server count (as per the LUSER command). The server is also REQUIRED to give an unambiguous message to the client, stating its name and version, plus any other introductory messages that MAY be deemed appropriate. 👋
After dealing with this, the server MUST then send out the new user's nickname and other information, as supplied by itself (USER command) and as the server could discover (from DNS/authentication servers). The server MUST send this information out with NICK first, followed by USER. Order matters, bestie, the vibes depend on it 🎀
8.6 Establishing a server-server connection.
Setting up a server-to-server connection is fraught with danger, since there are a lot of possible places where problems can happen. The least of them are race conditions 😵💫
After a server has received a connection followed by a PASS/SERVER pair that was recognised as valid, the server SHOULD then reply with its own PASS/SERVER information for that connection, plus all of the other state information it knows about, as described below. 🤝
When the initiating server receives a PASS/SERVER pair, it too checks that the responding server is authenticated properly before accepting the connection to be that server. 🔍
8.6.1 Server exchange of state information when connecting
The order of state information exchanged between servers is essential. The REQUIRED order is as follows:
- all known other servers;
- all known user information;
- all known channel information.
Information about servers is sent via extra SERVER messages, user information with NICK/USER/MODE/JOIN messages, and channels with MODE messages. 📬
NOTE: channel topics are NOT exchanged here, because the TOPIC command overwrites any old topic information. So at best, the two sides of the connection would just swap topics 🙃
Passing the state information about servers first means any collisions with servers that already exist happen before nickname collisions caused by a second server introducing a particular nickname. Since the IRC network can only exist as an acyclic graph, the network may already have reconnected in another location. The place where the collision occurs shows where the net needs to split. 💥 Sis, that's some serious network logic 🧠
8.7 Terminating server-client connections
When a client connection closes, a QUIT message is generated on behalf of the client by the server the client connected to. No other message is to be generated or used. Clean exit, no drama 👋💜
8.8 Terminating server-server connections ✨
okay so if a server-server connection gets closed 💔, either because someone sent a remotely generated SQUIT or because of "natural" causes like a network hiccup, the rest of the IRC network MUST get its info updated. The server that noticed the closure is the one who does it. It sends a list of SQUITs (one for each server hiding behind that connection) and a list of QUITs (again, one for each client behind it). Super organized, I'm obsessed 🧚
8.9. Tracking nickname changes 🎀
every IRC server is REQUIRED to keep a history of recent nickname changes. Why? So the server has a fighting chance of keeping track of things when nick-change race conditions happen with commands that touch nicks 🙈 These are the commands that MUST trace nick changes:
- KILL (the nick being killed)
- MODE (
+/- o,v) - KICK (the nick being kicked)
No other commands get nick changes checked, bestie 🚫
In those cases, the server is REQUIRED to check that the nickname exists first, then look through its history to see who that nick currently belongs to (if anyone!). This cuts down race conditions, but they can still happen, and the server might end up affecting the wrong client 😭 When doing a change trace for any of those commands, it is RECOMMENDED that a time range is given and entries that are too old get ignored.
For a reasonable history, a server SHOULD be able to keep the previous nickname for every client it knows about, in case they all decided to change at once. The size is limited by other stuff, like memory and so on 💅
8.10 Flood control of clients 🌊
with a big network of linked IRC servers, it's super easy for one client to send a nonstop stream of messages. That floods the network AND makes everyone else's experience worse 💀 Instead of making every victim protect themselves, flood protection was built into the server and it's applied to all clients except services. Here's the current algorithm:
- check whether the client's
message timeris less than the current time (set it equal if it is); - read any data present from the client;
- while the timer is less than ten seconds ahead of the current time, parse any messages present and penalize the client by 2 seconds for each message;
so basically, the client MAY send 1 message every 2 seconds without getting hit with any penalty 🦋
8.11 Non-blocking lookups ⏱️
in a real-time environment, a server process has to wait as little as possible so every client gets serviced fairly. This obviously means non-blocking IO on all network read and write operations. For normal server connections that wasn't too hard, but other support operations (like disk reads) can make the server block. Wherever possible, that kind of activity SHOULD be performed with a short timeout 🫶
8.11.1 Hostname (DNS) lookups 🌐
using the standard resolver libraries from Berkeley and others caused big delays in some cases, where replies timed out and everything got stuck 😩 To avoid that, a separate set of DNS routines was written. They were set up for non-blocking IO operations and then polled from inside the main server IO loop. Iconic solution, honestly 👑
8.11.2 Username (Ident) lookups 🔍
there are plenty of ident libraries out there for use in other programs, but they caused problems because they ran synchronously and led to frequent delays. So again, the fix was to write a set of routines that cooperate with the rest of the server and work with non-blocking IO 💖
8.12 Configuration File 📝
to make the server flexible to set up and run, it is RECOMMENDED that a configuration file gets used. It tells the server about:
- which hosts to accept client connections from;
- which hosts to allow to connect as servers;
- which hosts to connect to (both actively and passively);
- information about where the server is (university, city/state, company are examples of this);
- who is responsible for the server and an email address where they can be contacted;
- hostnames and passwords for clients who want access to restricted operator commands.
when you specify hostnames, both domain names and the 'dot' notation (127.0.0.1) SHOULD both be accepted 🌸 It MUST be possible to specify the password used or accepted for all outgoing and incoming connections (although the only outgoing connections are the ones to other servers).
That list is the minimum requirement for any server that wants to connect with another server. Other items that might be useful are:
- specifying which servers other servers may introduce;
- how deep a server branch is allowed to become;
- hours during which clients may connect.
8.12.1 Allowing clients to connect 🚪
a server SHOULD use some sort of 'access control list' (in the configuration file or somewhere else) that gets read at startup and decides which hosts clients may use to connect. Both 'deny' and 'allow' SHOULD be implemented so you get the flexibility you need for host access control 🎀
8.12.2 Operators 👑
giving operator privileges to a disruptive person can have dire consequences for the whole IRC net, because of how much power they get. So getting those powers SHOULD NOT be very easy 🙅♀️ The current setup requires two 'passwords', though one of them is usually easy to guess 🙈 Storing oper passwords in configuration files is preferable to hard coding them, and they SHOULD be stored in a crypted format (ie using crypt(3) from Unix) so nobody can easily steal them 🔐
8.12.3 Allowing servers to connect 🔗
connecting servers is not a trivial matter, because one bad connection can seriously mess with how useful IRC is 💀 So each server SHOULD have a list of the servers it may connect to, and the servers that may connect to it. A server SHOULD NOT, under any circumstances, allow an arbitrary host to connect as a server 🚫 On top of which servers may and may not connect, the configuration file SHOULD also store the password and other characteristics of that link.
8.12.4 Administrivia 📋
to give accurate and valid replies to the ADMIN command (see section 4.3.7), the server SHOULD look up the relevant details in the configuration 🧚
8.13 Channel membership 🌈
the current server lets any registered local user join up to 10 different channels. There's no limit for non-local users, so the server stays (reasonably) consistent with all the others on a channel membership basis 💅
9. Current problems 😬
there are a bunch of recognized problems with this protocol, and they're all hoping to get solved sometime soon during its rewrite. Work is underway right now to find working solutions 🔧
9.1 Scalability 📈
it's widely recognized that this protocol doesn't scale well when used in a large arena 💔 The main issue is that every server has to know about every other server and every user, and that info has to be updated the second it changes. It's also desirable to keep the number of servers low, so the path length between any two points stays minimal and the spanning tree is as strongly branched as possible 🌳
9.2 Labels 🏷️
the current IRC protocol has 3 types of labels: the nickname, the channel name and the server name. Each type has its own domain, and no duplicates are allowed inside that domain. Right now, users can pick the label for any of the three, which leads to collisions 😭 It's widely recognized that this needs reworking. A plan for unique names for channels and nicks that don't collide is desirable, and so is a solution that allows a cyclic tree ✨
9.2.1 Nicknames 💬
the nickname is super convenient for users talking to each other outside of a channel, but there's only a finite nickname space. It's not unusual for several people to want the same nick, and if two people pick the same nickname on this protocol, either one fails or both get removed with KILL (4.6.1) 💀
9.2.2 Channels 🎪
the current channel layout requires every server to know about all channels, their inhabitants and their properties. Besides not scaling well, privacy is also a concern 🙈 A channel collision is treated as an inclusive event (both people who created the new channel are considered members of it), rather than an exclusive one like the way nickname collisions get solved 🦋
9.2.3 Servers 🖥️
the number of servers is usually small compared to the number of users and channels, but they are currently REQUIRED to be known globally. Each one is either known separately or hidden behind a mask 🎭
9.3 Algorithms 🧮
in some parts of the server code, it hasn't been possible to avoid N^2 algorithms, like checking the channel list of a set of clients 😩
there are no database consistency checks in current server versions. Each server just assumes a neighbouring server is correct. That opens the door to big problems if a connecting server is buggy or tries to introduce contradictions into the existing net 🚨
because there are no unique internal or global labels, there are tons of race conditions. They mostly come from messages taking time to travel through the IRC network and take effect. Even switching to unique labels won't fully fix it, since channel-related commands can still get disrupted 🌀
10. Current support and availability 💌
Mailing lists for IRC related discussion:
Future protocol: ircd-three-request@eff.org
General discussion: operlist-request@eff.org
Software implemenations
cs.bu.edu:/irc
nic.funet.fi:/pub/irc
coombs.anu.edu.au:/pub/irc
Newsgroup: alt.ircSecurity Considerations 🚨🔐
Security issues are discussed in sections 4.1, 4.1.1, 4.1.3, 5.5, and 7. Please read those sections carefully, bestie. This is serious business, not a vibe check 💀
12. Authors' Addresses 🫶
Jarkko Oikarinen
Tuirantie 17 as 9
90500 OULU
FINLAND
Email: jto@tolsun.oulu.fi
Darren Reed
4 Pateman Street
Watsonia, Victoria 3087
Australia
Email: avalon@coombs.anu.edu.au📦 where this page comes from
- ietf: rfc1459 1993-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms