The following is a list of numeric replies which are generated in
response to the commands given above. Each numeric is given with its
number, name and reply string.
6.1 Error Replies.
"<nickname> :No such nick/channel"
- Used to indicate the nickname parameter supplied to a
command is currently unused.
"<server name> :No such server"
- Used to indicate the server name given currently
"<channel name> :No such channel"
- Used to indicate the given channel name is invalid.
"<channel name> :Cannot send to channel"
- Sent to a user who is either (a) not on a channel
which is mode +n or (b) not a chanop (or mode +v) on
a channel which has mode +m set and is trying to send
a PRIVMSG message to that channel.
"<channel name> :You have joined too many \
- Sent to a user when they have joined the maximum
number of allowed channels and they try to join
"<nickname> :There was no such nickname"
- Returned by WHOWAS to indicate there is no history
information for that nickname.
"<target> :Duplicate recipients. No message \
- Returned to a client which is attempting to send a
PRIVMSG/NOTICE using the user@host destination format
and for a user@host which has several occurrences.
":No origin specified"
- PING or PONG message missing the originator parameter
which is required since these commands must work
without valid prefixes.
":No recipient given (<command>)"
":No text to send"
"<mask> :No toplevel domain specified"
"<mask> :Wildcard in toplevel domain"
- 412 - 414 are returned by PRIVMSG to indicate that
the message wasn't delivered for some reason.
ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
are returned when an invalid use of
"PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
"<command> :Unknown command"
- Returned to a registered client to indicate that the
command sent is unknown by the server.
":MOTD File is missing"
- Server's MOTD file could not be opened by the server.
"<server> :No administrative info available"
- Returned by a server in response to an ADMIN message
when there is an error in finding the appropriate
":File error doing <file op> on <file>"
- Generic error message used to report a failed file
operation during the processing of a message.
":No nickname given"
- Returned when a nickname parameter expected for a
command and isn't found.
"<nick> :Erroneus nickname"
- Returned after receiving a NICK message which contains
characters which do not fall in the defined set. See
section x.x.x for details on valid nicknames.
"<nick> :Nickname is already in use"
- Returned when a NICK message is processed that results
in an attempt to change to a currently existing
"<nick> :Nickname collision KILL"
- Returned by a server to a client when it detects a
nickname collision (registered of a NICK that
already exists by another server).
"<nick> <channel> :They aren't on that channel"
- Returned by the server to indicate that the target
user of the command is not on the given channel.
"<channel> :You're not on that channel"
- Returned by the server whenever a client tries to
perform a channel effecting command for which the
client isn't a member.
"<user> <channel> :is already on channel"
- Returned when a client tries to invite a user to a
channel they are already on.
"<user> :User not logged in"
- Returned by the summon after a SUMMON command for a
user was unable to be performed since they were not
":SUMMON has been disabled"
- Returned as a response to the SUMMON command. Must be
returned by any server which does not implement it.
":USERS has been disabled"
- Returned as a response to the USERS command. Must be
returned by any server which does not implement it.
":You have not registered"
- Returned by the server to indicate that the client
must be registered before the server will allow it
to be parsed in detail.
"<command> :Not enough parameters"
- Returned by the server by numerous commands to
indicate to the client that it didn't supply enough
":You may not reregister"
- Returned by the server to any link which tries to
change part of the registered details (such as
password or user details from second USER message).
":Your host isn't among the privileged"
- Returned to a client which attempts to register with
a server which does not been setup to allow
connections from the host the attempted connection
- Returned to indicate a failed attempt at registering
a connection for which a password was required and
was either not given or incorrect.
":You are banned from this server"
- Returned after an attempt to connect and register
yourself with a server which has been setup to
explicitly deny connections to you.
"<channel> :Channel key already set"
"<channel> :Cannot join channel (+l)"
"<char> :is unknown mode char to me"
"<channel> :Cannot join channel (+i)"
"<channel> :Cannot join channel (+b)"
"<channel> :Cannot join channel (+k)"
":Permission Denied- You're not an IRC operator"
- Any command requiring operator privileges to operate
must return this error to indicate the attempt was
"<channel> :You're not channel operator"
- Any command requiring 'chanop' privileges (such as
MODE messages) must return this error if the client
making the attempt is not a chanop on the specified
":You cant kill a server!"
- Any attempts to use the KILL command on a server
are to be refused and this error returned directly
to the client.
":No O-lines for your host"
- If a client sends an OPER message and the server has
not been configured to allow connections from the
client's host as an operator, this error must be
":Unknown MODE flag"
- Returned by the server to indicate that a MODE
message was sent with a nickname parameter and that
the a mode flag sent was not recognized.
":Cant change mode for other users"
- Error sent to any user trying to view or change the
user mode for a user other than themselves.
6.2 Command responses.
Dummy reply number. Not used.
- Reply format used by USERHOST to list replies to
the query list. The reply string is composed as
<reply> ::= <nick>['*'] '=' <'+'|'-'><hostname>
The '*' indicates whether the client has registered
as an Operator. The '-' or '+' characters represent
whether the client has set an AWAY message or not
- Reply format used by ISON to list replies to the
"<nick> :<away message>"
":You are no longer marked as being away"
":You have been marked as being away"
- These replies are used with the AWAY command (if
allowed). RPL_AWAY is sent to any client sending a
PRIVMSG to a client which is away. RPL_AWAY is only
sent by the server to which the client is connected.
Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the
client removes and sets an AWAY message.
"<nick> <user> <host> * :<real name>"
"<nick> <server> :<server info>"
"<nick> :is an IRC operator"
"<nick> <integer> :seconds idle"
"<nick> :End of /WHOIS list"
- Replies 311 - 313, 317 - 319 are all replies
generated in response to a WHOIS message. Given that
there are enough parameters present, the answering
server must either formulate a reply out of the above
numerics (if the query nick is found) or return an
error reply. The '*' in RPL_WHOISUSER is there as
the literal character and not as a wild card. For
each reply set, only RPL_WHOISCHANNELS may appear
more than once (for long lists of channel names).
The '@' and '+' characters next to the channel name
indicate whether a client is a channel operator or
has been granted permission to speak on a moderated
channel. The RPL_ENDOFWHOIS reply is used to mark
the end of processing a WHOIS message.
"<nick> <user> <host> * :<real name>"
"<nick> :End of WHOWAS"
- When replying to a WHOWAS message, a server must use
the replies RPL_WHOWASUSER, RPL_WHOISSERVER or
ERR_WASNOSUCHNICK for each nickname in the presented
list. At the end of all reply batches, there must
be RPL_ENDOFWHOWAS (even if there was only one reply
and it was an error).
"Channel :Users Name"
"<channel> <# visible> :<topic>"
":End of /LIST"
- Replies RPL_LISTSTART, RPL_LIST, RPL_LISTEND mark
the start, actual replies with data and end of the
server's response to a LIST command. If there are
no channels available to return, only the start
and end reply must be sent.
"<channel> <mode> <mode params>"
"<channel> :No topic is set"
- When sending a TOPIC message to determine the
channel topic, one of two replies is sent. If
the topic is set, RPL_TOPIC is sent back else
- Returned by the server to indicate that the
attempted INVITE message was successful and is
being passed onto the end client.
"<user> :Summoning user to IRC"
- Returned by a server answering a SUMMON message to
indicate that it is summoning that user.
"<version>.<debuglevel> <server> :<comments>"
- Reply by the server showing its version details.
The <version> is the version of the software being
used (including any patchlevel revisions) and the
<debuglevel> is used to indicate if the server is
running in "debug mode".
The "comments" field may contain any comments about
the version or further version details.
"<channel> <user> <host> <server> <nick> \
<H|G>[*][@|+] :<hopcount> <real name>"
"<name> :End of /WHO list"
- The RPL_WHOREPLY and RPL_ENDOFWHO pair are used
to answer a WHO message. The RPL_WHOREPLY is only
sent if there is an appropriate match to the WHO
query. If there is a list of parameters supplied
with a WHO message, a RPL_ENDOFWHO must be sent
after processing each list item with <name> being
"<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]"
"<channel> :End of /NAMES list"
- To reply to a NAMES message, a reply pair consisting
of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the
server back to the client. If there is no channel
found as in the query, then only RPL_ENDOFNAMES is
returned. The exception to this is when a NAMES
message is sent with no parameters and all visible
channels and contents are sent back in a series of
RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
"<mask> <server> :<hopcount> <server info>"
"<mask> :End of /LINKS list"
- In replying to the LINKS message, a server must send
replies back using the RPL_LINKS numeric and mark the
end of the list using an RPL_ENDOFLINKS reply.
"<channel> :End of channel ban list"
- When listing the active 'bans' for a given channel,
a server is required to send the list back using the
RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate
RPL_BANLIST is sent for each active banid. After the
banids have been listed (or if none present) a
RPL_ENDOFBANLIST must be sent.
":End of /INFO list"
- A server responding to an INFO message is required to
send all its 'info' in a series of RPL_INFO messages
with a RPL_ENDOFINFO reply to indicate the end of the
":- <server> Message of the day - "
":End of /MOTD command"
- When responding to the MOTD message and the MOTD file
is found, the file is displayed line by line, with
each line no longer than 80 characters, using
RPL_MOTD format replies. These should be surrounded
by a RPL_MOTDSTART (before the RPL_MOTDs) and an
":You are now an IRC operator"
- RPL_YOUREOPER is sent back to a client which has
just successfully issued an OPER message and gained
"<config file> :Rehashing"
- If the REHASH option is used and an operator sends
a REHASH message, an RPL_REHASHING is sent back to
"<server> :<string showing server's local time>"
- When replying to the TIME message, a server must send
the reply using the RPL_TIME format above. The string
showing the time need only contain the correct day and
time there. There is no further requirement for the
":UserID Terminal Host"
":%-8s %-9s %-8s"
":End of users"
":Nobody logged in"
- If the USERS message is handled by a server, the
replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and
RPL_NOUSERS are used. RPL_USERSSTART must be sent
first, following by either a sequence of RPL_USERS
or a single RPL_NOUSER. Following this is
"Link <version & debug level> <destination> \
"Try. <class> <server>"
"H.S. <class> <server>"
"???? <class> [<client IP address in dot form>]"
"Oper <class> <nick>"
"User <class> <nick>"
"Serv <class> <int>S <int>C <server> \
"<newtype> 0 <client name>"
"File <logfile> <debug level>"
- The RPL_TRACE* are all returned by the server in
response to the TRACE message. How many are
returned is dependent on the the TRACE message and
whether it was sent by an operator or not. There
is no predefined order for which occurs first.
Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and
RPL_TRACEHANDSHAKE are all used for connections
which have not been fully established and are either
unknown, still attempting to connect or in the
process of completing the 'server handshake'.
RPL_TRACELINK is sent by any server which handles
a TRACE message and has to pass it on to another
server. The list of RPL_TRACELINKs sent in
response to a TRACE command traversing the IRC
network should reflect the actual connectivity of
the servers themselves along that path.
RPL_TRACENEWTYPE is to be used for any connection
which does not fit in the other categories but is
being displayed anyway.
"<linkname> <sendq> <sent messages> \
<sent bytes> <received messages> \
<received bytes> <time open>"
"C <host> * <name> <port> <class>"
"N <host> * <name> <port> <class>"
"I <host> * <host> <port> <class>"
"K <host> * <username> <port> <class>"
"Y <class> <ping frequency> <connect \
frequency> <max sendq>"
"<stats letter> :End of /STATS report"
"L <hostmask> * <servername> <maxdepth>"
":Server Up %d days %d:%02d:%02d"
"O <hostmask> * <name>"
"H <hostmask> * <servername>"
"<user mode string>"
- To answer a query about a client's own mode,
RPL_UMODEIS is sent back.
":There are <integer> users and <integer> \
invisible on <integer> servers"
"<integer> :operator(s) online"
"<integer> :unknown connection(s)"
"<integer> :channels formed"
":I have <integer> clients and <integer> \
- In processing an LUSERS message, the server
sends a set of replies from RPL_LUSERCLIENT,
RPL_LUSERCHANNELS and RPL_LUSERME. When
replying, a server must send back
RPL_LUSERCLIENT and RPL_LUSERME. The other
replies are only sent back if a non-zero count
is found for them.
"<server> :Administrative info"
- When replying to an ADMIN message, a server
is expected to use replies RLP_ADMINME
through to RPL_ADMINEMAIL and provide a text
message with each. For RPL_ADMINLOC1 a
description of what city, state and country
the server is in is expected, followed by
details of the university and department
(RPL_ADMINLOC2) and finally the administrative
contact for the server (an email address here
is required) in RPL_ADMINEMAIL.
6.3 Reserved numerics.
These numerics are not described above since they fall into one of
the following categories:
1. no longer in use;
2. reserved for future planned use;
3. 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
316 RPL_WHOISCHANOP 361 RPL_KILLDONE
362 RPL_CLOSING 363 RPL_CLOSEEND
373 RPL_INFOSTART 384 RPL_MYPORTIS
466 ERR_YOUWILLBEBANNED 476 ERR_BADCHANMASK
7. Client and server authentication
Clients and servers are both subject to the same level of
authentication. For both, an IP number to hostname lookup (and
reverse check on this) is performed for all connections made to the
server. Both connections are then subject to a password check (if
there is a password set for that connection). These checks are
possible on all connections although the password check is only
commonly used with servers.
An additional check that is becoming of more and more common is that
of the username responsible for making the connection. Finding the
username of the other end of the connection typically involves
connecting to an authentication server such as IDENT as described in
Given that without passwords it is not easy to reliably determine who
is on the other end of a network connection, use of passwords is
strongly recommended on inter-server connections in addition to any
other measures such as using an ident server.
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 with what is laid out. On 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 of
importance to those who wish to implement a server but some parts
also apply directly to clients as well.
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.
The use of multicast IP is an alternative, but it is not widely
available or supported at the present time.
8.1.1 Support of Unix sockets
Given that 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
8.2 Command Parsing
To provide useful 'non-buffered' network IO for clients and servers,
each connection is given its own private 'input buffer' in which the
results of the most recent read and parsing are kept. A buffer size
of 512 bytes is used so as to hold 1 full message, although, this
will 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'.
8.3 Message delivery
It is common to find network links saturated or hosts to which you
are sending data unable to send data. Although Unix typically
handles this through the TCP window and internal buffers, the server
often has large amounts of data to send (especially when a new
server-server link forms) and the small buffers provided in the
kernel are not enough for the outgoing queue. To alleviate this
problem, 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 will first read and parse 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.
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, its connection is closed
using the appropriate procedures. A connection is also dropped if
its sendq grows beyond the maximum allowed, because it is better to
close a slow connection than have a server process block.
8.5 Establishing a server to client connection
Upon connecting to an IRC server, a client is 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 which states its name and version as well as any other
introductory messages which 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
8.6 Establishing a server-server connection.
The process of establishing of a server-to-server connection is
fraught with danger since there are many possible areas where
problems can occur - the least of which are race conditions.
After a server has received a connection following by a PASS/SERVER
pair which were recognised as being valid, the server should then
reply with its own PASS/SERVER information for that connection as
well as all of the other state information it knows about as
When the initiating server receives a PASS/SERVER pair, it too then
checks that the server responding 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 being exchanged between servers is
essential. The required order is as follows:
* all known other servers;
* all known user information;
* all known channel information.
Information regarding servers is sent via extra SERVER messages, user
information with NICK/USER/MODE/JOIN messages and channels with MODE
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 exchange topics.
By passing the state information about servers first, any collisions
with servers that already exist occur before nickname collisions due
to a second server introducing a particular nickname. Due to the IRC
network only being able to exist as an acyclic graph, it may be
possible that the network has already reconnected in another
location, the place where the collision occurs indicating where the
net needs to split.
8.7 Terminating server-client connections
When a client connection closes, a QUIT message is generated on
behalf of the client by the server to which the client connected. No
other message is to be generated or used.
8.8 Terminating server-server connections
If a server-server connection is closed, either via a remotely
generated SQUIT or 'natural' causes, the rest of the connected IRC
network must have its information updated with by the server which
detected the closure. The server then sends a list of SQUITs (one
for each server behind that connection) and a list of QUITs (again,
one for each client behind that connection).
8.9 Tracking nickname changes
All IRC servers are required to keep a history of recent nickname
changes. This is required to allow the server to have a chance of
keeping in touch of things when nick-change race conditions occur
with commands which manipulate them. Commands which must trace nick
* KILL (the nick being killed)
* MODE (+/- o,v)
* KICK (the nick being kicked)
No other commands are to have nick changes checked for.
In the above cases, the server is required to first check for the
existence of the nickname, then check its history to see who that
nick currently belongs to (if anyone!). This reduces the chances of
race conditions but they can still occur with the server ending up
affecting the wrong client. When performing a change trace for an
above command it is recommended that a time range be given and
entries which are too old ignored.
For a reasonable history, a server should be able to keep previous
nickname for every client it knows about if they all decided to
change. This size is limited by other factors (such as memory, etc).
8.10 Flood control of clients
With a large network of interconnected IRC servers, it is quite easy
for any single client attached to the network to supply a continuous
stream of messages that result in not only flooding the network, but
also degrading the level of service provided to others. Rather than
require every 'victim' to be provide their own protection, flood
protection was written into the server and is applied to all clients
except services. The current algorithm is as follows:
* check to see if client's `message timer' is less than
current time (set to be 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 present messages and penalize the client by
2 seconds for each message;
which in essence means that the client may send 1 message every 2
seconds without being adversely affected.
8.11 Non-blocking lookups
In a real-time environment, it is essential that a server process do
as little waiting as possible so that all the clients are serviced
fairly. Obviously this requires non-blocking IO on all network
read/write operations. For normal server connections, this was not
difficult, but there are other support operations that may cause the
server to block (such as disk reads). Where possible, such activity
should be performed with a short timeout.
8.11.1 Hostname (DNS) lookups
Using the standard resolver libraries from Berkeley and others has
meant large delays in some cases where replies have timed out. To
avoid this, a separate set of DNS routines were written which were
setup for non-blocking IO operations and then polled from within the
main server IO loop.
8.11.2 Username (Ident) lookups
Although there are numerous ident libraries for use and inclusion
into other programs, these caused problems since they operated in a
synchronous manner and resulted in frequent delays. Again the
solution was to write a set of routines which would cooperate with
the rest of the server and work using non-blocking IO.
8.12 Configuration File
To provide a flexible way of setting up and running the server, it is
recommended that a configuration file be used which contains
instructions to the server on the following:
* which hosts to accept client connections from;
* which hosts to allow to connect as servers;
* which hosts to connect to (both actively and
* information about where the server is (university,
city/state, company are examples of this);
* who is responsible for the server and an email address
at which they can be contacted;
* hostnames and passwords for clients which wish to be given
access to restricted operator commands.
In specifying hostnames, both domain names and use of the 'dot'
notation (127.0.0.1) should both be accepted. It must be possible to
specify the password to be used/accepted for all outgoing and
incoming connections (although the only outgoing connections are
those to other servers).
The above list is the minimum requirement for any server which wishes
to make a connection with another server. Other items which may be
of use are:
* specifying which servers other server 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' (either in the
configuration file or elsewhere) that is read at startup and used to
decide what hosts clients may use to connect to it.
Both 'deny' and 'allow' should be implemented to provide the required
flexibility for host access control.
The granting of operator privileges to a disruptive person can have
dire consequences for the well-being of the IRC net in general due to
the powers given to them. Thus, the acquisition of such powers
should not be very easy. The current setup requires two 'passwords'
to be used although one of them is usually easy guessed. Storage of
oper passwords in configuration files is preferable to hard coding
them in and should be stored in a crypted format (ie using crypt(3)
from Unix) to prevent easy theft.
8.12.3 Allowing servers to connect
The interconnection of server is not a trivial matter: a bad
connection can have a large impact on the usefulness of IRC. Thus,
each server should have a list of servers to which it may connect and
which servers may connect to it. Under no circumstances should a
server allow an arbitrary host to connect as a server. In addition
to which servers may and may not connect, the configuration file
should also store the password and other characteristics of that
To provide accurate and valid replies to the ADMIN command (see
section 4.3.7), the server should find the relevant details in the
8.13 Channel membership
The current server allows any registered local user to join upto 10
different channels. There is no limit imposed on non-local users so
that the server remains (reasonably) consistant with all others on a
channel membership basis
9. Current problems
There are a number of recognized problems with this protocol, all of
which hope to be solved sometime in the near future during its
rewrite. Currently, work is underway to find working solutions to
It is widely recognized that this protocol does not scale
sufficiently well when used in a large arena. The main problem comes
from the requirement that all servers know about all other servers
and users and that information regarding them be updated as soon as
it changes. It is also desirable to keep the number of servers low
so that the path length between any two points is kept minimal and
the spanning tree as strongly branched as possible.
The current IRC protocol has 3 types of labels: the nickname, the
channel name and the server name. Each of the three types has its
own domain and no duplicates are allowed inside that domain.
Currently, it is possible for users to pick the label for any of the
three, resulting in collisions. It is widely recognized that this
needs reworking, with a plan for unique names for channels and nicks
that don't collide being desirable as well as a solution allowing a
The idea of the nickname on IRC is very convenient for users to use
when talking to each other outside of a channel, but there is only a
finite nickname space and being what they are, its not uncommon for
several people to want to use the same nick. If a nickname is chosen
by two people using this protocol, either one will not succeed or
both will removed by use of KILL (4.6.1).
The current channel layout requires that all servers know about all
channels, their inhabitants and properties. Besides not scaling
well, the issue of privacy is also a concern. A collision of
channels is treated as an inclusive event (both people who create the
new channel are considered to be members of it) rather than an
exclusive one such as used to solve nickname collisions.
Although the number of servers is usually small relative to the
number of users and channels, they two currently required to be known
globally, either each one separately or hidden behind a mask.
In some places within the server code, it has not been possible to
avoid N^2 algorithms such as checking the channel list of a set
In current server versions, there are no database consistency checks,
each server assumes that a neighbouring server is correct. This
opens the door to large problems if a connecting server is buggy or
otherwise tries to introduce contradictions to the existing net.
Currently, because of the lack of unique internal and global labels,
there are a multitude of race conditions that exist. These race
conditions generally arise from the problem of it taking time for
messages to traverse and effect the IRC network. Even by changing to
unique labels, there are problems with channel-related commands being
10. Current support and availability
Mailing lists for IRC related discussion:
Future protocol: email@example.com
General discussion: firstname.lastname@example.org