DWIRC:Staff Training/IRC Services

DarkWorld IRC Staff Training
Module 5: IRC Services

Program	DarkWorld IRC Staff Training Program
Module	5 of 10
Difficulty	Intermediate
Estimated study time	3–4 hours
Assessment	Knowledge check, support exercises, and Services scenarios
Prerequisite	Module 4 — User and Channel Modes

Module Overview

DarkWorld IRC uses IRC Services to provide registered accounts, channel registration, access control, virtual hosts, and other persistent network features.

DarkWorld IRC currently uses Anope Services. Available commands depend on the installed Anope version, loaded modules, and DarkWorld configuration.

This module teaches candidates how to:

• Understand IRC Services.
• Assist users with NickServ.
• Assist with registered channels through ChanServ.
• Understand HostServ and virtual hosts.
• Recognize MemoServ and BotServ functions where enabled.
• Distinguish normal user support from Services administration.
• Handle account and channel disputes safely.
• Protect passwords and recovery information.
• Escalate high-risk Services requests.

Important: Always confirm current command syntax with the service’s own `HELP` command. Do not copy administrative commands from another IRC network or a different Anope version.

Learning Objectives

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

1. Explain the purpose of IRC Services.
2. Distinguish a nickname from a registered account.
3. Help a user register and identify securely.
4. Explain SASL authentication.
5. Use NickServ information commands safely.
6. Explain ChanServ channel registration and access.
7. Distinguish channel status from persistent Services access.
8. Understand HostServ and virtual hosts.
9. Recognize common account and channel problems.
10. Protect passwords and recovery information.
11. Identify requests requiring Services Administrator escalation.
12. Avoid unauthorized account or channel modifications.

1. What Are IRC Services?

IRC Services are specialized systems connected to the IRC network.

They provide persistent features that ordinary IRC servers do not maintain by themselves.

Services may include:

Service	General purpose
NickServ	Registered accounts, nickname management, and authentication
ChanServ	Channel registration, access, settings, and enforcement
MemoServ	Offline messages between registered accounts, where enabled
HostServ	Virtual hosts and cloaks
BotServ	Services bots and channel bot features, where enabled
OperServ	Administrative Services and network operations

Services commands are generally sent through:

/MSG ServiceName COMMAND parameters

Example:

/MSG NickServ HELP

Many clients also support aliases such as:

/NS HELP
/CS HELP
/HS HELP
/MS HELP
/BS HELP
/OS HELP

Aliases depend on the IRC client. The full `/MSG` form is generally more portable.

2. Services Security

Services accounts may control:

• Registered nicknames.
• Registered channels.
• Channel access lists.
• Channel founder privileges.
• Virtual hosts.
• Memos.
• Other persistent network resources.

A compromised Services account can therefore cause serious damage.

Staff must never ask users to provide:

• Their account password.
• A SASL password.
• A password-reset code.
• An email-verification code.
• A two-factor authentication secret.
• A private key or certificate.
• A screenshot showing credentials.

Staff should never identify to a user’s account on the user’s behalf.

Correct Support Approach

Staff should:

1. Explain the official command or recovery process.
2. Direct the user to a private Services query.
3. Confirm that the service nickname is correct.
4. Avoid asking the user to paste credentials.
5. Verify ownership through approved procedures.
6. Escalate unresolved ownership cases.
7. Record administrative intervention where required.

3. Nicknames and Registered Accounts

A visible nickname and a registered account are related but separate.

Example:

Information	Example
Current nickname	Falcon-Away
Registered account	Falcon
Ident	falcon
Displayed hostname	User.DarkWorld.Network

A user may:

• Use a nickname that is not registered.
• Use a nickname associated with an account but remain unidentified.
• Authenticate to one account while using another grouped nickname.
• Change nicknames while remaining authenticated.
• Connect through multiple clients using the same account, subject to policy.

Where identity matters, staff should check the registered account rather than relying solely on the current nickname.

4. NickServ Help

General help:

/MSG NickServ HELP

Help for a specific command:

