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	3–4 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.

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.

Learning Objectives

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

1. Explain the difference between user modes and channel modes.
2. View current user and channel modes.
3. Understand channel access levels.
4. Add and remove modes using correct syntax.
5. Explain when a mode requires a parameter.
6. View and interpret channel ban lists.
7. Create reasonably precise ban masks.
8. Explain ban, exception, and invite-exception lists.
9. Use moderated and invite-only modes correctly.
10. Understand registered-user and TLS-related restrictions.
11. Recognize the risks of broad or conflicting modes.
12. Record and reverse temporary mode changes.

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.

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 commonly allows a user to speak while the channel is moderated with `+m`.

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 Security and Control Modes

UnrealIRCd may provide additional channel modes. Availability and behavior depend on the current configuration.

Common examples may include:

Mode	Common purpose
`+C`	Restricts channel CTCP messages
`+c`	Restricts color or formatting codes
`+S`	Strips color or formatting codes
`+T`	Restricts channel notices
`+R`	Restricts joining to registered or identified users
`+M`	Restricts speaking to registered or identified users
`+z`	Restricts joining to secure TLS connections
`+K`	Restricts use of the KNOCK command
`+V`	Restricts channel invitations
`+N`	Restricts nickname changes while in the channel
`+Q`	Restricts channel kicks

The exact meaning may differ by UnrealIRCd version or loaded modules.

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 supports extended ban types that can match more than a basic `nick!ident@host` mask.

Depending on the current server version and configuration, extended bans may match or act upon:

• Registered account.
• Real-name field.
• Security group.
• Certificate fingerprint.
• Users in another channel.
• Specific message types.
• Other connection properties.

Some extended bans can also restrict speaking without preventing a user from joining.

Because syntax and availability are version-specific, candidates must not memorize examples from unrelated networks and assume they work on DarkWorld IRC.

Before applying an extended ban:

1. Check DarkWorld’s current UnrealIRCd documentation.
2. Use the server’s official help.
3. Verify the exact matching behavior.
4. Test only in an approved training channel.
5. Ensure the ban is no broader than required.
6. Record the complete entry.
7. Know how to remove it.

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 may provide configurable flood-protection channel modes.

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, and automatic actions.

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.

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:

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

28. 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