Wikipedia - Benutzerbeiträge [de]

Matrix (Kommunikationsprotokoll)

2015-05-09T11:33:57Z

Categorization: just jotting first

{{AFC submission|t||ts=20150328052535|u=ThaddeusB|ns=118}}

'''Matrix''' is an [[application layer]] protocol based on open standard for decentralised communication, providing simple HTTP APIs and open source reference implementations for securely distributing and persisting JSON over an open federation of servers.<ref>{{Cite web|url = https://matrix.org/|title = Matrix.org|date = |accessdate = 2015-03-27|website = |publisher = |last = |first = }}</ref>

Matrix.org is an ambitious not-for-profit open source initiative defining a new open standard for decentralised, persistent and interoperable communications over the internet. Matrix.org’s aim is to fix the problem of fragmented IP-communications between devices, people and services, and make them as seamless and interoperable as possible. Matrix addresses use cases like VoIP, IoT and instant messaging but its real potential and ultimate mission is to be a generic messaging and data synchronization system for the web - allowing anyone and anything to easily communicate securely, maintaining full conversation history with no single points of control or failure. Any developer can use Matrix to easily create and host their own feature-rich real-time communication apps or add such features to an existing service whilst building on the Matrix community of users. Existing communication services can also easily join in and integrate with the Matrix ecosystem.

The Matrix standard specifies simple RESTful HTTP APIs for securely transmitting and replicating JSON data between Matrix-capable clients, servers and services. Clients send data by PUTing it to a ‘room’ on their server, which then replicates the data over all the Matrix servers participating in this ‘room’. This data is signed using a blockchain-style signature to mitigate tampering, and the federated traffic is encrypted with HTTPS and signed with each server’s private key to avoid spoofing. Replication follows eventual consistency semantics, allowing servers to function even if offline or after data-loss by resynchronizing missing history from other participating servers. End-to-end encryption ensures data at rest is only readable by the room participants. The result is that data transmitted over Matrix is never stored in any single place, and is instead securely shared on a purely need-to-know basis between relevant parties, with control of access residing solely with the author.

- See more at: https://www.crunchbase.com/organization/matrix-org#sthash.GJAZxJGJ.dpuf
https://www.crunchbase.com/organization/matrix-org

Client software is available for open-federated Instant Messaging (IM), Voice over IP (VoIP) and Internet of Things (IoT) communication, designed to create and support a new global real-time communication ecosystem.<ref>{{Cite web|url = https://matrix.org/docs/spec/|title = Matrix Specification Documentation|date = 2015-03-27|accessdate = |website = |publisher = |last = |first = }}</ref>
<references />{{Computer-mediated communication}}

Matrix (Kommunikationsprotokoll)

2015-03-30T15:18:37Z

Categorization: removing extra table, but keeping the computer-mediated communication one just to see if there is a part that fits wih Matrix?? unsure, will change probably

Matrix (Kommunikationsprotokoll)

2015-03-28T02:15:28Z

Categorization: basic cites

Matrix (Kommunikationsprotokoll)

2015-03-28T00:53:01Z

Categorization: cutting!

Matrix (Kommunikationsprotokoll)

2015-03-28T00:39:10Z

Categorization: hmm

'''Matrix''' is an [[application layer]] protocol based on open standard for decentralised communication, providing simple HTTP APIs and open source reference implementations for securely distributing and persisting JSON over an open federation of servers.

Client software is available for open-federated Instant Messaging (IM), Voice over IP (VoIP) and Internet of Things (IoT) communication, designed to create and support a new global real-time communication ecosystem.

facilitates transfer of messages in the form of text. The chat process works on a client/server model of networking. IRC clients are computer programs that a user can install on their system. These clients are able to communicate with chat servers to transfer messages to other clients.<ref name="rfc 1459 1 introduction">{{cite IETF
| rfc = 1459
| sectionname = Introduction
| section = 1
| page = 4
| idanchor = ietf
}}</ref> It is mainly designed for [[Many-to-many|group communication]] in discussion forums, called ''[[#Channels|channels]]'',<ref>{{cite IETF
| rfc = 1459
| sectionname = One-to-many
| section = 3.2
| page = 11
| idanchor = ietf
}}</ref> but also allows one-to-one communication via [[instant messaging|private message]]<ref>{{cite IETF
| rfc = 2810
| sectionname = One-To-One Communication
| section = 5.1
| page = 5
| idanchor = ietf
}}</ref> as well as [[Direct Client-to-Client|chat and data transfer]],<ref>{{cite web
| url = http://www.irchelp.org/irchelp/rfc/dccspec.html
| title = A description of the DCC protocol
| accessdate = 2011-04-08
| last = Rollo
| first = Troy
| publisher = irchelp.org
}}</ref> including [[file sharing]].<ref>{{cite book
| last = Wang
| first = Wallace
| title = Steal this File Sharing Book
| edition = 1st
| date = 2004-10-25
| publisher = [[No Starch Press]]
| location = [[San Francisco, California]]
| isbn = 1-59327-050-X
| pages = 61{{spaced ndash}}67
| chapter = Instant Messaging and Online Chat Rooms: Internet Relay Chat (IRC)
}}</ref>

[[Comparison of Internet Relay Chat clients|Client software]] is available for every major operating system that supports Internet access.<ref name=Sage>{{cite web
|title=SAGE IRC Channel
|url=http://www.sage.org/about/irc.html
|publisher=Sage – The USENIX Special Interest Group for Sysadmins
|accessdate=18 April 2011
|archiveurl=http://web.archive.org/web/20120207191923/http://sage.org/about/irc.html|archivedate=7 February 2012}}</ref> As of April 2011, the top 100 IRC networks served more than half a million users at a time,<ref name="irc networks top 100">{{cite web
| url = http://irc.netsplit.de/networks/top100.php
| title = IRC Networks – Top 100
| accessdate = 2011-04-08
| publisher = irc.netsplit.de
}}</ref> with hundreds of thousands of channels<ref name="irc networks top 100" /> operating on a total of roughly 1,500 servers<ref name="irc networks top 100" /> out of roughly 3,200 servers worldwide.<ref>{{cite web
| url = http://irc.netsplit.de/servers/summary.php
| title = IRC Servers – Summary
| accessdate = 2011-04-08
| publisher = irc.netsplit.de
}}</ref>

Over the past decade IRC usage has been declining: since 2003 it has lost 60% of its users (from 1 million to about 400,000 in 2014) and half of its channels (from half a million in 2003).<ref>{{cite web
| url = http://royal.pingdom.com/2012/04/24/irc-is-dead-long-live-irc/
| title = IRC is dead, long live IRC
| accessdate = 2014-05-16
}}</ref>

{{IPstack}}

==History {{anchor|MultiUser Talk}}== 
IRC was created by [[Jarkko Oikarinen]] in August 1988 to replace a program called MUT (MultiUser Talk) on a [[Bulletin board system|BBS]] called OuluBox in [[Finland]].<ref name="founding irc">{{cite web
| url = http://www.mirc.com/jarkko.html
| title = Founding IRC
| accessdate = 2011-04-08
| last = Oikarinen
| first = Jarkko
| authorlink = Jarkko Oikarinen
}}</ref> Oikarinen found inspiration in a chat system known as [[Bitnet Relay]], which operated on the [[BITNET]].<ref name="founding irc" />

IRC was used to report on the [[1991 Soviet coup d'état attempt]] throughout a [[media blackout]].<ref>{{cite web
| url = http://www.ibiblio.org/pub/academic/communications/logs/report-ussr-gorbatchev
| title = IRC transcripts from the time of the 1991 Soviet coup d'état attempt
| accessdate = 2011-04-08
| publisher = [[ibiblio]]
| location = [[Chapel Hill, North Carolina]]
}}</ref> It was previously used in a similar fashion during the [[Gulf War]].<ref>{{cite web
| url = http://www.ibiblio.org/pub/academic/communications/logs/Gulf-War/
| title = IRC logs of events of the Gulf War
| accessdate = 2011-04-08
| publisher = [[ibiblio]]
| location = [[Chapel Hill, North Carolina]]
}}</ref> Logs of these and other events are kept in the [[ibiblio]] archive.<ref>{{cite web
| url = http://www.ibiblio.org/pub/academic/communications/logs/
| title = Logs of major events in the online community
| accessdate = 2011-04-08
| publisher = [[ibiblio]]
| location = [[Chapel Hill, North Carolina]]
}}</ref>

==Technical information==
{{See also|IRCd}}

[[File:Screenshot of HexChat in Windows 8.png|right|thumb|A screenshot of [[HexChat]], an IRC client for [[GTK]] environments.]]
[[File:Xaric screen shot.jpg|right|thumb|Xaric, a text-based IRC client, in use on [[Mac OS X]]. Shown are two IRC channels and a private conversation with the software author.]]
IRC is an open [[Network protocol|protocol]] that uses [[Transmission Control Protocol|TCP]]<ref name="rfc 1459 1 introduction" /> and, optionally, [[Transport Layer Security|TLS]]. An [[IRC server]] can connect to other IRC servers to expand the IRC network.<ref>{{cite IETF
| rfc = 1459
| sectionname = Servers
| section = 1.1
| page = 4
| idanchor = ietf
}}</ref> Users access IRC networks by connecting a client to a server.<ref>{{cite IETF
| rfc = 2810
| sectionname = Clients
| section = 2.2
| page = 3
| idanchor = ietf
}}</ref> 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 user will have to set a nickname before being connected.<ref>{{cite IETF
| rfc = 1459
| sectionname = Clients
| section = 1.2
| page = 5
| idanchor = ietf
}}</ref>

IRC was originally a [[Text-based protocol|plain text protocol]] <ref name="rfc 1459 1 introduction" /> (although later extended), which on request was assigned port [[List of TCP and UDP port numbers|194/TCP]] by [[Internet Assigned Numbers Authority|IANA]].<ref>{{cite web
| url = http://www.iana.org/assignments/port-numbers
| title = Port Numbers
| accessdate = 2011-04-08
| date = 2011-04-06
| publisher = [[Internet Assigned Numbers Authority]]
| location = [[Marina del Rey, California]]
}}</ref> However, the [[de facto standard|''de facto'' standard]] has always been to run IRC on 6667/TCP<ref>{{cite IETF
| rfc = 1459
| sectionname = Connect message
| section = 4.3.5
| page = 29
| idanchor = ietf
}}</ref> and nearby port numbers (for example TCP ports 6660–6669, 7000)<ref>{{cite book
| last1 = Lucas
| first1 = Mark
| last2 = Singh
| first2 = Abhishek
| last3 = Cantrell
| first3 = Chris
| editor-last = Henmi
| editor-first = Anne
| title = Firewall Policies and VPN Configurations
| date = 2006-10-05
| publisher = [[Syngress Publishing]]
| location = [[Rockland, Massachusetts]]
| isbn = 1-59749-088-1
| page = 93
| chapter = Defining a Firewall
}}</ref> to avoid having to run the [[IRCd]] software with [[Superuser|root privileges]].

The protocol specified that characters were 8-bit but did not specify the character encoding the text was supposed to use.<ref name="rfc 1459 2.2 character codes">{{cite IETF
| rfc = 1459
| sectionname = Character codes
| section = 2.2
| page = 7
| idanchor = ietf
}}</ref> 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 (RFC 2810, RFC 2811, RFC 2812 and RFC 2813); however, these protocol changes have not been widely adopted among other implementations.{{Citation needed|date=July 2007}}

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.{{Citation needed|date=July 2007}}

Microsoft made an extension for IRC in 1998 via the proprietary [[IRCX]].<ref>{{cite IETF
| title = Extensions to the Internet Relay Chat Protocol (IRCX)
| draft = draft-pfenning-irc-extensions-04
| last = Abraham
| first = Dalen
| year = 1998
| month = June
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2011-04-08
}}</ref> They later stopped distributing software supporting IRCX, instead developing the proprietary [[Microsoft Notification Protocol|MSNP]].

The standard structure of a network of IRC servers is a [[Tree network|tree]].<ref>{{cite IETF
| rfc = 2810
| sectionname = Architecture
| section = 3
| pages = 3{{spaced ndash}}4
| idanchor = ietf
}}</ref> Messages are routed along only necessary branches of the tree but network state is sent to every server<ref>{{cite IETF
| rfc = 2810
| sectionname = Introduction
| section = 1
| page = 2
| idanchor = ietf
}}</ref> and there is generally a high degree of implicit trust between servers. This architecture has a number of problems. A misbehaving or malicious server can cause major damage to the network<ref>{{cite IETF
| rfc = 1459
| sectionname = Algorithms
| section = 9.3
| page = 64
| idanchor = ietf
}}</ref> 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<ref>{{cite IETF
| rfc = 2810
| sectionname = Network Congestion
| section = 6.3
| pages = 7{{spaced ndash}}8
| idanchor = ietf
}}</ref> 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.<ref>{{cite IETF
| rfc = 2810
| sectionname = To A Channel
| section = 5.2.1
| pages = 5{{spaced ndash}}6
| idanchor = ietf
}}</ref> This is a strength in comparison to non-multicasting protocols such as [[Simple Mail Transfer Protocol]] (SMTP) or [[Extensible Messaging and Presence Protocol]] (XMPP).

An IRC daemon can also be used on a local area network (LAN). IRC can thus be used to facilitate communication between people of the own network (internal communication).<ref>{{cite web|url=http://computerquestionhelp.com/content/how-guide-setup-your-own-irc-server-using-personal-or-dedicated-system-or-server-top-freewar|title=IRC daemons for LAN|publisher=|accessdate=2 October 2014}}</ref><ref>{{cite web|url=http://www.irc-wiki.org/IRC_server|title=Running an own IRC server|publisher=|accessdate=2 October 2014}}</ref>

===Commands and replies===
{{Main|List of Internet Relay Chat commands}}
IRC has a line-based structure with the client sending single-line messages to the server,<ref>{{cite IETF
| rfc = 1459
| sectionname = Message format in 'pseudo' BNF
| section = 2.3.1
| page = 8
| idanchor = ietf
}}</ref> receiving replies to those messages<ref>{{cite IETF
| rfc = 1459
| sectionname = Numeric replies
| section = 2.4
| page = 10
| idanchor = ietf
}}</ref> and receiving 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 (generally for commands the client does not recognize) passed directly to the server, possibly with some modification.{{Citation needed|date=May 2009}}

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.<ref>{{cite web
| url = http://www.shanemcc.co.uk/irc/#listmode
| title = IRC List Modes – List mode extension showing pair confusion for lists
| accessdate = 2011-04-08
| date = 2009-11-25
}}</ref>

===Channels===
The basic means of communicating to a group of users in an established IRC session is through a ''[[chat room|channel]]''.<ref name="rfc 1459 3.2.2 to a group (channel)">{{cite IETF
| rfc = 1459
| sectionname = To a group (channel)
| section = 3.2.2
| page = 11
| idanchor = ietf
}}</ref> Channels on a network can be displayed using the IRC command ''LIST'',<ref>{{cite IETF
| rfc = 1459
| sectionname = List message
| section = 4.2.6
| page = 24
| idanchor = ietf
}}</ref> 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,<ref name="rfc 1459 4.2.1 join message">{{cite IETF
| rfc = 1459
| sectionname = Join message
| section = 4.2.1
| page = 19
| idanchor = ietf
}}</ref> in most clients available as ''/join #channelname''. Messages sent to the joined channels are then relayed to all other users.<ref name="rfc 1459 3.2.2 to a group (channel)" />

Channels that are available across an entire IRC network are prefixed with a '#', while those local to a server use '&'.<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel Scope
| section = 2.2
| page2 = 3{{spaced ndash}}4
| idanchor = ietf
}}</ref> Other less common channel types include '+' channels—'modeless' channels without operators —<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel Properties
| section = 2.3
| page = 4
| idanchor = ietf
}}</ref> and '!' channels, a form of [[#Nick/channel delay|timestamped]] channel on normally non-timestamped networks.<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel lifetime
| section = 3
| page = 5
| idanchor = ietf
}}</ref>

===Modes===
Users and channels may have ''modes'' that are represented by single case-sensitive letters<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel Modes
| section = 4
| page = 7
| idanchor = ietf
}}</ref> and are set using the ''MODE'' command.<ref>{{cite IETF
| rfc = 1459
| sectionname = Mode message
| section = 4.2.3
| page = 21
| idanchor = ietf
}}</ref> User modes and channel modes are separate and can use the same letter to mean different things (e.g. usermode "i" is invisible mode whilst channelmode "i" is invite only.<ref>{{cite IETF
| rfc = 1459
| sectionname = Channel modes
| section = 4.2.3.1
| pages = 21{{spaced ndash}}22
| idanchor = ietf
}}</ref>) Modes are usually set and unset using the mode command that takes a target (user or channel), a set of modes to set (+) or unset (-) and any parameters the modes need.

Some but not all channel modes take parameters and some channel modes apply to a user on a channel or add or remove a mask (e.g. a ban mask) from a list associated with the channel rather than applying to the channel as a whole.<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel Access Control
| section = 4.3
| pages = 10{{spaced ndash}}11
| idanchor = ietf
}}</ref> Modes that apply to users on a channel have an associated symbol that is used to represent the mode in names replies<ref name="rfc 1459 p.51 rpl_namreply">{{cite IETF
| rfc = 1459
| sectionname = Command responses: 353 RPL_NAMREPLY
| page = 51
| idanchor = ietf
}}</ref> (sent to clients on first joining a channel<ref name="rfc 1459 4.2.1 join message" /> and use of the names command) 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.<ref>{{cite web
| url = http://www.irc.org/tech_docs/005.html
| title = The 005 numeric: ISUPPORT
| accessdate = 2011-04-10
| last = Roeckx
| first = Kurt
| date = 2004-10-14
| publisher = irc.org
}}</ref><ref>{{cite IETF
| title = IRC RPL_ISUPPORT Numeric Definition
| draft = draft-brocklesby-irc-isupport-03
| last = Brocklesby
| first = Edward
| year = 2002
| month = September
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2011-04-10
}}</ref>

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,<ref name="rfc 1459 p.51 rpl_namreply" /> but multiple such modes can be set on a single user. For example, if a user holds both operator status (+o) and voice status (+v) on a channel, a new client will be unable to know the less precedented mode (voice). Workarounds for this are possible on both the client and server side but none is widely implemented.

