Order a domain here

Domains from $3.99

Enter Domain Name:
.com .net .org
Ex: domainname.com

Internet Relay Chat

Internet Relay Chat (IRC) is a form of instant communication over the Internet. It is mainly designed for group (many-to-many) communication in discussion forums called channels, but also allows one-to-one communication.

IRC was created by Jarkko Oikarinen (nickname "WiZ") in August 1988 to replace a program called MUT (MultiUser Talk) on a BBS called OuluBox in Finland. Oikarinen found inspiration in Bitnet Relay Chat which operated on the Bitnet network.

IRC gained prominence when it was used behind the Iron Curtain to report on the fall of the USSR during a media blackout. It was later used in a similar fashion by Kuwaitis during the Iraqi invasion.

Technical information

IRC is an open protocol that uses TCP or Unix-domain sockets and optionally SSL. An IRC server can connect to other IRC servers to form an IRC network. Users access IRC networks by connecting a client to a server. There are many client and server implementations. Most IRC servers do not require users to log in, but a user will have to set a nickname before being connected.

IRC is a plaintext protocol, which means that it is fully possible (though quite inconvenient) to use IRC via a basic byte-stream client such as netcat or telnet. However, the protocol only uses a slightly modified version of ASCII, and does not provide any support for non-ASCII characters in text, with that result that many different, incompatible character encodings (such as ISO 8859-1 and UTF-8) are used.

Because most IRC implementations use an acyclic graph as their connection model, there is no redundancy, and outage of a server or a link can cause a netsplit.

Evolution

All client-to-server IRC protocols in use today are descended from the protocol implemented in the irc2.8 version of the IRC2server, 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; RFC 2810, RFC 2811, RFC 2812 and RFC 2813, however these protocol changes have not been widely adopted among other implementations. IRC 2.10 is most widely used on the IRCnet network.

While the client-to-server protocols are at least functionally similar, server-to-server protocols differ widely (TS5, P10, and ND/CD are several widely-used and incompatible server protocols), making it very difficult to "link" two separate implementations of the IRC server. Some "bridge" servers do exist, to allow linking of, for example, 2.10 servers to TS5 servers, but these are often accompanied with restrictions of which parts of each protocol may be used, and are not widely deployed.

In its first incarnations, IRC did not have many features which are taken for granted today, such as named channels and channel operators. Channels were numbered -- channel 4 and channel 57, for example -- and the channel topic described the kind of conversation that took place in the channel. One holdover of this is that joining channel 0 causes a client to leave all the channels it is presently on: "CHANNEL 0" being the original command to leave the current channel.

The first major change to IRC, in version 2.5, was to add named channels -- "+channels". "+channels" were later replaced with "#channels" in version 2.7, numeric channels were removed entirely and channel bans (mode +b) were implemented. irc2.8 added "&channels" (those that exist only on the current server, rather than the entire network), and is the baseline release from which nearly all current implementations are derived.

Significant releases based on 2.8 include:

• 2.8.21+CS, the EFnet-oriented patchset from Comstud.
• 2.8+th, Taner's patchset, which later became
• 2.8/hybrid, originally developed by Jon Lusky (Rodder) and Diane Bruce (Dianora), later joined by a large development team.
• 2.9, 2.10, 2.11, ... continue the development of the original codebase, mainly for use on the IRCnet network. This development line produced the 4 IRC RFCs released after RFC 1459, which document this server protocol exclusively.

2.8.21+CS and 2.8/hybrid continue to be used on EFnet as of 2004.

Undernet's IRC server, ircu, is one of the few servers not descended from irc2.8; it was forked from the irc2.7 codebase.

Channels and Modes

The basic means of communication in an established IRC session is a channel which users can join and then send messages to, which are then relayed to all other users in the same channel. Channels which are available across an entire IRC network are prepended with a '#', while those local to a server use '&'. Other (non-standard) channel types include '+' channels—'modeless' channels without operators, and '!' channels, a form of timestamped channel on normally non-timestamped networks.

Both users and channels may have modes, which are some kind of attributes or switches. Modes are abbreviated by single letters so you can string them together concisely. An example for an user mode is 'i', which stands for invisible. (You cannot tell whether or not a invisible user is on a channel unless you join that channel.) There are many more channel modes than user modes. A simple example is 'm' (moderated), specifying that only 'voiced' users are allowed to speak on the channel. Many channel modes have arguments, which may be a number, a string or a list of user names. Instances for the latter are 'o', 'v' and 'b', holding the lists of channel operators (see below), voiced users and banned users, respectively.

Most IRC networks feature a lot of extra modes not specified in any RFC document. This makes it difficult to develop portable client software. For a complete list see the external link.

Some users in each channel have modes that make them privileged; these are called channel operators. Only channel operators are allowed to set their channel's modes. There are also users whose privileges extend to whole servers or networks of servers; these are called IRC Operators. On some IRC implementations, IRC operators are also given channel operator status in every channel, although many people believe that administration of channels and administration of the network should be kept separate, and that IRC operator status does not confer the right to interfere with a particular channel's operation.

Because IRC connections are unencrypted and typically span long time periods, they are an attractive target for malicious hackers. Because of this, careful security policy is necessary to ensure that an IRC network is not susceptible to an attack such as an IRC takeover war. IRC networks also k-line or g-line users or networks that tend to have a harming effect.

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 ("nuking") to annoy users or facilitate takeovers.

