DWIRC:Staff Training/User and Channel Modes

DarkWorld IRC Staff Training
Module 4: User and Channel Modes

Program	DarkWorld IRC Staff Training Program
Module	4 of 10
Difficulty	Intermediate
Estimated study time	4–5 hours
Assessment	Knowledge check, mode exercises, and moderation scenarios
Prerequisite	Module 3 — DarkWorld IRC Rules and Policies

Module Overview

IRC modes control user behavior, channel access, channel visibility, moderation, and security.

A staff candidate must understand:

• User modes.
• Channel modes.
• Channel access status.
• Mode parameters.
• Ban lists.
• Ban exceptions.
• Invite exceptions.
• Moderated channels.
• Registered-user restrictions.
• Flood-protection modes.
• Extended bans.
• The risks of incorrect or overly broad modes.

Mode availability and exact behavior can depend on the current version and configuration of UnrealIRCd.

This module is written for UnrealIRCd 6. DarkWorld may disable, restrict, or configure individual modules differently, so the live server configuration remains authoritative.

Important: This lesson explains commonly used modes. Staff must verify current behavior through official DarkWorld documentation, IRC server help, and authorized procedures before applying unfamiliar modes.

Official technical references

• UnrealIRCd — User modes
• UnrealIRCd — Channel modes
• UnrealIRCd — Extended bans
• UnrealIRCd — Channel anti-flood settings

These external pages describe upstream UnrealIRCd behavior and may change as UnrealIRCd is updated. They supplement, but do not replace, DarkWorld policy, authorization boundaries, trainer instructions, or the current server configuration.

Learning Objectives

After completing this module, the candidate should be able to:

1. Explain the difference between user modes and channel modes.
2. Explain the difference between a mode that a user chooses and a status indicator set by the server or Services.
3. View current user and channel modes.
4. Understand channel access levels.
5. Add and remove modes using correct syntax.
6. Explain when a mode requires a parameter.
7. View and interpret channel ban lists.
8. Create reasonably precise ban masks.
9. Explain ban, exception, and invite-exception lists.
10. Use moderated and invite-only modes correctly.
11. Understand registered-user and TLS-related restrictions.
12. Recognize the risks of broad or conflicting modes.
13. Record and reverse temporary mode changes.
14. Use selected UnrealIRCd 6 extended bans safely in an approved training channel.

1. What Is an IRC Mode?

A mode changes the state or behavior of an IRC user or channel.

Modes are normally represented by letters.

Examples:

+i
+m
+n
+t
+k
+l
+b

The plus sign adds a mode:

/MODE #channel +m

The minus sign removes a mode:

/MODE #channel -m

Some modes require parameters.

Example:

/MODE #channel +k SecretKey

Other modes do not require parameters:

/MODE #channel +m

2. User Modes and Channel Modes

User Modes

User modes apply to an individual IRC connection.

To view your current user modes:

/MODE YourNickname

A user normally sets only their own permitted user modes.

Some user modes are selected by the user, while others are status indicators set only by the server, Services, or IRC operator authorization. A displayed mode does not by itself create staff authority.

Common user modes on UnrealIRCd 6

Mode	Meaning	Who sets it / operational note
+i	Invisible from broad /WHO and /NAMES queries made by people who do not share a channel with the user.	Commonly set automatically or by the user. It does not make the user invisible to everyone.
+x	Uses a hidden or cloaked hostname.	Protects the displayed hostname; it does not provide anonymity from authorized network systems.
+B	Marks the connection as a bot in /WHOIS.	Identification only; it does not grant bot privileges or staff authority.
+p	Hides the user’s channel list from ordinary /WHOIS responses.	Privacy feature; authorized staff visibility may differ.
+R	Accepts private messages only from users authenticated to Services.	This is a user mode; do not confuse it with channel +R, which restricts joins.
+T	Prevents the user from receiving CTCP requests.	May affect legitimate CTCP functions as well as abuse.
+Z	Allows private messages, notices, and CTCPs only between this user and TLS-connected users.	This is a user mode; do not confuse it with channel +Z.
+z	Indicates that the connection is using TLS.	Set by the server. It is a connection-security indicator, not proof of identity or trustworthiness.
+r	Indicates that the connection is authenticated to a registered Services account.	Set by Services. Authentication does not automatically mean the current nickname and account name are identical.
+t	Indicates use of a vhost or altered displayed host.	Set by the server following authorized host/vhost mechanisms.
+o	Indicates IRC operator status.	Set by the server after successful authorized oper authentication. Its permissions come from the assigned operclass.
+s	Receives selected server notices (snomasks).	IRC operator only and covered in the IRC Operator Fundamentals module.

