Fizi: Created page with "{{DISPLAYTITLE:Module 4 — User and Channel Modes}}
DarkWorld IRC Staff Training
Module 4: User and Channel Modes
{| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 4 of 10 |- ! Difficulty | Intermed..."

2026-08-08T17:34:33Z

Created page with "{{DISPLAYTITLE:Module 4 — User and Channel Modes}} <div style="background:#151515; border-left:5px solid #8b5cf6; color:#eeeeee; padding:16px; margin-bottom:20px;"> <span style="font-size:170%; font-weight:bold;">DarkWorld IRC Staff Training</span><br> <span style="font-size:125%;">Module 4: User and Channel Modes</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 4 of 10 |- ! Difficulty | Intermed..."

New page

{{DISPLAYTITLE:Module 4 — User and Channel Modes}}

<div style="background:#151515; border-left:5px solid #8b5cf6; color:#eeeeee; padding:16px; margin-bottom:20px;">
<span style="font-size:170%; font-weight:bold;">DarkWorld IRC Staff Training</span><br>
<span style="font-size:125%;">Module 4: User and Channel Modes</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! 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
| [[DWIRC:Staff Training/Policies|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.

<div style="background:#fff8e1; border-left:4px solid #f59e0b; padding:12px; margin:15px 0;">
'''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.
</div>

= Learning Objectives =

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

# Explain the difference between user modes and channel modes.
# View current user and channel modes.
# Understand channel access levels.
# Add and remove modes using correct syntax.
# Explain when a mode requires a parameter.
# View and interpret channel ban lists.
# Create reasonably precise ban masks.
# Explain ban, exception, and invite-exception lists.
# Use moderated and invite-only modes correctly.
# Understand registered-user and TLS-related restrictions.
# Recognize the risks of broad or conflicting modes.
# 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:

<pre>
+i
+m
+n
+t
+k
+l
+b
</pre>

The plus sign adds a mode:

<pre>
/MODE #channel +m
</pre>

The minus sign removes a mode:

<pre>
/MODE #channel -m
</pre>

Some modes require parameters.

Example:

<pre>
/MODE #channel +k SecretKey
</pre>

Other modes do not require parameters:

<pre>
/MODE #channel +m
</pre>

= 2. User Modes and Channel Modes =

== User Modes ==

User modes apply to an individual IRC connection.

To view your current user modes:

<pre>
/MODE YourNickname
</pre>

A user normally sets only their own permitted user modes.

== Channel Modes ==

Channel modes apply to a channel.

To view the current modes:

<pre>
/MODE #channel
</pre>

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:

<pre>
/MODE target modes parameters
</pre>

Examples:

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

Multiple modes may be combined:

<pre>
/MODE #Training +mnt
</pre>

Modes requiring parameters must have corresponding parameters:

<pre>
/MODE #Training +ov Falcon Eagle
</pre>

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:

{| class="wikitable" style="width:100%;"
! 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:

<pre>
/MODE #channel +v nickname
</pre>

Remove voice:

<pre>
/MODE #channel -v nickname
</pre>

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:

<pre>
/MODE #channel +h nickname
</pre>

Remove half-operator:

<pre>
/MODE #channel -h nickname
</pre>

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

== Channel Operator: +o ==

Grant operator:

<pre>
/MODE #channel +o nickname
</pre>

Remove operator:

<pre>
/MODE #channel -o nickname
</pre>

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:

<pre>
/MODE #channel +a nickname
</pre>

Remove administrator status:

<pre>
/MODE #channel -a nickname
</pre>

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

== Channel Owner: +q ==

Grant owner status:

<pre>
/MODE #channel +q nickname
</pre>

Remove owner status:

<pre>
/MODE #channel -q nickname
</pre>

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

<div style="background:#e8f4fd; border-left:4px solid #2563eb; padding:12px; margin:15px 0;">
'''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.
</div>

= 5. Common Channel Modes =

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

{| class="wikitable" style="width:100%;"
! 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:

<pre>
/MODE #channel +i
</pre>

Remove:

<pre>
/MODE #channel -i
</pre>

Invite a user:

<pre>
/INVITE nickname #channel
</pre>

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:

<pre>
/MODE #channel +m
</pre>

Remove:

<pre>
/MODE #channel -m
</pre>

Grant voice:

<pre>
/MODE #channel +v nickname
</pre>

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.

<pre>
/MODE #channel +n
</pre>

This is a common protective mode for public channels.

== Topic Protection: +t ==

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

<pre>
/MODE #channel +t
</pre>

== Secret: +s ==

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

<pre>
/MODE #channel +s
</pre>

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:

<pre>
/MODE #channel +k TrainingKey
</pre>

Join:

<pre>
/JOIN #channel TrainingKey
</pre>

Remove:

<pre>
/MODE #channel -k TrainingKey
</pre>

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:

<pre>
/MODE #channel +l 50
</pre>

Remove the limit:

<pre>
/MODE #channel -l
</pre>

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:

{| class="wikitable" style="width:100%;"
! 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:

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

= 7. Viewing Mode Lists =

== Ban List ==

<pre>
/MODE #channel +b
</pre>

== Ban-Exception List ==

<pre>
/MODE #channel +e
</pre>

== Invite-Exception List ==

<pre>
/MODE #channel +I
</pre>

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:

<pre>
/MODE #channel +b mask
</pre>

Remove a ban:

<pre>
/MODE #channel -b mask
</pre>

Examples:

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

== Ban-Mask Precision ==

Consider the following masks:

{| class="wikitable" style="width:100%;"
! 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:

# Set the appropriate ban.
# Remove the user with a clear reason.
# Record the action when required.
# Review the ban later.

Example:

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

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:

<pre>
/MODE #channel +e mask
</pre>

Remove>
an exception:

<pre>
/MODE #channel -e mask
</pre>

Example:

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

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:

<pre>
/MODE #channel +I mask
</pre>

Remove:

<pre>
/MODE #channel -I mask
</pre>

Example:

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

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:

# Check DarkWorld’s current UnrealIRCd documentation.
# Use the server’s official help.
# Verify the exact matching behavior.
# Test only in an approved training channel.
# Ensure the ban is no broader than required.
# Record the complete entry.
# 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 ==

<pre>
/MODE #channel +b *!*@*
</pre>

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

== Mistake 2: Forgetting a Parameter ==

<pre>
/MODE #channel +o
</pre>

The command lacks the nickname required for operator status.

== Mistake 3: Wrong Parameter Order ==

<pre>
/MODE #channel +ov UserOne UserTwo
</pre>

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:

# Confirm the correct channel.
# View existing modes.
# View relevant mode lists.
# Identify the operational purpose.
# Confirm your authority.
# Verify the mode syntax.
# Consider who may be affected.
# Apply the smallest effective change.
# Confirm that the server accepted it.
# Document the reason where required.
# Review or remove temporary changes later.

After applying a mode, verify it:

<pre>
/MODE #channel
</pre>

For a list mode:

<pre>
/MODE #channel +b
</pre>

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:

<pre>
/MODE YourNickname
/MODE #ApprovedTrainingChannel
/MODE #ApprovedTrainingChannel +b
/MODE #ApprovedTrainingChannel +e
/MODE #ApprovedTrainingChannel +I
</pre>

Record the results without publishing confidential information.

== Exercise 2: Status Modes ==

With trainer authorization:

<pre>
/MODE #ApprovedTrainingChannel +v TraineeNick
/MODE #ApprovedTrainingChannel -v TraineeNick
/MODE #ApprovedTrainingChannel +h TraineeNick
/MODE #ApprovedTrainingChannel -h TraineeNick
</pre>

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:

# Set `+m`.
# Confirm that an unvoiced test user cannot speak.
# Grant the user `+v`.
# Confirm that the user can speak.
# Remove `+v`.
# Remove `+m`.
# Confirm normal channel behavior is restored.

== Exercise 4: Temporary Ban ==

Using a trainer-provided test identity:

# Identify the full user mask.
# Select the least broad effective mask.
# Add the ban.
# View the ban list.
# Remove the exact ban.
# Verify that it was removed.

== Exercise 5: Invite-Only Channel ==

With authorization:

# Set `+i`.
# Attempt to join using a test user.
# Invite the user.
# Confirm the invited user can join.
# Remove `+i`.
# Confirm the original state is restored.

== Exercise 6: Emergency Mode Record ==

Prepare a record containing:

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

= 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:

# What is the difference between a user mode and a channel mode?
# How do `+` and `-` affect a mode?
# Which channel status modes correspond to voice, half-operator, operator, administrator, and owner?
# Does channel operator status provide network authority?
# What does moderated mode generally do?
# Why can `+m` affect innocent users?
# What is the purpose of `+n`?
# What is the purpose of `+t`?
# What information is needed to join a keyed channel?
# What does a user limit do?
# How do you view a channel’s ban list?
# What is the difference between `+b`, `+e`, and `+I`?
# Why should existing mode lists be checked before adding entries?
# Why is `*!*@*` normally an unsafe ban?
# Why can a hostname ban affect unrelated users?
# When might a targeted speak restriction be better than a ban?
# What risks can registered-user-only modes create in a help channel?
# What does TLS-only channel access protect, and what does it not protect?
# Why must unfamiliar extended bans be verified before use?
# What should be recorded when applying temporary emergency modes?
# Why must emergency modes be reviewed afterward?
# What is OperOverride?
# When must forced mode changes not be used?
# Why should a mode change be verified after sending the command?
# What should staff do after discovering that they changed the wrong mode?

= 24. Written Assignment =

Write approximately '''600–800 words''' analyzing this incident:

<blockquote>
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.
</blockquote>

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 =

{| class="wikitable" style="width:100%;"
! 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 =

{| class="wikitable" style="width:100%;"
! 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:

'''[[DWIRC:Staff Training/IRC Services|Module 5 — IRC Services]]'''

----

'''Previous:''' [[DWIRC:Staff Training/Policies|Module 3 — DarkWorld IRC Rules and Policies]]
'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
'''Next:''' [[DWIRC:Staff Training/IRC Services|Module 5 — IRC Services]]

[[Category:DarkWorld IRC Staff Training]]
[[Category:DWIRC]]
[[Category:IRC Modes]]
[[Category:Staff Documentation]]

DWIRC:Staff Training/User and Channel Modes - Revision history

Fizi at 22:09, 23 August 2026

Fizi: Protected "DWIRC:Staff Training/User and Channel Modes" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

Fizi: Created page with "{{DISPLAYTITLE:Module 4 — User and Channel Modes}}
DarkWorld IRC Staff Training
Module 4: User and Channel Modes
{| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 4 of 10 |- ! Difficulty | Intermed..."

← Older revision	Revision as of 22:35, 8 August 2026
(No difference)

DWIRC:Staff Training/User and Channel Modes - Revision history

Fizi at 22:09, 23 August 2026

Fizi: Protected "DWIRC:Staff Training/User and Channel Modes" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

Fizi: Created page with "{{DISPLAYTITLE:Module 4 — User and Channel Modes}} DarkWorld IRC Staff Training Module 4: User and Channel Modes {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 4 of 10 |- ! Difficulty | Intermed..."

Fizi: Created page with "{{DISPLAYTITLE:Module 4 — User and Channel Modes}}
DarkWorld IRC Staff Training
Module 4: User and Channel Modes
{| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 4 of 10 |- ! Difficulty | Intermed..."