Abuse prevention: timestamping vs. nick/channel delay protocol

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 which 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 which 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 an "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.

Nick/channel delay

The nick/channel delay solution to this problem was very simple. After a user signed off and the nickname became available, or a channel ceased to exist because all its users left (as often happens during a netsplit), the server would not allow any user to use that nickname or join that channel, respectively, until a certain period of time (the delay) had passed. The idea behind this was that even if a netsplit occurred, it was useless to an abuser because they could not take the nickname or gain operator status on a channel, and thus no collision of a nickname or 'merging' of a channel could occur.

Timestamping

The alternative, the timestamp or TS protocol, took a different approach. Every nickname and channel on the network was assigned a timestamp -- the date and time when it was created. When a netsplit occurred, two users on each side were free to use the same nickname or channel, but when the two sides were joined, only one could survive. In the case of nicknames, the newer user, according to their TS, was killed; when a channel collided, the members (users on the channel) were merged, but the channel operators on the "losing" side of the split were de-opped.

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" (where two servers on the same network disagree about the current state of the network), 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 which would then be merged when the split rejoined, even though the users who had set those modes were no longer opped. 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.

There is not, and likely never will be, a consensus on timestamping vs. delay; it was part of the issues and disagreements which caused the split between EFnet and IRCnet (EFnet after the split moving to a TS protocol, and IRCnet using ND/CD), and supporters on both sides were known for heated arguments regarding the merits of their solution.

Networks

Today there are several hundred running IRC networks in the world. They run various implementations of IRC servers, and are administered by various groups of IRC Operators, but the protocol exposed to IRC users is very similar, and all IRC networks can be accessed by the same client software.

The largest IRC networks have traditionally been grouped in The Big Four — a designation for networks that top the statistics. Currently this includes four networks regularly frequented by around or over hundred thousand clients, namely:

• EFnet
• IRCnet
• QuakeNet
• Undernet

Other large networks include:

• DALnet
• Enter The Game
• Freenode
• GameSurge

Clients

• Multiple platforms : ChatZilla, ircII-EPIC, Gaim, jIRC, X-Chat
• Microsoft Windows : Bersirc, dIRC, HydraIRC, Klient, mIRC, Microsoft Comic Chat, Miranda IM, pIRCh, Trillian, ViRC, XiRCON
• Unix-like : BitchX, IIRC, ircII, irssi, Kopete, KVIrc, naim, ScrollZ, TalkSoup, Zircon
• MacOS : Colloquy, Fire, IRCle, Minerva IRC, Snak, ShadowIRC
• AmigaOS : AmIRC
• DOS : jpirc

mIRC is widely believed to be the most popular IRC client. ircII is the canonical Unix IRC client, but its userbase has declined with the appearance of competing clients such as ircII-EPIC, BitchX, irssi, X-Chat etc.

Bots

There are also many automated clients, called bots. The first bot was written by Greg Lindahl and provided moderation for the game of Wumpus, but most modern bots are usually used to exercise operator privileges (controlling channels and acting quickly in case of abuse), to annoy other users (perhaps by spamming them with lots of messages), to answer repetitive user questions and provide help when channels are not attended, or serve as permanent points of contact for information exchange (an answering machine, file transfer, etc.). The most popular IRC bot is Eggdrop.

The modern IRC services are implemented via bots. They're used for example in channel maintenance: banning users, keeping a list of operators, keeping the channel topic etc.

Bouncer

A program that runs as a daemon on a server and functions as a persistent proxy is known as a bouncer. A bouncer's purpose is to maintain a connection to an IRC server, acting as a relay between it and the connecting client. Should the client lose network connectivity, the bouncer will archive all traffic for later delivery, allowing the user to resume his IRC session without externally perceptible disruption.

Modern IRC

IRC has changed much over its life on the Internet. New server software has added a multitude of new features.

• Services: Network-Operated bots to facilitate registration of nicknames and channels, sending messages for offline users and network operator functions.
• Extra Modes: While the original IRC system used a set of standard user and channel modes, new servers add many new modes for such features as removing color codes from text, or obscuring a user's hostmask to protect from denial of service attacks.
• Proxy Detection: Most modern servers support detection of users attempting to connect through an insecure (misconfigured or exploited) proxy, which can then be denied a connection.
• Additional Commands: New commands can be such things as shorthand commands to issue commands to Services, to network operator only commands to manipulate a user's hostmask.
• Encryption: For the client-to-server leg of the connection SSL might be used (messages cease to be secure once they are relayed to other users on standard connections, but it makes eavesdropping on or wiretapping an individual's IRC sessions difficult).

See also

• Bash.org
• Depot channel
• Direct Client-to-Client
• Idle RPG - A role playing game for IRC
• Instant messaging
• Online chat
• Peer-to-peer
• XDCC

External links

• History of IRC summarized by Daniel Stenberg (http://daniel.haxx.se/irchistory.html)
• mIRC server list, most of the larger IRC networks (http://www.mirc.com/servers.html)
• Andreas Gelhausen's extensive IRC statistics (http://irc.netsplit.de/)
• List of channel modes that various IRC Daemons use (http://www.alien.net.au/irc/chanmodes.html)
• SearchIRC provides a search for terms in channelname and topic, including most IRC networks (http://searchirc.com/)