/MSG NickServ HELP REGISTER
/MSG NickServ HELP IDENTIFY
/MSG NickServ HELP INFO

Candidates should use current Services help before instructing a user.

5. Registering a NickServ Account

The normal registration syntax may resemble:

/MSG NickServ REGISTER password email@example.com

The exact syntax must be confirmed with:

/MSG NickServ HELP REGISTER

DarkWorld IRC may require a valid email address and confirmation before registration becomes complete.

Secure Registration Guidance

Users should:

• Use a strong and unique password.
• Use an email address they control.
• Enter the command in the NickServ query.
• Verify that the recipient is the official NickServ.
• Complete any required email confirmation.
• Configure SASL after registration.
• Avoid reusing passwords from other services.

Staff Must Not

Staff must not:

• Choose the user’s password.
• Ask the user to post the registration command publicly.
• Register accounts on behalf of users without authorization.
• Use a temporary password known to staff unless an approved recovery procedure specifically requires it.
• Bypass email verification without authority.
• Promise that a requested nickname will be granted.

6. Email Confirmation

Where email confirmation is enabled, NickServ may provide a confirmation code or instructions.

The user should check:

• Inbox.
• Spam or junk folder.
• Whether the address was entered correctly.
• Whether the email provider delayed the message.
• Whether the account is still awaiting confirmation.

Users should follow the exact instructions provided by NickServ and the confirmation email.

Staff should never ask a user to post the confirmation code in a public channel.

If confirmation repeatedly fails, staff should collect:

• Account name.
• Approximate registration time.
• Non-sensitive error message.
• Whether any email arrived.
• The email domain, if relevant and appropriate.

The case may then be escalated without requesting the full private email address publicly.

7. Identifying to NickServ

A common identification command is:

/MSG NickServ IDENTIFY account password

Depending on Services configuration, a user already using the account’s nickname may be able to use:

/MSG NickServ IDENTIFY password

The current syntax should be checked:

/MSG NickServ HELP IDENTIFY

Common Identification Problems

• Incorrect account name.
• Incorrect password.
• Unconfirmed registration.
• Typing the command into a channel.
• Sending the command to an impersonating nickname.
• Client automatically identifying with outdated credentials.
• SASL and manual identification using different passwords.
• Account suspension or restriction.
• Temporary Services unavailability.

Staff should ask for the exact error message, not the password.

8. SASL Authentication

SASL authenticates a user during connection.

Recommended general settings are:

Setting	Value
Connection security	TLS enabled
SASL	Enabled
Mechanism	PLAIN, where supported over verified TLS
Username	Registered NickServ account
Password	NickServ account password

Benefits include:

• Authentication before joining channels.
• Immediate recognition by Services.
• Better access to registered-user channels.
• Reduced nickname-enforcement problems.
• More reliable account-based permissions.

When SASL fails, staff should check:

1. The account name.
2. Whether the account is confirmed.
3. Whether TLS is enabled.
4. The selected SASL mechanism.
5. Whether the client saved an old password.
6. The exact server error.
7. Whether manual identification works.

The user should make these checks privately and must not reveal the password.

9. NickServ INFO

To view public account or nickname information:

/MSG NickServ INFO nickname

The response may show:

• Registered account.
• Registration date.
• Last-seen information.
• Account options.
• Grouped nickname information.
• Virtual host.
• Other public metadata.

The exact output depends on permissions and configuration.

NickServ INFO does not prove a person’s legal identity.

Staff must not disclose additional restricted information merely because they can access it.

10. Account Status

Where available, a status command may help determine whether a nickname is recognized or identified:

/MSG NickServ STATUS nickname

Current availability and status meanings must be confirmed through:

/MSG NickServ HELP STATUS

A WHOIS response may also show whether a user is logged into a Services account.

Staff should distinguish:

• Using a registered nickname.
• Being identified to an account.
• Being grouped to an account.
• Owning an external identity with the same name.

11. Changing Account Settings

NickServ may provide commands for changing:

• Password.
• Email address.
• Language.
• Privacy settings.
• Account protection.
• Other preferences.

