Second printing with some errors corrected and other assorted revision, 2020.
	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.
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.

	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 <message>".

EDIT: An "ordinary message" is interpreted as "msg $active <message" since /query is used to message a user

9. A command always begins with "/".
	10. Clients.
	11. Web chats.
	12. Finding channels.
	13. Server key, address, and nick.
	14. Message of the day.
	15. Joining channels.
	16. Networks.
	17. Autojoins.
10. There is no single make of client; instead there is a variety of types. Ones I've used are:
mIRC: For Windows. Proprietary shareware with a $20 license fee after 30 days.
Pidgin: For Windows and Linux. Is also a client for many other chat protocols, but is slightly different from more conventional IRC clients.
Trillian: For OS X, Windows, Linux, iOS, and Android. Proprietary, has a free version and a paid version without ads, resembles an IM client much more than an IRC client. Is also a client for its in-house chat protocol.
HexChat: For Windows. FOSS version of XChat, which has a proprietary Windows version that requires payment. Past a certain point, will clear old messages as new messages come in. Has support for mIRC color codes, but not for Chinese characters.

EDIT: allows installing HexChat for free and the Windows store version is NOT a must on Win 10, the Win 7 .exe's work perfectly fine

Irssi: For Linux. A Text Based client, unlike the 4 others, which are GUI clients. Not recommended for new users.
There are also other clients that I haven't used:
Chatzilla (an add-on for Firefox), XChat (FOSS for Linux), WeeChat, Quassel, AdiIRC, etc.
11. For connecting on the go or from foreign devices, use KiwiIRC ( or Mibbit (, or see if the IRC network provides a web chat.
12. To find IRC channels, use Most clients will include lists of networks with them.

EDIT: is another good source to mention and more well known

13. To connect to IRC, it is needed to provide:
First. A server key or password. Very few servers will have this.
Second. A server address. Use the address the network provides for the whole network; a server will be automatically assigned to you.
Third. A nickname or nick. If your nick is already in use, the server will let you join with numbers added to the end.

EDIT: It is said very few networks require a server password, which is mostly true, why mention it as first step?  Also a username/ident and a realname/gecos MUST be provided as well (filled out in your client). Also the part with "your nick is already in use" is semi-true, it is up to the client whether you "join with numbers added at the end" (short version, that part is client specific, NOT server behavior).

14. Once you have connected, you will receive a Message Of The Day. This will usually include ground rules for the network and helpful tips.
15. From this point on, type "/join [channel, including leading symbol] [password if one is needed]" if you were asked to join a channel, or just "/list" if you're just looking around.

EDIT: Due to "recent" spamwaves (ongoing for long periods of time) some networks impose a restriction that one must wait a certain duration after connecting to use /list and/or sometimes to /join a channel. Also some clients (e.g. AdiIRC) will work with /join channel (they will join #channel). Perhaps of more relevance is that one may join multiple channels at once via /join #A,#B key-a,key-b (if they need keys add those comma seperated).

16. Here are some networks:
Freenode: Focuses on free and open-source software and other collaborative projects. Much more centralized and strictly governed than other IRC networks. (
Rizon: A general-purpose IRC network. It aims to cultivate a free, fun atmosphere. Both entertainment channels like #4chan and #8chan as well as more serious channels like #bibanon are there. (
EFnet: The original IRC network (not exactly, but close enough.) Has no ChanServ or NickServ, so keeping your nickname and channel yours will require some legwork. (
IRCnet: A European split of EFnet. Has no ChanServ or NickServ, so keeping your nickname and channel yours will require some legwork. (
Undernet: Has no NickServ, and registering channels is by application; channels will only be registered if they are active and have 5 regulars. (
These are the biggest ones, but there are many small networks. You're liable to find a good conversation and many friends on any of them, so give them a try!
17. At this point you may be wondering how to have your client join a channel every time you log on. Your client should have an "execute upon connection" box. Type /join [channel] [password if one is needed] in it.

EDIT: Some networks have server-sided autojoin channels, where one would need to /part [channel] if joning them is not desired (or an "execute upon connection" is not necessary if those should be joined).

	Prior reading: para. 9.
	18. /join, /j.
	19. /msg, /m
	20. Target of /msg.
	21. /quit.
	22. /part.
	23. /say, /query.
	24. Important notices for /say and /query.
	25. /invite.
	26. /op, /deop, /voice, /devoice, /hop, /dehop.
	27. /ban, /unban, /kick, /kickban, /kb.
	28. /whois, /whowas.
	29. /help.
18. The first command we will look at is /join or /j. It has two parameters:
First. Channel to join. Mandatory. The initial symbol must be included.
Second. Channel key. Optional. If you happen to forget it, you may ask ChanServ using /cs GETKEY.
Note. A /join command may fail because the channel you join is an invite-only channel. Again, ask ChanServ for an invite.

EDIT: See EDIT under 15. for information about /join (joining multiple channels, prefix if # not being mandatory in certain clients etc). Also /cs getkey and /cs invite require sufficient ChanServ channel access.

19. Another command is /msg, or /m for short everywhere except Pidgin. It is used for private messages, (DO NOT CALL THEM DIRECT MESSAGES UNLESS YOU WANT TO SOUND LIKE YOU USE DISCORD WHICH YOU SHOULDN'T BECAUSE IT'S GAY.) It has two parameters:
First. The target. Mandatory.
Second. The message. Mandatory.

EDIT: The bashing of Discord, especially calling it gay, is uncalled for. Uncertain if /m is as universal as /msg. 

20. The target can be:
First. A user. The message might not get through because the user might not take PMs from unregistered users or have put you on /ignore.
Second. A channel. Channels are set by default not to accept messages from users that are not in them.
Third. A service. In most clients, messages to services do not appear in a separate window.

EDIT: Uncertain about "most clients". Also technically a service is seen as a user from the perspective of one's client (it just responds via NOTICE by default, so User notices would get as easily lost).

21. Another command is /quit. It disconnects you from IRC. The command takes one parameter: a quit message. It is optional to leave a quit message, but usually people will tell a joke in it. If none is given, it will default to "Leaving".

EDIT: Default can also be a different message (e.g. Unreal defaults to the user's nick if no message was given). Also some networks employ static/fixed/forced quits.

22. Another command is /part. It allows you to leave a channel without disconnecting altogether. It has two parameters:
First. A channel to leave. Optional, defaults to channel you are typing /part in.
Second. A part message. Optional, defaults to none.

EDIT: Like with /join multiple channels may be left simultaneously (/part #A,#B)

23. Another two commands are /say and /query. They send a message normally as if no command were being used, and are good for two purposes:
First. Sending a message beginning with / without triggering a command.
Second. PMing someone and opening a separate window with that person (/msg doesn't do that.)
Note. For the first item, if you begin a message with ./ you will be understood.
24. For using /say and /query, remember that:
First. /say works on channels, while /query works on users.
Second. /say takes only the message as a parameter, while /query takes the same parameters as /msg except it is not possible to /query channels.

EDIT: /say (at least on mIRC and AdiIRC) only works in the active channel, not a channel of one's choice (source of statement in 24 unclear, perhaps irssi?). Also /say on mIRC can work in queries as well, source:,%2C%20use%20the%20%2Fmsg%20command.

25. Another command is /invite. For invite only channels, this will be necessary if you want to get someone in. It has two parameters:
First. The user to be invited. Mandatory.
Second. The channel to be invited to. Optional, defaults to current channel. 
Note. You have to be an op to use this. If you are already one and can't get in, use ChanServ.

EDIT: "defaults to current channel" would be client specific behavior, the "actual" /INVITE command requires both params. Also while being op is often needed for this, UnrealIRCd allows anyone to /INVITE by default. Using ChanServ requires sufficient channel level access through ChanServ first.

26. Another set of commands are /op and /deop, /hop and /dehop, /voice and /devoice. They will save you a lot of effort if you don't want to use /mode or ChanServ. 
Note. To op yourself when you have the right to do so, use ChanServ.

EDIT: While /op and /deop are (most likely) very universally supported, it should be noted these are client sided commands.

27. To punish people, use /ban and /unban, /kick, or /kickban or /kb if you want to do both. People who are under a plain /ban will not be allowed to send messages to the channel, but will still be able to view messages. If they leave, they can't rejoin for the duration of the ban. It takes one parameter, the mask, consisting of three parts:
First. The nickname. This will ban everyone using the nickname.
Second. The "ident", i.e. the part you see before the @ when someone joins a channel.
Third. The host. An IP address or range of IP addresses can be used. If there are no legitimate users from a country or state trolls are posting from, you may do /ban *!*@*.[country code] or /ban *!*@*.[USPS code, e.g. wa for Washington].us. Regular expressions may be used for all 3 parts of the mask.
Note. Timed bans are not possible with /ban or /kb. You must /unban manually.

EDIT: The commands mentioned here, like above, are client sided (excluding /KICK being server-sided) and if not supported, /MODE +|-b #channel_name nick!user@hostmask must be used instead.

28. To find out what someone's IP is, use /whois and /whowas. The only parameter is the nickname.

EDIT: Cloaks on freenode are NOT designed to hide the IP, see

Also /whois may take 2 params, on some IRCd's <nick> <server> OR <server> <nick>. Often /WHOIS <nick> <nick> (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.
	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.
	38. Auto-identify.
	39. GHOST.
	40. GROUP.
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

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.
	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.
	56. LEVELS.
	57. ACCESS.
	58. Purpose of FLAGS.
	59. Nature of 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).

	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.

| 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            |
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):
RFC 2811 "Channel Management" :
RFC 2812 "Client Protocol":
Rizon Wiki
Atheme Wiki
UnrealIRCd Documentation Wiki