IRC: Difference between revisions

Content deleted Content added

Inline

Revision as of 06:05, 26 June 2006

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 late 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 to report on the Soviet coup attempt of 1991 throughout a media blackout.^{[citation needed]} It was previously used in a similar fashion by Kuwaitis during the Iraqi invasion.^{[citation needed]}

Technical information

File:XChat Windows.png

A screenshot from X-Chat, an IRC client.

IRC is an open protocol that uses TCP and optionally SSL. 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 and server implementations, such as mIRC and the Bahamut IRCd, respectively. 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 originally provide any support for non-ASCII characters in text, with the 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.11 is most widely used on the IRCnet network. The IRC protocol was extended by Microsoft in 1998 via its IRCX protocol that solves many of the traditional problems that legacy IRC networks faced, along with some features that most users felt were 'ahead of its time'. 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.

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 that 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 "!channels" (Those that are theoretically safe from suffering from the many ways that a user could exploit a channel by "riding a netsplit"), and is the baseline release from which nearly all current implementations are derived.

Significant releases based on 2.8 include:

2.8.21+CS, developed by Comstud
2.8+th, Taner's patchset, which later became
ircd-hybrid, originally developed by Jon Lusky (Rodder) and Diane Bruce (Dianora) as 2.8/hybrid, 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 ircd-hybrid continue to be used on EFnet, with ircd-ratbox (an offshoot of ircd-hybrid) as of 2004 being the most popular.

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

Many modern IRC servers have been coded from scratch, such as csircd (also from Comstud), ConferenceRoom, Microsoft Exchange Chat Service, InspIRCd, and IRCPlus/IRCXPro.

Channels and modes