Users should begin with:

/MSG NickServ HELP SET

Then request help for the specific option.

Example:

/MSG NickServ HELP SET PASSWORD

Staff should avoid giving remembered syntax for security-sensitive changes unless it has been verified against the current Services help.

After changing a password, the user should also update:

• SASL configuration.
• Automatic identify commands.
• IRC bouncer settings.
• Mobile IRC clients.
• Any other authorized connection using the account.

12. Nickname Recovery

A registered nickname may remain connected because:

• The user lost their connection.
• A bouncer is still connected.
• Another device is connected.
• Someone else is using the nickname.
• A stale session remains temporarily.
• The user is authenticated under another nickname.

NickServ may provide commands such as:

/MSG NickServ RECOVER nickname
/MSG NickServ RELEASE nickname
/MSG NickServ GHOST nickname

Availability and parameters must be verified:

/MSG NickServ HELP RECOVER
/MSG NickServ HELP RELEASE
/MSG NickServ HELP GHOST

Recovery Procedure

Staff should ask the user to:

1. Connect with a temporary nickname.
2. Authenticate to the correct account through SASL or NickServ.
3. Check the nickname’s account information.
4. Use the supported recovery command.
5. Change to the recovered nickname.
6. Review other connected clients or bouncers.
7. Change the password if unauthorized access is suspected.

Staff should not forcibly disconnect a nickname merely because another user claims ownership.

13. Lost Account Access

A user may lose account access because:

• They forgot the password.
• They lost access to the registered email.
• The email address is incorrect.
• The account was compromised.
• The account was suspended.
• The user confused the nickname with the account name.
• The account expired under applicable policy.
• The account was never confirmed.

Safe Recovery Principles

Account recovery must be based on approved ownership verification.

Staff should not accept as sufficient proof:

• “Everyone knows this is my nickname.”
• A matching display name.
• A similar social-media username.
• Friendship with a staff member.
• An old screenshot without supporting information.
• Knowledge of public account details.

Administrative recovery should be handled only by authorized Services staff.

14. Grouped Nicknames

Where enabled, NickServ may allow additional nicknames to be grouped under one account.

General help may be available through:

/MSG NickServ HELP GROUP

Grouped nicknames:

• May be associated with the same account.
• Do not create separate staff identities.
• May share account-based channel access.
• Still require compliance with nickname policies.
• Must not be used for impersonation or ban evasion.

Staff should confirm the registered account rather than assuming separate grouped nicknames belong to different people.

15. ChanServ

ChanServ manages registered channels.

General help:

/MSG ChanServ HELP

Common functions include:

• Channel registration.
• Channel information.
• Access management.
• Channel settings.
• Mode locking.
• Automatic kicks or bans.
• Founder and successor management.
• Topic and channel protection.
• Channel dropping or transfer.

Some actions are high risk and restricted to channel founders or Services administrators.

16. Channel Registration

The current registration command should be checked:

/MSG ChanServ HELP REGISTER

Depending on configuration, a user may need to:

• Be identified to a registered account.
• Be present in the channel.
• Hold channel operator status.
• Meet registration limits.
• Comply with channel-registration policy.
• Provide a description.
• Ensure the channel is not already registered or restricted.

Registration gives persistent Services control, but does not exempt the channel from network policy.

Staff Support Procedure

When a user cannot register a channel:

1. Confirm they are identified.
2. Confirm the exact channel name.
3. Check whether the channel is already registered.
4. Check the exact ChanServ response.
5. Check applicable registration requirements.
6. Avoid overriding existing ownership.
7. Escalate disputes or restricted channels.

17. ChanServ INFO

To view channel registration information:

/MSG ChanServ INFO #channel

Information may include:

• Registration date.
• Founder or owning account.
• Description.
• Successor.
• Channel settings.
• Last-used information.
• Mode-lock information.
• Other public registration details.

Restricted information must remain confidential.

18. Channel Founder

The founder is the account with primary Services ownership of a registered channel.

Founder status may provide authority to:

• Manage channel access.
• Change channel settings.
• Assign a successor.
• Manage mode locks.
• Drop or transfer the channel.
• Perform other high-level ChanServ actions.

Channel founder status is not the same as:

• IRC operator status.
• Network ownership.
• Services Administrator status.
• Authority over other channels.
• Authority over other DarkWorld projects.

Founder-related changes are security-sensitive and must be handled carefully.

19. Channel Access

ChanServ access provides persistent privileges based on registered accounts or configured entries.

Current help:

/MSG ChanServ HELP ACCESS

Depending on configuration, access may use:

• Numeric access levels.
• Named privileges.
• Flags.
• Templates.
• Founder-defined access groups.

Common operations may include:

/MSG ChanServ ACCESS #channel LIST
/MSG ChanServ ACCESS #channel ADD account level
/MSG ChanServ ACCESS #channel DEL account

Exact syntax and permitted levels must be verified.

Services Access vs Live Channel Status

Services access and live channel status are different.

For example:

• `+o` is the user’s current channel operator status.
• ChanServ access may allow the user to obtain `+o` automatically or on request.
• Removing live `+o` may not remove the persistent ChanServ access.
• Removing ChanServ access may not immediately remove a currently held mode.

Staff must identify whether a problem concerns:

• A temporary live mode.
• A persistent access-list entry.
• Founder ownership.
• An account compromise.
• A channel-mode lock.

20. Channel Access Security

Channel founders should:

• Grant access to registered accounts rather than uncertain masks where practical.
• Assign only necessary privileges.
• Review access lists periodically.
• Remove former staff promptly.
• Avoid giving founder-equivalent access unnecessarily.
• Confirm account names carefully.
• Document major access changes.
• Use a successor where appropriate.
• Secure their own NickServ account.

Before adding access, verify:

1. The exact channel.
2. The exact account.
3. The requested privilege.
4. The requester’s authority.
5. Whether the access is temporary or permanent.
6. Whether a lower level is sufficient.

21. Mode Lock

ChanServ may enforce selected channel modes through a mode-lock system.

Help may be available through:

/MSG ChanServ HELP SET MLOCK

A mode lock can:

• Require specified modes.
• Prevent specified modes.
• Restore channel modes after unauthorized changes.
• Apply mode parameters such as a limit or key.

Incorrect mode locks may:

• Prevent legitimate changes.
• Lock users out.
• Conflict with emergency moderation.
• Expose or mishandle channel keys.
• Cause repeated mode changes.

Only authorized channel management or Services staff should change mode locks.

22. ChanServ AKICK

An automatic-kick list may prevent matching users from remaining in a registered channel.

Current help:

/MSG ChanServ HELP AKICK

Possible operations may include adding, deleting, and listing entries.

An AKICK entry can be more persistent than a normal live channel ban.

Before adding one, consider:

• The accuracy of the mask or account.
• Whether the restriction should be temporary.
• The risk to users on shared hosts.
• Whether channel policy supports the action.
• Whether the requester has authority.
• Whether a normal channel ban is sufficient.

Trainees must not modify another channel’s AKICK list without authorization.

23. ChanServ OP and Status Commands

ChanServ may provide commands for granting or removing channel status.

Possible help topics include:

/MSG ChanServ HELP OP
/MSG ChanServ HELP DEOP
/MSG ChanServ HELP VOICE
/MSG ChanServ HELP DEVOICE

Staff should not use Services to obtain channel status unless their account has legitimate access and there is an authorized operational reason.

Services commands must not be used to bypass channel management.

24. Dropping or Transferring a Channel

Dropping or changing ownership of a registered channel is a high-risk action.

It can result in:

• Loss of access lists.
• Loss of settings.
• Channel takeover.
• Disruption to a community or project.
• Difficult ownership disputes.

Trainees and ordinary support staff must never:

• Drop a user’s channel for them.
• Change a founder based only on a verbal claim.
• Transfer a channel to resolve a personal dispute.
• bypass the approved ownership-review process.
• Ask a user to post founder credentials.

