Internet Relay Chat


Internet Relay Chat is an application layer protocol that facilitates communication in the form of text. The chat process works on a client/server networking model. IRC clients are computer programs that users can install on their system or web based applications running either locally in the browser or on a 3rd party server. These clients communicate with chat servers to transfer messages to other clients. IRC is mainly designed for group communication in discussion forums, called [|channels], but also allows one-on-one communication via private messages as well as chat and data transfer, including file sharing.
Client software is available for every major operating system that supports Internet access. As of April 2011, the top 100 IRC networks served more than half a million users at a time, with hundreds of thousands of channels operating on a total of roughly 1,500 servers out of roughly 3,200 servers worldwide. IRC usage has been declining steadily since 2003, losing 60% of its users and half of its channels.

History

IRC was created by Jarkko Oikarinen in August 1988 to replace a program called MUT on a BBS called OuluBox at the University of Oulu in Finland, where he was working at the Department of Information Processing Science. Jarkko intended to extend the BBS software he administered, to allow news in the Usenet style, real time discussions and similar BBS features. The first part he implemented was the chat part, which he did with borrowed parts written by his friends Jyrki Kuoppala and Jukka Pihl. The first IRC network was running on a single server named tolsun.oulu.fi. Oikarinen found inspiration in a chat system known as Bitnet Relay, which operated on the BITNET.
Jyrki Kuoppala pushed Oikarinen to ask Oulu University to free the IRC code so that it also could be run outside of Oulu, and after they finally got it released, Jyrki Kuoppala immediately installed another server. This was the first "irc network". Oikarinen got some friends at the Helsinki University and Tampere University to start running IRC servers when his number of users increased and other universities soon followed. At this time Oikarinen realized that the rest of the BBS features probably wouldn't fit in his program.
Oikarinen got in touch with people at the University of Denver and Oregon State University. They had their own IRC network running and wanted to connect to the Finnish network. They had obtained the program from one of Oikarinen's friends, Vijay Subramaniam—the first non-Finnish person to use IRC. IRC then grew larger and got used on the entire Finnish national network—Funet—and then connected to Nordunet, the Scandinavian branch of the Internet. In November 1988, IRC had spread across the Internet and in the middle of 1989, there were some 40 servers worldwide.

EFnet

In August 1990, the first major disagreement took place in the IRC world. The "A-net" included a server named eris.berkeley.edu. It was all open, required no passwords and had no limit on the number of connects. As Greg "wumpus" Lindahl explains: "it had a wildcard server line, so people were hooking up servers and nick-colliding everyone". The "Eris Free Network", EFnet, made the eris machine the first to be Q-lined from IRC. In wumpus' words again: "Eris refused to remove that line, so I formed EFnet. It wasn't much of a fight; I got all the hubs to join, and almost everyone else got carried along." A-net was formed with the eris servers, while EFnet was formed with the non-eris servers. History showed most servers and users went with EFnet. Once ANet disbanded, the name EFnet became meaningless, and once again it was the one and only IRC network.
It is around that time that IRC was used to report on the 1991 Soviet coup d'état attempt throughout a media blackout. It was previously used in a similar fashion during the Gulf War. Chat logs of these and other events are kept in the ibiblio archive.

Undernet fork

Another fork effort, the first that really made a big and lasting difference, was initiated by 'Wildthang' in the U.S. October 1992. It was meant to be just a test network to develop bots on but it quickly grew to a network "for friends and their friends". In Europe and Canada a separate new network was being worked on and in December the French servers connected to the Canadian ones, and by the end of the month, the French and Canadian network was connected to the US one, forming the network that later came to be called "The Undernet".
The "undernetters" wanted to take ircd further in an attempt to make it less bandwidth consumptive and to try to sort out the channel chaos that EFnet started to suffer from. For the latter purpose, the Undernet implemented timestamps, new routing and offered the CService—a program that allowed users to register channels and then attempted to protect them from troublemakers. The very first server list presented, from 15 February 1993, includes servers from USA, Canada, France, Croatia and Japan. On 15 August, the new user count record was set to 57 users.
In May 1993, RFC 1459 was published and details a simple protocol for client/server operation, channels, one-to-one and one-to-many conversations. It is notable that a significant number of extensions like CTCP, colors and formats are not included in the protocol specifications, nor is character encoding, which led various implementations of servers and clients to diverge. In fact, software implementation varied significantly from one network to the other, each network implementing their own policies and standards in their own code bases.