Other user modes may be available. Candidates should consult the official UnrealIRCd user-mode reference and the live server configuration before relying on an unfamiliar mode.

Do not confuse similarly named modes: user +R restricts incoming private messages, while channel +R restricts channel joins. User +z indicates TLS, channel +z requires TLS for joining, and channel +Z is a server-set indication that everyone currently present is using TLS.

Channel Modes

Channel modes apply to a channel.

To view the current modes:

/MODE #channel

Changing channel modes normally requires appropriate channel privileges.

Important Difference

The same letter may have a different meaning when used as a user mode and as a channel mode.

Staff should always identify whether the mode applies to:

• A user.
• A channel.
• A channel member’s status.
• A ban or exception list.

3. Mode Syntax

General syntax:

/MODE target modes parameters

Examples:

/MODE #Training +m
/MODE #Training -m
/MODE #Training +o Falcon
/MODE #Training -o Falcon
/MODE #Training +b *!*@example.host
/MODE #Training -b *!*@example.host

Multiple modes may be combined:

/MODE #Training +mnt

Modes requiring parameters must have corresponding parameters:

/MODE #Training +ov Falcon Eagle

This gives operator status to Falcon and voice to Eagle.

A missing or incorrectly ordered parameter may cause the command to fail or affect the wrong target.

4. Channel Access Status

Channel status modes assign privileges to users within a channel.

DarkWorld IRC may use the following hierarchy:

Mode	Common prefix	Common title	General purpose
+v	+	Voice	Allows speaking in a moderated channel.
+h	%	Half-operator	Provides limited channel moderation privileges.
+o	@	Channel operator	Provides normal channel-management privileges.
+a	&	Channel administrator or protected operator	Provides elevated channel-management status.
+q	~	Channel owner	Represents the highest channel access status.

The displayed prefixes depend on the IRC client.

A user may hold more than one status mode, although the client may display only the highest prefix.

Voice: +v

Grant voice:

/MODE #channel +v nickname

Remove voice:

/MODE #channel -v nickname

Voice allows a user to speak while the channel is moderated with +m or +M. Under standard UnrealIRCd behavior, a voiced user may also continue speaking while matching a channel ban, so voice should not be granted casually during an active incident.

Voice does not make someone a network staff member.

Half-Operator: +h

Grant half-operator:

/MODE #channel +h nickname

Remove half-operator:

/MODE #channel -h nickname

Half-operators may have limited moderation abilities. Exact permissions depend on server and channel configuration.

Channel Operator: +o

Grant operator:

/MODE #channel +o nickname

Remove operator:

/MODE #channel -o nickname

Channel operators can normally manage common channel modes, kicks, and bans.

Channel operator status does not provide network-wide authority.

Channel Administrator: +a

Grant administrator status:

/MODE #channel +a nickname

Remove administrator status:

/MODE #channel -a nickname

This is an elevated channel role and should not be granted casually.

Channel Owner: +q

Grant owner status:

/MODE #channel +q nickname

Remove owner status:

/MODE #channel -q nickname

Channel-owner status should normally correspond to authorized channel ownership and Services access.

Remember: Channel status and IRC operator status are separate. A channel owner is not automatically an IRC operator, and an IRC operator is not automatically part of every channel’s management.

5. Common Channel Modes

The following modes are commonly available. Current behavior must be verified on DarkWorld IRC.

Mode	General meaning	Example
+i	Invite-only channel	/MODE #channel +i
+m	Moderated channel	/MODE #channel +m
+n	Blocks messages from users outside the channel	/MODE #channel +n
+t	Restricts topic changes to authorized channel staff	/MODE #channel +t
+s	Secret channel	/MODE #channel +s
+p	Private channel, where supported	/MODE #channel +p
+k	Requires a channel key	/MODE #channel +k KeyValue
+l	Sets a channel user limit	/MODE #channel +l 50
+b	Adds an entry to the ban list	/MODE #channel +b mask
+e	Adds an entry to the ban-exception list	/MODE #channel +e mask
+I	Adds an entry to the invite-exception list	/MODE #channel +I mask