Such requests must be escalated to authorized Services administration.

25. Channel Ownership Disputes

A dispute may involve:

• A founder who is absent.
• A compromised founder account.
• Former project staff retaining access.
• Competing claims of project ownership.
• A channel that expired and was re-registered.
• A founder who transferred access informally.
• A registered project’s official identity.
• A staff member using override access.

Required Approach

1. Preserve the current state.
2. Avoid making irreversible changes.
3. Identify the registered founder account.
4. Collect relevant dates and records.
5. Separate channel ownership from external project ownership.
6. Check applicable channel-registration policy.
7. Disclose any staff conflict of interest.
8. Escalate to authorized Services management.
9. Record the final decision and reason.

External ownership of a domain, business, or social-media account may be relevant, but it does not automatically replace the Services ownership-review process.

26. HostServ and Virtual Hosts

HostServ manages virtual hosts, commonly called vhosts.

A vhost replaces or supplements the displayed hostname with an approved identity.

Example:

User.DarkWorld.Network

DarkWorld IRC may automatically apply an approved vhost when a user registers or identifies, according to current configuration.

Common user help:

/MSG HostServ HELP
/MSG HostServ HELP ON
/MSG HostServ HELP OFF
/MSG HostServ HELP REQUEST

Available commands depend on configuration.

Vhost Principles

A vhost:

• Improves privacy by hiding the original displayed host.
• Can show an approved identity or affiliation.
• Does not prove a legal identity by itself.
• Does not provide staff authority.
• Does not exempt a user from rules.
• Must comply with naming and impersonation policies.
• Must not falsely represent an official DarkWorld role or project.

Administrative vhost assignment must be performed only by authorized staff.

27. MemoServ

MemoServ may allow registered users to send messages that can be read later.

General help:

/MSG MemoServ HELP

Possible functions include:

• Sending a memo.
• Listing memos.
• Reading a memo.
• Deleting a memo.
• Managing memo notifications.

Memos should not be used to send:

• Passwords.
• Authentication tokens.
• Private keys.
• Unapproved mass advertising.
• Harassment.
• Threats.
• Sensitive evidence without an approved process.

Availability depends on the current Services configuration.

28. BotServ

BotServ may provide Services-managed bots for registered channels.

General help:

/MSG BotServ HELP

Possible features include:

• Assigning an approved Services bot.
• Channel greetings.
• Bad-word controls.
• Kick settings.
• Fantasy commands.
• Other channel automation.

BotServ features must not replace good moderation judgment.

A channel’s use of BotServ remains subject to network policy.

29. OperServ

OperServ provides high-level Services administration.

It may be used for:

• Services administration.
• Account suspension.
• Channel suspension.
• Services database operations.
• Network restrictions.
• Administrative overrides.
• Services maintenance.
• Other privileged operations.

Restricted area: OperServ commands are not part of ordinary candidate training. Knowledge of a command does not authorize its use.

OperServ access should require:

• A specific operational role.
• Management approval.
• Strong account security.
• Least-privilege permissions.
• Appropriate logging.
• Specialist training.
• Review of important actions.

30. Services Administrator Escalation

Escalate when a case involves:

• Lost access without normal recovery options.
• A compromised account.
• Account suspension.
• Founder or channel ownership changes.
• Channel transfer or drop requests.
• Services impersonation.
• Suspected Services database problems.
• Incorrect automatic vhosts.
• Administrative access changes.
• Large-scale Services failure.
• A disputed account or project identity.
• An action affecting multiple users or channels.
• Requests for confidential Services information.

The escalation should include:

Date and time:
Requesting user:
Current nickname:
Claimed account:
Affected channel:
Exact Services response:
Actions already attempted:
Relevant public information:
Evidence available:
Security concern:
Requested outcome:

Do not include passwords, recovery codes, or authentication secrets.

31. Services Outage Recognition

A Services outage may appear as:

• NickServ and ChanServ disconnecting.
• Identification commands receiving no response.
• Users losing automatically assigned channel status.
• Registered nicknames not being enforced.
• Channel modes changing unexpectedly.
• SASL authentication failing for many users.
• HostServ vhosts not being applied.
• Services reconnecting repeatedly.

If many users are affected:

1. Do not advise everyone to reset passwords.
2. Check whether Services are connected.
3. Record the approximate start time.
4. Notify authorized operational staff.
5. Reassure users without making unsupported promises.
6. Avoid permanent access changes during unstable synchronization.
7. Confirm recovery after Services return.

32. Common Services Support Mistakes

Asking for a Password

Staff do not need the user’s password to explain the official recovery process.

Trusting the Current Nickname

A nickname alone does not prove account ownership.

Changing Ownership Too Quickly

A founder dispute requires evidence and authorized review.

Confusing Live Modes With Access

Removing `+o` does not necessarily remove persistent ChanServ access.

Using OperServ for Convenience

Administrative commands should not replace normal user procedures.

Ignoring Other Connected Clients

A “stolen” nickname may actually be held by the user’s bouncer, mobile client, or another authorized session.

Publishing Account Information

Restricted Services information must not be posted publicly.

33. Practical Exercises

Perform these exercises only with your own training account and an approved training channel.

Exercise 1: Services Help

Run:

/MSG NickServ HELP
/MSG NickServ HELP INFO
/MSG ChanServ HELP
/MSG ChanServ HELP INFO
/MSG HostServ HELP

Record which commands are currently available without copying confidential account data.

Exercise 2: Account Verification

Using your own account:

1. Run WHOIS on your nickname.
2. Run NickServ INFO on your nickname.
3. Identify the current nickname.
4. Identify the registered account.
5. Explain the difference.

Exercise 3: SASL Configuration

Configure SASL in an approved IRC client.

Verify that:

• TLS is enabled.
• Certificate verification is enabled.
• Authentication succeeds during connection.
• WHOIS shows the expected account.
• No password appears in public output.

Exercise 4: Channel Information

In an approved training channel:

/MSG ChanServ INFO #ApprovedTrainingChannel

Identify:

• Whether the channel is registered.
• Founder or owning account, if publicly visible.
• Registration date, if available.
• Current settings visible to you.

Exercise 5: Live Mode vs Services Access

Explain the difference between:

/MODE #channel +o nickname

and a persistent ChanServ access-list entry.

No access changes should be performed without trainer authorization.

Exercise 6: Recovery Guidance

Prepare safe instructions for a user who:

• Is connected with a temporary nickname.
• Owns a registered account.
• Cannot use their usual nickname.
• Still has access to their account password.
• May have another client connected.

Do not ask the user to reveal the password.

34. Practical Scenarios

Scenario 1: Password in Help Channel

A user posts their IDENTIFY command, including the password, in `#Help`.

Recommended response:

Do not repeat the password. Tell the user to change it immediately through the official NickServ process and update SASL or other saved connections. Escalate if the account may have been compromised.

Scenario 2: Founder Claim

A user says they created a channel many years ago and wants staff to remove its current founder.

Recommended response:

Do not alter ownership based on the claim alone. Collect relevant non-sensitive information and escalate through the authorized ownership-review process.

Scenario 3: Missing Channel Operator Status

A channel staff member says ChanServ did not automatically give them `+o`.

Recommended response:

Confirm their registered account, whether they are identified, the channel’s access list, current settings, and the exact Services response. Distinguish persistent access from the current live mode.

Scenario 4: Automatic Vhost Missing

A registered user says their normal vhost was not applied after connection.

Recommended response:

Confirm whether they are authenticated, whether SASL succeeded, and what HostServ reports. Do not expose the original host publicly. Escalate a configuration problem if necessary.

Scenario 5: Account Impersonation

A nickname resembling NickServ sends private messages asking users for their passwords.

Recommended response:

Treat this as a serious phishing and impersonation incident. Warn affected users without repeating sensitive information, preserve evidence, and escalate immediately.

Scenario 6: Services Disconnection

NickServ, ChanServ, and HostServ disappear at the same time.

