Editing IRC (section)

==Technical information==
{{See also|IRCd}}
[[File:Hexchat 2.16.0 screenshot.png|right|thumb|A screenshot of [[HexChat]], an IRC client for [[GTK]] environments]]
[[File:Irssi 1.2.3 screenshot.png|right|thumb|[[Irssi]], a text-based IRC client]]
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
|title=Internet Relay Chat Protocol
| 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
|title=Internet Relay Chat: Architecture
| 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 [[Nickname#Computing|nickname]] is required before being connected.<ref>{{cite IETF
| rfc         = 1459
|title=Internet Relay Chat Protocol
| 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|date=6 April 2011|title=Port Numbers|url=https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=5|access-date=5 April 2021|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
|title=Internet Relay Chat Protocol
| 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        = 5 October 2006
| publisher   = Syngress Publishing
| location    = [[Rockland, Massachusetts]]
| isbn        = 978-1-59749-088-7
| 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
|title=Internet Relay Chat Protocol
| 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
|date=June 1998
| publisher   = [[Internet Engineering Task Force|IETF]]
| access-date  = 8 April 2011
}}</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
|title=Internet Relay Chat: Architecture
| sectionname = Architecture
| section     = 3
| pages       = 3 – 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
|title=Internet Relay Chat: Architecture
| sectionname = Introduction
| section     = 1
| page        = 2
| idanchor    = ietf
}}</ref> and there is generally a high degree of implicit trust between servers. However, this architecture has a number of problems. A misbehaving or malicious server can cause major damage to the network<ref>{{cite IETF
| rfc         = 1459
|title=Internet Relay Chat Protocol
| 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
|title=Internet Relay Chat: Architecture
| sectionname = Network Congestion
| section     = 6.3
| pages       = 7 – 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
|title=Internet Relay Chat: Architecture
| sectionname = To A Channel
| section     = 5.2.1
| pages       = 5 – 6
| idanchor    = ietf
}}</ref> This is a strength in comparison to non-multicasting protocols such as [[Simple Mail Transfer Protocol]] (SMTP){{Citation needed|date=July 2007}} or [[Extensible Messaging and Presence Protocol]] (XMPP){{Citation needed|date=July 2007}}.

An IRC daemon can be used on a local area network (LAN). IRC can thus be used to facilitate communication between people within the local area 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|access-date=2 October 2014}}</ref><ref>{{cite web|url=http://www.irc-wiki.org/IRC_server|title=Running an own IRC server|access-date=2 October 2014}}</ref>

===Commands and replies===
{{Main|List of Internet Relay Chat commands}}
IRC has a line-based structure. Clients send single-line messages to the server,<ref>{{cite IETF
| rfc         = 1459
|title=Internet Relay Chat Protocol
| sectionname = Message format in 'pseudo' BNF
| section     = 2.3.1
| page        = 8
| idanchor    = ietf
}}</ref> receive replies to those messages<ref>{{cite IETF
| rfc         = 1459
|title=Internet Relay Chat Protocol
| sectionname = Numeric replies
| section     = 2.4
| page        = 10
| idanchor    = ietf
}}</ref> and receive copies of some messages sent by other clients. In most clients, users can enter commands by prefixing them with a '/'. Depending on the command, these may either be handled entirely by the client, or (generally for commands the client does not recognize) passed directly to the server, possibly with some modification.<ref>[https://www.disabled-world.com/communication/irc-chat.php IRC Chat Rooms]</ref>

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
| access-date  = 8 April 2011
| date        = 25 November 2009
}}</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
|title=Internet Relay Chat Protocol
| 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
|title=Internet Relay Chat Protocol
| 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
|title=Internet Relay Chat Protocol
| 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
|title=Internet Relay Chat: Channel Management
| sectionname = Channel Scope
| section     = 2.2
| pages       = 3 – 4
| idanchor    = ietf
}}</ref> Other less common channel types include '+' channels—'modeless' channels without operators<ref>{{cite IETF
| rfc         = 2811
|title=Internet Relay Chat: Channel Management
| sectionname = Channel Properties
| section     = 2.3
| page        = 4
| idanchor    = ietf
}}</ref>—and '!' channels, a form of [[#delay|timestamped]] channel on normally non-timestamped networks.<ref>{{cite IETF
| rfc         = 2811
|title=Internet Relay Chat: Channel Management
| sectionname = Channel lifetime
| section     = 3
| page        = 5
| idanchor    = ietf
}}</ref>