Invite-Only: +i

When +i is set, users generally need an invitation or applicable exception to join.

Set:

/MODE #channel +i

Remove:

/MODE #channel -i

Invite a user:

/INVITE nickname #channel

Invite-only mode may be useful during:

• An active raid.
• A private meeting.
• A controlled training exercise.
• A temporary security incident.

It should not be left enabled accidentally after an emergency.

Moderated: +m

When +m is set, users without the required channel status normally cannot speak.

Set:

/MODE #channel +m

Remove:

/MODE #channel -m

Grant voice:

/MODE #channel +v nickname

Moderated mode may help control:

• Message flooding.
• Disruptive public events.
• Announcements.
• Training sessions.
• Emergency situations.

Moderating a busy public channel affects every unvoiced participant. Staff should review whether the restriction remains necessary.

No External Messages: +n

Mode +n normally prevents users who are not in the channel from sending messages to it.

/MODE #channel +n

This is a common protective mode for public channels.

Topic Protection: +t

Mode +t normally restricts topic changes to authorized channel staff.

/MODE #channel +t

Secret: +s

A secret channel is hidden from normal public channel listings and may be hidden from some user-information responses.

/MODE #channel +s

Secret does not mean that messages are encrypted end-to-end or that every participant will keep them confidential.

Channel Key: +k

A keyed channel requires users to provide the key when joining.

Set:

/MODE #channel +k TrainingKey

Join:

/JOIN #channel TrainingKey

Remove:

/MODE #channel -k TrainingKey

Some clients or server versions may allow the key parameter to be omitted when removing it.

Keys should not be posted publicly if the channel is intended to be restricted.

User Limit: +l

Set a maximum number of channel members:

/MODE #channel +l 50

Remove the limit:

/MODE #channel -l

A limit can help during some incidents but may also prevent legitimate users from joining.

6. Additional UnrealIRCd Channel Modes

UnrealIRCd 6 provides additional channel modes through loaded modules. DarkWorld may configure or restrict them differently, so candidates must verify live behavior and authorization before use.

Mode	UnrealIRCd 6 purpose	Operational caution
+C	Blocks channel CTCP messages.	May block legitimate CTCP actions as well as abuse.
+c	Blocks ANSI and mIRC color codes.	Messages containing prohibited formatting may be rejected.
+S	Strips ANSI and mIRC color codes instead of rejecting the message.	Do not confuse this channel mode with Services or user-mode letters.
+T	Blocks channel notices.	Normal channel messages remain possible unless another mode restricts them.
+R	Allows only users authenticated to Services to join.	Can block legitimate new users who need registration help.
+M	Allows speaking only by Services-authenticated users or users with +v or higher.	Existing unauthenticated users may remain but cannot normally speak.
+z	Allows only TLS-connected clients to join.	Does not provide end-to-end encryption or prove identity.
+Z	Indicates that the channel is +z and everyone currently present uses TLS.	Set only by the server; channel staff do not set it manually.
+K	Blocks use of /KNOCK.	Relevant mainly when invite-only access and knocking are in use.
+V	Prevents use of /INVITE for the channel.	May interfere with legitimate channel access workflows.
+N	Prevents nickname changes while users remain in the channel.	Normally a temporary response to nickname-change flooding.
+Q	Prevents /KICK and may force use of Services-based controls.	Unusual; do not use as a routine protection mode.
+G	Applies the server-configured bad-word filter.	Behavior depends on the DarkWorld IRCd badword configuration.
+H	Enables channel history according to the supplied history parameters.	History changes privacy and retention expectations; use only under approved channel policy.
+F	Applies a named channel anti-flood profile.	Available in UnrealIRCd 6.1.0 and later; use an approved profile rather than inventing settings.
+f	Provides advanced, fine-grained channel anti-flood settings.	Incorrect thresholds or actions can disrupt legitimate users. Use only with training and authorization.
+D	Delays JOIN visibility for ordinary users until the joining user speaks.	This does not prevent the person from joining; server mode +d may appear temporarily when +D is removed.
+P	Makes a channel permanent and stores its state through the channel database module.	IRC operator only and not a normal trainee tool.
+O	Restricts the channel to IRC operators.	IRC operator only.