====Standard (RFC 1459) modes====

{| class="wikitable"
|+ User modes
|-
! Letter
! Symbol
! Description
|-
| '''i'''
|
| Invisible—cannot be seen without a common channel or knowing the exact name
|-
| '''s'''
|
| Receives server notices
|-
| '''w'''
|
| Receives wallops<ref>{{cite IETF
| rfc = 1459
| sectionname = Operwall message
| section = 5.6
| page = 41
| idanchor = ietf
}}</ref>
|-
| '''o'''
|
| User is an IRC operator (ircop)
|}

{| class="wikitable"
|+ Channel modes
|-
! Letter
! Symbol
! Parameter(s)
! Description
|-
| '''o'''
| @
| Name of affected user
| Channel operator—can change channel modes and kick users out of the channel among other things
|-
| '''s'''
|
|
| Secret channel—not shown in channel list or user whois except to users already on the channel
|-
| '''p'''
|
|
| Private channel—listed in channel list as "prv" according to <nowiki>RFC 1459</nowiki>
|-
| '''n'''
|
|
| Users cannot send messages to the channel externally
|-
| '''m'''
|
|
| Channel is moderated (only those who hold operator or voice status on the channel can send messages to it)
|-
| '''i'''
|
|
| Only users with invites may enter the channel.
|-
| '''t'''
|
|
| Only operators can change the channel topic.
|-
| '''l'''
|
| Limit number
| Limits number of users able to be on channel (when full, no new users can join)
|-
| '''b'''
|
| Ban mask (nick!user@host with wildcards allowed)
| Bans [[hostmask]]s from channel
|-
| '''v''' 
| +
| Name of affected user
| Gives a user voice status on channel (see +m above)
|-
| '''k'''
|
| New channel key
| Sets 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.<ref>{{cite web
| url = http://www.alien.net.au/irc/usermodes.html
| title = IRC User Modes List
| accessdate = 2011-04-10
| last = Butcher
| first = Simon
| date = 2005-01-12
| publisher = alien.net.au
}}</ref><ref>{{cite web
| url = http://www.alien.net.au/irc/chanmodes.html
| title = IRC Channel Modes List
| accessdate = 2011-04-10
| last = Butcher
| first = Simon
| date = 2005-01-12
| publisher = alien.net.au
}}</ref><ref>{{cite web
| url = http://www.alien.net.au/irc/servermodes.html
| title = IRC Server Modes List
| accessdate = 2011-04-10
| last = Butcher
| first = Simon
| date = 2005-01-12
| publisher = alien.net.au
}}</ref><ref>{{cite web
| url = http://webtoman.com/opera/panel/ircdmodes.html
| title = IRCd Modes
| accessdate = 2011-04-10
| last = Olsen
| first = Tommy
| publisher = webtoman.com
}}</ref>

===Channel Operators===
A ''Channel Operator'' is a [[Client (computing)|client]] on an [[IRC channel]] that manages the channel.
IRC Channel Operators can be easily seen by a symbol "@", or a Latin letter "+o"/"o".
On most networks, an operator can:
* Kick a user
* Ban a user
* Give another user IRC Channel Operator Status or IRC Channel Voice Status.
* Change the IRC Channel topic.
* Change the IRC Channel Mode locks.

===IRC Operators===
{{main|Internet Relay Chat operator}}
There are also users who maintain elevated rights on their local server, or the entire network; these are called IRC operators,<ref name="rfc 1459 1.2.1 operators">{{cite IETF
| rfc = 1459
| sectionname = Operators
| section = 1.2.1
| page = 5
| idanchor = ietf
}}</ref> sometimes shortened to IRCops or Opers (not to be confused with channel operators). As the implementation of the IRCd varies, so do the privileges of the IRC operator on the given IRCd. RFC 1459<ref name="rfc 1459 1.2.1 operators" /> claims that IRC operators are "a necessary evil" to keep 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 IPs or complete subnets. Networks that carry services (Nickserv et al.) usually allow their IRC operators also to handle basic "Ownership" matters. Further privileged rights may include overriding channel bans (being able to join channels they would not be allowed to join, if they were not opered), 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 (computing)|client]] connected to an IRC [[Server (computing)|server]].<ref name="thiedeke-2003">{{cite book
| last = Thiedeke
| first = Udo
| title = Virtuelle Gruppen: Charakteristika und Problemdimensionen
| url = http://books.google.com/?id=aQ74THYRyYsC&lpg=PA314&pg=PA315#v=onepage&q=hostmask
| accessdate = 2010-03-30
| edition = 2nd
| date = 2003-09-23
| publisher = {{Ill|de|Springer VS}}
| language = German
| isbn = 3-531-33372-0
| pages = 314, 337
| chapter = Nicola Döring, Alexander Schestag
}}</ref><ref name="rogers-2005">{{cite book
| last = Rogers
| first = Russ
| editor-last = Devost
| editor-first = Matthew G.
| title = Hacking a Terror Network: The Silent Threat of Covert Channels
| url = http://books.google.com/books?id=e3ggsGgTzUgC&lpg=PA10&pg=PA10#v=onepage&q=Hostmask%20IRC
| accessdate = 2010-03-30
| edition = 1st
| date = 2004-12-01
| publisher = [[Syngress Publishing]]
| location = [[Rockland, Massachusetts]]
| isbn = 1-928994-98-9
| page = 10
| chapter = The Mind of Terror
}}</ref> IRC [[IRCd|server]]s, [[Internet Relay Chat services|services]], and other clients including [[Internet Relay Chat bot|bots]] can use it to identify a specific IRC session.

The format of a hostmask is <code>nick!user@host</code>. 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 protocol|ident]] on the client.<ref name="petersen-2002">{{cite book
| editor-last = Petersen
| editor-first = Julie K.
| title = The Telecommunications Illustrated Dictionary
| url = http://books.google.com/books?id=b2mMzS0hCkAC&lpg=PA500&pg=PA500#v=onepage&q=Hostmask
| accessdate = 2010-03-30
| edition = 2nd
| date = 2002-05-29
| publisher = [[CRC Press]]
| isbn = 0-8493-1173-X
| page = 500
| chapter = Internet Relay Chat
}}</ref> If ident is not available on the client, the username specified when the client connected is used after being prefixed with a [[tilde]].<ref name="freenode faq">{{cite web
| url = http://freenode.net/faq.shtml
| title = Frequently-Asked Questions
| accessdate = 2010-03-30
| publisher = [[freenode]]
}}</ref>

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 [[IRCd|IRC daemons]] also provide privacy features, such as InspIRCD or UnrealIRCD's "+x" mode. This [[Cryptographic hash function|hashes]] a client IP address or masks part of a client's hostname, making it unreadable to users other than [[Internet Relay Chat#IRC Operators|IRCops]]. Users may also have the option of requesting a "virtual host" (or "vhost"), 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.<ref>{{cite web
| url = http://meta.wikimedia.org/wiki/IRC/Cloaks
| title = IRC/Cloaks
| accessdate = 2011-11-27
| publisher = [[Wikimedia]]
}}</ref>

==Challenges==
Issues in the original design of IRC were the amount of shared state data<ref>{{cite IETF
| rfc = 1324
| sectionname = Size
| section = 2.5.1
| pages = 5{{spaced ndash}}6
| idanchor = ietf
}}</ref><ref>{{cite IETF
| rfc = 2810
| sectionname = Scalability
| section = 6.1
| page = 7
| idanchor = ietf
}}</ref> being a limitation on its scalability,<ref>{{harvnb|Loesch|2003}} 1.2.1 Growth</ref> the absence of unique user identifications leading to the nickname collision problem,<ref>{{cite IETF
| rfc = 1324
| sectionname = User identification
| section = 5.4.1
| page = 10
| idanchor = ietf
}}</ref> lack of protection from netsplits by means of cyclic routing,<ref>{{cite IETF
| rfc = 1324
| sectionname = Trees and cycles
| section = 5.4.2
| page = 10
| idanchor = ietf
}}</ref><ref>{{harvnb|Loesch|2003}} 1.2.2 Network failures</ref> the trade-off in scalability for the sake of real-time user presence information,<ref>{{cite IETF
| rfc = 1324
| sectionname = State Information problems
| section = 2.1
| page = 4
| idanchor = ietf
}}</ref> protocol weaknesses providing a platform for abuse,<ref>{{harvnb|Loesch|2003}} 1.2.3 Sociological and security aspects</ref> no transparent and optimizable message passing,<ref>{{cite IETF
| rfc = 1324
| sectionname = Message passing
| section = 5.2.1
| page = 7
| idanchor = ietf
}}</ref> and no encryption.<ref>{{cite IETF
| rfc = 1324
| sectionname = Conference security
| section = 5.2.4
| page = 8
| idanchor = ietf
}}</ref> Some of these issues have been addressed in ''Modern IRC''.

===Attacks===
Because IRC connections are usually unencrypted and typically span long time periods, they are an attractive target for [[Denial-of-service attack|Dos/DDoS attackers]] and [[Hacker (computer security)|hackers]]. Because of this, careful security policy is necessary to ensure that an IRC network is not susceptible to an attack such as a [[Internet Relay Chat takeover|takeover]] war. IRC networks may also [[K-line (IRC)|K-line]] or [[G-line]] users or networks that have a harming effect.

A small number of IRC servers support [[Transport Layer Security|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 (that may require the user to install SSL binaries and IRC client specific patches or modules on their computers). Some networks also use SSL for server to server connections, and provide a special channel flag (such as <code>+S</code>) to only allow SSL-connected users on the channel, while disallowing operator identification in clear text, to better utilize the advantages that SSL provides.<ref>{{cite web
| url = http://esper.net/help.php
| title = Getting Help on EsperNet
| publisher = The EsperNet IRC Network
| accessdate = 2012-07-31
}}</ref><ref>{{cite web
| url = http://www.dal.net/news/shownews.php?id=67
| title = New Feature: SSL For Users
| author = brandon
| date = 2010-05-18
| publisher = DALnet
| accessdate = 2012-07-31
}}</ref>

IRC served as an early laboratory for many kinds of Internet attacks, such as using fake [[Internet Control Message Protocol|ICMP]] unreachable messages to break [[Transmission Control Protocol|TCP]]-based IRC connections ([[Nuke (computer)|nuking]]) to annoy users or facilitate [[Internet Relay Chat takeover|takeover]]s.

===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 attack]]s, 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 (i.e., 'nick-collision').
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 [[netsplit]]s, 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, 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{{spaced ndash}}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 lost 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" (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 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.

====SAVE====
In recent versions of the IRCnet ircd, as well as ircds using the TS6 protocol (including Charybdis), ND has been extended/replaced by a mechanism called SAVE. This mechanism assigns every client a unique UID upon connecting to an IRC server. This ID starts with a number, which is forbidden in nicks (although some ircds, namely IRCnet and InspIRCd, allow clients to switch to their own UID as the nickname).

If two clients with the same nickname join from different sides of a netsplit ("nick collision"), 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 (ND) to prevent both clients from changing back to the original nickname, thus colliding again.

==Networks==
[[File:Tolsun 2.jpg|thumb|right|The first IRC server, tolsun.oulu.fi, a [[Sun-3]] server on display near the [[University of Oulu]] computer centre. (2001)]]

There are thousands of running IRC networks in the world. They run various implementations of [[IRC server]]s, and are administered by various groups of [[IRC operator]]s, but the protocol exposed to IRC users is very similar, and all IRC networks can be accessed by the same client software, although there might be slight incompatibilities and limited functionality due to the differing server software implementations.

The largest IRC networks have traditionally been grouped as the "Big Four"<ref name="the book of irc">{{cite book
| last = Charalabidis
| first = Alex
| title = The Book of IRC: The Ultimate Guide to Internet Relay Chat
| edition = 1st
| date = 1999-12-15
| publisher = No Starch Press
| location = [[San Francisco, California]]
| isbn = 1-886411-29-8
| page = 61
| chapter = IRCing On The Macintosh: Ircle
| quote = On large networks such as the Big Four{{mdash}} EFnet, IRCnet, Undernet, and DALnet{{mdash}} trying to list the thousands of channels with Ircle always causes you to disconnect due to the flood of information, while other clients can usually manage the feat, if you are on a direct Ethernet connection.
}}</ref><ref name="encyclopedia of new media">{{cite book
| editor-last = Jones
| editor-first = Steve
| title = Encyclopedia of New Media: An Essential Reference to Communication and Technology
| edition = 1st
| date = 2002-12-10
| publisher = [[SAGE Publications]]
| location = [[Thousand Oaks, California]]
| isbn = 0-7619-2382-9
| page = 257
| chapter = Internet Relay Chat
| quote = Today there are hundreds of independent IRC networks, but the "Big Four" are EFNet, UnderNet, Dalnet, and IRCnet.
}}</ref><ref name="the imac book">{{cite book
| last = Rittner
| first = Don
| title = The iMac Book
| edition = 1st
| date = 1999-03-03
| publisher = Coriolis Group
| location = [[Scottsdale, Arizona]]
| isbn = 1-57610-429-X
| page = 215
| chapter =
| quote = There are several large networks: EFnet, UnderNET, DALnet, and IRCnet make up the Big Four.
}}</ref><ref name="information technology for management">{{cite book
| last1 = Turban
| first1 = Efraim
| last2 = Leidner
| first2 = Dorothy
| last3 = McLean
| first3 = Ephraim
| last4 = Wetherbe
| first4 = James
| title = Information Technology for Management: Transforming Organizations in the Digital Economy
| edition = 5th
| date = 2005-02-07
| publisher = [[John Wiley & Sons]]
| location = [[Hoboken, New Jersey]]
| isbn = 0-471-70522-5
| pages = 106{{spaced ndash}}107
| chapter = Communication
| quote = The largest networks have traditionally been grouped as the "Big Four": EFNet, IrcNet, QuakeNet, and UnderNet.
}}</ref>{{mdash}} 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:<ref name="the book of irc" /><ref name="encyclopedia of new media" /><ref name="the imac book" />
* [[EFnet]]
* [[IRCnet]]
* [[Undernet]]
* [[DALnet]]

IRC reached 6 million simultaneous users in 2001 and 10 million users in 2003.{{citation needed|date=January 2015}}

As of March 2015 the largest IRC networks were:

* [[freenode]] – around 99k users at peak hours
* [[IRCNet]] – around 44k users at peak hours
* [[QuakeNet]] – around 36k users at peak hours
* [[EFnet]] – around 26k users at peak hours
* [[Undernet]] – around 25k users at peak hours
* [[rizon]] – around 25k users at peak hours