DALnet fork

During the summer of 1994, the Undernet was itself forked. The new network was called DALnet, formed for better user service and more user and channel protections. One of the more significant changes in DALnet was use of longer nicknames. DALnet ircd modifications were made by Alexei "Lefler" Kosut. DALnet was thus based on the Undernet ircd server, although the DALnet pioneers were EFnet abandoners. According to James Ng, the initial DALnet people were "ops in #StarTrek sick from the constant splits/lags/takeovers/etc".
DALnet quickly offered global WallOps, longer nicknames, Q:Lined nicknames, global K:Lines, IRCop only communications: GlobOps, +H mode showing that an IRCop is a "helpop" etc. Much of DALnet's new functions were written in early 1995 by Brian "Morpher" Smith and allow users to own nicknames, control channels, send memos, and more.

IRCnet fork

In July 1996, after months of flame wars and discussions on the mailing list, there was yet another split due to disagreement in how the development of the ircd should evolve. Most notably, the "european" side that later named itself IRCnet argued for nick and channel delays where the EFnet side argued for timestamps. There were also disagreements about policies: the European side had started to establish a set of rules directing what IRCops could and could not do, a point of view opposed by the US side.
Most of the IRCnet servers were in Europe, while most of the EFnet servers were in the US. This event is also known as "The Great Split" in many IRC societies. EFnet has since grown and passed the number of users it had then. In the autumn of the year 2000, EFnet had some 50,000 users and IRCnet 70,000.

Modern IRC

IRC has changed much over its life on the Internet. New server software has added a multitude of new features.
, a new standardization effort is under way under a working group called IRCv3, which focuses on more advanced client features like instant notifications, better history support and improved security., no major IRC networks have fully adopted the proposed standard.
After its golden era during the 1990s and early 2000s, IRC has seen a significant decline, losing around 60% of users between 2003 and 2012, with users moving to newer social media platforms like Facebook or Twitter, but also to open platforms like XMPP which was developed in 1999. Certain networks like Freenode have not followed the overall trend and have more than quadrupled in size during the same period. As of 2016, Freenode is the largest IRC network with around 90,000 users.
The largest IRC networks have traditionally been grouped as the "Big Four"—a designation for networks that top the statistics. The Big Four networks change periodically, but due to the community nature of IRC there are a large number of other networks for users to choose from.
Historically the "Big Four" were:
IRC reached 6 million simultaneous users in 2001 and 10 million users in 2003, dropping to 371k in 2018.
, the largest IRC networks are:
Today, the top 100 IRC networks have around 370k users connected at peak hours.

Timeline

Technical information