For the complete upstream list and current restrictions, consult UnrealIRCd — Channel modes.

Before using an unfamiliar mode:

1. Check the current server help.
2. Check the official channel-mode documentation.
3. Confirm the mode’s parameters.
4. Consider how many users will be affected.
5. Confirm that you have authority.
6. Know how to reverse the mode.
7. Record temporary emergency changes.

7. Viewing Mode Lists

Ban List

/MODE #channel +b

Ban-Exception List

/MODE #channel +e

Invite-Exception List

/MODE #channel +I

Depending on the client, list entries may show:

• The mask.
• Who set it.
• When it was set.

Staff should check existing entries before adding a duplicate or broader restriction.

8. Channel Bans

A channel ban normally prevents a matching user from joining or participating, depending on server behavior and additional modes.

Add a ban:

/MODE #channel +b mask

Remove a ban:

/MODE #channel -b mask

Examples:

/MODE #Training +b ExampleNick!*@*
/MODE #Training +b *!example@*
/MODE #Training +b *!*@Example.User.DarkWorld.Network

Ban-Mask Precision

Consider the following masks:

Mask	Matches	Main limitation
ExampleNick!*@*	A particular nickname	The user may change nickname
*!example@*	A particular ident	Other users may use the same ident
*!*@Example.User.DarkWorld.Network	A particular displayed host	The host may be shared or changed
*!*@*.provider.example	A provider or host range	May affect many unrelated users
*!*@*	Everyone	Extremely broad and normally inappropriate

The safest effective mask depends on:

• The incident.
• Available identity information.
• Whether the host is shared.
• Account information.
• Whether the action is temporary.
• The likely effect on innocent users.
• Available extended-ban features.

9. Ban and Kick Order

A common moderation sequence is:

1. Set the appropriate ban.
2. Remove the user with a clear reason.
3. Record the action when required.
4. Review the ban later.

Example:

/MODE #channel +b *!*@Example.User.DarkWorld.Network
/KICK #channel ExampleNick Repeated flooding after warning

Setting the ban first reduces the chance of an immediate return between the kick and ban commands.

This sequence is not appropriate in every situation. Sometimes:

• A warning is sufficient.
• A quiet or moderated mode is preferable.
• The user has already left.
• A Services access restriction is required.
• A network-level response is needed.
• A broad host ban would harm innocent users.

10. Ban Exceptions: +e

A ban exception permits a matching user to bypass a matching channel ban.

Add an exception:

/MODE #channel +e mask

Remove an exception:

/MODE #channel -e mask

Example:

/MODE #channel +b *!*@*.shared-provider.example
/MODE #channel +e TrustedUser!*@*.shared-provider.example

Exceptions should not be used to hide a poorly designed broad ban when a more precise restriction is available.

Staff should understand which ban and exception entries overlap.

11. Invite Exceptions: +I

An invite exception may allow matching users to join an invite-only channel without receiving an individual invitation.

Add:

/MODE #channel +I mask

Remove:

/MODE #channel -I mask

Example:

/MODE #channel +I *!*@Authorized.Project.Host

An invite exception must not be granted merely for convenience if it weakens a channel’s intended security.

12. Extended Bans

UnrealIRCd 6 extended bans use readable names beginning with a tilde. They can be used with channel bans (+b), ban exceptions (+e), and—where supported for that selector—invite exceptions (+I).

General examples:

/MODE #channel +b ~account:AbusiveAccount
/MODE #channel +e ~account:TrustedAccount
/MODE #channel +I ~account:ApprovedAccount

An account name is not necessarily the same as the user’s current nickname.

12.1 Timed bans

The ~time wrapper removes an entry automatically after the stated number of minutes:

/MODE #channel +b ~time:10:*!*@Example.User.DarkWorld.Network

This creates a ten-minute ban. Staff must still document and review the action; an automatic expiry does not remove accountability.

12.2 Action extended bans

Type	Effect	Example
~quiet	Allows the matching user to remain or join but prevents speaking unless the user has +v or higher.	/MODE #channel +b ~quiet:*!*@Example.Host
~nickchange	Prevents the matching user from changing nickname unless voiced or higher.	/MODE #channel +b ~nickchange:*!*@Example.Host
~join	Prevents matching users from joining but does not restrict them if they are already inside.	/MODE #channel +b ~join:*!*@Example.Host
~forward	Forwards a matching user to another channel.	/MODE #channel +b ~forward:#Help:*!*@Example.Host