Today, the top 100 IRC networks have around [http://irc.netsplit.de/networks/top100.php 460k users connected at peak hours].

===Timeline===

{{Simple Horizontal timeline

|from=1990
|to=2014
|inc=2

|styleDefault-borderbottom=solid 0.1em black;

|row1=timeline
|row1-style=styleDefault
|row1-bordertop=solid 0.1em black;
|row1-1-color=#ffbb33
|row1-1-from=1990
|row1-1-to=2014
|row1-1-text=[[EFnet]]

|row2=timeline
|row2-style=styleDefault
|row2-1-from=1990
|row2-1-to=1992
|row2-2-to=2014
|row2-2-text=[[Undernet]]
|row2-2-color=#33b5e5

|row3=timeline
|row3-style=styleDefault
|row3-1-from=1990
|row3-1-to=1994
|row3-2-color=#cc0000
|row3-2-to=2014
|row3-2-text=[[DALnet]]

|row4=timeline
|row4-style=styleDefault
|row4-1-from=1990
|row4-1-to=1995
|row4-2-color=#aa66cc
|row4-2-to=2014
|row4-2-text=[[freenode]]

|row5=timeline
|row5-style=styleDefault
|row5-1-from=1990
|row5-1-to=1997
|row5-2-color=#99cc00
|row5-2-to=2014
|row5-2-text=[[IRCnet]]

|row6=timeline
|row6-style=styleDefault
|row6-1-from=1990
|row6-1-to=1997
|row6-2-color=#ff4444
|row6-2-to=2014
|row6-2-text=[[QuakeNet]]

|row7=timeline
|row7-1-from=1990
|row7-1-to=2002
|row7-2-color=#ff44ff
|row7-2-to=2014
|row7-2-text=[[Rizon]]

|row8=scale
|caption=IRC networks
}}

==URI scheme==
There are three recognized [[URI scheme]]s for Internet Relay Chat, irc, irc6, and ircs,<ref>{{cite web
| url = http://www.iana.org/assignments/uri-schemes.html
| title = Uniform Resource Identifier (URI) Schemes
| publisher = Internet Assigned Numbers Authority | accessdate = 2012-10-14
}}</ref> that (when supported) allows [[hyperlink]]s of various forms, including
<nowiki>irc://<host>[:<port>]/[<channel>[?<channel_keyword>]]</nowiki>
(where items enclosed within brackets ([,]) are optional) to be used to (if necessary) connect to the specified host (or network, if known to the IRC client) and join the specified channel.<ref>{{cite IETF
| title = Uniform Resource Locator Schemes for Internet Relay Chat Entities
| draft = draft-butcher-irc-url-04
| last = Butcher
| first = Simon
| year = 2003
| month = January
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2011-04-10
}}</ref> (This can be used within the client itself, or from another application such as a Web browser). 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 (for example, mIRC) will do so ''unconditionally'' resulting in a (usually unintended) extra (for example, ##channel), if included in the URL.

Some implementations allow multiple channels to be specified, separated by commas.{{Citation needed|date=April 2011}}

==Clients==

===Client software===
{{Details|Comparison of Internet Relay Chat clients}}
[[File:Ircnetz-Schema.svg|right|thumb|Scheme of an IRC network with [[Client (computing)|normal clients]] (green), [[IRC bot|bots]] (blue) and [[Bouncer (networking)|bouncers]] (orange)]]

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 [[Microsoft Windows|Windows]], [[Unix]] & [[Linux]], [[Mac OS X]] and mobile operating systems (such as [[iOS]] and [[Android (operating system)|Android]]). On Windows, [[mIRC]] is one of the most popular clients.<ref>{{cite book|last=Smith|first=Roderick W.|title=The Multi-Boot Configuration Handbook| url= http://books.google.com/books?id=OuPtI5fHhBoC|accessdate=2010-07-25|series= Handbook Series| date= 2000-04-08| publisher= [[Que Publishing]]| location= [[Upper Saddle River, New Jersey]]|isbn= 0-7897-2283-6|page=289|chapter=The Internet: Using IRC to Get Help|quote= mIRC is one of the most popular Windows IRC clients.}}</ref>

Some programs which are extensible through [[plug-in (computing)|plug-ins]] also serve as platforms for IRC clients. For instance, a client called [[ERC (software)|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 browser]]s have built in IRC clients, such as [[Opera (Web browser)|Opera]] ([[Features of the Opera web browser#Legacy features|version 12.17 and earlier]])<ref>{{cite web| url=http://operawiki.info/OperaIRC| title = Opera Browser Wiki: IRC Client| accessdate = 2011-04-10}}</ref> or the [[ChatZilla]] add-on for Mozilla [[Firefox]] (included as a built-in component of [[SeaMonkey]]). Web-based clients, such as [[Mibbit]] and open source [[KiwiIRC]], can run in most browsers.

Games such as ''[[War§ow]]'',<ref>{{cite web
| url = http://www.warsow.net/wiki/index.php?title=IRC_Module
| title = Warsow Wiki: IRC Module
| accessdate = 2011-04-10
}}</ref> ''[[Unreal Tournament]]'' (up to [[Unreal Tournament 2004]]),<ref>{{cite web
| url = http://www.bcchardware.com/index.php?option=com_content&task=view&id=35&Itemid=40
| title = UT2004 Review
| accessdate = 2011-04-10
| last = Guenter
| first = Daniel
| date = 2004-06-21
| publisher = BCCHardware
}}</ref> ''[[Uplink (video game)|Uplink]]'',<ref>{{cite web
| url = http://guide.modlink.net/section11.php
| title = The Ultimate Uplink Guide
| accessdate = 2011-04-10
}}</ref> ''[[Spring Engine]]''-based games, [[0 A.D. (video game)|0 A.D.]] and ''[[ZDaemon]]'' have included IRC.<ref>{{cite web
| url = http://doomwiki.org/wiki/ZDaemon#Other_utilities
| title = ZDaemon – The Doom Wiki: Other utilities
| accessdate = 2011-04-10
}}</ref>

[[Ustream]]'s chat interface is [[IRC]] with custom authentication<ref>{{cite web
| url = http://ustream-helpers.com/how-to/ircclient
| title = How to setup an IRC client to connect and login to Ustream
| accessdate = 2013-04-27
| date = 2012-01-29
| publisher = Ustream-Helpers
}}</ref> as well as [[Justin.tv]]'s.<ref>{{cite web
| url = http://www.liquidsilver.org/2010/06/ustream-v-justin/
| title = Ustream vs. Justin.tv
| accessdate = 2011-07-13
| date = 2010-06-20
| publisher = LiquidSilver
| author = Mauldor
}}</ref>

===Bots===
{{Main|IRC bot}}

A typical use of bots in IRC is to provide [[Internet Relay Chat services|IRC services]] or a specific functionality within a channel such as to host a chat-based game or provide notifications of external events.

===Bouncer===
{{Main|BNC (software)}}
A program that runs as a [[daemon (computer software)|daemon]] on a [[Server (computing)|server]] and functions as a persistent [[proxy server|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.{{Citation needed|date=April 2011}} Should the client lose network connectivity, the BNC may stay connected and archive all traffic for later delivery, allowing the user to resume his IRC session without disrupting their connection to the server.<ref>{{cite web
| url = http://www.psybnc.at/readme.txt
| title = psyBNC Readme
| accessdate = 2011-04-10
| publisher = psybnc.at
}}</ref>

Furthermore, as a way of obtaining a bouncer-like effect, an IRC client (typically [[text-based]], for example [[Irssi]]) may be run on an always-on server to which the user connects via [[secure shell|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.<ref>{{cite web
| url = http://chriscarey.com/wordpress/2009/07/18/irc-with-irssi-proxy-screen/
| title = IRC with irssi-proxy + screen
| accessdate = 2011-04-10
| last = Carey
| first = Chris
| date = 2009-07-18
| publisher = chriscarey.com
}}</ref>

To keep the IRC client from quitting when the ssh connection closes, the client can be run inside a piece of screen-detaching software (e.g. [[GNU Screen]] or [[tmux]]), thus staying connected to the IRC network(s) constantly and able to log conversation in channels that the user is interested in, etc. Modelled after this setup, in 2004 an IRC client following the [[client-server]] model, called [[Smuxi]], has been launched.<ref>{{cite web
| url = http://www.smuxi.org/blog/show/Detachable_Frontend_Core_Rewrite__UML__Windows_Port_kicking_Glade
| title = Detachable Frontend (Core Rewrite) / UML / Windows Port (kicking Glade)
| accessdate = 2010-07-25
| date = 2004-12-25
| publisher = smuxi.org
}}</ref><ref>{{cite web
| url = http://www.smuxi.org/page/About
| title = About Smuxi
| accessdate = 2011-04-10
| publisher = smuxi.org
}}</ref>

==Search engines==
There are numerous search engines available to aid the user in finding what they are looking for on IRC.<ref>{{cite book
| last = Mutton
| first = Paul
| title = IRC Hacks
| edition = 1st
| date = 2004-07-27
| publisher = [[O'Reilly Media]]
| location = [[Sebastopol, California]]
| isbn = 0-596-00687-X
| pages = 44{{spaced ndash}}46
| chapter = Users and Channels
}}</ref><ref>{{cite book
| last = Wang
| first = Wallace
| title = Steal this File Sharing Book
| edition = 1st
| date = 2004-10-25
| publisher = [[No Starch Press]]
| location = [[San Francisco, California]]
| isbn = 1-59327-050-X
| pages = 65{{spaced ndash}}67
| chapter = Instant Messaging and Online Chat Rooms: Internet Relay Chat (IRC)
}}</ref> Generally the search engine consists of two parts, a "back-end" (or "spider/crawler") and a front-end "search engine".

The back-end (spider/crawler) 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 database|Oracle]].{{Citation needed|date=January 2010}}

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.{{Citation needed|date=August 2009}}

Many users have implemented their own [[ad hoc]] search engines using the logging features built into many IRC clients.

==Modern IRC==
IRC has changed much over its life on the Internet. New server software has added a multitude of new features.
* [[IRC services|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 attack]]s.{{Citation needed|date=January 2010}}
* Proxy detection: Most modern servers support detection of users attempting to connect through an insecure (misconfigured or exploited) [[proxy server]], which can then be denied a connection. An example is the [http://www.blitzed.org/proxy Blitzed Open Proxy Monitor] or BOPM. This proxy detection software is used by several networks, although that real time list of proxies is defunct since early 2006.{{Citation needed|date=January 2010}}
* 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.{{Citation needed|date=January 2010}}
* [[Encryption]]: For the client-to-server leg of the connection [[Secure Sockets Layer|SSL]] might be used (messages cease to be secure once they are relayed to other users on standard connections, but it makes [[Man-in-the-middle attack|eavesdropping]] on or wiretapping an individual's IRC sessions difficult). For client-to-client communication, [[Secure Direct Client-to-Client|SDCC]] (Secure DCC) can be used.{{Citation needed|date=January 2010}}
* 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.

There is an effort of standardization and adding new features to the IRC protocol by IRCv3 working group.<ref>{{cite web
| url = http://www.ircv3.org/
| title = IRCv3 Working Group
| accessdate = 2014-03-08
}}</ref>

==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{{Clarify|date=July 2009}} transfer messages from a client to another client just as byte sequences, without any interpretation or recoding of [[character (computing)|characters]]. The IRC protocol (unlike e.g. [[MIME]] or [[HTTP]]) 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 particular [[Unix]] derivatives) in the respective language communities:

* '''7-bit era:''' In the early days of IRC, especially among [[North Germanic languages|Scandinavian]] and [[Finnish language]] users, national variants of [[ISO 646]] were the dominant [[character encoding]]s. These encode non-ASCII characters like Ä Ö Å ä ö å at code positions 0x5B 0x5C 0x5D 0x7B 0x7C 0x7D ([[US-ASCII]]: '''[''' '''\''' ''']''' '''{''' '''|''' '''}'''). That is why these codes are always allowed in nicknames. According to RFC 1459, { | } in nicknames should be treated as lowercase equivalents of [ \ ] respectively.<ref name="rfc 1459 2.2 character codes" /> By the late 1990s, the use of 7-bit encodings had disappeared in favour of [[ISO 8859-1]], and such equivalence mappings were dropped from some IRC daemons.

* '''8-bit era:''' Since the early 1990s, 8-bit encodings such as [[ISO 8859-1]] have become commonly used for European languages. Russian users had a choice of [[KOI8-R]], [[ISO 8859-5]]{{Citation needed|date=October 2008}} and [[CP1251]], and since about 2000, modern Russian IRC networks convert between these different commonly used encodings of the [[Cyrillic script]].

* '''Multi-byte era:''' For a long time, East Asian IRC channels with ideographic scripts in China, Japan, and Korea have been using multi-byte encodings such as [[Extended Unix Code|EUC]] or [[ISO-2022-JP]]. With the common migration from ISO 8859 to UTF-8 on Linux and Unix platforms since about 2002, [[UTF-8]] has become an increasingly popular substitute for many of the previously used 8-bit encodings in European channels. Some IRC clients are now capable of reading messages both in ISO 8859-1 or UTF-8 in the same channel, heuristically autodetecting which encoding is used. The shift to UTF-8 began in particular on Finnish-speaking IRC ([[:fi:IRC#Merkistö|Merkistö]] (Finnish)).

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 bytes 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 [[Peer-to-peer|P2P]] file sharing, users can create file servers that allow them to share files with each other by using customised [[IRC bot]]s or scripts for their [[IRC client]]. Often users will group together to distribute [[warez]] via a network of IRC bots.<ref>{{cite web
| url = http://www.zdnet.com/news/pirated-movies-now-playing-on-a-server-near-you/122663
| title = Pirated movies: Now playing on a server near you
| accessdate = 2011-04-10
| last = Vamosi
| first = Robert
| date = 2002-05-08
| publisher = [[ZDNet]]
}}</ref>

Technically, IRC provides no [[file transfer]] mechanisms itself; file sharing is implemented by IRC ''clients'', typically using the [[Direct Client-to-Client]] (DCC) 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.<ref>{{cite web
| url = http://www.macobserver.com/tip/2002/04/04.1.shtml
| title = IRC 101: What Is It & How Do I Use It?
| accessdate = 2011-04-10
| last = Sasaki
| first = Darla
| date = 2002-04-04
| publisher = Macobserver.com
}}</ref> 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.

==See also==
{{Portal|Internet Relay Chat}}
* [[Chat room]]
* [[Client-to-client protocol]]
* [[Comparison of instant messaging protocols]]
* [[Comparison of IRC clients]]
* [[Comparison of IRC daemons]]

* [[Internet slang]]
* [[List of IRC commands]]
* [[Serving channel]]
* [[The Hamnet Players]]

==References==
{{reflist|30em}}

==Bibliography==
* {{cite IETF
| title = A Discussion on Computer Network Conferencing
| rfc = 1324
| last = Reed
| first = Darren
| year = 1992
| month = May
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
| ref = ietf
}}
* {{cite IETF
| title = Internet Relay Chat Protocol
| rfc = 1459
| last1 = Oikarinen
| first1 = Jarkko
| authorlink1 = Jarkko Oikarinen
| last2 = Reed
| first2 = Darren
| year = 1993
| month = May
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
| ref = ietf
}}
* {{cite IETF
| title = Internet Relay Chat: Architecture
| rfc = 2810
| last = Kalt
| first = Christophe
| year = 2000
| month = April
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
| ref = ietf
}}
* {{cite IETF
| title = Internet Relay Chat: Channel Management
| rfc = 2811
| last = Kalt
| first = Christophe
| year = 2000
| month = April
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
| ref = ietf
}}
* {{cite journal
| last = Loesch
| first = Carl
| date = 2003-07-17
| title = Functionality Provided by Systems for Synchronous Conferencing
| publisher = psyc.eu
| url = http://www.psyc.eu/synconf
| accessdate = 2011-04-10
| ref = harv
}}

==Further reading==
* {{cite IETF
| title = Internet Relay Chat: Client Protocol
| rfc = 2812
| last = Kalt
| first = Christophe
| year = 2000
| month = April
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
}}
* {{cite IETF
| title = Internet Relay Chat: Server Protocol
| rfc = 2813
| last = Kalt
| first = Christophe
| year = 2000
| month = April
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
}}
* {{cite web
| url = http://www.ibiblio.org/pub/academic/communications/logs/
| title = Logs of major events in the online community
| accessdate = 2011-04-08
| publisher = [[ibiblio]]
| location = [[Chapel Hill, North Carolina]]
}}
* {{cite web
| url = http://www.alien.net.au/irc/
| title = IRC technical information
| accessdate = 2011-04-10
| last = Butcher
| first = Simon
| publisher = alien.net.au
}}

==External links==
{{Wikibooks|Internet Technologies|IRC}}
{{Commons category|IRC}}
* {{Dmoz|Computers/Internet/Chat/IRC|IRC}}
* [http://www.alien.net.au/irc/irc2numerics.html IRC/2 Numerics List]
* [http://www.irc.org/history.html History of IRC]
* [http://www.irc.org/ IRC.org] – Technical and Historical IRC6 information; Articles on the history of IRC
* [http://www.irchelp.org/ IRChelp.org] – Internet Relay Chat (IRC) help archive; Large archive of IRC-related documents
* [http://www.ircv3.org/ IRCv3] – Working group of developers, who add new features to the protocol and write specs for them

{{IRC topics}}
{{URI scheme}}
{{Computer-mediated communication}}

[[Category:Internet Relay Chat| ]]
[[Category:Application layer protocols]]
[[Category:Finnish inventions]]
[[Category:Internet terminology]]
[[Category:Virtual communities]]
[[Category:1988 introductions]]

Matrix (Kommunikationsprotokoll)

2015-03-28T00:36:44Z

Categorization: just trying to keep it going slowly, trying to read https://en.wikipedia.org/wiki/List_of_social_networking_websites to see examples for form.

"Matrix is an open standard for decentralised communication, providing simple HTTP APIs and open source reference implementations for securely distributing and persisting JSON over an open federation of servers."

just using IRC as first draft, editing live

'''Matrix''' is an [[application layer]] protocol based on open standard for decentralised communication, providing simple HTTP APIs and open source reference implementations for securely distributing and persisting JSON over an open federation of servers.

facilitates transfer of messages in the form of text. The chat process works on a client/server model of networking. IRC clients are computer programs that a user can install on their system. These clients are able to communicate with chat servers to transfer messages to other clients.<ref name="rfc 1459 1 introduction">{{cite IETF
| rfc = 1459
| sectionname = Introduction
| section = 1
| page = 4
| idanchor = ietf
}}</ref> It is mainly designed for [[Many-to-many|group communication]] in discussion forums, called ''[[#Channels|channels]]'',<ref>{{cite IETF
| rfc = 1459
| sectionname = One-to-many
| section = 3.2
| page = 11
| idanchor = ietf
}}</ref> but also allows one-to-one communication via [[instant messaging|private message]]<ref>{{cite IETF
| rfc = 2810
| sectionname = One-To-One Communication
| section = 5.1
| page = 5
| idanchor = ietf
}}</ref> as well as [[Direct Client-to-Client|chat and data transfer]],<ref>{{cite web
| url = http://www.irchelp.org/irchelp/rfc/dccspec.html
| title = A description of the DCC protocol
| accessdate = 2011-04-08
| last = Rollo
| first = Troy
| publisher = irchelp.org
}}</ref> including [[file sharing]].<ref>{{cite book
| last = Wang
| first = Wallace
| title = Steal this File Sharing Book
| edition = 1st
| date = 2004-10-25
| publisher = [[No Starch Press]]
| location = [[San Francisco, California]]
| isbn = 1-59327-050-X
| pages = 61{{spaced ndash}}67
| chapter = Instant Messaging and Online Chat Rooms: Internet Relay Chat (IRC)
}}</ref>

[[Comparison of Internet Relay Chat clients|Client software]] is available for every major operating system that supports Internet access.<ref name=Sage>{{cite web
|title=SAGE IRC Channel
|url=http://www.sage.org/about/irc.html
|publisher=Sage – The USENIX Special Interest Group for Sysadmins
|accessdate=18 April 2011
|archiveurl=http://web.archive.org/web/20120207191923/http://sage.org/about/irc.html|archivedate=7 February 2012}}</ref> As of April 2011, the top 100 IRC networks served more than half a million users at a time,<ref name="irc networks top 100">{{cite web
| url = http://irc.netsplit.de/networks/top100.php
| title = IRC Networks – Top 100
| accessdate = 2011-04-08
| publisher = irc.netsplit.de
}}</ref> with hundreds of thousands of channels<ref name="irc networks top 100" /> operating on a total of roughly 1,500 servers<ref name="irc networks top 100" /> out of roughly 3,200 servers worldwide.<ref>{{cite web
| url = http://irc.netsplit.de/servers/summary.php
| title = IRC Servers – Summary
| accessdate = 2011-04-08
| publisher = irc.netsplit.de
}}</ref>

Over the past decade IRC usage has been declining: since 2003 it has lost 60% of its users (from 1 million to about 400,000 in 2014) and half of its channels (from half a million in 2003).<ref>{{cite web
| url = http://royal.pingdom.com/2012/04/24/irc-is-dead-long-live-irc/
| title = IRC is dead, long live IRC
| accessdate = 2014-05-16
}}</ref>

{{IPstack}}

==History {{anchor|MultiUser Talk}}== 
IRC was created by [[Jarkko Oikarinen]] in August 1988 to replace a program called MUT (MultiUser Talk) on a [[Bulletin board system|BBS]] called OuluBox in [[Finland]].<ref name="founding irc">{{cite web
| url = http://www.mirc.com/jarkko.html
| title = Founding IRC
| accessdate = 2011-04-08
| last = Oikarinen
| first = Jarkko
| authorlink = Jarkko Oikarinen
}}</ref> Oikarinen found inspiration in a chat system known as [[Bitnet Relay]], which operated on the [[BITNET]].<ref name="founding irc" />

IRC was used to report on the [[1991 Soviet coup d'état attempt]] throughout a [[media blackout]].<ref>{{cite web
| url = http://www.ibiblio.org/pub/academic/communications/logs/report-ussr-gorbatchev
| title = IRC transcripts from the time of the 1991 Soviet coup d'état attempt
| accessdate = 2011-04-08
| publisher = [[ibiblio]]
| location = [[Chapel Hill, North Carolina]]
}}</ref> It was previously used in a similar fashion during the [[Gulf War]].<ref>{{cite web
| url = http://www.ibiblio.org/pub/academic/communications/logs/Gulf-War/
| title = IRC logs of events of the Gulf War
| accessdate = 2011-04-08
| publisher = [[ibiblio]]
| location = [[Chapel Hill, North Carolina]]
}}</ref> Logs of these and other events are kept in the [[ibiblio]] archive.<ref>{{cite web
| url = http://www.ibiblio.org/pub/academic/communications/logs/
| title = Logs of major events in the online community
| accessdate = 2011-04-08
| publisher = [[ibiblio]]
| location = [[Chapel Hill, North Carolina]]
}}</ref>

==Technical information==
{{See also|IRCd}}

[[File:Screenshot of HexChat in Windows 8.png|right|thumb|A screenshot of [[HexChat]], an IRC client for [[GTK]] environments.]]
[[File:Xaric screen shot.jpg|right|thumb|Xaric, a text-based IRC client, in use on [[Mac OS X]]. Shown are two IRC channels and a private conversation with the software author.]]
IRC is an open [[Network protocol|protocol]] that uses [[Transmission Control Protocol|TCP]]<ref name="rfc 1459 1 introduction" /> and, optionally, [[Transport Layer Security|TLS]]. An [[IRC server]] can connect to other IRC servers to expand the IRC network.<ref>{{cite IETF
| rfc = 1459
| sectionname = Servers
| section = 1.1
| page = 4
| idanchor = ietf
}}</ref> Users access IRC networks by connecting a client to a server.<ref>{{cite IETF
| rfc = 2810
| sectionname = Clients
| section = 2.2
| page = 3
| idanchor = ietf
}}</ref> 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 user will have to set a nickname before being connected.<ref>{{cite IETF
| rfc = 1459
| sectionname = Clients
| section = 1.2
| page = 5
| idanchor = ietf
}}</ref>

IRC was originally a [[Text-based protocol|plain text protocol]] <ref name="rfc 1459 1 introduction" /> (although later extended), which on request was assigned port [[List of TCP and UDP port numbers|194/TCP]] by [[Internet Assigned Numbers Authority|IANA]].<ref>{{cite web
| url = http://www.iana.org/assignments/port-numbers
| title = Port Numbers
| accessdate = 2011-04-08
| date = 2011-04-06
| publisher = [[Internet Assigned Numbers Authority]]
| location = [[Marina del Rey, California]]
}}</ref> However, the [[de facto standard|''de facto'' standard]] has always been to run IRC on 6667/TCP<ref>{{cite IETF
| rfc = 1459
| sectionname = Connect message
| section = 4.3.5
| page = 29
| idanchor = ietf
}}</ref> and nearby port numbers (for example TCP ports 6660–6669, 7000)<ref>{{cite book
| last1 = Lucas
| first1 = Mark
| last2 = Singh
| first2 = Abhishek
| last3 = Cantrell
| first3 = Chris
| editor-last = Henmi
| editor-first = Anne
| title = Firewall Policies and VPN Configurations
| date = 2006-10-05
| publisher = [[Syngress Publishing]]
| location = [[Rockland, Massachusetts]]
| isbn = 1-59749-088-1
| page = 93
| chapter = Defining a Firewall
}}</ref> to avoid having to run the [[IRCd]] software with [[Superuser|root privileges]].

The protocol specified that characters were 8-bit but did not specify the character encoding the text was supposed to use.<ref name="rfc 1459 2.2 character codes">{{cite IETF
| rfc = 1459
| sectionname = Character codes
| section = 2.2
| page = 7
| idanchor = ietf
}}</ref> 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 (RFC 2810, RFC 2811, RFC 2812 and RFC 2813); however, these protocol changes have not been widely adopted among other implementations.{{Citation needed|date=July 2007}}

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.{{Citation needed|date=July 2007}}

Microsoft made an extension for IRC in 1998 via the proprietary [[IRCX]].<ref>{{cite IETF
| title = Extensions to the Internet Relay Chat Protocol (IRCX)
| draft = draft-pfenning-irc-extensions-04
| last = Abraham
| first = Dalen
| year = 1998
| month = June
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2011-04-08
}}</ref> They later stopped distributing software supporting IRCX, instead developing the proprietary [[Microsoft Notification Protocol|MSNP]].

The standard structure of a network of IRC servers is a [[Tree network|tree]].<ref>{{cite IETF
| rfc = 2810
| sectionname = Architecture
| section = 3
| pages = 3{{spaced ndash}}4
| idanchor = ietf
}}</ref> Messages are routed along only necessary branches of the tree but network state is sent to every server<ref>{{cite IETF
| rfc = 2810
| sectionname = Introduction
| section = 1
| page = 2
| idanchor = ietf
}}</ref> and there is generally a high degree of implicit trust between servers. This architecture has a number of problems. A misbehaving or malicious server can cause major damage to the network<ref>{{cite IETF
| rfc = 1459
| sectionname = Algorithms
| section = 9.3
| page = 64
| idanchor = ietf
}}</ref> 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<ref>{{cite IETF
| rfc = 2810
| sectionname = Network Congestion
| section = 6.3
| pages = 7{{spaced ndash}}8
| idanchor = ietf
}}</ref> 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.<ref>{{cite IETF
| rfc = 2810
| sectionname = To A Channel
| section = 5.2.1
| pages = 5{{spaced ndash}}6
| idanchor = ietf
}}</ref> This is a strength in comparison to non-multicasting protocols such as [[Simple Mail Transfer Protocol]] (SMTP) or [[Extensible Messaging and Presence Protocol]] (XMPP).

An IRC daemon can also be used on a local area network (LAN). IRC can thus be used to facilitate communication between people of the own network (internal communication).<ref>{{cite web|url=http://computerquestionhelp.com/content/how-guide-setup-your-own-irc-server-using-personal-or-dedicated-system-or-server-top-freewar|title=IRC daemons for LAN|publisher=|accessdate=2 October 2014}}</ref><ref>{{cite web|url=http://www.irc-wiki.org/IRC_server|title=Running an own IRC server|publisher=|accessdate=2 October 2014}}</ref>

===Commands and replies===
{{Main|List of Internet Relay Chat commands}}
IRC has a line-based structure with the client sending single-line messages to the server,<ref>{{cite IETF
| rfc = 1459
| sectionname = Message format in 'pseudo' BNF
| section = 2.3.1
| page = 8
| idanchor = ietf
}}</ref> receiving replies to those messages<ref>{{cite IETF
| rfc = 1459
| sectionname = Numeric replies
| section = 2.4
| page = 10
| idanchor = ietf
}}</ref> and receiving 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 (generally for commands the client does not recognize) passed directly to the server, possibly with some modification.{{Citation needed|date=May 2009}}

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.<ref>{{cite web
| url = http://www.shanemcc.co.uk/irc/#listmode
| title = IRC List Modes – List mode extension showing pair confusion for lists
| accessdate = 2011-04-08
| date = 2009-11-25
}}</ref>

===Channels===
The basic means of communicating to a group of users in an established IRC session is through a ''[[chat room|channel]]''.<ref name="rfc 1459 3.2.2 to a group (channel)">{{cite IETF
| rfc = 1459
| sectionname = To a group (channel)
| section = 3.2.2
| page = 11
| idanchor = ietf
}}</ref> Channels on a network can be displayed using the IRC command ''LIST'',<ref>{{cite IETF
| rfc = 1459
| sectionname = List message
| section = 4.2.6
| page = 24
| idanchor = ietf
}}</ref> 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,<ref name="rfc 1459 4.2.1 join message">{{cite IETF
| rfc = 1459
| sectionname = Join message
| section = 4.2.1
| page = 19
| idanchor = ietf
}}</ref> in most clients available as ''/join #channelname''. Messages sent to the joined channels are then relayed to all other users.<ref name="rfc 1459 3.2.2 to a group (channel)" />

Channels that are available across an entire IRC network are prefixed with a '#', while those local to a server use '&'.<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel Scope
| section = 2.2
| page2 = 3{{spaced ndash}}4
| idanchor = ietf
}}</ref> Other less common channel types include '+' channels—'modeless' channels without operators —<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel Properties
| section = 2.3
| page = 4
| idanchor = ietf
}}</ref> and '!' channels, a form of [[#Nick/channel delay|timestamped]] channel on normally non-timestamped networks.<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel lifetime
| section = 3
| page = 5
| idanchor = ietf
}}</ref>

===Modes===
Users and channels may have ''modes'' that are represented by single case-sensitive letters<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel Modes
| section = 4
| page = 7
| idanchor = ietf
}}</ref> and are set using the ''MODE'' command.<ref>{{cite IETF
| rfc = 1459
| sectionname = Mode message
| section = 4.2.3
| page = 21
| idanchor = ietf
}}</ref> User modes and channel modes are separate and can use the same letter to mean different things (e.g. usermode "i" is invisible mode whilst channelmode "i" is invite only.<ref>{{cite IETF
| rfc = 1459
| sectionname = Channel modes
| section = 4.2.3.1
| pages = 21{{spaced ndash}}22
| idanchor = ietf
}}</ref>) Modes are usually set and unset using the mode command that takes a target (user or channel), a set of modes to set (+) or unset (-) and any parameters the modes need.

Some but not all channel modes take parameters and some channel modes apply to a user on a channel or add or remove a mask (e.g. a ban mask) from a list associated with the channel rather than applying to the channel as a whole.<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel Access Control
| section = 4.3
| pages = 10{{spaced ndash}}11
| idanchor = ietf
}}</ref> Modes that apply to users on a channel have an associated symbol that is used to represent the mode in names replies<ref name="rfc 1459 p.51 rpl_namreply">{{cite IETF
| rfc = 1459
| sectionname = Command responses: 353 RPL_NAMREPLY
| page = 51
| idanchor = ietf
}}</ref> (sent to clients on first joining a channel<ref name="rfc 1459 4.2.1 join message" /> and use of the names command) 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.<ref>{{cite web
| url = http://www.irc.org/tech_docs/005.html
| title = The 005 numeric: ISUPPORT
| accessdate = 2011-04-10
| last = Roeckx
| first = Kurt
| date = 2004-10-14
| publisher = irc.org
}}</ref><ref>{{cite IETF
| title = IRC RPL_ISUPPORT Numeric Definition
| draft = draft-brocklesby-irc-isupport-03
| last = Brocklesby
| first = Edward
| year = 2002
| month = September
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2011-04-10
}}</ref>

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,<ref name="rfc 1459 p.51 rpl_namreply" /> but multiple such modes can be set on a single user. For example, if a user holds both operator status (+o) and voice status (+v) on a channel, a new client will be unable to know the less precedented mode (voice). Workarounds for this are possible on both the client and server side but none is widely implemented.

====Standard (RFC 1459) modes====

{| class="wikitable"
|+ User modes
|-
! Letter
! Symbol
! Description
|-
| '''i'''
|
| Invisible—cannot be seen without a common channel or knowing the exact name
|-
| '''s'''
|
| Receives server notices
|-
| '''w'''
|
| Receives wallops<ref>{{cite IETF
| rfc = 1459
| sectionname = Operwall message
| section = 5.6
| page = 41
| idanchor = ietf
}}</ref>
|-
| '''o'''
|
| User is an IRC operator (ircop)
|}

{| class="wikitable"
|+ Channel modes
|-
! Letter
! Symbol
! Parameter(s)
! Description
|-
| '''o'''
| @
| Name of affected user
| Channel operator—can change channel modes and kick users out of the channel among other things
|-
| '''s'''
|
|
| Secret channel—not shown in channel list or user whois except to users already on the channel
|-
| '''p'''
|
|
| Private channel—listed in channel list as "prv" according to <nowiki>RFC 1459</nowiki>
|-
| '''n'''
|
|
| Users cannot send messages to the channel externally
|-
| '''m'''
|
|
| Channel is moderated (only those who hold operator or voice status on the channel can send messages to it)
|-
| '''i'''
|
|
| Only users with invites may enter the channel.
|-
| '''t'''
|
|
| Only operators can change the channel topic.
|-
| '''l'''
|
| Limit number
| Limits number of users able to be on channel (when full, no new users can join)
|-
| '''b'''
|
| Ban mask (nick!user@host with wildcards allowed)
| Bans [[hostmask]]s from channel
|-
| '''v''' 
| +
| Name of affected user
| Gives a user voice status on channel (see +m above)
|-
| '''k'''
|
| New channel key
| Sets 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.<ref>{{cite web
| url = http://www.alien.net.au/irc/usermodes.html
| title = IRC User Modes List
| accessdate = 2011-04-10
| last = Butcher
| first = Simon
| date = 2005-01-12
| publisher = alien.net.au
}}</ref><ref>{{cite web
| url = http://www.alien.net.au/irc/chanmodes.html
| title = IRC Channel Modes List
| accessdate = 2011-04-10
| last = Butcher
| first = Simon
| date = 2005-01-12
| publisher = alien.net.au
}}</ref><ref>{{cite web
| url = http://www.alien.net.au/irc/servermodes.html
| title = IRC Server Modes List
| accessdate = 2011-04-10
| last = Butcher
| first = Simon
| date = 2005-01-12
| publisher = alien.net.au
}}</ref><ref>{{cite web
| url = http://webtoman.com/opera/panel/ircdmodes.html
| title = IRCd Modes
| accessdate = 2011-04-10
| last = Olsen
| first = Tommy
| publisher = webtoman.com
}}</ref>

===Channel Operators===
A ''Channel Operator'' is a [[Client (computing)|client]] on an [[IRC channel]] that manages the channel.
IRC Channel Operators can be easily seen by a symbol "@", or a Latin letter "+o"/"o".
On most networks, an operator can:
* Kick a user
* Ban a user
* Give another user IRC Channel Operator Status or IRC Channel Voice Status.
* Change the IRC Channel topic.
* Change the IRC Channel Mode locks.

===IRC Operators===
{{main|Internet Relay Chat operator}}
There are also users who maintain elevated rights on their local server, or the entire network; these are called IRC operators,<ref name="rfc 1459 1.2.1 operators">{{cite IETF
| rfc = 1459
| sectionname = Operators
| section = 1.2.1
| page = 5
| idanchor = ietf
}}</ref> sometimes shortened to IRCops or Opers (not to be confused with channel operators). As the implementation of the IRCd varies, so do the privileges of the IRC operator on the given IRCd. RFC 1459<ref name="rfc 1459 1.2.1 operators" /> claims that IRC operators are "a necessary evil" to keep 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 IPs or complete subnets. Networks that carry services (Nickserv et al.) usually allow their IRC operators also to handle basic "Ownership" matters. Further privileged rights may include overriding channel bans (being able to join channels they would not be allowed to join, if they were not opered), 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 (computing)|client]] connected to an IRC [[Server (computing)|server]].<ref name="thiedeke-2003">{{cite book
| last = Thiedeke
| first = Udo
| title = Virtuelle Gruppen: Charakteristika und Problemdimensionen
| url = http://books.google.com/?id=aQ74THYRyYsC&lpg=PA314&pg=PA315#v=onepage&q=hostmask
| accessdate = 2010-03-30
| edition = 2nd
| date = 2003-09-23
| publisher = {{Ill|de|Springer VS}}
| language = German
| isbn = 3-531-33372-0
| pages = 314, 337
| chapter = Nicola Döring, Alexander Schestag
}}</ref><ref name="rogers-2005">{{cite book
| last = Rogers
| first = Russ
| editor-last = Devost
| editor-first = Matthew G.
| title = Hacking a Terror Network: The Silent Threat of Covert Channels
| url = http://books.google.com/books?id=e3ggsGgTzUgC&lpg=PA10&pg=PA10#v=onepage&q=Hostmask%20IRC
| accessdate = 2010-03-30
| edition = 1st
| date = 2004-12-01
| publisher = [[Syngress Publishing]]
| location = [[Rockland, Massachusetts]]
| isbn = 1-928994-98-9
| page = 10
| chapter = The Mind of Terror
}}</ref> IRC [[IRCd|server]]s, [[Internet Relay Chat services|services]], and other clients including [[Internet Relay Chat bot|bots]] can use it to identify a specific IRC session.

The format of a hostmask is <code>nick!user@host</code>. 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 protocol|ident]] on the client.<ref name="petersen-2002">{{cite book
| editor-last = Petersen
| editor-first = Julie K.
| title = The Telecommunications Illustrated Dictionary
| url = http://books.google.com/books?id=b2mMzS0hCkAC&lpg=PA500&pg=PA500#v=onepage&q=Hostmask
| accessdate = 2010-03-30
| edition = 2nd
| date = 2002-05-29
| publisher = [[CRC Press]]
| isbn = 0-8493-1173-X
| page = 500
| chapter = Internet Relay Chat
}}</ref> If ident is not available on the client, the username specified when the client connected is used after being prefixed with a [[tilde]].<ref name="freenode faq">{{cite web
| url = http://freenode.net/faq.shtml
| title = Frequently-Asked Questions
| accessdate = 2010-03-30
| publisher = [[freenode]]
}}</ref>

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 [[IRCd|IRC daemons]] also provide privacy features, such as InspIRCD or UnrealIRCD's "+x" mode. This [[Cryptographic hash function|hashes]] a client IP address or masks part of a client's hostname, making it unreadable to users other than [[Internet Relay Chat#IRC Operators|IRCops]]. Users may also have the option of requesting a "virtual host" (or "vhost"), 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.<ref>{{cite web
| url = http://meta.wikimedia.org/wiki/IRC/Cloaks
| title = IRC/Cloaks
| accessdate = 2011-11-27
| publisher = [[Wikimedia]]
}}</ref>

==Challenges==
Issues in the original design of IRC were the amount of shared state data<ref>{{cite IETF
| rfc = 1324
| sectionname = Size
| section = 2.5.1
| pages = 5{{spaced ndash}}6
| idanchor = ietf
}}</ref><ref>{{cite IETF
| rfc = 2810
| sectionname = Scalability
| section = 6.1
| page = 7
| idanchor = ietf
}}</ref> being a limitation on its scalability,<ref>{{harvnb|Loesch|2003}} 1.2.1 Growth</ref> the absence of unique user identifications leading to the nickname collision problem,<ref>{{cite IETF
| rfc = 1324
| sectionname = User identification
| section = 5.4.1
| page = 10
| idanchor = ietf
}}</ref> lack of protection from netsplits by means of cyclic routing,<ref>{{cite IETF
| rfc = 1324
| sectionname = Trees and cycles
| section = 5.4.2
| page = 10
| idanchor = ietf
}}</ref><ref>{{harvnb|Loesch|2003}} 1.2.2 Network failures</ref> the trade-off in scalability for the sake of real-time user presence information,<ref>{{cite IETF
| rfc = 1324
| sectionname = State Information problems
| section = 2.1
| page = 4
| idanchor = ietf
}}</ref> protocol weaknesses providing a platform for abuse,<ref>{{harvnb|Loesch|2003}} 1.2.3 Sociological and security aspects</ref> no transparent and optimizable message passing,<ref>{{cite IETF
| rfc = 1324
| sectionname = Message passing
| section = 5.2.1
| page = 7
| idanchor = ietf
}}</ref> and no encryption.<ref>{{cite IETF
| rfc = 1324
| sectionname = Conference security
| section = 5.2.4
| page = 8
| idanchor = ietf
}}</ref> Some of these issues have been addressed in ''Modern IRC''.

===Attacks===
Because IRC connections are usually unencrypted and typically span long time periods, they are an attractive target for [[Denial-of-service attack|Dos/DDoS attackers]] and [[Hacker (computer security)|hackers]]. Because of this, careful security policy is necessary to ensure that an IRC network is not susceptible to an attack such as a [[Internet Relay Chat takeover|takeover]] war. IRC networks may also [[K-line (IRC)|K-line]] or [[G-line]] users or networks that have a harming effect.

A small number of IRC servers support [[Transport Layer Security|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 (that may require the user to install SSL binaries and IRC client specific patches or modules on their computers). Some networks also use SSL for server to server connections, and provide a special channel flag (such as <code>+S</code>) to only allow SSL-connected users on the channel, while disallowing operator identification in clear text, to better utilize the advantages that SSL provides.<ref>{{cite web
| url = http://esper.net/help.php
| title = Getting Help on EsperNet
| publisher = The EsperNet IRC Network
| accessdate = 2012-07-31
}}</ref><ref>{{cite web
| url = http://www.dal.net/news/shownews.php?id=67
| title = New Feature: SSL For Users
| author = brandon
| date = 2010-05-18
| publisher = DALnet
| accessdate = 2012-07-31
}}</ref>

IRC served as an early laboratory for many kinds of Internet attacks, such as using fake [[Internet Control Message Protocol|ICMP]] unreachable messages to break [[Transmission Control Protocol|TCP]]-based IRC connections ([[Nuke (computer)|nuking]]) to annoy users or facilitate [[Internet Relay Chat takeover|takeover]]s.

===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 attack]]s, 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 (i.e., 'nick-collision').
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 [[netsplit]]s, 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, 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{{spaced ndash}}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 lost 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" (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 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.

====SAVE====
In recent versions of the IRCnet ircd, as well as ircds using the TS6 protocol (including Charybdis), ND has been extended/replaced by a mechanism called SAVE. This mechanism assigns every client a unique UID upon connecting to an IRC server. This ID starts with a number, which is forbidden in nicks (although some ircds, namely IRCnet and InspIRCd, allow clients to switch to their own UID as the nickname).

If two clients with the same nickname join from different sides of a netsplit ("nick collision"), 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 (ND) to prevent both clients from changing back to the original nickname, thus colliding again.

==Networks==
[[File:Tolsun 2.jpg|thumb|right|The first IRC server, tolsun.oulu.fi, a [[Sun-3]] server on display near the [[University of Oulu]] computer centre. (2001)]]

There are thousands of running IRC networks in the world. They run various implementations of [[IRC server]]s, and are administered by various groups of [[IRC operator]]s, but the protocol exposed to IRC users is very similar, and all IRC networks can be accessed by the same client software, although there might be slight incompatibilities and limited functionality due to the differing server software implementations.

The largest IRC networks have traditionally been grouped as the "Big Four"<ref name="the book of irc">{{cite book
| last = Charalabidis
| first = Alex
| title = The Book of IRC: The Ultimate Guide to Internet Relay Chat
| edition = 1st
| date = 1999-12-15
| publisher = No Starch Press
| location = [[San Francisco, California]]
| isbn = 1-886411-29-8
| page = 61
| chapter = IRCing On The Macintosh: Ircle
| quote = On large networks such as the Big Four{{mdash}} EFnet, IRCnet, Undernet, and DALnet{{mdash}} trying to list the thousands of channels with Ircle always causes you to disconnect due to the flood of information, while other clients can usually manage the feat, if you are on a direct Ethernet connection.
}}</ref><ref name="encyclopedia of new media">{{cite book
| editor-last = Jones
| editor-first = Steve
| title = Encyclopedia of New Media: An Essential Reference to Communication and Technology
| edition = 1st
| date = 2002-12-10
| publisher = [[SAGE Publications]]
| location = [[Thousand Oaks, California]]
| isbn = 0-7619-2382-9
| page = 257
| chapter = Internet Relay Chat
| quote = Today there are hundreds of independent IRC networks, but the "Big Four" are EFNet, UnderNet, Dalnet, and IRCnet.
}}</ref><ref name="the imac book">{{cite book
| last = Rittner
| first = Don
| title = The iMac Book
| edition = 1st
| date = 1999-03-03
| publisher = Coriolis Group
| location = [[Scottsdale, Arizona]]
| isbn = 1-57610-429-X
| page = 215
| chapter =
| quote = There are several large networks: EFnet, UnderNET, DALnet, and IRCnet make up the Big Four.
}}</ref><ref name="information technology for management">{{cite book
| last1 = Turban
| first1 = Efraim
| last2 = Leidner
| first2 = Dorothy
| last3 = McLean
| first3 = Ephraim
| last4 = Wetherbe
| first4 = James
| title = Information Technology for Management: Transforming Organizations in the Digital Economy
| edition = 5th
| date = 2005-02-07
| publisher = [[John Wiley & Sons]]
| location = [[Hoboken, New Jersey]]
| isbn = 0-471-70522-5
| pages = 106{{spaced ndash}}107
| chapter = Communication
| quote = The largest networks have traditionally been grouped as the "Big Four": EFNet, IrcNet, QuakeNet, and UnderNet.
}}</ref>{{mdash}} 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:<ref name="the book of irc" /><ref name="encyclopedia of new media" /><ref name="the imac book" />
* [[EFnet]]
* [[IRCnet]]
* [[Undernet]]
* [[DALnet]]

IRC reached 6 million simultaneous users in 2001 and 10 million users in 2003.{{citation needed|date=January 2015}}

As of March 2015 the largest IRC networks were:

* [[freenode]] – around 99k users at peak hours
* [[IRCNet]] – around 44k users at peak hours
* [[QuakeNet]] – around 36k users at peak hours
* [[EFnet]] – around 26k users at peak hours
* [[Undernet]] – around 25k users at peak hours
* [[rizon]] – around 25k users at peak hours

Today, the top 100 IRC networks have around [http://irc.netsplit.de/networks/top100.php 460k users connected at peak hours].

===Timeline===

{{Simple Horizontal timeline

|from=1990
|to=2014
|inc=2

|styleDefault-borderbottom=solid 0.1em black;

|row1=timeline
|row1-style=styleDefault
|row1-bordertop=solid 0.1em black;
|row1-1-color=#ffbb33
|row1-1-from=1990
|row1-1-to=2014
|row1-1-text=[[EFnet]]

|row2=timeline
|row2-style=styleDefault
|row2-1-from=1990
|row2-1-to=1992
|row2-2-to=2014
|row2-2-text=[[Undernet]]
|row2-2-color=#33b5e5

|row3=timeline
|row3-style=styleDefault
|row3-1-from=1990
|row3-1-to=1994
|row3-2-color=#cc0000
|row3-2-to=2014
|row3-2-text=[[DALnet]]

|row4=timeline
|row4-style=styleDefault
|row4-1-from=1990
|row4-1-to=1995
|row4-2-color=#aa66cc
|row4-2-to=2014
|row4-2-text=[[freenode]]

|row5=timeline
|row5-style=styleDefault
|row5-1-from=1990
|row5-1-to=1997
|row5-2-color=#99cc00
|row5-2-to=2014
|row5-2-text=[[IRCnet]]

|row6=timeline
|row6-style=styleDefault
|row6-1-from=1990
|row6-1-to=1997
|row6-2-color=#ff4444
|row6-2-to=2014
|row6-2-text=[[QuakeNet]]

|row7=timeline
|row7-1-from=1990
|row7-1-to=2002
|row7-2-color=#ff44ff
|row7-2-to=2014
|row7-2-text=[[Rizon]]

|row8=scale
|caption=IRC networks
}}

==URI scheme==
There are three recognized [[URI scheme]]s for Internet Relay Chat, irc, irc6, and ircs,<ref>{{cite web
| url = http://www.iana.org/assignments/uri-schemes.html
| title = Uniform Resource Identifier (URI) Schemes
| publisher = Internet Assigned Numbers Authority | accessdate = 2012-10-14
}}</ref> that (when supported) allows [[hyperlink]]s of various forms, including
<nowiki>irc://<host>[:<port>]/[<channel>[?<channel_keyword>]]</nowiki>
(where items enclosed within brackets ([,]) are optional) to be used to (if necessary) connect to the specified host (or network, if known to the IRC client) and join the specified channel.<ref>{{cite IETF
| title = Uniform Resource Locator Schemes for Internet Relay Chat Entities
| draft = draft-butcher-irc-url-04
| last = Butcher
| first = Simon
| year = 2003
| month = January
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2011-04-10
}}</ref> (This can be used within the client itself, or from another application such as a Web browser). 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 (for example, mIRC) will do so ''unconditionally'' resulting in a (usually unintended) extra (for example, ##channel), if included in the URL.

Some implementations allow multiple channels to be specified, separated by commas.{{Citation needed|date=April 2011}}

==Clients==

===Client software===
{{Details|Comparison of Internet Relay Chat clients}}
[[File:Ircnetz-Schema.svg|right|thumb|Scheme of an IRC network with [[Client (computing)|normal clients]] (green), [[IRC bot|bots]] (blue) and [[Bouncer (networking)|bouncers]] (orange)]]

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 [[Microsoft Windows|Windows]], [[Unix]] & [[Linux]], [[Mac OS X]] and mobile operating systems (such as [[iOS]] and [[Android (operating system)|Android]]). On Windows, [[mIRC]] is one of the most popular clients.<ref>{{cite book|last=Smith|first=Roderick W.|title=The Multi-Boot Configuration Handbook| url= http://books.google.com/books?id=OuPtI5fHhBoC|accessdate=2010-07-25|series= Handbook Series| date= 2000-04-08| publisher= [[Que Publishing]]| location= [[Upper Saddle River, New Jersey]]|isbn= 0-7897-2283-6|page=289|chapter=The Internet: Using IRC to Get Help|quote= mIRC is one of the most popular Windows IRC clients.}}</ref>

Some programs which are extensible through [[plug-in (computing)|plug-ins]] also serve as platforms for IRC clients. For instance, a client called [[ERC (software)|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 browser]]s have built in IRC clients, such as [[Opera (Web browser)|Opera]] ([[Features of the Opera web browser#Legacy features|version 12.17 and earlier]])<ref>{{cite web| url=http://operawiki.info/OperaIRC| title = Opera Browser Wiki: IRC Client| accessdate = 2011-04-10}}</ref> or the [[ChatZilla]] add-on for Mozilla [[Firefox]] (included as a built-in component of [[SeaMonkey]]). Web-based clients, such as [[Mibbit]] and open source [[KiwiIRC]], can run in most browsers.

Games such as ''[[War§ow]]'',<ref>{{cite web
| url = http://www.warsow.net/wiki/index.php?title=IRC_Module
| title = Warsow Wiki: IRC Module
| accessdate = 2011-04-10
}}</ref> ''[[Unreal Tournament]]'' (up to [[Unreal Tournament 2004]]),<ref>{{cite web
| url = http://www.bcchardware.com/index.php?option=com_content&task=view&id=35&Itemid=40
| title = UT2004 Review
| accessdate = 2011-04-10
| last = Guenter
| first = Daniel
| date = 2004-06-21
| publisher = BCCHardware
}}</ref> ''[[Uplink (video game)|Uplink]]'',<ref>{{cite web
| url = http://guide.modlink.net/section11.php
| title = The Ultimate Uplink Guide
| accessdate = 2011-04-10
}}</ref> ''[[Spring Engine]]''-based games, [[0 A.D. (video game)|0 A.D.]] and ''[[ZDaemon]]'' have included IRC.<ref>{{cite web
| url = http://doomwiki.org/wiki/ZDaemon#Other_utilities
| title = ZDaemon – The Doom Wiki: Other utilities
| accessdate = 2011-04-10
}}</ref>

[[Ustream]]'s chat interface is [[IRC]] with custom authentication<ref>{{cite web
| url = http://ustream-helpers.com/how-to/ircclient
| title = How to setup an IRC client to connect and login to Ustream
| accessdate = 2013-04-27
| date = 2012-01-29
| publisher = Ustream-Helpers
}}</ref> as well as [[Justin.tv]]'s.<ref>{{cite web
| url = http://www.liquidsilver.org/2010/06/ustream-v-justin/
| title = Ustream vs. Justin.tv
| accessdate = 2011-07-13
| date = 2010-06-20
| publisher = LiquidSilver
| author = Mauldor
}}</ref>

===Bots===
{{Main|IRC bot}}

A typical use of bots in IRC is to provide [[Internet Relay Chat services|IRC services]] or a specific functionality within a channel such as to host a chat-based game or provide notifications of external events.

===Bouncer===
{{Main|BNC (software)}}
A program that runs as a [[daemon (computer software)|daemon]] on a [[Server (computing)|server]] and functions as a persistent [[proxy server|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.{{Citation needed|date=April 2011}} Should the client lose network connectivity, the BNC may stay connected and archive all traffic for later delivery, allowing the user to resume his IRC session without disrupting their connection to the server.<ref>{{cite web
| url = http://www.psybnc.at/readme.txt
| title = psyBNC Readme
| accessdate = 2011-04-10
| publisher = psybnc.at
}}</ref>

Furthermore, as a way of obtaining a bouncer-like effect, an IRC client (typically [[text-based]], for example [[Irssi]]) may be run on an always-on server to which the user connects via [[secure shell|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.<ref>{{cite web
| url = http://chriscarey.com/wordpress/2009/07/18/irc-with-irssi-proxy-screen/
| title = IRC with irssi-proxy + screen
| accessdate = 2011-04-10
| last = Carey
| first = Chris
| date = 2009-07-18
| publisher = chriscarey.com
}}</ref>

To keep the IRC client from quitting when the ssh connection closes, the client can be run inside a piece of screen-detaching software (e.g. [[GNU Screen]] or [[tmux]]), thus staying connected to the IRC network(s) constantly and able to log conversation in channels that the user is interested in, etc. Modelled after this setup, in 2004 an IRC client following the [[client-server]] model, called [[Smuxi]], has been launched.<ref>{{cite web
| url = http://www.smuxi.org/blog/show/Detachable_Frontend_Core_Rewrite__UML__Windows_Port_kicking_Glade
| title = Detachable Frontend (Core Rewrite) / UML / Windows Port (kicking Glade)
| accessdate = 2010-07-25
| date = 2004-12-25
| publisher = smuxi.org
}}</ref><ref>{{cite web
| url = http://www.smuxi.org/page/About
| title = About Smuxi
| accessdate = 2011-04-10
| publisher = smuxi.org
}}</ref>

==Search engines==
There are numerous search engines available to aid the user in finding what they are looking for on IRC.<ref>{{cite book
| last = Mutton
| first = Paul
| title = IRC Hacks
| edition = 1st
| date = 2004-07-27
| publisher = [[O'Reilly Media]]
| location = [[Sebastopol, California]]
| isbn = 0-596-00687-X
| pages = 44{{spaced ndash}}46
| chapter = Users and Channels
}}</ref><ref>{{cite book
| last = Wang
| first = Wallace
| title = Steal this File Sharing Book
| edition = 1st
| date = 2004-10-25
| publisher = [[No Starch Press]]
| location = [[San Francisco, California]]
| isbn = 1-59327-050-X
| pages = 65{{spaced ndash}}67
| chapter = Instant Messaging and Online Chat Rooms: Internet Relay Chat (IRC)
}}</ref> Generally the search engine consists of two parts, a "back-end" (or "spider/crawler") and a front-end "search engine".

The back-end (spider/crawler) 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 database|Oracle]].{{Citation needed|date=January 2010}}

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.{{Citation needed|date=August 2009}}

Many users have implemented their own [[ad hoc]] search engines using the logging features built into many IRC clients.

==Modern IRC==
IRC has changed much over its life on the Internet. New server software has added a multitude of new features.
* [[IRC services|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 attack]]s.{{Citation needed|date=January 2010}}
* Proxy detection: Most modern servers support detection of users attempting to connect through an insecure (misconfigured or exploited) [[proxy server]], which can then be denied a connection. An example is the [http://www.blitzed.org/proxy Blitzed Open Proxy Monitor] or BOPM. This proxy detection software is used by several networks, although that real time list of proxies is defunct since early 2006.{{Citation needed|date=January 2010}}
* 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.{{Citation needed|date=January 2010}}
* [[Encryption]]: For the client-to-server leg of the connection [[Secure Sockets Layer|SSL]] might be used (messages cease to be secure once they are relayed to other users on standard connections, but it makes [[Man-in-the-middle attack|eavesdropping]] on or wiretapping an individual's IRC sessions difficult). For client-to-client communication, [[Secure Direct Client-to-Client|SDCC]] (Secure DCC) can be used.{{Citation needed|date=January 2010}}
* 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.

There is an effort of standardization and adding new features to the IRC protocol by IRCv3 working group.<ref>{{cite web
| url = http://www.ircv3.org/
| title = IRCv3 Working Group
| accessdate = 2014-03-08
}}</ref>

==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{{Clarify|date=July 2009}} transfer messages from a client to another client just as byte sequences, without any interpretation or recoding of [[character (computing)|characters]]. The IRC protocol (unlike e.g. [[MIME]] or [[HTTP]]) 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 particular [[Unix]] derivatives) in the respective language communities:

* '''7-bit era:''' In the early days of IRC, especially among [[North Germanic languages|Scandinavian]] and [[Finnish language]] users, national variants of [[ISO 646]] were the dominant [[character encoding]]s. These encode non-ASCII characters like Ä Ö Å ä ö å at code positions 0x5B 0x5C 0x5D 0x7B 0x7C 0x7D ([[US-ASCII]]: '''[''' '''\''' ''']''' '''{''' '''|''' '''}'''). That is why these codes are always allowed in nicknames. According to RFC 1459, { | } in nicknames should be treated as lowercase equivalents of [ \ ] respectively.<ref name="rfc 1459 2.2 character codes" /> By the late 1990s, the use of 7-bit encodings had disappeared in favour of [[ISO 8859-1]], and such equivalence mappings were dropped from some IRC daemons.

* '''8-bit era:''' Since the early 1990s, 8-bit encodings such as [[ISO 8859-1]] have become commonly used for European languages. Russian users had a choice of [[KOI8-R]], [[ISO 8859-5]]{{Citation needed|date=October 2008}} and [[CP1251]], and since about 2000, modern Russian IRC networks convert between these different commonly used encodings of the [[Cyrillic script]].

* '''Multi-byte era:''' For a long time, East Asian IRC channels with ideographic scripts in China, Japan, and Korea have been using multi-byte encodings such as [[Extended Unix Code|EUC]] or [[ISO-2022-JP]]. With the common migration from ISO 8859 to UTF-8 on Linux and Unix platforms since about 2002, [[UTF-8]] has become an increasingly popular substitute for many of the previously used 8-bit encodings in European channels. Some IRC clients are now capable of reading messages both in ISO 8859-1 or UTF-8 in the same channel, heuristically autodetecting which encoding is used. The shift to UTF-8 began in particular on Finnish-speaking IRC ([[:fi:IRC#Merkistö|Merkistö]] (Finnish)).

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 bytes 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 [[Peer-to-peer|P2P]] file sharing, users can create file servers that allow them to share files with each other by using customised [[IRC bot]]s or scripts for their [[IRC client]]. Often users will group together to distribute [[warez]] via a network of IRC bots.<ref>{{cite web
| url = http://www.zdnet.com/news/pirated-movies-now-playing-on-a-server-near-you/122663
| title = Pirated movies: Now playing on a server near you
| accessdate = 2011-04-10
| last = Vamosi
| first = Robert
| date = 2002-05-08
| publisher = [[ZDNet]]
}}</ref>

Technically, IRC provides no [[file transfer]] mechanisms itself; file sharing is implemented by IRC ''clients'', typically using the [[Direct Client-to-Client]] (DCC) 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.<ref>{{cite web
| url = http://www.macobserver.com/tip/2002/04/04.1.shtml
| title = IRC 101: What Is It & How Do I Use It?
| accessdate = 2011-04-10
| last = Sasaki
| first = Darla
| date = 2002-04-04
| publisher = Macobserver.com
}}</ref> 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.

==See also==
{{Portal|Internet Relay Chat}}
* [[Chat room]]
* [[Client-to-client protocol]]
* [[Comparison of instant messaging protocols]]
* [[Comparison of IRC clients]]
* [[Comparison of IRC daemons]]

* [[Internet slang]]
* [[List of IRC commands]]
* [[Serving channel]]
* [[The Hamnet Players]]

==References==
{{reflist|30em}}

==Bibliography==
* {{cite IETF
| title = A Discussion on Computer Network Conferencing
| rfc = 1324
| last = Reed
| first = Darren
| year = 1992
| month = May
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
| ref = ietf
}}
* {{cite IETF
| title = Internet Relay Chat Protocol
| rfc = 1459
| last1 = Oikarinen
| first1 = Jarkko
| authorlink1 = Jarkko Oikarinen
| last2 = Reed
| first2 = Darren
| year = 1993
| month = May
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
| ref = ietf
}}
* {{cite IETF
| title = Internet Relay Chat: Architecture
| rfc = 2810
| last = Kalt
| first = Christophe
| year = 2000
| month = April
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
| ref = ietf
}}
* {{cite IETF
| title = Internet Relay Chat: Channel Management
| rfc = 2811
| last = Kalt
| first = Christophe
| year = 2000
| month = April
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
| ref = ietf
}}
* {{cite journal
| last = Loesch
| first = Carl
| date = 2003-07-17
| title = Functionality Provided by Systems for Synchronous Conferencing
| publisher = psyc.eu
| url = http://www.psyc.eu/synconf
| accessdate = 2011-04-10
| ref = harv
}}

==Further reading==
* {{cite IETF
| title = Internet Relay Chat: Client Protocol
| rfc = 2812
| last = Kalt
| first = Christophe
| year = 2000
| month = April
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
}}
* {{cite IETF
| title = Internet Relay Chat: Server Protocol
| rfc = 2813
| last = Kalt
| first = Christophe
| year = 2000
| month = April
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
}}
* {{cite web
| url = http://www.ibiblio.org/pub/academic/communications/logs/
| title = Logs of major events in the online community
| accessdate = 2011-04-08
| publisher = [[ibiblio]]
| location = [[Chapel Hill, North Carolina]]
}}
* {{cite web
| url = http://www.alien.net.au/irc/
| title = IRC technical information
| accessdate = 2011-04-10
| last = Butcher
| first = Simon
| publisher = alien.net.au
}}

==External links==
{{Wikibooks|Internet Technologies|IRC}}
{{Commons category|IRC}}
* {{Dmoz|Computers/Internet/Chat/IRC|IRC}}
* [http://www.alien.net.au/irc/irc2numerics.html IRC/2 Numerics List]
* [http://www.irc.org/history.html History of IRC]
* [http://www.irc.org/ IRC.org] – Technical and Historical IRC6 information; Articles on the history of IRC
* [http://www.irchelp.org/ IRChelp.org] – Internet Relay Chat (IRC) help archive; Large archive of IRC-related documents
* [http://www.ircv3.org/ IRCv3] – Working group of developers, who add new features to the protocol and write specs for them

{{IRC topics}}
{{URI scheme}}
{{Computer-mediated communication}}

[[Category:Internet Relay Chat| ]]
[[Category:Application layer protocols]]
[[Category:Finnish inventions]]
[[Category:Internet terminology]]
[[Category:Virtual communities]]
[[Category:1988 introductions]]

Matrix (Kommunikationsprotokoll)

2015-03-28T00:26:28Z

Categorization: Just using IRC as a basic frame and for homage

"Matrix is an open standard for decentralised communication, providing simple HTTP APIs and open source reference implementations for securely distributing and persisting JSON over an open federation of servers."

just using IRC as first draft, editing live

'''Matrix''' ('''IRC''') is an [[application layer]] protocol that facilitates transfer of messages in the form of text. The chat process works on a client/server model of networking. IRC clients are computer programs that a user can install on their system. These clients are able to communicate with chat servers to transfer messages to other clients.<ref name="rfc 1459 1 introduction">{{cite IETF
| rfc = 1459
| sectionname = Introduction
| section = 1
| page = 4
| idanchor = ietf
}}</ref> It is mainly designed for [[Many-to-many|group communication]] in discussion forums, called ''[[#Channels|channels]]'',<ref>{{cite IETF
| rfc = 1459
| sectionname = One-to-many
| section = 3.2
| page = 11
| idanchor = ietf
}}</ref> but also allows one-to-one communication via [[instant messaging|private message]]<ref>{{cite IETF
| rfc = 2810
| sectionname = One-To-One Communication
| section = 5.1
| page = 5
| idanchor = ietf
}}</ref> as well as [[Direct Client-to-Client|chat and data transfer]],<ref>{{cite web
| url = http://www.irchelp.org/irchelp/rfc/dccspec.html
| title = A description of the DCC protocol
| accessdate = 2011-04-08
| last = Rollo
| first = Troy
| publisher = irchelp.org
}}</ref> including [[file sharing]].<ref>{{cite book
| last = Wang
| first = Wallace
| title = Steal this File Sharing Book
| edition = 1st
| date = 2004-10-25
| publisher = [[No Starch Press]]
| location = [[San Francisco, California]]
| isbn = 1-59327-050-X
| pages = 61{{spaced ndash}}67
| chapter = Instant Messaging and Online Chat Rooms: Internet Relay Chat (IRC)
}}</ref>

[[Comparison of Internet Relay Chat clients|Client software]] is available for every major operating system that supports Internet access.<ref name=Sage>{{cite web
|title=SAGE IRC Channel
|url=http://www.sage.org/about/irc.html
|publisher=Sage – The USENIX Special Interest Group for Sysadmins
|accessdate=18 April 2011
|archiveurl=http://web.archive.org/web/20120207191923/http://sage.org/about/irc.html|archivedate=7 February 2012}}</ref> As of April 2011, the top 100 IRC networks served more than half a million users at a time,<ref name="irc networks top 100">{{cite web
| url = http://irc.netsplit.de/networks/top100.php
| title = IRC Networks – Top 100
| accessdate = 2011-04-08
| publisher = irc.netsplit.de
}}</ref> with hundreds of thousands of channels<ref name="irc networks top 100" /> operating on a total of roughly 1,500 servers<ref name="irc networks top 100" /> out of roughly 3,200 servers worldwide.<ref>{{cite web
| url = http://irc.netsplit.de/servers/summary.php
| title = IRC Servers – Summary
| accessdate = 2011-04-08
| publisher = irc.netsplit.de
}}</ref>

Over the past decade IRC usage has been declining: since 2003 it has lost 60% of its users (from 1 million to about 400,000 in 2014) and half of its channels (from half a million in 2003).<ref>{{cite web
| url = http://royal.pingdom.com/2012/04/24/irc-is-dead-long-live-irc/
| title = IRC is dead, long live IRC
| accessdate = 2014-05-16
}}</ref>

{{IPstack}}

==History {{anchor|MultiUser Talk}}== 
IRC was created by [[Jarkko Oikarinen]] in August 1988 to replace a program called MUT (MultiUser Talk) on a [[Bulletin board system|BBS]] called OuluBox in [[Finland]].<ref name="founding irc">{{cite web
| url = http://www.mirc.com/jarkko.html
| title = Founding IRC
| accessdate = 2011-04-08
| last = Oikarinen
| first = Jarkko
| authorlink = Jarkko Oikarinen
}}</ref> Oikarinen found inspiration in a chat system known as [[Bitnet Relay]], which operated on the [[BITNET]].<ref name="founding irc" />

IRC was used to report on the [[1991 Soviet coup d'état attempt]] throughout a [[media blackout]].<ref>{{cite web
| url = http://www.ibiblio.org/pub/academic/communications/logs/report-ussr-gorbatchev
| title = IRC transcripts from the time of the 1991 Soviet coup d'état attempt
| accessdate = 2011-04-08
| publisher = [[ibiblio]]
| location = [[Chapel Hill, North Carolina]]
}}</ref> It was previously used in a similar fashion during the [[Gulf War]].<ref>{{cite web
| url = http://www.ibiblio.org/pub/academic/communications/logs/Gulf-War/
| title = IRC logs of events of the Gulf War
| accessdate = 2011-04-08
| publisher = [[ibiblio]]
| location = [[Chapel Hill, North Carolina]]
}}</ref> Logs of these and other events are kept in the [[ibiblio]] archive.<ref>{{cite web
| url = http://www.ibiblio.org/pub/academic/communications/logs/
| title = Logs of major events in the online community
| accessdate = 2011-04-08
| publisher = [[ibiblio]]
| location = [[Chapel Hill, North Carolina]]
}}</ref>

==Technical information==
{{See also|IRCd}}

[[File:Screenshot of HexChat in Windows 8.png|right|thumb|A screenshot of [[HexChat]], an IRC client for [[GTK]] environments.]]
[[File:Xaric screen shot.jpg|right|thumb|Xaric, a text-based IRC client, in use on [[Mac OS X]]. Shown are two IRC channels and a private conversation with the software author.]]
IRC is an open [[Network protocol|protocol]] that uses [[Transmission Control Protocol|TCP]]<ref name="rfc 1459 1 introduction" /> and, optionally, [[Transport Layer Security|TLS]]. An [[IRC server]] can connect to other IRC servers to expand the IRC network.<ref>{{cite IETF
| rfc = 1459
| sectionname = Servers
| section = 1.1
| page = 4
| idanchor = ietf
}}</ref> Users access IRC networks by connecting a client to a server.<ref>{{cite IETF
| rfc = 2810
| sectionname = Clients
| section = 2.2
| page = 3
| idanchor = ietf
}}</ref> 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 user will have to set a nickname before being connected.<ref>{{cite IETF
| rfc = 1459
| sectionname = Clients
| section = 1.2
| page = 5
| idanchor = ietf
}}</ref>

IRC was originally a [[Text-based protocol|plain text protocol]] <ref name="rfc 1459 1 introduction" /> (although later extended), which on request was assigned port [[List of TCP and UDP port numbers|194/TCP]] by [[Internet Assigned Numbers Authority|IANA]].<ref>{{cite web
| url = http://www.iana.org/assignments/port-numbers
| title = Port Numbers
| accessdate = 2011-04-08
| date = 2011-04-06
| publisher = [[Internet Assigned Numbers Authority]]
| location = [[Marina del Rey, California]]
}}</ref> However, the [[de facto standard|''de facto'' standard]] has always been to run IRC on 6667/TCP<ref>{{cite IETF
| rfc = 1459
| sectionname = Connect message
| section = 4.3.5
| page = 29
| idanchor = ietf
}}</ref> and nearby port numbers (for example TCP ports 6660–6669, 7000)<ref>{{cite book
| last1 = Lucas
| first1 = Mark
| last2 = Singh
| first2 = Abhishek
| last3 = Cantrell
| first3 = Chris
| editor-last = Henmi
| editor-first = Anne
| title = Firewall Policies and VPN Configurations
| date = 2006-10-05
| publisher = [[Syngress Publishing]]
| location = [[Rockland, Massachusetts]]
| isbn = 1-59749-088-1
| page = 93
| chapter = Defining a Firewall
}}</ref> to avoid having to run the [[IRCd]] software with [[Superuser|root privileges]].

The protocol specified that characters were 8-bit but did not specify the character encoding the text was supposed to use.<ref name="rfc 1459 2.2 character codes">{{cite IETF
| rfc = 1459
| sectionname = Character codes
| section = 2.2
| page = 7
| idanchor = ietf
}}</ref> 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 (RFC 2810, RFC 2811, RFC 2812 and RFC 2813); however, these protocol changes have not been widely adopted among other implementations.{{Citation needed|date=July 2007}}

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.{{Citation needed|date=July 2007}}

Microsoft made an extension for IRC in 1998 via the proprietary [[IRCX]].<ref>{{cite IETF
| title = Extensions to the Internet Relay Chat Protocol (IRCX)
| draft = draft-pfenning-irc-extensions-04
| last = Abraham
| first = Dalen
| year = 1998
| month = June
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2011-04-08
}}</ref> They later stopped distributing software supporting IRCX, instead developing the proprietary [[Microsoft Notification Protocol|MSNP]].

The standard structure of a network of IRC servers is a [[Tree network|tree]].<ref>{{cite IETF
| rfc = 2810
| sectionname = Architecture
| section = 3
| pages = 3{{spaced ndash}}4
| idanchor = ietf
}}</ref> Messages are routed along only necessary branches of the tree but network state is sent to every server<ref>{{cite IETF
| rfc = 2810
| sectionname = Introduction
| section = 1
| page = 2
| idanchor = ietf
}}</ref> and there is generally a high degree of implicit trust between servers. This architecture has a number of problems. A misbehaving or malicious server can cause major damage to the network<ref>{{cite IETF
| rfc = 1459
| sectionname = Algorithms
| section = 9.3
| page = 64
| idanchor = ietf
}}</ref> 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<ref>{{cite IETF
| rfc = 2810
| sectionname = Network Congestion
| section = 6.3
| pages = 7{{spaced ndash}}8
| idanchor = ietf
}}</ref> 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.<ref>{{cite IETF
| rfc = 2810
| sectionname = To A Channel
| section = 5.2.1
| pages = 5{{spaced ndash}}6
| idanchor = ietf
}}</ref> This is a strength in comparison to non-multicasting protocols such as [[Simple Mail Transfer Protocol]] (SMTP) or [[Extensible Messaging and Presence Protocol]] (XMPP).

An IRC daemon can also be used on a local area network (LAN). IRC can thus be used to facilitate communication between people of the own network (internal communication).<ref>{{cite web|url=http://computerquestionhelp.com/content/how-guide-setup-your-own-irc-server-using-personal-or-dedicated-system-or-server-top-freewar|title=IRC daemons for LAN|publisher=|accessdate=2 October 2014}}</ref><ref>{{cite web|url=http://www.irc-wiki.org/IRC_server|title=Running an own IRC server|publisher=|accessdate=2 October 2014}}</ref>

===Commands and replies===
{{Main|List of Internet Relay Chat commands}}
IRC has a line-based structure with the client sending single-line messages to the server,<ref>{{cite IETF
| rfc = 1459
| sectionname = Message format in 'pseudo' BNF
| section = 2.3.1
| page = 8
| idanchor = ietf
}}</ref> receiving replies to those messages<ref>{{cite IETF
| rfc = 1459
| sectionname = Numeric replies
| section = 2.4
| page = 10
| idanchor = ietf
}}</ref> and receiving 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 (generally for commands the client does not recognize) passed directly to the server, possibly with some modification.{{Citation needed|date=May 2009}}

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.<ref>{{cite web
| url = http://www.shanemcc.co.uk/irc/#listmode
| title = IRC List Modes – List mode extension showing pair confusion for lists
| accessdate = 2011-04-08
| date = 2009-11-25
}}</ref>

===Channels===
The basic means of communicating to a group of users in an established IRC session is through a ''[[chat room|channel]]''.<ref name="rfc 1459 3.2.2 to a group (channel)">{{cite IETF
| rfc = 1459
| sectionname = To a group (channel)
| section = 3.2.2
| page = 11
| idanchor = ietf
}}</ref> Channels on a network can be displayed using the IRC command ''LIST'',<ref>{{cite IETF
| rfc = 1459
| sectionname = List message
| section = 4.2.6
| page = 24
| idanchor = ietf
}}</ref> 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,<ref name="rfc 1459 4.2.1 join message">{{cite IETF
| rfc = 1459
| sectionname = Join message
| section = 4.2.1
| page = 19
| idanchor = ietf
}}</ref> in most clients available as ''/join #channelname''. Messages sent to the joined channels are then relayed to all other users.<ref name="rfc 1459 3.2.2 to a group (channel)" />

Channels that are available across an entire IRC network are prefixed with a '#', while those local to a server use '&'.<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel Scope
| section = 2.2
| page2 = 3{{spaced ndash}}4
| idanchor = ietf
}}</ref> Other less common channel types include '+' channels—'modeless' channels without operators —<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel Properties
| section = 2.3
| page = 4
| idanchor = ietf
}}</ref> and '!' channels, a form of [[#Nick/channel delay|timestamped]] channel on normally non-timestamped networks.<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel lifetime
| section = 3
| page = 5
| idanchor = ietf
}}</ref>

===Modes===
Users and channels may have ''modes'' that are represented by single case-sensitive letters<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel Modes
| section = 4
| page = 7
| idanchor = ietf
}}</ref> and are set using the ''MODE'' command.<ref>{{cite IETF
| rfc = 1459
| sectionname = Mode message
| section = 4.2.3
| page = 21
| idanchor = ietf
}}</ref> User modes and channel modes are separate and can use the same letter to mean different things (e.g. usermode "i" is invisible mode whilst channelmode "i" is invite only.<ref>{{cite IETF
| rfc = 1459
| sectionname = Channel modes
| section = 4.2.3.1
| pages = 21{{spaced ndash}}22
| idanchor = ietf
}}</ref>) Modes are usually set and unset using the mode command that takes a target (user or channel), a set of modes to set (+) or unset (-) and any parameters the modes need.

Some but not all channel modes take parameters and some channel modes apply to a user on a channel or add or remove a mask (e.g. a ban mask) from a list associated with the channel rather than applying to the channel as a whole.<ref>{{cite IETF
| rfc = 2811
| sectionname = Channel Access Control
| section = 4.3
| pages = 10{{spaced ndash}}11
| idanchor = ietf
}}</ref> Modes that apply to users on a channel have an associated symbol that is used to represent the mode in names replies<ref name="rfc 1459 p.51 rpl_namreply">{{cite IETF
| rfc = 1459
| sectionname = Command responses: 353 RPL_NAMREPLY
| page = 51
| idanchor = ietf
}}</ref> (sent to clients on first joining a channel<ref name="rfc 1459 4.2.1 join message" /> and use of the names command) 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.<ref>{{cite web
| url = http://www.irc.org/tech_docs/005.html
| title = The 005 numeric: ISUPPORT
| accessdate = 2011-04-10
| last = Roeckx
| first = Kurt
| date = 2004-10-14
| publisher = irc.org
}}</ref><ref>{{cite IETF
| title = IRC RPL_ISUPPORT Numeric Definition
| draft = draft-brocklesby-irc-isupport-03
| last = Brocklesby
| first = Edward
| year = 2002
| month = September
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2011-04-10
}}</ref>

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,<ref name="rfc 1459 p.51 rpl_namreply" /> but multiple such modes can be set on a single user. For example, if a user holds both operator status (+o) and voice status (+v) on a channel, a new client will be unable to know the less precedented mode (voice). Workarounds for this are possible on both the client and server side but none is widely implemented.

====Standard (RFC 1459) modes====

{| class="wikitable"
|+ User modes
|-
! Letter
! Symbol
! Description
|-
| '''i'''
|
| Invisible—cannot be seen without a common channel or knowing the exact name
|-
| '''s'''
|
| Receives server notices
|-
| '''w'''
|
| Receives wallops<ref>{{cite IETF
| rfc = 1459
| sectionname = Operwall message
| section = 5.6
| page = 41
| idanchor = ietf
}}</ref>
|-
| '''o'''
|
| User is an IRC operator (ircop)
|}

{| class="wikitable"
|+ Channel modes
|-
! Letter
! Symbol
! Parameter(s)
! Description
|-
| '''o'''
| @
| Name of affected user
| Channel operator—can change channel modes and kick users out of the channel among other things
|-
| '''s'''
|
|
| Secret channel—not shown in channel list or user whois except to users already on the channel
|-
| '''p'''
|
|
| Private channel—listed in channel list as "prv" according to <nowiki>RFC 1459</nowiki>
|-
| '''n'''
|
|
| Users cannot send messages to the channel externally
|-
| '''m'''
|
|
| Channel is moderated (only those who hold operator or voice status on the channel can send messages to it)
|-
| '''i'''
|
|
| Only users with invites may enter the channel.
|-
| '''t'''
|
|
| Only operators can change the channel topic.
|-
| '''l'''
|
| Limit number
| Limits number of users able to be on channel (when full, no new users can join)
|-
| '''b'''
|
| Ban mask (nick!user@host with wildcards allowed)
| Bans [[hostmask]]s from channel
|-
| '''v''' 
| +
| Name of affected user
| Gives a user voice status on channel (see +m above)
|-
| '''k'''
|
| New channel key
| Sets 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.<ref>{{cite web
| url = http://www.alien.net.au/irc/usermodes.html
| title = IRC User Modes List
| accessdate = 2011-04-10
| last = Butcher
| first = Simon
| date = 2005-01-12
| publisher = alien.net.au
}}</ref><ref>{{cite web
| url = http://www.alien.net.au/irc/chanmodes.html
| title = IRC Channel Modes List
| accessdate = 2011-04-10
| last = Butcher
| first = Simon
| date = 2005-01-12
| publisher = alien.net.au
}}</ref><ref>{{cite web
| url = http://www.alien.net.au/irc/servermodes.html
| title = IRC Server Modes List
| accessdate = 2011-04-10
| last = Butcher
| first = Simon
| date = 2005-01-12
| publisher = alien.net.au
}}</ref><ref>{{cite web
| url = http://webtoman.com/opera/panel/ircdmodes.html
| title = IRCd Modes
| accessdate = 2011-04-10
| last = Olsen
| first = Tommy
| publisher = webtoman.com
}}</ref>

===Channel Operators===
A ''Channel Operator'' is a [[Client (computing)|client]] on an [[IRC channel]] that manages the channel.
IRC Channel Operators can be easily seen by a symbol "@", or a Latin letter "+o"/"o".
On most networks, an operator can:
* Kick a user
* Ban a user
* Give another user IRC Channel Operator Status or IRC Channel Voice Status.
* Change the IRC Channel topic.
* Change the IRC Channel Mode locks.

===IRC Operators===
{{main|Internet Relay Chat operator}}
There are also users who maintain elevated rights on their local server, or the entire network; these are called IRC operators,<ref name="rfc 1459 1.2.1 operators">{{cite IETF
| rfc = 1459
| sectionname = Operators
| section = 1.2.1
| page = 5
| idanchor = ietf
}}</ref> sometimes shortened to IRCops or Opers (not to be confused with channel operators). As the implementation of the IRCd varies, so do the privileges of the IRC operator on the given IRCd. RFC 1459<ref name="rfc 1459 1.2.1 operators" /> claims that IRC operators are "a necessary evil" to keep 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 IPs or complete subnets. Networks that carry services (Nickserv et al.) usually allow their IRC operators also to handle basic "Ownership" matters. Further privileged rights may include overriding channel bans (being able to join channels they would not be allowed to join, if they were not opered), 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 (computing)|client]] connected to an IRC [[Server (computing)|server]].<ref name="thiedeke-2003">{{cite book
| last = Thiedeke
| first = Udo
| title = Virtuelle Gruppen: Charakteristika und Problemdimensionen
| url = http://books.google.com/?id=aQ74THYRyYsC&lpg=PA314&pg=PA315#v=onepage&q=hostmask
| accessdate = 2010-03-30
| edition = 2nd
| date = 2003-09-23
| publisher = {{Ill|de|Springer VS}}
| language = German
| isbn = 3-531-33372-0
| pages = 314, 337
| chapter = Nicola Döring, Alexander Schestag
}}</ref><ref name="rogers-2005">{{cite book
| last = Rogers
| first = Russ
| editor-last = Devost
| editor-first = Matthew G.
| title = Hacking a Terror Network: The Silent Threat of Covert Channels
| url = http://books.google.com/books?id=e3ggsGgTzUgC&lpg=PA10&pg=PA10#v=onepage&q=Hostmask%20IRC
| accessdate = 2010-03-30
| edition = 1st
| date = 2004-12-01
| publisher = [[Syngress Publishing]]
| location = [[Rockland, Massachusetts]]
| isbn = 1-928994-98-9
| page = 10
| chapter = The Mind of Terror
}}</ref> IRC [[IRCd|server]]s, [[Internet Relay Chat services|services]], and other clients including [[Internet Relay Chat bot|bots]] can use it to identify a specific IRC session.

The format of a hostmask is <code>nick!user@host</code>. 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 protocol|ident]] on the client.<ref name="petersen-2002">{{cite book
| editor-last = Petersen
| editor-first = Julie K.
| title = The Telecommunications Illustrated Dictionary
| url = http://books.google.com/books?id=b2mMzS0hCkAC&lpg=PA500&pg=PA500#v=onepage&q=Hostmask
| accessdate = 2010-03-30
| edition = 2nd
| date = 2002-05-29
| publisher = [[CRC Press]]
| isbn = 0-8493-1173-X
| page = 500
| chapter = Internet Relay Chat
}}</ref> If ident is not available on the client, the username specified when the client connected is used after being prefixed with a [[tilde]].<ref name="freenode faq">{{cite web
| url = http://freenode.net/faq.shtml
| title = Frequently-Asked Questions
| accessdate = 2010-03-30
| publisher = [[freenode]]
}}</ref>

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 [[IRCd|IRC daemons]] also provide privacy features, such as InspIRCD or UnrealIRCD's "+x" mode. This [[Cryptographic hash function|hashes]] a client IP address or masks part of a client's hostname, making it unreadable to users other than [[Internet Relay Chat#IRC Operators|IRCops]]. Users may also have the option of requesting a "virtual host" (or "vhost"), 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.<ref>{{cite web
| url = http://meta.wikimedia.org/wiki/IRC/Cloaks
| title = IRC/Cloaks
| accessdate = 2011-11-27
| publisher = [[Wikimedia]]
}}</ref>

==Challenges==
Issues in the original design of IRC were the amount of shared state data<ref>{{cite IETF
| rfc = 1324
| sectionname = Size
| section = 2.5.1
| pages = 5{{spaced ndash}}6
| idanchor = ietf
}}</ref><ref>{{cite IETF
| rfc = 2810
| sectionname = Scalability
| section = 6.1
| page = 7
| idanchor = ietf
}}</ref> being a limitation on its scalability,<ref>{{harvnb|Loesch|2003}} 1.2.1 Growth</ref> the absence of unique user identifications leading to the nickname collision problem,<ref>{{cite IETF
| rfc = 1324
| sectionname = User identification
| section = 5.4.1
| page = 10
| idanchor = ietf
}}</ref> lack of protection from netsplits by means of cyclic routing,<ref>{{cite IETF
| rfc = 1324
| sectionname = Trees and cycles
| section = 5.4.2
| page = 10
| idanchor = ietf
}}</ref><ref>{{harvnb|Loesch|2003}} 1.2.2 Network failures</ref> the trade-off in scalability for the sake of real-time user presence information,<ref>{{cite IETF
| rfc = 1324
| sectionname = State Information problems
| section = 2.1
| page = 4
| idanchor = ietf
}}</ref> protocol weaknesses providing a platform for abuse,<ref>{{harvnb|Loesch|2003}} 1.2.3 Sociological and security aspects</ref> no transparent and optimizable message passing,<ref>{{cite IETF
| rfc = 1324
| sectionname = Message passing
| section = 5.2.1
| page = 7
| idanchor = ietf
}}</ref> and no encryption.<ref>{{cite IETF
| rfc = 1324
| sectionname = Conference security
| section = 5.2.4
| page = 8
| idanchor = ietf
}}</ref> Some of these issues have been addressed in ''Modern IRC''.

===Attacks===
Because IRC connections are usually unencrypted and typically span long time periods, they are an attractive target for [[Denial-of-service attack|Dos/DDoS attackers]] and [[Hacker (computer security)|hackers]]. Because of this, careful security policy is necessary to ensure that an IRC network is not susceptible to an attack such as a [[Internet Relay Chat takeover|takeover]] war. IRC networks may also [[K-line (IRC)|K-line]] or [[G-line]] users or networks that have a harming effect.

A small number of IRC servers support [[Transport Layer Security|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 (that may require the user to install SSL binaries and IRC client specific patches or modules on their computers). Some networks also use SSL for server to server connections, and provide a special channel flag (such as <code>+S</code>) to only allow SSL-connected users on the channel, while disallowing operator identification in clear text, to better utilize the advantages that SSL provides.<ref>{{cite web
| url = http://esper.net/help.php
| title = Getting Help on EsperNet
| publisher = The EsperNet IRC Network
| accessdate = 2012-07-31
}}</ref><ref>{{cite web
| url = http://www.dal.net/news/shownews.php?id=67
| title = New Feature: SSL For Users
| author = brandon
| date = 2010-05-18
| publisher = DALnet
| accessdate = 2012-07-31
}}</ref>

IRC served as an early laboratory for many kinds of Internet attacks, such as using fake [[Internet Control Message Protocol|ICMP]] unreachable messages to break [[Transmission Control Protocol|TCP]]-based IRC connections ([[Nuke (computer)|nuking]]) to annoy users or facilitate [[Internet Relay Chat takeover|takeover]]s.

===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 attack]]s, 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 (i.e., 'nick-collision').
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 [[netsplit]]s, 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, 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{{spaced ndash}}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 lost 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" (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 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.

====SAVE====
In recent versions of the IRCnet ircd, as well as ircds using the TS6 protocol (including Charybdis), ND has been extended/replaced by a mechanism called SAVE. This mechanism assigns every client a unique UID upon connecting to an IRC server. This ID starts with a number, which is forbidden in nicks (although some ircds, namely IRCnet and InspIRCd, allow clients to switch to their own UID as the nickname).

If two clients with the same nickname join from different sides of a netsplit ("nick collision"), 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 (ND) to prevent both clients from changing back to the original nickname, thus colliding again.

==Networks==
[[File:Tolsun 2.jpg|thumb|right|The first IRC server, tolsun.oulu.fi, a [[Sun-3]] server on display near the [[University of Oulu]] computer centre. (2001)]]

There are thousands of running IRC networks in the world. They run various implementations of [[IRC server]]s, and are administered by various groups of [[IRC operator]]s, but the protocol exposed to IRC users is very similar, and all IRC networks can be accessed by the same client software, although there might be slight incompatibilities and limited functionality due to the differing server software implementations.

The largest IRC networks have traditionally been grouped as the "Big Four"<ref name="the book of irc">{{cite book
| last = Charalabidis
| first = Alex
| title = The Book of IRC: The Ultimate Guide to Internet Relay Chat
| edition = 1st
| date = 1999-12-15
| publisher = No Starch Press
| location = [[San Francisco, California]]
| isbn = 1-886411-29-8
| page = 61
| chapter = IRCing On The Macintosh: Ircle
| quote = On large networks such as the Big Four{{mdash}} EFnet, IRCnet, Undernet, and DALnet{{mdash}} trying to list the thousands of channels with Ircle always causes you to disconnect due to the flood of information, while other clients can usually manage the feat, if you are on a direct Ethernet connection.
}}</ref><ref name="encyclopedia of new media">{{cite book
| editor-last = Jones
| editor-first = Steve
| title = Encyclopedia of New Media: An Essential Reference to Communication and Technology
| edition = 1st
| date = 2002-12-10
| publisher = [[SAGE Publications]]
| location = [[Thousand Oaks, California]]
| isbn = 0-7619-2382-9
| page = 257
| chapter = Internet Relay Chat
| quote = Today there are hundreds of independent IRC networks, but the "Big Four" are EFNet, UnderNet, Dalnet, and IRCnet.
}}</ref><ref name="the imac book">{{cite book
| last = Rittner
| first = Don
| title = The iMac Book
| edition = 1st
| date = 1999-03-03
| publisher = Coriolis Group
| location = [[Scottsdale, Arizona]]
| isbn = 1-57610-429-X
| page = 215
| chapter =
| quote = There are several large networks: EFnet, UnderNET, DALnet, and IRCnet make up the Big Four.
}}</ref><ref name="information technology for management">{{cite book
| last1 = Turban
| first1 = Efraim
| last2 = Leidner
| first2 = Dorothy
| last3 = McLean
| first3 = Ephraim
| last4 = Wetherbe
| first4 = James
| title = Information Technology for Management: Transforming Organizations in the Digital Economy
| edition = 5th
| date = 2005-02-07
| publisher = [[John Wiley & Sons]]
| location = [[Hoboken, New Jersey]]
| isbn = 0-471-70522-5
| pages = 106{{spaced ndash}}107
| chapter = Communication
| quote = The largest networks have traditionally been grouped as the "Big Four": EFNet, IrcNet, QuakeNet, and UnderNet.
}}</ref>{{mdash}} 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:<ref name="the book of irc" /><ref name="encyclopedia of new media" /><ref name="the imac book" />
* [[EFnet]]
* [[IRCnet]]
* [[Undernet]]
* [[DALnet]]

IRC reached 6 million simultaneous users in 2001 and 10 million users in 2003.{{citation needed|date=January 2015}}

As of March 2015 the largest IRC networks were:

* [[freenode]] – around 99k users at peak hours
* [[IRCNet]] – around 44k users at peak hours
* [[QuakeNet]] – around 36k users at peak hours
* [[EFnet]] – around 26k users at peak hours
* [[Undernet]] – around 25k users at peak hours
* [[rizon]] – around 25k users at peak hours

Today, the top 100 IRC networks have around [http://irc.netsplit.de/networks/top100.php 460k users connected at peak hours].

===Timeline===

{{Simple Horizontal timeline

|from=1990
|to=2014
|inc=2

|styleDefault-borderbottom=solid 0.1em black;

|row1=timeline
|row1-style=styleDefault
|row1-bordertop=solid 0.1em black;
|row1-1-color=#ffbb33
|row1-1-from=1990
|row1-1-to=2014
|row1-1-text=[[EFnet]]

|row2=timeline
|row2-style=styleDefault
|row2-1-from=1990
|row2-1-to=1992
|row2-2-to=2014
|row2-2-text=[[Undernet]]
|row2-2-color=#33b5e5

|row3=timeline
|row3-style=styleDefault
|row3-1-from=1990
|row3-1-to=1994
|row3-2-color=#cc0000
|row3-2-to=2014
|row3-2-text=[[DALnet]]

|row4=timeline
|row4-style=styleDefault
|row4-1-from=1990
|row4-1-to=1995
|row4-2-color=#aa66cc
|row4-2-to=2014
|row4-2-text=[[freenode]]

|row5=timeline
|row5-style=styleDefault
|row5-1-from=1990
|row5-1-to=1997
|row5-2-color=#99cc00
|row5-2-to=2014
|row5-2-text=[[IRCnet]]

|row6=timeline
|row6-style=styleDefault
|row6-1-from=1990
|row6-1-to=1997
|row6-2-color=#ff4444
|row6-2-to=2014
|row6-2-text=[[QuakeNet]]

|row7=timeline
|row7-1-from=1990
|row7-1-to=2002
|row7-2-color=#ff44ff
|row7-2-to=2014
|row7-2-text=[[Rizon]]

|row8=scale
|caption=IRC networks
}}

==URI scheme==
There are three recognized [[URI scheme]]s for Internet Relay Chat, irc, irc6, and ircs,<ref>{{cite web
| url = http://www.iana.org/assignments/uri-schemes.html
| title = Uniform Resource Identifier (URI) Schemes
| publisher = Internet Assigned Numbers Authority | accessdate = 2012-10-14
}}</ref> that (when supported) allows [[hyperlink]]s of various forms, including
<nowiki>irc://<host>[:<port>]/[<channel>[?<channel_keyword>]]</nowiki>
(where items enclosed within brackets ([,]) are optional) to be used to (if necessary) connect to the specified host (or network, if known to the IRC client) and join the specified channel.<ref>{{cite IETF
| title = Uniform Resource Locator Schemes for Internet Relay Chat Entities
| draft = draft-butcher-irc-url-04
| last = Butcher
| first = Simon
| year = 2003
| month = January
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2011-04-10
}}</ref> (This can be used within the client itself, or from another application such as a Web browser). 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 (for example, mIRC) will do so ''unconditionally'' resulting in a (usually unintended) extra (for example, ##channel), if included in the URL.

Some implementations allow multiple channels to be specified, separated by commas.{{Citation needed|date=April 2011}}

==Clients==

===Client software===
{{Details|Comparison of Internet Relay Chat clients}}
[[File:Ircnetz-Schema.svg|right|thumb|Scheme of an IRC network with [[Client (computing)|normal clients]] (green), [[IRC bot|bots]] (blue) and [[Bouncer (networking)|bouncers]] (orange)]]

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 [[Microsoft Windows|Windows]], [[Unix]] & [[Linux]], [[Mac OS X]] and mobile operating systems (such as [[iOS]] and [[Android (operating system)|Android]]). On Windows, [[mIRC]] is one of the most popular clients.<ref>{{cite book|last=Smith|first=Roderick W.|title=The Multi-Boot Configuration Handbook| url= http://books.google.com/books?id=OuPtI5fHhBoC|accessdate=2010-07-25|series= Handbook Series| date= 2000-04-08| publisher= [[Que Publishing]]| location= [[Upper Saddle River, New Jersey]]|isbn= 0-7897-2283-6|page=289|chapter=The Internet: Using IRC to Get Help|quote= mIRC is one of the most popular Windows IRC clients.}}</ref>

Some programs which are extensible through [[plug-in (computing)|plug-ins]] also serve as platforms for IRC clients. For instance, a client called [[ERC (software)|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 browser]]s have built in IRC clients, such as [[Opera (Web browser)|Opera]] ([[Features of the Opera web browser#Legacy features|version 12.17 and earlier]])<ref>{{cite web| url=http://operawiki.info/OperaIRC| title = Opera Browser Wiki: IRC Client| accessdate = 2011-04-10}}</ref> or the [[ChatZilla]] add-on for Mozilla [[Firefox]] (included as a built-in component of [[SeaMonkey]]). Web-based clients, such as [[Mibbit]] and open source [[KiwiIRC]], can run in most browsers.

Games such as ''[[War§ow]]'',<ref>{{cite web
| url = http://www.warsow.net/wiki/index.php?title=IRC_Module
| title = Warsow Wiki: IRC Module
| accessdate = 2011-04-10
}}</ref> ''[[Unreal Tournament]]'' (up to [[Unreal Tournament 2004]]),<ref>{{cite web
| url = http://www.bcchardware.com/index.php?option=com_content&task=view&id=35&Itemid=40
| title = UT2004 Review
| accessdate = 2011-04-10
| last = Guenter
| first = Daniel
| date = 2004-06-21
| publisher = BCCHardware
}}</ref> ''[[Uplink (video game)|Uplink]]'',<ref>{{cite web
| url = http://guide.modlink.net/section11.php
| title = The Ultimate Uplink Guide
| accessdate = 2011-04-10
}}</ref> ''[[Spring Engine]]''-based games, [[0 A.D. (video game)|0 A.D.]] and ''[[ZDaemon]]'' have included IRC.<ref>{{cite web
| url = http://doomwiki.org/wiki/ZDaemon#Other_utilities
| title = ZDaemon – The Doom Wiki: Other utilities
| accessdate = 2011-04-10
}}</ref>

[[Ustream]]'s chat interface is [[IRC]] with custom authentication<ref>{{cite web
| url = http://ustream-helpers.com/how-to/ircclient
| title = How to setup an IRC client to connect and login to Ustream
| accessdate = 2013-04-27
| date = 2012-01-29
| publisher = Ustream-Helpers
}}</ref> as well as [[Justin.tv]]'s.<ref>{{cite web
| url = http://www.liquidsilver.org/2010/06/ustream-v-justin/
| title = Ustream vs. Justin.tv
| accessdate = 2011-07-13
| date = 2010-06-20
| publisher = LiquidSilver
| author = Mauldor
}}</ref>

===Bots===
{{Main|IRC bot}}

A typical use of bots in IRC is to provide [[Internet Relay Chat services|IRC services]] or a specific functionality within a channel such as to host a chat-based game or provide notifications of external events.

===Bouncer===
{{Main|BNC (software)}}
A program that runs as a [[daemon (computer software)|daemon]] on a [[Server (computing)|server]] and functions as a persistent [[proxy server|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.{{Citation needed|date=April 2011}} Should the client lose network connectivity, the BNC may stay connected and archive all traffic for later delivery, allowing the user to resume his IRC session without disrupting their connection to the server.<ref>{{cite web
| url = http://www.psybnc.at/readme.txt
| title = psyBNC Readme
| accessdate = 2011-04-10
| publisher = psybnc.at
}}</ref>

Furthermore, as a way of obtaining a bouncer-like effect, an IRC client (typically [[text-based]], for example [[Irssi]]) may be run on an always-on server to which the user connects via [[secure shell|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.<ref>{{cite web
| url = http://chriscarey.com/wordpress/2009/07/18/irc-with-irssi-proxy-screen/
| title = IRC with irssi-proxy + screen
| accessdate = 2011-04-10
| last = Carey
| first = Chris
| date = 2009-07-18
| publisher = chriscarey.com
}}</ref>

To keep the IRC client from quitting when the ssh connection closes, the client can be run inside a piece of screen-detaching software (e.g. [[GNU Screen]] or [[tmux]]), thus staying connected to the IRC network(s) constantly and able to log conversation in channels that the user is interested in, etc. Modelled after this setup, in 2004 an IRC client following the [[client-server]] model, called [[Smuxi]], has been launched.<ref>{{cite web
| url = http://www.smuxi.org/blog/show/Detachable_Frontend_Core_Rewrite__UML__Windows_Port_kicking_Glade
| title = Detachable Frontend (Core Rewrite) / UML / Windows Port (kicking Glade)
| accessdate = 2010-07-25
| date = 2004-12-25
| publisher = smuxi.org
}}</ref><ref>{{cite web
| url = http://www.smuxi.org/page/About
| title = About Smuxi
| accessdate = 2011-04-10
| publisher = smuxi.org
}}</ref>

==Search engines==
There are numerous search engines available to aid the user in finding what they are looking for on IRC.<ref>{{cite book
| last = Mutton
| first = Paul
| title = IRC Hacks
| edition = 1st
| date = 2004-07-27
| publisher = [[O'Reilly Media]]
| location = [[Sebastopol, California]]
| isbn = 0-596-00687-X
| pages = 44{{spaced ndash}}46
| chapter = Users and Channels
}}</ref><ref>{{cite book
| last = Wang
| first = Wallace
| title = Steal this File Sharing Book
| edition = 1st
| date = 2004-10-25
| publisher = [[No Starch Press]]
| location = [[San Francisco, California]]
| isbn = 1-59327-050-X
| pages = 65{{spaced ndash}}67
| chapter = Instant Messaging and Online Chat Rooms: Internet Relay Chat (IRC)
}}</ref> Generally the search engine consists of two parts, a "back-end" (or "spider/crawler") and a front-end "search engine".

The back-end (spider/crawler) 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 database|Oracle]].{{Citation needed|date=January 2010}}

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.{{Citation needed|date=August 2009}}

Many users have implemented their own [[ad hoc]] search engines using the logging features built into many IRC clients.

==Modern IRC==
IRC has changed much over its life on the Internet. New server software has added a multitude of new features.
* [[IRC services|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 attack]]s.{{Citation needed|date=January 2010}}
* Proxy detection: Most modern servers support detection of users attempting to connect through an insecure (misconfigured or exploited) [[proxy server]], which can then be denied a connection. An example is the [http://www.blitzed.org/proxy Blitzed Open Proxy Monitor] or BOPM. This proxy detection software is used by several networks, although that real time list of proxies is defunct since early 2006.{{Citation needed|date=January 2010}}
* 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.{{Citation needed|date=January 2010}}
* [[Encryption]]: For the client-to-server leg of the connection [[Secure Sockets Layer|SSL]] might be used (messages cease to be secure once they are relayed to other users on standard connections, but it makes [[Man-in-the-middle attack|eavesdropping]] on or wiretapping an individual's IRC sessions difficult). For client-to-client communication, [[Secure Direct Client-to-Client|SDCC]] (Secure DCC) can be used.{{Citation needed|date=January 2010}}
* 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.

There is an effort of standardization and adding new features to the IRC protocol by IRCv3 working group.<ref>{{cite web
| url = http://www.ircv3.org/
| title = IRCv3 Working Group
| accessdate = 2014-03-08
}}</ref>

==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{{Clarify|date=July 2009}} transfer messages from a client to another client just as byte sequences, without any interpretation or recoding of [[character (computing)|characters]]. The IRC protocol (unlike e.g. [[MIME]] or [[HTTP]]) 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 particular [[Unix]] derivatives) in the respective language communities:

* '''7-bit era:''' In the early days of IRC, especially among [[North Germanic languages|Scandinavian]] and [[Finnish language]] users, national variants of [[ISO 646]] were the dominant [[character encoding]]s. These encode non-ASCII characters like Ä Ö Å ä ö å at code positions 0x5B 0x5C 0x5D 0x7B 0x7C 0x7D ([[US-ASCII]]: '''[''' '''\''' ''']''' '''{''' '''|''' '''}'''). That is why these codes are always allowed in nicknames. According to RFC 1459, { | } in nicknames should be treated as lowercase equivalents of [ \ ] respectively.<ref name="rfc 1459 2.2 character codes" /> By the late 1990s, the use of 7-bit encodings had disappeared in favour of [[ISO 8859-1]], and such equivalence mappings were dropped from some IRC daemons.

* '''8-bit era:''' Since the early 1990s, 8-bit encodings such as [[ISO 8859-1]] have become commonly used for European languages. Russian users had a choice of [[KOI8-R]], [[ISO 8859-5]]{{Citation needed|date=October 2008}} and [[CP1251]], and since about 2000, modern Russian IRC networks convert between these different commonly used encodings of the [[Cyrillic script]].

* '''Multi-byte era:''' For a long time, East Asian IRC channels with ideographic scripts in China, Japan, and Korea have been using multi-byte encodings such as [[Extended Unix Code|EUC]] or [[ISO-2022-JP]]. With the common migration from ISO 8859 to UTF-8 on Linux and Unix platforms since about 2002, [[UTF-8]] has become an increasingly popular substitute for many of the previously used 8-bit encodings in European channels. Some IRC clients are now capable of reading messages both in ISO 8859-1 or UTF-8 in the same channel, heuristically autodetecting which encoding is used. The shift to UTF-8 began in particular on Finnish-speaking IRC ([[:fi:IRC#Merkistö|Merkistö]] (Finnish)).

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 bytes 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 [[Peer-to-peer|P2P]] file sharing, users can create file servers that allow them to share files with each other by using customised [[IRC bot]]s or scripts for their [[IRC client]]. Often users will group together to distribute [[warez]] via a network of IRC bots.<ref>{{cite web
| url = http://www.zdnet.com/news/pirated-movies-now-playing-on-a-server-near-you/122663
| title = Pirated movies: Now playing on a server near you
| accessdate = 2011-04-10
| last = Vamosi
| first = Robert
| date = 2002-05-08
| publisher = [[ZDNet]]
}}</ref>

Technically, IRC provides no [[file transfer]] mechanisms itself; file sharing is implemented by IRC ''clients'', typically using the [[Direct Client-to-Client]] (DCC) 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.<ref>{{cite web
| url = http://www.macobserver.com/tip/2002/04/04.1.shtml
| title = IRC 101: What Is It & How Do I Use It?
| accessdate = 2011-04-10
| last = Sasaki
| first = Darla
| date = 2002-04-04
| publisher = Macobserver.com
}}</ref> 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.

==See also==
{{Portal|Internet Relay Chat}}
* [[Chat room]]
* [[Client-to-client protocol]]
* [[Comparison of instant messaging protocols]]
* [[Comparison of IRC clients]]
* [[Comparison of IRC daemons]]

* [[Internet slang]]
* [[List of IRC commands]]
* [[Serving channel]]
* [[The Hamnet Players]]

==References==
{{reflist|30em}}

==Bibliography==
* {{cite IETF
| title = A Discussion on Computer Network Conferencing
| rfc = 1324
| last = Reed
| first = Darren
| year = 1992
| month = May
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
| ref = ietf
}}
* {{cite IETF
| title = Internet Relay Chat Protocol
| rfc = 1459
| last1 = Oikarinen
| first1 = Jarkko
| authorlink1 = Jarkko Oikarinen
| last2 = Reed
| first2 = Darren
| year = 1993
| month = May
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
| ref = ietf
}}
* {{cite IETF
| title = Internet Relay Chat: Architecture
| rfc = 2810
| last = Kalt
| first = Christophe
| year = 2000
| month = April
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
| ref = ietf
}}
* {{cite IETF
| title = Internet Relay Chat: Channel Management
| rfc = 2811
| last = Kalt
| first = Christophe
| year = 2000
| month = April
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
| ref = ietf
}}
* {{cite journal
| last = Loesch
| first = Carl
| date = 2003-07-17
| title = Functionality Provided by Systems for Synchronous Conferencing
| publisher = psyc.eu
| url = http://www.psyc.eu/synconf
| accessdate = 2011-04-10
| ref = harv
}}

==Further reading==
* {{cite IETF
| title = Internet Relay Chat: Client Protocol
| rfc = 2812
| last = Kalt
| first = Christophe
| year = 2000
| month = April
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
}}
* {{cite IETF
| title = Internet Relay Chat: Server Protocol
| rfc = 2813
| last = Kalt
| first = Christophe
| year = 2000
| month = April
| publisher = [[Internet Engineering Task Force|IETF]]
| accessdate = 2009-10-30
}}
* {{cite web
| url = http://www.ibiblio.org/pub/academic/communications/logs/
| title = Logs of major events in the online community
| accessdate = 2011-04-08
| publisher = [[ibiblio]]
| location = [[Chapel Hill, North Carolina]]
}}
* {{cite web
| url = http://www.alien.net.au/irc/
| title = IRC technical information
| accessdate = 2011-04-10
| last = Butcher
| first = Simon
| publisher = alien.net.au
}}

==External links==
{{Wikibooks|Internet Technologies|IRC}}
{{Commons category|IRC}}
* {{Dmoz|Computers/Internet/Chat/IRC|IRC}}
* [http://www.alien.net.au/irc/irc2numerics.html IRC/2 Numerics List]
* [http://www.irc.org/history.html History of IRC]
* [http://www.irc.org/ IRC.org] – Technical and Historical IRC6 information; Articles on the history of IRC
* [http://www.irchelp.org/ IRChelp.org] – Internet Relay Chat (IRC) help archive; Large archive of IRC-related documents
* [http://www.ircv3.org/ IRCv3] – Working group of developers, who add new features to the protocol and write specs for them

{{IRC topics}}
{{URI scheme}}
{{Computer-mediated communication}}

[[Category:Internet Relay Chat| ]]
[[Category:Application layer protocols]]
[[Category:Finnish inventions]]
[[Category:Internet terminology]]
[[Category:Virtual communities]]
[[Category:1988 introductions]]