A Beginner's Guide to IRC
The short and quick version
IRC stands for Internet Relay Chat, an open protocol that lets people chat online in real-time.
To chat on IRC, you must first connect to a network. Each network is made up of many servers. To connect, you will need to download an IRC client. The IRC client will connect to a server on the network to communicate with other users.
After installing your preferred IRC Client, you may wish to request a bouncer with IRCNow to stay connected. The IRC clients page has instructions about how to do this.
Searching for IRC network to connect to
Because of the way IRC is designed, servers do not store messages for clients. They only relay those messages to clients. This means that when you disconnect, you can't receive any messages. For this reason, we recommend . Otherwise, you will lose messages whenever you disconnect.
On IRC, channels generally begin with the hashtag (#). On networks like Snoonet and Freenode, a single hashtag (like #ircnow) indicates an official channel, whereas two hashtags (like ##chat) is an unofficial channel. Channels beginning with an ampersand (&) are usable on one server only.
To create a channel, simply join it. The command is /join #channel. Notice how in IRC, a command always begins with "/". A channel is automatically created when the first user joins, and is destroyed when the last user leaves.
Every channel has its own operators, the people who help maintain order in a channel.
To send a message to a single user, type /msg <nickname> . This will create a private message, or PM for short.
Design of the IRC protocol
The beauty of IRC is that IRC is an open protocol that anyone can write software for. As a result, there is no official IRC client; there are instead hundreds. Here is a list of some of the most common IRC clients.
When you connect to IRC, you will be asked for the hostname and port of the server, as well as whether you want to use plaintext or SSL (a secured connection). The hostname will look something like irc.ircnow.org. The port will often be 6667 for plaintext and 6697 for SSL. Enabling SSL will ensure that your connection is secured by encryption. Make sure that you have the correct port and that you check if the port uses SSL or not. Using the wrong port and putting the incorrect setting for SSL is a huge cause of connection problems. It is not possible to use SSL on a port if the server doesn't support it.
Once you connect to a network, you can type /list. This will list all the visible channels on the network so you can find one to join.
What most users find surprising about IRC is that by design, you don't have to register to chat. You can pick any nickname/real name you want. The main benefit of this design is that you can be totally anonymous on IRC, something which is impossible on most social networks. As you might expect, however, this can be confusing and can lead to impersonation, harassment, and spam. As a result, many IRC networks encourage you to register and claim your nickname.
Unfortunately, IRC in its current state is very fragmented. There is no "One True Services" and so every single network implements its own services in a different and contradictory way. For now, we'll discuss the most common services implemented by Atheme and Anope, which uses Nickserv.
To interact with Nickserv, you send the message /msg Nickserv <command>, like /msg Nickserv help. This will show you all the options available to register a nick, reset a password, and so forth. Once you register a nick, you can then register a channel. To do so, type /msg Chanserv <command>, like /msg Chanserv help.
Joining and leaving and also managing channels
To leave a channel, type /part. To quit your IRC client, type /quit. To invite a user to your channel, type /invite nickname #channel.
To make another user a channel operator, type /mode +o nickname.
Sometimes you will have troublesome users. Unfortunately, IRC's method of banning users is confusing and unnecessarily complex. This bad design can and should be fixed someday, as we hope to do by making a more user-friendly app.
To kick a user from a channel ban a user, type /kick nickname. This kick is only temporary, however, because a user can rejoin right after being kicked. To ban him permanently from the channel, you must learn how to ban a user.
On IRC, every client that connects to a server will have a vhost that looks like this:
If you type /mode +b nickname, you will ban nickname!*@*, where the asterisk * refers to any match. That is, you will ban all users that have the same nickname, regardless of what their username or hostmask is. This is not, however, what you really want. Any user can simply change his nickname and rejoin the channel.
You might therefore choose to ban a user based on his hostmask, which is usually the same as his IP address. If you type /mode +b *!*@hostmask, this will ban all users with the same hostmask, which is usually a ban on the IP address.
Unfortunately, there is another complication. Some IP addresses might have multiple users connecting to it, such as if the IP address is hosting a bouncer. To ban only a single user from this IP address, you will want to type /mode +b *!username@hostmask. This will ban all users with the username and hostmask, which should only be one user instead of all users.
To find out more information about a user, type /whois nickname and /whowas nickname. Some users will try to mask their IP address to increase privacy. This is particularly important because IRC is filled with criminals who might try to attack you. There are two ways to do this: one is by using a bouncer, the other is by cloaking it. Cloaks may occasionally leak information if used improperly and require requesting a cloak from each and every network you connect to, so we recommend using a bouncer where possible.
To learn more about the commands in your IRC client, type /help.
Extra comments from other sites
70. On Freenode, there is no HostServ. Instead "cloaks" (their name for vHosts) are to be manually requested in #freenode. If you are affiliated with a FOSS project, you may request a cloak of that project, in the form project/role/user. If you do not meet that project's policy for letting you have cloaks, you can get an "unaffiliated" cloak, in the form unaffiliated/accountname. Note. It is possible through manipulating ChanServ to reveal a person's IP. The details will not be discussed here, both because I cannot see a reason someone would want to know this without malicious intent, and because I personally do not know how. But the take-away is that cloaks are not completely secure and complete security requires a VPN or Tor.
EDIT: Personal wording should be avoided, also using a VPN does not guarantee one is "completely secure", this is still shifting trust in the end, and a VPN provider can be dodgy/have malicious intentions as well (tl;dr: one should not blindly trust a VPN 100% with one's sensitive data).
71. Unlike private messages with users, messages to services are NOT in a separate window, except in Pidgin. Thus it is EXTREMELY EASY to accidentally divulge your password if you mistype something. For that reason I would recommend not using a password you use anywhere else, and always double checking if you have the prefix "/msg NickServ" completely right.
EDIT: Advice usually given is /query NickServ so that NOTICEs do not get lost. This has nothing to do with *Serv bots et al being services, but simply responding via NOTICE by default (can at times be optionally changed to use PRIVMSG).
Channel and user modes
PART V. CHANNEL AND USER MODES.
72. Divisions of modes. 73. Classes of channel modes. 74. How to set modes. 75. Adding or removing multiple modes. Div. 1. Channel Modes. Div. 2. User Modes.
72. Modes are divided into: First. User modes, set by a user upon themselves or a server upon a user. Second. Channel modes, set by an op upon a channel or users in it, or by a server or service upon a channel. Third. Server modes, set by a server operator upon their server, which is beyond the scope of this work.
EDIT: Server modes? Modes set upon a server? Source required as this seems to be more theoretical "what could be someday" by some RFCs (which also stated nicknames would become obsoleted).
73. Channel modes are in this work considered in two classes: First. Modes set by an op upon a channel. Second. Modes set by an op upon its users, giving them privileges or restrictions. 74. To set modes, use /mode, with the following parameters: First. The target of the mode, be it a user for the first division of modes, or a channel for the second. Second. + or - and the mode or modes to be added or removed. Third. Any parameter for the mode. 75. Multiple modes may be added at the same time, but: First. The modes and the parameters must be grouped together; as "/mode #channel +bbbb troll1 troll2 troll3 troll4" (to ban 4 trolls with 1 /mode). Second. There must be as many modes as there are parameters. Third. The same action cannot both add and remove modes.
EDIT: Incorrect, it is possible to "mix up" modes e.g. "/mode #channel +b+e troll1*@* good_user1!*@*" is permitted. (Also correct syntax should be used in examples, as in troll1!*@* troll2!*@* etc). Second is incorrect as well, there are modes which require no parameters, thus one could e.g. set 1 ban, but also moderated and secret. so "/mode #channel +bsm troll3!*@*" is valid. Third is incorrect as well, one may set AND remove modes simultaneously.
Div. 1. Channel Modes.
76. First step of channel modes. 77. +k. 78. +i. 79. +b. 80. +e. 81. +I. 82. Modes of different op grades. 83. Applications. 84. +r. 85. +m. 86. +M.
76. In this division, the first step is always /mode followed by the target channel. 77. To make a channel require a password to join: First. "+k". Second. The password, case sensitive. 78. To make a channel invite-only, "+i". 79. To ban someone: First. +b. Second. The mask intended to be banned. [See para. 27.] 80. To exempt someone from banning: First. +e. Second. The mask intended to be excepted. 81. To exempt someone from having to be invited: First. +I. Second. The mask intended to be exempted. 82. To use xOP through /mode [see para. 44]: First. To make someone owner, +q. Second. To super-op someone, +a. Third. To op someone, +o. Fourth. To half-op someone, +h. Fifth. To voice someone, +v. 83. It is possible to use /mode to op people through masks as well as nicks. This may be useful on Freenode.
EDIT: Incorrect. /mode #channel +o requires a nickname as a paramemter. Perhaps using ChanServ to op by masks was meant?
84. To prevent unregistered users from joining, +r.
EDIT: As this is a common countermeasure recommended, it should be noted that often the chanmode is +R.
85. To prevent unvoiced users from talking (but not from viewing), +m. Note. You may want to use LEVELS SET AUTOVOICE 0 to auto-voice people, and then strip voice when they become troublemakers.
EDIT: Once again Anope specific advice, for Atheme one may wish to /cs flags #chan *!*@* +V (do note that all an abuser would have to do in either case is leave and rejoin to get voiced again). Also 0 in Anope should mean "all users" but actually means "all registered users". In effect, -1 is "all users" (despite the help files saying otherwise).
86. To prevent unvoiced AND unregistered users from talking (but not from viewing), +M. Note. The above three measures are all very good defenses against low-effort trolls.
At least partially incorrect, +M often only blocks unregistered users from speaking. If they are registered but NOT voiced, they are usually permitted to speak. Also +M CAN have different functionalities.
Div. 2. User Modes.
87. +R. 88. +p.
87. To block private messages from unregistered users, +R. 88. To hide channels the enquirer doesn't share with you, as well as sign-on and idle time from /whois, +p.
EDIT: This is Unreal and Rizon-specific advice, on InspIRCd one would use user mode +I to hide channels, on freenode user mode +i (set by default) hides non-common channels. Also of note that Unreal's and Insp's chan hiding do NOT hide the idle + signon time. (Again the guide appears to cater a lot to Rizon, then to freenode).
Note. Freenode does that automatically, but MOST OTHER NETWORKS DON'T, and thus this information, in conjunction with others can be a versatile tool for investigating trolls.
EDIT: freenode no longer sets +R by default.
THE END. TABULATION OF MOD ROLES.
| Common name | /mode code | Symbol (text based) | Symbol (Hexchat) | Symbol (Pidgin) | ACCESS level | | Owner | +q | ~ | Orange dot | Blue flag | 10000 | | Super-op | +a | & | Yellow dot | None | 10 | | Op | +o | @ | Blue dot | Gold hexagram | 5 | | Half-op | +h | % | Light blue dot | Silver star | 4 | | Voiced | +v | + | Blue dot | "Connection" | 3 |
EDIT: If the channel is set persist (often +P or e.g. +z on Rizon) it will remain even if the last person leaves (as this is implemented in many major IRCd's this should be mentioned). (Also possible with Anope's ChanServ without a persistent channel mode)
Note: The sources provided herein are for purposes of comparison and reference only. No inference of endorsement or responsibility for any part of any of their contents is to be drawn or can be accepted.--Author. Original IRC RFC's: RFC 1459 by Jarkko Oikarinen (inventor of IRC): https://tools.ietf.org/html/rfc1459 RFC 2811 "Channel Management" : https://tools.ietf.org/html/rfc2811 RFC 2812 "Client Protocol": https://tools.ietf.org/html/rfc2812 Rizon Wiki https://wiki.rizon.net/index.php?title=Main_Page AnopeWiki https://wiki.anope.org/index.php/Main_Page Atheme Wiki https://github.com/atheme/atheme/wiki UnrealIRCd Documentation Wiki https://www.unrealircd.org/docs/Main_Page