IRC is an open protocol that uses TCP and, optionally, TLS. An IRC server can connect to other IRC servers to expand the IRC network. Users access IRC networks by connecting a client to a server. There are many client implementations, such as mIRC, HexChat and irssi, and server implementations, e.g. the original IRCd. Most IRC servers do not require users to register an account but a nick is required before being connected.
IRC was originally a plain text protocol, which on request was assigned port 194/TCP by IANA. However, the de facto standard has always been to run IRC on 6667/TCP and nearby port numbers to avoid having to run the IRCd software with root privileges.
The protocol specified that characters were 8-bit but did not specify the character encoding the text was supposed to use. This can cause problems when users using different clients and/or different platforms want to converse.
All client-to-server IRC protocols in use today are descended from the protocol implemented in the irc2.4.0 version of the IRC2 server, and documented in RFC 1459. Since RFC 1459 was published, the new features in the irc2.10 implementation led to the publication of several revised protocol documents ; however, these protocol changes have not been widely adopted among other implementations.
Although many specifications on the IRC protocol have been published, there is no official specification, as the protocol remains dynamic. Virtually no clients and very few servers rely strictly on the above RFCs as a reference.
Microsoft made an extension for IRC in 1998 via the proprietary IRCX. They later stopped distributing software supporting IRCX, instead developing the proprietary MSNP.
The standard structure of a network of IRC servers is a tree. Messages are routed along only necessary branches of the tree but network state is sent to every server and there is generally a high degree of implicit trust between servers. However, this architecture has a number of problems. A misbehaving or malicious server can cause major damage to the network and any changes in structure, whether intentional or a result of conditions on the underlying network, require a net-split and net-join. This results in a lot of network traffic and spurious quit/join messages to users and temporary loss of communication to users on the splitting servers. Adding a server to a large network means a large background bandwidth load on the network and a large memory load on the server. Once established, however, each message to multiple recipients is delivered in a fashion similar to multicast, meaning each message travels a network link exactly once. This is a strength in comparison to non-multicasting protocols such as Simple Mail Transfer Protocol or Extensible Messaging and Presence Protocol.
An IRC daemon can also be used on a local area network. IRC can thus be used to facilitate communication between people within the local area network.

Commands and replies

IRC has a line-based structure. Clients send single-line messages to the server, receive replies to those messages and receive copies of some messages sent by other clients. In most clients, users can enter commands by prefixing them with a '/'. Depending on the command, these may either be handled entirely by the client, or passed directly to the server, possibly with some modification.
Due to the nature of the protocol, automated systems cannot always correctly pair a sent command with its reply with full reliability and are subject to guessing.

Channels

The basic means of communicating to a group of users in an established IRC session is through a channel. Channels on a network can be displayed using the IRC command LIST, which lists all currently available channels that do not have the modes +s or +p set, on that particular network.
Users can join a channel using the JOIN command, in most clients available as /join #channelname. Messages sent to the joined channels are then relayed to all other users.
Channels that are available across an entire IRC network are prefixed with a '#', while those local to a server use '&'. Other less common channel types include '+' channels—'modeless' channels without operators—and '!' channels, a form of [|timestamped] channel on normally non-timestamped networks.

Modes

Users and channels may have modes that are represented by single case-sensitive letters and are set using the MODE command. User modes and channel modes are separate and can use the same letter to mean different things Modes are usually set and unset using the mode command that takes a target, a set of modes to set or unset and any parameters the modes need.
Some channel modes take parameters and other channel modes apply to a user on a channel or add or remove a mask from a list associated with the channel rather than applying to the channel as a whole. Modes that apply to users on a channel have an associated symbol that is used to represent the mode in names replies and in many clients also used to represent it in the client's displayed list of users in a channel or to display an own indicator for a user's modes.
In order to correctly parse incoming mode messages and track channel state the client must know which mode is of which type and for the modes that apply to a user on a channel which symbol goes with which letter. In early implementations of IRC this had to be hard-coded in the client but there is now a de facto standard extension to the protocol called ISUPPORT that sends this information to the client at connect time using numeric 005.
There is a small design fault in IRC regarding modes that apply to users on channels: the names message used to establish initial channel state can only send one such mode per user on the channel, but multiple such modes can be set on a single user. For example, if a user holds both operator status and voice status on a channel, a new client will be unable to see the mode with less priority. Workarounds for this are possible on both the client and server side but none are widely implemented.

Standard (RFC 1459) modes

LetterSymbolDescription
iInvisible—cannot be seen without a common channel or knowing the exact name
sReceives server notices
wReceives wallops
oUser is an IRC operator