The basic means of communication in an established IRC session is a channel. You can see all the channels in a server using the command /list [#string] [-min #] [-max #] that lists all currently available channels, optionally filtering for parameters (#string for the entire or part of the name, with wildcards, and #min / #max for number of users in the channel).

Users can join to channels (using the command /join #channelname) and then send messages to it, 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 and less common) 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 an invisible user is on a channel unless you join that channel or use the whois command on its nick.) A simple channel-mode example is 'm' (moderated), specifying that only 'voiced' users and channel operators are allowed to speak on the channel. This, along with 'k' (keyed - requires a password to join the channel) and 'i' (invite-only - requires an invitation from a channel operator) modes can be used to keep abuse out of the channel.

There are five types of channelmodes, four of which will accept an argument, type A accepting an argument to add/remove values from a list (such as 'b'), type B accepting an argument that is used when turning the mode 'on' and 'off' (such as 'k'), type C accepting an argument only when the mode is turned 'on' (such as 'l'), type D which accepts no arguments and is simply a boolean flag (such as 'm', 'n', and 't'), and type E (usually called 'class' or 'prefix' modes) that give/take a privilege from a user on a channel (such as 'o').

Type E modes (channel classes) specify which users on a channel have privileges, and what level of those privileges they have. Originally only 'channel operator' (mode 'o') and 'voice' (mode 'v') existed. Channel operator (usually abbreviated chanop or simply 'op') privileges allow a user to kick users, set modes, and change the topic even if the channel is '+t'. Voice privileges allow a user to speak on a channel if it is moderated (mode 'm'). Additions to these classes are 'channel owner' (mode 'q') created by Microsoft in its IRCX implementation (and later used by UnrealIrcd); 'half-operator' (mode 'h') which is similar to a chanop, except they cannot set certain modes and can only kick normal users; 'protected' (mode 'a'); 'administrator' (mode 'a' or 'u'); and many more.

Each channel class has an associated prefix that is shown beside a user's nickname whenever associated with that channel. The most common prefixes are '@' for channel operator, '+' for voice, '%' for half-op, '.' or '~' for channel owner, '&' for protected user, '!' or the lesser known '*' for administrator.

Unless the channel is moderated, the only effect of +v (voice) is the plus sign appearing beside the nick name. On many channels this is used to indicate seniority or regularity of use, or a kind of "trusted user" flag in case the channel does have to be moderated.

Most IRC networks feature a lot of extra modes not specified in any RFC document. This is a very simple feat for clients to adapt to since a list of all the valid user and channelmodes are sent to clients in the RPL_MYINFO reply upon logon. In addition, the list of channelmodes (and what type of arguments they accept), and the prefixes for class modes are specified in the protocol control reply (RPL_PROTOCTL or 005) sent from most IRC servers when a client connects. This message is used to tell clients what features the server supports, and what its limits are (for example, the maximum number of users you can have on your notify list, or the maximum length of your nickname).

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 "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 (Abbreviated ND/CD) 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. To some extent, this inconvenienced legitimate users, who might be forced to briefly use a different name (appending an underscore was popular) after rejoining.

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; however most networks today use the timestamping approach. It was part of the issues and disagreements which caused several servers to split away from EFnet and form the newer IRCnet (EFNnet 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 and URLs

Today there are several thousand 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.

One can join servers by clicking on a irc://irc.server.net:port/channel web link.

The largest IRC networks have traditionally been grouped in 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.

The Big Four:

Some of the other lesser (but still large) networks include, but are not limited to:

For network statistics, rankings, and a list of smaller networks, see netsplit.de and Search IRC. For other articles on IRC networks, see Category:IRC networks.

Clients

See list of IRC clients for more detail.

mIRC is widely believed to be the most popular IRC client on Windows based systems. However, with the recent introduction of clients such as Bersirc, KVIrc, Trillian, Solar IRC, and X-Chat, mIRC is beginning to see much more competition. Many people still use mIRC most likely due to the fact that it has been around for quite some time and has a wide variety of scripts available. 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. For Mac OS X, the most widely-used clients are Ircle, Colloquy and Conversation. OS X can also run most Unix-like command line and X11 IRC clients. Recently a special build of X-Chat has been gaining ground on OS X systems, X-Chat Aqua.

ChatZilla is the Mozilla IRC client.

Opera also has a built-in IRC client.

For a novice user, mIRC and other large-window clients might seem to be unnecessarily large and complex. New users may prefer instant messenger based clients like Miranda IM or Trillian, providing a familiar interface to the IRC application. The multi-platform open-source instant messenger Gaim also supports connection to the IRC networks.

A framework designed to incorporate IRC into various other applications, such as games, is LibIRC, although it is still heavily under development.

Bots

There are also many automated clients, called bots. The first bot was written by Greg Lindahl and provided moderation for the game of Hunt the Wumpus. As bots evolved, they began to serve as permanent points of contact for information exchange and protection agents for the channels they served, because of their superior speed when compared to humans. Presently, although many of these functions are often delegated to network-provided services which allow for registration and management of both nicknames and channels, bots still remain popular and continue to be adapted to new and unexpected tasks.

Bots can be written in a variety of languages, and a wide array of implementations exist, although recently and partly due to the overwhelming popularity of the mIRC IRC client, an increasing number of bots are written using the mIRC scripting language and run inside the client. Popular 'standalone' bots are Eggdrop and EnergyMech, both written in the C programming language.

Most modern IRC services typically implement bot-like interfaces, through which users can communicate with and control the functionality.

Some bots were created for malevolent uses, such as flooding or taking over channels, occupying them from rightful owner(s). Those have been put on a strict laws in the later years, but not in the early times when they were mostly a new phenomen.

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. Two of the most popular bouncers are muh and psyBNC. Muh is exclusively for single user connections, while psyBNC supports multiple users. Another feature-rich bouncer is ZNC.

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. First being the "back-end" or the "spider/crawler". This 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 (text that is publicly displayed in public channels). The storage method is usually some sort of relational database, like MySQL or Oracle. Which database that is used depends exclusively on the programming language in which the spider bot is written. The second part to the equation is the front-end "search engine". This search engine is the user interface to the database. It supplies the user 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. The more popular languages for such search engines and indexing spiders are: Perl, PHP, ASP and C. Most search engines have their own spider that is a single application that is responsible for crawling IRC and indexing data itself; however, others are "user based" indexers.

What this means is that they rely on users to install their "add-on" to their IRC client (like mIRC) and this add-on is what sends the database the channel information of whatever channel[s] the user happens to be on. IRC search engines have completely automated the process of finding information on IRC and have thus contibuted greatly to the popularity of IRC in recent years.

Some of the more popular IRC search engines are...

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 ("cloaking") 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. An example is the Blitzed Open Proxy Monitor or BOPM, used by several networks.
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). For client-to-client communication, SDCC (Secure DCC) can be used.
Ident: Provides identification to the IRC server.
Connection Protocol: IRC can be connected to via IPv4, the current standard version of the Internet Protocol, or by IPv6, the next-generation version of the Protocol.

Forms of abuse

Like any network open to the public, people with malicious intent can often be found on IRC networks. These people commonly utilize the following tactics:

Denial of service attacks and netsplit abuses, described above.
Responding to requests for help with potentially harmful instructions, such as

Ctrl+Alt+Delete twice (forces a reboot in earlier versions of Windows)
Alt+F4 (Closes current program in Windows)
Ctrl+F4 (Closes current active window in mIRC)
Alt+Z (Closes the current channel window in mIRC)

Attempting to trick users into typing commands that will cause them to quit the server. For example: "Two friends are sitting in a garden: /exit and /quit. /exit walks away, who is left?"
Advertising channels that end in ",0" (such as #0,0). A single JOIN request can join multiple channels separated by commas, and joining channel 0 will cause a user to part all channels.
Using mIRC's $encode() and $decode() feature to make people do IRC commands for them.

File sharing

Using scripts like Sysreset, UPP, Polaris and, most commonly, OmenServe, users can create file servers that allow them to share files with others. In addition to the normal pros and cons of file-sharing (see Copyright infringement of software), there are also groups that set up anime fansubbing networks, allowing American audiences to see anime that would normally be unavailable in English or outside of Japan.

Due to the large number of people who use IRC for file sharing, some think of IRC as a form of P2P file sharing. Conversely, many users try to defeat this view by persistently discouraging it or refusing to help with it. Technically, IRC is not for file sharing, although it does possess some advanced file transfer mechanisms which, most importantly, support resuming.

External links

@@ Line 96: / Line 96: @@
 * [[Undernet]]
+Some of the other lesser (but still large) networks include, but are not limited to:
-''Some of other the lesser (but still large) networks include'', but are not limited:
 * [[UniBG]]
 * [[DALnet]]