IRC MADE EASY, by QUINTUPLICATE, 2019. Second printing with some errors corrected and other assorted revision, 2020. CONTENTS. Introduction. Part I. The Nature of IRC. Part II. Connecting. Part III. Commands. Part IV. Using Network Services. Part V. Channel and User Modes. Tabulation of Mod Roles. Further Reading. INTRODUCTION. If you are reading this, you do not need reasons for using IRC; therefore none will be given. Brevity, simplicity, clarity, organization, and convenience have been the goals of this work, and not literary beauty. I would like to thank all those who read and offered feedback on this work. I do not pretend to be an expert, and this work is mostly based on experience. All faults in this work are mine alone, and improvement is eagerly requested. This work is intended to be read from beginning to end. Sequential indices head every part and division, in order to provide a concise summary of the matter contained therein. I disclaim all legal responsibility for anything done in consequence of this work. THE AUTHOR. PART I. THE NATURE OF IRC. 1. IRC, servers, clients. 2. Clients only receive when they are online. 3. Networks and channels. 4. # and & channels. 5. Life and death of channels. 6. Channel, network, and server operators. 7. Existence of # channels. 8. Commands and ordinary messages. 9. / for starting commands. 1. Internet Relay Chat, or IRC, is a protocol for communication between: First. Servers, which carry the communication; and Second. Clients, which are connected to servers, through which they communicate with each other. 2. Servers do not store messages for clients; a client will only see the messages servers transmit when it is online. 3. Servers-- First. May be grouped into networks, which allow channels to be shared; Second. Carry channels, in which all communication between clients takes place. 4. Channels begin with-- First. # for channels usable throughout the network; and Second. & for channels usable on one server only. Few networks will have or allow the creation of such channels. Note. Channels beginning with ## are # channels, and on Freenode are used for conversation unrelated to FOSS. EDIT: ## vs # is (mostly) only done by Snoonet and freenode and NOT a general practice. 5. A channel is created when the first user joins, and is destroyed when the last user leaves. Note. When a client joins a channel, it is created on the server to which the client is connected. 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) 6. Channels, servers, and networks have their own classes of operators, each having a wider range of power than the one before it. 7. A channel beginning with # exists-- First. On every server to which a client that is a member of it is connected; Second. On every server through which a message to every server covered by the first item must pass. EDIT: Potentially (most likely) wrong as # channels are global thus they exist on the ENTIRE network (all servers). 8. Clients and servers may send commands to servers. An ordinary message is interpreted as "/query ". EDIT: An "ordinary message" is interpreted as "msg $active OR . Often /WHOIS (the same nick) is supported to query idle + signon time (as well as the away reason if the user is /AWAY) on users who are on remote servers (not the one you are on). 29. To know what commands your client supports, use /help. Play around a bit. It'll explain some of the more obscure commands better than I can. PART IV. USING NETWORK SERVICES. 30. Services common to all networks with them. 31. Services that occasionally appear. 32. Scope of part. 33. Querying a server, /ns, /cs, /ms, /hs. 34. HELP. Div. 1. NickServ. Div. 2. ChanServ. Div. 3. MemoServ. Div. 4. Miscellaneous. 30. Every network that has services will have-- First. NickServ, for registering nicknames. Second. ChanServ, for registering channels. Third. MemoServ, for sending memos to offline users. Fourth. OperServ, for use by server operators. EDIT: "Every" network is incorrect, e.g. UnderNET and QuakeNet offer services albeit different ones than the usual *Serv ones. 31. Some networks will also have-- First. HostServ, for requesting virtual hosts for cloaking IPs. Second. BotServ, for requesting bots. Third. HelpServ, for requesting help. Fourth. FunServ, for trivia games. 32. This work will not attempt to go into an exhaustive description of what every service can do, but will cover the basics of using them as well as some useful functions. 33. To query a server, use /msg [service] [command]. Most, but by no means all, clients will allow you to shorten the query by using: First. For NickServ, /nickserv or /ns. Second. For ChanServ, /chanserv or /cs. Third. For MemoServ, /memoserv or /ms. Fourth. For HostServ, /hostserv or /hs. Note. The latter, abbreviated forms will be used throughout this work. EDIT: These commands are often server-sided and thus not needed to be client-sided. Note that ngIRCd, which IRCNow utilizes, does NOT support these aliases and they must be integrated into the client via scripting/aliasing etc 34. Your first command to a service should always be /msg [service] HELP. Div. 1. NickServ. 35. REGISTER. 36. CONFIRM. 37. IDENTIFY. 38. Auto-identify. 39. GHOST. 40. GROUP. 41. SET ENFORCE. 35. To register a nickname, use /ns REGISTER, with the following two parameters: First. A password. Second. An email address. Note. Registration is highly encouraged, both for the security of your nickname, as well as because some channels won't let you join if you are unregistered to prevent spammers. 36. After you have done so, you will receive an email which will direct you to type /ns CONFIRM followed by a code. The registration will expire if you do not confirm it within 24 hours. EDIT: The user MUST be identified/logged in otherwise the confirmation code will NOT work. (incase they disconnect temporarily). 37. To log in as a registered nickname, use /ns IDENTIFY, with the following parameters: First. A nickname, if it is not your current nickname. Second. The password you registered it as. EDIT: Not ALL NickServs allow specifying the nick (albeit most do) (e.g. Rizon does NOT though). 38. Constantly typing it may be annoying, not to mention revealing of your IP. To have your client "remember" your password, put /ns IDENTIFY [password] in your auto-execute box. EDIT: 37. mentions that one can specify the nickname (in most cases) why is this not mentioned in 38? Most networks support SASL authentication which offers the benefit of e.g. occuring during signon instead of after, and only going to the acual service (so if one uses /msg NickServ then NickServ COULD be an imposter, but SASL would only go to the real one). For SASL regarding various clients see https://freenode.net/kb/answer/sasl 39. Sometimes when you get disconnected there may be a copy of yourself still in the channel. To remove this copy, type /ns GHOST with the following parameters: First. The nickname to be removed. Second. The password of that nick, if you are not in a group with it. Note. If your client allows for it, by all means put down names for your "second alternative" and "third alternative", and register them. 40. If you do get a vHost/cloak, it would be a good idea to group all your nicks under one group, so that all the nicks may use it. Use /ns GROUP with the following parameters: First. A nick you wish to be in the same group with. Second. That nick's password. EDIT: Often /hs group will be necessary as well to "synch" the main nick's vhost with the grouped nicks. 41. To protect your nickname while you are offline, use /ns SET ENFORCE. This will give anybody who uses this nickname 30 seconds to supply the password, or have their nick changed. EDIT: This is Atheme specific, Anope would use /ns SET KILL Div. 2. ChanServ. 42. REGISTER. 43. SET ACCESSTYPE. 44. Ways to use xOP. 45. SOP, AOP, HOP, VOP. 46. xOP. 47. Powers of ops. 48. Voiced people. 49. Half-ops. 50. Ops. 51. Super-ops. 52. Symbols for ops. 53. Purpose of ACCESS. 54. Access levels. 55. HELP LEVELS DESC. 56. LEVELS. 57. ACCESS. 58. Purpose of FLAGS. 59. Nature of FLAGS. 60. HELP FLAGS. 61. FLAGS. 62. Need to register. 42. To register a channel, use /cs REGISTER, with the following three parameters: First. The channel to be registered. Second. A password for that channel. While mandatory, you may wish to enable SECUREFOUNDER to prevent anyone into the hands of which the password might fall from abusing it. Third. A description of that channel, for use with /list. 43. There are three ways to manage the various administrative positions of an IRC channel: First. xOP. Second. ACCESS. Third. FLAGS. Note. To change from one to the other, use /cs SET #channel ACCESSTYPE. EDIT: This is near-exclusive to Rizon using an Anope 1.8.x fork, Atheme and Anope 2.0.x let you use all types simultaneously (assuming the respective modules are loased in the services configs). 44. XOP may be used: First. By /mode. Second. By ChanServ. EDIT: The various XOP levels (VOP, AOP etc) are services sided sets of privileges, which CANNOT be granted via /mode . The various prefixes can be granted via /mode though with sufficient privileges. 45. There are four types of ops: First. Super-ops (SOP). Second. Ops (AOP). Third. Half-ops. (HOP). Fourth. Voiced people. (VOP). EDIT: Sometimes a QOP (quintessential op) is a type as well, like a co-owner (may have different names at times). 46. To add people to each class, use /cs #channel xOP [hence the name] with the single parameter of the nickname of the person to be added. Unless xOP is meant to be replaced with the real levels (AOP, VOP etc) (which is NOT made clear through the wording) this advice literally using xOP is incorrect. 47. Each level of op, except voiced people, can: First. Ban and kick people at or below their level. Second. Give and take access levels at or below their level. 48. Voiced people gain no privileges except the right to keep sending messages when the channel is under +m. 49. Half-ops can set the topic on top of that. 50. Ops, also known as chanops or chops, can ban, give, and take ops and half-ops. 51. Super-ops, or protect-ops, can only be kicked by the channel owner. 52. The symbols for them are: First. For the owner of the channel, ~ before the nick, an orange dot in Hexchat, or a blue flag in Pidgin. Second. For super-ops, & before the nick, a yellow dot in Hexchat, none in Pidgin. Third. For ops, @ before the nick, a blue dot in Hexchat, or a gold sheriff's star in Pidgin. Fourth. For half-ops, % before the nick, a light blue dot in Hexchat, or a silver star in Pidgin. Fifth. For voiced people, + before the nick, a blue dot in Hexchat, or a circle with waves protruding out in Pidgin. 53. ACCESS is useful if you wish all users of a certain class to have privileges other than the default granted by xOP. 54. The access levels are: First. The founder, 10000. Second. Super-ops, 10. Third. Ops, 5. Fourth. Half-ops, 4. Fifth. Voiced people, 3. Sixth. Ordinary users, 0. Seventh. Banned people, -1. Note. The gaps between access levels are deliberate, to enable the formation of new access levels. 55. For a list of access levels with their features, use /cs HELP LEVELS DESC. 56. To adjust them, use /cs LEVELS with the following parameters: First. The channel on which the change is to take place. Second. LIST, to simply list the privileges of the current access levels for the channel and SET, to change them. Third. The feature (found using HELP LEVELS) the right to use which is sought to be changed. Fourth. The numerical access level to change it to. 57. To add or remove a person to the access list, use /cs ACCESS with the following parameters: First. The channel whose access list is sought to be changed. Second. ADD to add someone and DEL to remove someone. Third. The nick of the person to be added or removed. Fourth. The access level to which they are to be added (for ADD only). Note. To change the access level of a person, repeat this process. 58. FLAGS should be used if and only if you would like to fine-tune and individualize what every person is able to do. 59. FLAGS contains a list of attributes which are added to individual nicks as appropriate. Note. These "attributes" contain one letter, and ARE NOT coterminous or identical to the "features" of ACCESS! 60. To see a list of flags, use /cs HELP FLAGS. Note. Flags are case sensitive. 61. To use FLAGS, use /cs FLAGS with the following parameters: First. The channel. Second. The nick. Third. + or - followed by one-letter "flags". Note. +* to add all privileges, -* to remove all. EDIT: /cs levels is Anope exclusive, and NOT universal in all services out there. 62. It is absolutely necessary to be registered to register channels as well as be opped under either of these three systems. (Unless you use /mode, which expires every time you log off.) This is another incentive to register and have everyone in your channel register as well. EDIT: "oped under one of these three systems" to register a channel is incorrect, the user must be oped which is correct. If they are oped via xOP or ACCESS or FLAGS the channel already is registered. Div. 3. MemoServ. 63. MemoServ. 64. Advantages. 65. Memos to channels. 66. Possible application. 67. Range of memos to channels. 68. Storage of memos. 63. MemoServ is a service to send messages to registered: First. Users. Second. Channels. 64. The advantages of MemoServ are that it: First. Works whether the target is on- or offline. Second. Stores messages indefinitely. 65. MemoServ can be used to send messages to channels. 66. It is possible to set up a system where the ops of a channel talk to each other while private conversation continues unawares below. I do not believe this system is doable under any other protocol. This will greatly enhance the experience of managing a channel. EDIT: The rough setup/layout of such a system requires elaboration. Personal "bias" (I believe) should be avoided. If the system is using channel memos exclusively for communication, there is (often) a hard-enforced limit of how many memos a user/channel can store at once. 67. By default only super-ops and the owner will get memos to a channel. If you want people to get memos but do not trust them with super-op powers, your only choices are to use ACCESS or FLAGS. 68. MemoServ stores and numbers memos so you can look back on them whenever you want. EDIT: Memos to channels are Anope-specific (this guide appears a bit strongly based on Rizon). Div. 4. Miscellaneous. 69. VHosts. 70. Cloaks. 71. Note for using all services. 69. To hide your IP on most servers, ask HostServ. One will not be automatically given, but will be approved or rejected at network discretion. Pay attention to the kind of people that use the network and the kind of vHosts other people have to maximize your chances of approval. A vHost (short for "virtual host") is in the form of a domain, but does not actually resolve. EDIT: Most modern networks will cloak the hostname by default. A vHost CAN resolve technically speaking, but is often rejected due to network policies (but if one can prove ownership over the domain, it MAY be granted as vHost, this is once again up to the network's discrtion). 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). 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 | ------------------------------------------------------------------------------------------------------ FURTHER READING. 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