LetterSymbolParameterDescription
o@Name of affected userChannel operator—can change channel modes and kick users out of the channel among other things
sSecret channel—not shown in channel list or user whois except to users already on the channel
pPrivate channel—listed in channel list as "prv" according to RFC 1459
nUsers cannot send messages to the channel externally
mChannel is moderated
iOnly users with invites may enter the channel.
tOnly channel operators can change the channel topic.
lLimit numberLimits number of users able to be on channel
bBan mask Bans hostmasks from channel
v+Name of affected userGives a user voice status on channel
kNew channel keySets a channel key such that only users knowing the key can enter

Many daemons and networks have added extra modes or modified the behavior of modes in the above list.

Channel Operators

A Channel Operator is a client on an IRC channel that manages the channel.
IRC Channel Operators can be easily seen by the a symbol or icon next to their name.
On most networks, an operator can:
There are also users who maintain elevated rights on their local server, or the entire network; these are called IRC operators, sometimes shortened to IRCops or Opers. As the implementation of the IRCd varies, so do the privileges of the IRC operator on the given IRCd. RFC 1459 claims that IRC operators are "a necessary evil" to keep a clean state of the network, and as such they need to be able to disconnect and reconnect servers. Additionally, to prevent malicious users or even harmful automated programs from entering IRC, IRC operators are usually allowed to disconnect clients and completely ban IP addresses or complete subnets. Networks that carry services usually allow their IRC operators also to handle basic "ownership" matters. Further privileged rights may include overriding channel bans, being able to op themselves on channels where they would not be able without being opered, being auto-opped on channels always and so forth.

Hostmasks

A hostmask is a unique identifier of an IRC client connected to an IRC server. IRC servers, services, and other clients, including bots, can use it to identify a specific IRC session.
The format of a hostmask is nick!user@host. The hostmask looks similar to, but should not be confused with an e-mail address.
The nick part is the nickname chosen by the user and may be changed while connected.
The user part is the username reported by ident on the client. If ident is not available on the client, the username specified when the client connected is used after being prefixed with a tilde.
The host part is the hostname the client is connecting from. If the IP address of the client cannot be resolved to a valid hostname by the server, it is used instead of the hostname.
Because of the privacy implications of exposing the IP address or hostname of a client, some IRC daemons also provide privacy features, such as InspIRCD or UnrealIRCd's "+x" mode. This hashes a client IP address or masks part of a client's hostname, making it unreadable to users other than IRCops. Users may also have the option of requesting a "virtual host", to be displayed in the hostmask to allow further anonymity. Some IRC networks such as Freenode use these as "cloaks" to indicate that a user is affiliated with a group or project.

URI scheme