===Modes===
Users and channels may have ''modes'' that are represented by individual case-sensitive letters<ref>{{cite IETF
| rfc         = 2811
|title=Internet Relay Chat: Channel Management
| sectionname = Channel Modes
| section     = 4
| page        = 7
| idanchor    = ietf
}}</ref> and are set using the ''MODE'' command.<ref>{{cite IETF
| rfc         = 1459
|title=Internet Relay Chat Protocol
| 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. user mode "i" is invisible mode while channel mode "i" is invite only.<ref>{{cite IETF
| rfc         = 1459
|title=Internet Relay Chat Protocol
| sectionname = Channel modes
| section     = 4.2.3.1
| pages       = 21 – 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 channel modes take parameters and other 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
|title=Internet Relay Chat: Channel Management
| sectionname = Channel Access Control
| section     = 4.3
| pages       = 10 – 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
|title=Internet Relay Chat Protocol
| 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
| access-date  = 10 April 2011
| last        = Roeckx
| first       = Kurt
| date        = 14 October 2004
| publisher   = irc.org
}}</ref><ref>{{cite IETF
| title       = IRC RPL_ISUPPORT Numeric Definition
| draft       = draft-brocklesby-irc-isupport-03
| last        = Brocklesby
| first       = Edward
|date=September 2002
| publisher   = [[Internet Engineering Task Force|IETF]]
| access-date  = 10 April 2011
}}</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 see the mode with less priority (i.e. voice). Workarounds for this are possible on both the client and server side; a common solution is to use IRCv3 "multi-prefix" extension.<ref>{{cite web |url=https://ircv3.net/specs/extensions/multi-prefix |title='multi-prefix' Extension - IRCv3}}</ref>

====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
|title=Internet Relay Chat Protocol
| 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 channel operator or voice status on the channel can send messages to it)
|-
| '''i'''
|
|
| Only users with invites may enter the channel.
|-
| '''t'''
|
|
| Only channel 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''' <!-- That does belong here with the channel modes. It's not a user mode -->
| +
| 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
| access-date  = 10 April 2011
| last        = Butcher
| first       = Simon
| date        = 12 January 2005
| publisher   = alien.net.au
}}</ref><ref>{{cite web
| url         = http://www.alien.net.au/irc/chanmodes.html
| title       = IRC Channel Modes List
| access-date  = 10 April 2011
| last        = Butcher
| first       = Simon
| date        = 12 January 2005
| publisher   = alien.net.au
}}</ref><ref>{{cite web
| url         = http://www.alien.net.au/irc/servermodes.html
| title       = IRC Server Modes List
| access-date  = 10 April 2011
| last        = Butcher
| first       = Simon
| date        = 12 January 2005
| publisher   = alien.net.au
}}</ref><ref>{{cite web
 |url          = http://webtoman.com/opera/panel/ircdmodes.html
 |title        = IRCd Modes
 |access-date   = 10 April 2011
|last         = Olsen
 |first        = Tommy
 |publisher    = webtoman.com
 |archive-url  = https://web.archive.org/web/20111015190740/http://webtoman.com/opera/panel/ircdmodes.html
 |archive-date = 15 October 2011
|url-status   = dead
}}</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 the symbol or icon next to their name (varies by client implementation, commonly a "@" symbol prefix, a green circle, 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 while channel mode +t is set.
* Change the IRC Channel Mode locks.

===Operators===
{{main|IRC 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
|title=Internet Relay Chat Protocol
| 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 a clean state of the network, and as such they need to be able to disconnect and reconnect servers. Additionally, to prevent malicious users or even harmful automated programs from entering IRC, IRC operators are usually allowed to disconnect clients and completely ban IP addresses or complete subnets. Networks that carry services (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
| editor-last1        = Thiedeke
| editor-first1       = Udo
| last1               = Döring
| first1              = Nicola 
| last2               = Schestag
| first2              = Alexander 
| title       = Virtuelle Gruppen: Charakteristika und Problemdimensionen
| chapter-url         = https://books.google.com/books?id=aQ74THYRyYsC&q=hostmask&pg=PA315
| access-date  = 30 March 2010
| edition     = 2nd
| date        = 23 September 2003
| publisher   = {{Interlanguage link|Springer VS|de}}
| language    = de
| isbn        = 978-3-531-33372-4
| pages       = 314, 337
| chapter     = Soziele Norman in virtuellen Gruppen: ein empirische Analyse am Beispiel ausghewähiter Chat-Channels
}}</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
| chapter-url         = https://books.google.com/books?id=e3ggsGgTzUgC&q=Hostmask+IRC&pg=PA10
| access-date  = 30 March 2010
| edition     = 1st
| date        = 1 December 2004
| publisher   = Syngress Publishing
| location    = [[Rockland, Massachusetts]]
| isbn        = 978-1-928994-98-5
| page        = 10
| chapter     = The Mind of Terror
}}</ref> IRC [[IRCd|servers]], [[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
| chapter-url         = https://books.google.com/books?id=b2mMzS0hCkAC&q=Hostmask&pg=PA500
| access-date  = 30 March 2010
| edition     = 2nd
| date        = 29 May 2002
| publisher   = [[CRC Press]]
| isbn        = 978-0-8493-1173-4
| 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
| access-date         = 30 March 2010
| publisher         = [[freenode]]
| archive-url         = https://web.archive.org/web/20100326082146/http://freenode.net/faq.shtml
| archive-date         = 26 March 2010
| url-status         = dead
}}</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 [[#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 [[Libera Chat]] or [[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
| access-date = 27 November 2011
| publisher  = [[Meta-wiki]]
}}</ref>

===URI scheme===
There are three provisional recognized [[uniform resource identifier]] (URI) schemes for Internet Relay Chat: <code>irc</code>, <code>ircs</code>, and <code>irc6</code>.<ref>{{cite web
 | url        = https://www.iana.org/assignments/uri-schemes.html
 | title      = Uniform Resource Identifier (URI) Schemes
 | publisher  = Internet Assigned Numbers Authority | access-date = 14 October 2012
}}</ref> When supported, they allow [[hyperlink]]s of various forms, including
 <nowiki>irc://<host>[:<port>]/[<channel>[?<channel_keyword>]]</nowiki>
 <nowiki>ircs://<host>[:<port>]/[<channel>[?<channel_keyword>]]</nowiki>
 <nowiki>irc6://<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
|date=January 2003
| publisher   = [[Internet Engineering Task Force|IETF]]
| access-date  = 10 April 2011
}}</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.<ref>{{cite web |url=https://www.npmjs.com/package/node-irc |title=node-irc |website=npm |date=26 January 2020 |access-date=30 July 2021 }}</ref>