A targeted ~quiet is often less disruptive than moderating an entire public channel. A ~join entry does not silence or remove a user who is already present.

12.3 Selector extended bans

Type	Matches	Example
~account	A Services-authenticated account. ~account:* means all authenticated users; ~account:0 means unauthenticated users.	/MODE #channel +b ~account:AbusiveAccount
~channel	Users present in another channel, optionally at a specified access level.	/MODE #channel +e ~channel:@#TrustedOps
~country	A two-letter country code.	/MODE #channel +b ~country:XX
~security-group	A server-defined UnrealIRCd security group.	/MODE #channel +b ~security-group:unknown-users
~realname	The user’s realname/GECOS field. Underscores may match spaces and underscores.	/MODE #channel +b ~realname:*abusive_bot*
~certfp	A TLS client-certificate fingerprint visible through authorized information.	/MODE #channel +e ~certfp:FINGERPRINT
~asn	An Autonomous System Number; requires UnrealIRCd 6.1.7 or later.	/MODE #channel +b ~asn:64496

Country, ASN, channel-membership, realname, and security-group matches may cover many innocent users. They require a clear operational reason, precise scope, authorization, and review. Never invent or guess account names, certificate fingerprints, countries, or AS numbers.

12.4 Text and special extended bans

Text bans can block or censor matching channel content:

/MODE #channel +b ~text:block:*prohibited-pattern*
/MODE #channel +b ~text:censor:*prohibited-pattern*

Text patterns can create false positives and must be tested in an approved channel. Do not place confidential information, passwords, tokens, or private report content into a text-ban pattern.

Other special types include ~inherit, which can inherit selected ban or invite-exception behavior from another channel, and ~partmsg, which hides matching part or quit messages. These should be used only under approved DarkWorld procedures.

12.5 Stacking extended bans

Compatible extended bans may be combined. Examples:

/MODE #channel +b ~time:5:~quiet:~account:AbusiveAccount
/MODE #channel +e ~time:60:~account:TrustedAccount

The first example temporarily quiets the specified authenticated account for five minutes. The second creates a sixty-minute account-based ban exception. Not every type can be combined with every other type; verify the combination against the official UnrealIRCd extended-ban documentation.

12.6 Safe extended-ban procedure

Before applying an extended ban:

1. Identify the exact behavior that must be stopped.
2. Check DarkWorld’s current server configuration and procedures.
3. Consult the official UnrealIRCd 6 documentation.
4. Verify the exact matching behavior.
5. Test only in an approved training channel.
6. Ensure the ban is no broader than required.
7. Record the complete entry.
8. Know how to remove it.
9. Confirm the server accepted it and inspect the relevant list.
10. Remove or review temporary entries when the reason ends.

Remove an extended ban using the exact entry that appears in the list:

/MODE #channel -b ~account:AbusiveAccount

13. Quiet or Speak Restrictions

Sometimes the goal is to stop disruptive messages without removing the user from the channel.

Depending on available modes and extended-ban syntax, a channel may:

• Become moderated with +m.
• Remove the user’s voice.
• Apply a targeted speak restriction.
• Restrict unregistered users from speaking.
• Restrict notices or CTCP messages.

A targeted restriction may be less disruptive than banning a user from joining.

However, staff must verify current syntax before applying a quiet or extended ban.

14. Registered-User Restrictions

Modes such as +R and +M, where supported, may restrict participation based on account authentication.

Possible uses include:

• Reducing automated abuse.
• Protecting a channel during a raid.
• Requiring identified users for sensitive discussions.
• Limiting speech while still allowing observation.

Possible disadvantages include:

• Blocking legitimate new users.
• Confusing users who have not configured SASL.
• Interrupting support access.
• Preventing account-recovery requests.
• Affecting relay or gateway users.

Official help channels should be especially careful with restrictions that prevent unidentified users from asking for assistance.

15. TLS-Only Channels

Mode +z, where supported, may restrict the channel to users connected securely through TLS.

This can improve connection security expectations, but staff should remember:

• TLS protects transport between client and server.
• TLS does not prevent channel participants from logging messages.
• TLS does not provide end-to-end encryption between users.
• Users may need help correcting their client configuration.
• Relays or services may require compatible secure connections.

16. Flood-Protection Modes

UnrealIRCd provides two channel anti-flood approaches:

• +F applies a server-defined named flood profile and is available in UnrealIRCd 6.1.0 or later.
• +f provides advanced fine-tuning with thresholds, time windows, actions, and optional automatic mode removal.

These can respond to:

• Message floods.
• Repeated text.
• Join floods.
• Knock floods.
• Nickname-change floods.
• CTCP floods.
• Other rapid activity.

Flood settings may include thresholds, time windows, automatic actions, and automatic removal of emergency modes. For example, an authorized and approved +f profile may temporarily set +R after a join threshold is exceeded, but trainees must not copy an example into a live channel without checking DarkWorld’s approved syntax and thresholds.

An incorrectly configured flood mode may:

• Restrict normal conversation.
• Remove legitimate users.
• Affect busy events.
• Create repeated mode changes.
• Conflict with channel bots.
• Hide the original source of an incident.

Flood-protection modes should be configured according to official DarkWorld guidance and tested in an approved environment.

See UnrealIRCd — Channel anti-flood settings for the upstream technical reference.

Network-level connection flood protection belongs to authorized IRCd administrators, not ordinary channel trainees.

17. Temporary Emergency Modes

During an active raid or severe flood, authorized staff may temporarily apply modes such as:

• +m to moderate the channel.
• +i to prevent uncontrolled joins.
• +R to require registered users.
• +M to restrict speaking.
• +z to require TLS.
• An appropriate user limit.
• Targeted bans or speak restrictions.
• Flood-protection settings.

The responsible staff member should record:

• Which modes were changed.
• Why they were changed.
• The time of the change.
• Who authorized the action.
• When they should be reviewed.
• Which modes existed before the incident.

After the threat ends, temporary emergency modes should be reviewed and removed if no longer necessary.

18. OperOverride and Forced Modes

IRC operators may have elevated capabilities that allow them to bypass normal channel restrictions or force mode changes.

Examples may include:

• OperOverride.
• SAMODE.
• Services-enforced modes.
• Other administrative override commands.

These capabilities are not normal channel-management tools.

They must not be used:

• To win a personal dispute.
• To obtain unauthorized channel access.
• To override a founder without a network-policy reason.
• To demonstrate staff power.
• To avoid normal Services procedures.
• To make undocumented permanent changes.
• On behalf of a friend.

Use of elevated override capabilities should have:

• A valid network-level purpose.
• Appropriate authorization.
• A clear reason.
• Proper documentation.
• Review where required.

Detailed override commands belong in the IRC Operator and Services Administration specialist programs.

19. Common Mode Mistakes

Mistake 1: Broad Ban

/MODE #channel +b *!*@*

This may affect everyone and is normally far broader than necessary.

Mistake 2: Forgetting a Parameter

/MODE #channel +o

The command lacks the nickname required for operator status.

Mistake 3: Wrong Parameter Order

/MODE #channel +ov UserOne UserTwo

This gives +o to UserOne and +v to UserTwo. Reversing the names changes the result.

Mistake 4: Leaving Emergency Modes Enabled

A channel remains invite-only or moderated long after an incident ends, preventing normal participation.

Mistake 5: Removing the Wrong Ban

Staff copy an incomplete or different mask and remove another user’s protection.

Mistake 6: Assuming a Cloak Identifies One Person

Several unrelated users may share a cloak, gateway, provider, or connection system.

Mistake 7: Confusing Channel Status With Staff Status

A person with +q in a channel is treated as though they have network-level authority.

20. Mode Change Procedure

Before changing a significant mode:

1. Confirm the correct channel.
2. View existing modes.
3. View relevant mode lists.
4. Identify the operational purpose.
5. Confirm your authority.
6. Verify the mode syntax.
7. Consider who may be affected.
8. Apply the smallest effective change.
9. Confirm that the server accepted it.
10. Document the reason where required.
11. Review or remove temporary changes later.

After applying a mode, verify it:

/MODE #channel

For a list mode:

/MODE #channel +b

Do not assume that a command succeeded merely because it was entered.

21. Practical Exercises

Perform these exercises only in an approved training channel.

Exercise 1: View Modes

Run:

/MODE YourNickname
/MODE #ApprovedTrainingChannel
/MODE #ApprovedTrainingChannel +b
/MODE #ApprovedTrainingChannel +e
/MODE #ApprovedTrainingChannel +I

Record the results without publishing confidential information.

Exercise 2: Status Modes

With trainer authorization:

/MODE #ApprovedTrainingChannel +v TraineeNick
/MODE #ApprovedTrainingChannel -v TraineeNick
/MODE #ApprovedTrainingChannel +h TraineeNick
/MODE #ApprovedTrainingChannel -h TraineeNick

Explain what changed after each command.

Do not grant +o, +a, or +q unless the trainer specifically authorizes the exercise.

Exercise 3: Moderated Channel

With authorization:

1. Set +m.
2. Confirm that an unvoiced test user cannot speak.
3. Grant the user +v.
4. Confirm that the user can speak.
5. Remove +v.
6. Remove +m.
7. Confirm normal channel behavior is restored.

Exercise 4: Temporary Ban

Using a trainer-provided test identity:

1. Identify the full user mask.
2. Select the least broad effective mask.
3. Add the ban.
4. View the ban list.
5. Remove the exact ban.
6. Verify that it was removed.

Exercise 5: Invite-Only Channel

With authorization:

1. Set +i.
2. Attempt to join using a test user.
3. Invite the user.
4. Confirm the invited user can join.
5. Remove +i.
6. Confirm the original state is restored.

Exercise 6: Emergency Mode Record

Prepare a record containing:

Channel:
Incident:
Original modes:
Temporary modes added:
Time added:
Reason:
Authorized by:
Review time:
Modes removed:
Final channel state:

Exercise 7: Extended Bans

Using only trainer-provided test accounts and hosts in an approved training channel:

1. Add and view an account-based ban.
2. Remove the exact account-based ban.
3. Add a five-minute account-based quiet using compatible extended-ban stacking.
4. Confirm the entry appears in the ban list.
5. Explain why the quiet is less disruptive than a full join ban.
6. Remove the entry if the trainer directs you not to wait for expiry.
7. Confirm that the final ban, exception, and invite-exception lists match their original state.

Do not use a real user, real incident target, broad country/ASN selector, confidential account information, or production channel for this exercise.

22. Practical Scenarios

Scenario 1: Message Flood

One user sends repeated messages rapidly in a busy channel.

Recommended analysis:

A targeted warning, quiet, kick, or ban may be more proportionate than moderating the entire channel. Consider severity and whether the user stops after warning.

Scenario 2: Coordinated Raid

Many newly connected users join and flood simultaneously.

Recommended analysis:

Temporary emergency modes may be necessary. Moderate the channel, restrict joins or speech where authorized, preserve evidence, and escalate the coordinated incident.

Scenario 3: Shared Provider

The disruptive user has a host shared by several legitimate users.

Recommended analysis:

Avoid a broad provider ban if a more precise account, ident, host, or supported extended ban is available.

Scenario 4: Support Channel

An unidentified new user needs help registering but cannot speak because the support channel requires identified users.

Recommended analysis:

The restriction may prevent the channel from serving its purpose. Review whether a different protective measure can control abuse without blocking legitimate support users.

Scenario 5: Forgotten Invite-Only Mode

A channel remains +i the day after an incident.

Recommended analysis:

Review the incident record and current risk. If the restriction is no longer required and you are authorized, restore the normal state and document the change.

Scenario 6: Personal Dispute

An IRC operator uses override powers to give themselves operator status in a channel after arguing with its founder.

Recommended analysis:

This is a potential abuse of staff access. Preserve relevant evidence and escalate to senior management through the confidential process.

23. Knowledge Check

Answer the following questions in your own words:

1. What is the difference between a user mode and a channel mode?
2. What is the difference between user +R and channel +R?
3. Explain the relationship between user +z, channel +z, and server-set channel +Z.
4. How do + and - affect a mode?
5. Which channel status modes correspond to voice, half-operator, operator, administrator, and owner?
6. Does channel operator status provide network authority?
7. What does moderated mode generally do?
8. Why can +m affect innocent users?
9. What is the purpose of +n?
10. What is the purpose of +t?
11. What information is needed to join a keyed channel?
12. What does a user limit do?
13. How do you view a channel’s ban list?
14. What is the difference between +b, +e, and +I?
15. Why should existing mode lists be checked before adding entries?
16. Why is *!*@* normally an unsafe ban?
17. Why can a hostname ban affect unrelated users?
18. When might a targeted speak restriction be better than a ban?
19. What risks can registered-user-only modes create in a help channel?
20. What does TLS-only channel access protect, and what does it not protect?
21. Why must unfamiliar extended bans be verified before use?
22. What should be recorded when applying temporary emergency modes?
23. Why must emergency modes be reviewed afterward?
24. What is OperOverride?
25. When must forced mode changes not be used?
26. Why should a mode change be verified after sending the command?
27. What should staff do after discovering that they changed the wrong mode?

24. Written Assignment

Write approximately 600–800 words analyzing this incident:

During a public event in #Example, six new users join and begin flooding. An operator sets +m, +i, and a broad host ban. The flood stops, but legitimate users can no longer join or speak. Two innocent users share the banned provider host. The operator leaves without recording the changes.

Your answer must explain:

• Which immediate modes may have been justified.
• What risks were created.
• Why the broad host ban requires review.
• How legitimate users should be restored.
• Which information should have been recorded.
• When the temporary modes should be removed.
• How the incident should be escalated.
• What the operator should do differently next time.

25. Module Completion Requirements

To complete this module, the candidate must:

• Read the full lesson.
• Complete all authorized mode exercises.
• Correctly answer at least 21 of the 27 knowledge-check questions.
• Complete the written assignment.
• Demonstrate correct mode syntax.
• Demonstrate safe use and exact removal of trainer-approved extended-ban examples.
• Demonstrate the ability to reverse every training change.
• Avoid unsafe or unauthorized mode changes.
• Receive trainer approval.

26. Trainer Evaluation

Evaluation area	Maximum points
User and channel mode concepts	15
Channel status hierarchy	15
Ban and exception handling	20
Mode syntax and verification	15
Emergency mode judgment	15
Authority boundaries	10
Documentation and restoration	10
Total	100

Recommended passing score: 75 points.

A candidate should not pass if they:

• Repeatedly apply broad restrictions without checking impact.
• Cannot reverse their own changes.
• Use elevated access without authorization.
• Fail to recognize channel and network authority boundaries.
• Disregard the effect of modes on innocent users.

27. Quick Reference

Task	Command
View channel modes	/MODE #channel
Add moderated mode	/MODE #channel +m
Remove moderated mode	/MODE #channel -m
Add invite-only mode	/MODE #channel +i
Remove invite-only mode	/MODE #channel -i
Grant voice	/MODE #channel +v nickname
Remove voice	/MODE #channel -v nickname
Grant operator	/MODE #channel +o nickname
Remove operator	/MODE #channel -o nickname
Add ban	/MODE #channel +b mask
Remove ban	/MODE #channel -b mask
View bans	/MODE #channel +b
View ban exceptions	/MODE #channel +e
View invite exceptions	/MODE #channel +I
Set channel key	/MODE #channel +k key
Set user limit	/MODE #channel +l number
Remove user limit	/MODE #channel -l
Require Services-authenticated joins	/MODE #channel +R
Require Services authentication to speak unless voiced	/MODE #channel +M
Require TLS for new joins	/MODE #channel +z
Add account-based ban	/MODE #channel +b ~account:AccountName
Add account-based quiet	/MODE #channel +b ~quiet:~account:AccountName
Add ten-minute account-based quiet	/MODE #channel +b ~time:10:~quiet:~account:AccountName

28. References and Version Notes

This module was reviewed against the upstream UnrealIRCd 6 documentation listed below:

• User modes
• Channel modes
• Extended bans
• Channel anti-flood settings
• OperOverride

The external documentation describes UnrealIRCd capabilities, not permission to use them. DarkWorld policy, the trainee’s assigned authority, trainer instructions, and the live server configuration take priority. This module should be reviewed after major UnrealIRCd upgrades or material changes to loaded mode modules.

Documentation basis: UnrealIRCd 6 series
Training-page revision: 2026-08

29. Next Module

After passing this module, continue to:

Module 5 — IRC Services

---

Previous: Module 3 — DarkWorld IRC Rules and Policies Program: DarkWorld IRC Staff Training Program Next: Module 5 — IRC Services