Recommended response:

Treat it as a possible Services outage. Notify operational staff, avoid unnecessary permanent changes, record the time, and wait for proper synchronization after Services return.

35. Knowledge Check

Answer the following questions in your own words:

1. What is the purpose of IRC Services?
2. What is the difference between a nickname and a registered account?
3. Why must staff never ask for a user’s password?
4. How should command syntax be verified?
5. What information may NickServ INFO provide?
6. What does SASL do?
7. Why should SASL be used over verified TLS?
8. What should a user update after changing their account password?
9. Why might a user’s nickname remain connected after they disconnect?
10. What is the safe nickname-recovery process?
11. What evidence is insufficient by itself for administrative account recovery?
12. What are grouped nicknames?
13. What does ChanServ provide?
14. What requirements may apply to channel registration?
15. What is the difference between live `+o` and ChanServ access?
16. Why should persistent access be granted to accounts carefully?
17. What is a mode lock?
18. What risk can an incorrect mode lock create?
19. Why is an AKICK entry more sensitive than a temporary kick?
20. Does channel founder status provide network authority?
21. How should a channel ownership dispute be handled?
22. What is a vhost?
23. Does a vhost prove that someone is staff?
24. What is OperServ?
25. Who should have OperServ access?
26. Name five situations requiring Services Administrator escalation.
27. What are common signs of a Services outage?
28. Why should staff avoid forcing permanent access changes during an outage?
29. What should an escalation report exclude?
30. Why must account and channel information be handled confidentially?

36. Written Assignment

Write approximately 700–1,000 words analyzing the following case:

A user named `ProjectLead` reports that they have lost access to their registered account and official project channel. Another account currently holds founder access. The user provides an old screenshot and says several friends can confirm that the project belongs to them. They ask a trainee to change the founder immediately because an important event begins in one hour.

Your response must explain:

• What facts have been established.
• What remains unverified.
• Why the nickname alone is insufficient.
• Whether the screenshot and friend statements establish Services ownership.
• What information may be collected safely.
• Why the trainee must not change the founder.
• How the case should be escalated.
• What temporary assistance may be appropriate.
• How conflicts of interest should be handled.
• What should be recorded in the final decision.

37. Module Completion Requirements

To complete this module, the candidate must:

• Read the full lesson.
• Use Services help commands.
• Configure or demonstrate secure account authentication.
• Complete all authorized practical exercises.
• Correctly answer at least 23 of the 30 knowledge-check questions.
• Complete the written assignment.
• Demonstrate safe password handling.
• Demonstrate understanding of account and channel ownership boundaries.
• Receive trainer approval.

38. Trainer Evaluation

Evaluation area	Maximum points
NickServ knowledge	20
ChanServ knowledge	20
SASL and account security	15
Channel access and ownership	15
HostServ and other Services	10
Support procedure	10
Escalation and judgment	10
Total	100

Recommended passing score: 75 points.

A candidate should not pass if they:

• Request or expose passwords.
• Make unauthorized ownership changes.
• Confuse a nickname with verified account ownership.
• Use Services access to bypass channel management.
• Ignore compromised-account indicators.
• Attempt restricted OperServ actions.

39. Quick Reference

Task	Command
NickServ help	`/MSG NickServ HELP`
Command-specific help	`/MSG NickServ HELP command`
Nickname information	`/MSG NickServ INFO nickname`
ChanServ help	`/MSG ChanServ HELP`
Channel information	`/MSG ChanServ INFO #channel`
Channel access help	`/MSG ChanServ HELP ACCESS`
AKICK help	`/MSG ChanServ HELP AKICK`
HostServ help	`/MSG HostServ HELP`
MemoServ help	`/MSG MemoServ HELP`
BotServ help	`/MSG BotServ HELP`
Verify logged-in account	`/WHOIS nickname`

40. Next Module

After passing this module, continue to:

Module 6 — User Support and Communication

---

Previous: Module 4 — User and Channel Modes Program: DarkWorld IRC Staff Training Program Next: Module 6 — User Support and Communication