There are three recognized uniform resource identifier schemes for Internet Relay Chat: irc, ircs, and irc6. When supported, they allow hyperlinks of various forms, including
irc://///[?
to be used to connect to the specified host and join the specified channel.. irc is the default URI, irc6 specifies a connection to be made using IPv6, and ircs specifies a secure connection.
Per the specification, the usual [hash symbol will be prepended to channel names that begin with an alphanumeric character—allowing it to be omitted. Some implementations will do so unconditionally resulting in a extra, if included in the URL.
Some implementations allow multiple channels to be specified, separated by commas.

Challenges

Issues in the original design of IRC were the amount of shared state data being a limitation on its scalability, the absence of unique user identifications leading to the nickname collision problem, lack of protection from netsplits by means of cyclic routing, the trade-off in scalability for the sake of real-time user presence information, protocol weaknesses providing a platform for abuse, no transparent and optimizable message passing, and no encryption. Some of these issues have been addressed in Modern IRC.

Attacks

Because IRC connections may be unencrypted and typically span long time periods, they are an attractive target for DoS/DDoS attackers and hackers. Because of this, careful security policy is necessary to ensure that an IRC network is not susceptible to an attack such as a takeover war. IRC networks may also K-line or G-line users or servers that have a harming effect.
Some IRC servers support SSL/TLS connections for security purposes. This helps stop the use of packet sniffer programs to obtain the passwords of IRC users, but has little use beyond this scope due to the public nature of IRC channels. SSL connections require both client and server support. Some networks also use SSL for server-to-server connections, and provide a special channel flag to only allow SSL-connected users on the channel, while disallowing operator identification in clear text, to better utilize the advantages that SSL provides.
IRC served as an early laboratory for many kinds of Internet attacks, such as using fake ICMP unreachable messages to break TCP-based IRC connections to annoy users or facilitate takeovers.

Abuse prevention

One of the most contentious technical issues surrounding IRC implementations, which survives to this day, is the merit of "Nick/Channel Delay" vs. "Timestamp" protocols. Both methods exist to solve the problem of denial-of-service attacks, but take very different approaches.
The problem with the original IRC protocol as implemented was that when two servers split and rejoined, the two sides of the network would simply merge their channels. If a user could join on a "split" server, where a channel that existed on the other side of the network was empty, and gain operator status, they would become a channel operator of the "combined" channel after the netsplit ended; if a user took a nickname that existed on the other side of the network, the server would kill both users when rejoining.
This was often abused to "mass-kill" all users on a channel, thus creating "opless" channels where no operators were present to deal with abuse. Apart from causing problems within IRC, this encouraged people to conduct denial-of-service attacks against IRC servers in order to cause netsplits, which they would then abuse.
The nick delay and channel delay strategies aim to prevent abuse by delaying reconnections and renames. After a user signs off and the nickname becomes available, or a channel ceases to exist because all its users parted, the server will not allow any user to use that nickname or join that channel, until a certain period of time has passed. The idea behind this is that even if a netsplit occurs, it is useless to an abuser because they cannot take the nickname or gain operator status on a channel, and thus no collision of a nickname or 'merging' of a channel can occur. To some extent, this inconveniences legitimate users, who might be forced to briefly use a different name after rejoining.
The timestamp protocol is an alternative to nick/channel delays which resolves collisions using timestamped priority. Every nickname and channel on the network is assigned a timestampthe date and time when it was created. When a netsplit occurs, two users on each side are free to use the same nickname or channel, but when the two sides are joined, only one can survive. In the case of nicknames, the newer user, according to their TS, is killed; when a channel collides, the members are merged, but the channel operators on the "losing" side of the split lose their channel operator status.
TS is a much more complicated protocol than ND/CD, both in design and implementation, and despite having gone through several revisions, some implementations still have problems with "desyncs", and allowing too much leniency in what was allowed by the 'losing' side. Under the original TS protocols, for example, there was no protection against users setting bans or other modes in the losing channel that would then be merged when the split rejoined, even though the users who had set those modes lost their channel operator status. Some modern TS-based IRC servers have also incorporated some form of ND and/or CD in addition to timestamping in an attempt to further curb abuse.
Most networks today use the timestamping approach. The timestamp versus ND/CD disagreements caused several servers to split away from EFnet and form the newer IRCnet. After the split, EFnet moved to a TS protocol, while IRCnet used ND/CD.
In recent versions of the IRCnet ircd, as well as ircds using the TS6 protocol, ND has been extended/replaced by a mechanism called SAVE. This mechanism assigns every client a UID upon connecting to an IRC server. This ID starts with a number, which is forbidden in nicks.
If two clients with the same nickname join from different sides of a netsplit, the first server to see this collision will force both clients to change their nick to their UID, thus saving both clients from being disconnected. On IRCnet, the nickname will also be locked for some time to prevent both clients from changing back to the original nickname, thus colliding again.

Clients

Client software

Client software exists for various operating systems or software packages, as well as web-based or inside games. Many different clients are available for the various operating systems, including Windows, Unix and Linux, Mac OS X and mobile operating systems. On Windows, mIRC is one of the most popular clients.
Some programs which are extensible through plug-ins also serve as platforms for IRC clients. For instance, a client called ERC, written entirely in Emacs Lisp, is included in v.22.3 of Emacs. Therefore, any platform that can run Emacs can run ERC.
A number of web browsers have built-in IRC clients, such as Opera and the ChatZilla add-on for Mozilla Firefox. Web-based clients, such as Mibbit and open source KiwiIRC, can run in most browsers.
Games such as War§ow, Unreal Tournament, Uplink, Spring Engine-based games, 0 A.D. and ZDaemon have included IRC.
Ustream's chat interface is IRC with custom authentication as well as Twitch's.

Bots

A typical use of bots in IRC is to provide IRC services or specific functionality within a channel such as to host a chat-based game or provide notifications of external events. However, some IRC bots are used to launch malicious attacks such as denial of service, spamming, or exploitation.

Bouncer

A program that runs as a daemon on a server and functions as a persistent proxy is known as a BNC or bouncer. The purpose is to maintain a connection to an IRC server, acting as a relay between the server and client, or simply to act as a proxy. Should the client lose network connectivity, the BNC may stay connected and archive all traffic for later delivery, allowing the user to resume their IRC session without disrupting their connection to the server.
Furthermore, as a way of obtaining a bouncer-like effect, an IRC client may be run on an always-on server to which the user connects via ssh. This also allows devices that only have ssh functionality, but no actual IRC client installed themselves, to connect to the IRC, and it allows sharing of IRC sessions.
To keep the IRC client from quitting when the ssh connection closes, the client can be run inside a terminal multiplexer such as GNU Screen or tmux, thus staying connected to the IRC network constantly and able to log conversation in channels that the user is interested in, or to maintain a channel's presence on the network. Modelled after this setup, in 2004 an IRC client following the client-server model, called Smuxi, was launched.

Search engines

There are numerous search engines available to aid the user in finding what they are looking for on IRC. Generally the search engine consists of two parts, a "back-end" and a front-end "search engine".
The back-end is the work horse of the search engine. It is responsible for crawling IRC servers to index the information being sent across them. The information that is indexed usually consists solely of channel text. The storage method is usually some sort of relational database, like MySQL or Oracle.
The front-end "search engine" is the user interface to the database. It supplies users with a way to search the database of indexed information to retrieve the data they are looking for. These front-end search engines can also be coded in numerous programming languages.
Most search engines have their own spider that is a single application responsible for crawling IRC and indexing data itself; however, others are "user based" indexers. The latter rely on users to install their "add-on" to their IRC client; the add-on is what sends the database the channel information of whatever channels the user happens to be on.
Many users have implemented their own ad hoc search engines using the logging features built into many IRC clients. These search engines are usually implemented as bots and dedicated to a particular channel or group of associated channels.

Character encoding

IRC still lacks a single globally accepted standard convention for how to transmit characters outside the 7-bit ASCII repertoire.
IRC servers normally transfer messages from a client to another client just as byte sequences, without any interpretation or recoding of characters. The IRC protocol lacks mechanisms for announcing and negotiating character encoding options. This has put the responsibility for choosing the appropriate character codec on the client. In practice, IRC channels have largely used the same character encodings that were also used by operating systems in the respective language communities:
Today, the UTF-8 encoding of Unicode/ISO 10646 would be the most likely contender for a single future standard character encoding for all IRC communication, if such standard ever relaxed the 510-byte message size restriction. UTF-8 is ASCII compatible and covers the superset of all other commonly used coded character set standards.

File sharing

Much like conventional P2P file sharing, users can create file servers that allow them to share files with each other by using customised IRC bots or scripts for their IRC client. Often users will group together to distribute warez via a network of IRC bots.
Technically, IRC provides no file transfer mechanisms itself; file sharing is implemented by IRC clients, typically using the Direct Client-to-Client protocol, in which file transfers are negotiated through the exchange of private messages between clients. The vast majority of IRC clients feature support for DCC file transfers, hence the view that file sharing is an integral feature of IRC. The commonplace usage of this protocol, however, sometimes also causes DCC spam. DCC commands have also been used to exploit vulnerable clients into performing an action such as disconnecting from the server or exiting the client.