DarkWorld-Wiki - User contributions [en]

DWStats

2026-08-30T19:20:58Z

Fizi:

{{DWStats}}
<center>
[[File:DWStats-logo.png|200px|alt=DWStats Logo|link=https://wiki.darkworld.network/index.php/DWStats]]
</center>
<center>
<div style="font-size:90%; color:#666; margin-top:4px;">
A Project by the DarkWorld Network Community
</div>
</center>
= 🌐 DWStats – DarkWorld Network Statistics Bots =

'''DWStats''' (DarkWorld Stats) is a channel statistics bot that tracks IRC channel activity and user engagement.
It records lines, words, phrases, and other metrics over IRC channels and presents them graphically on a web interface. DWStats uses the PISG (Perl IRC Statistics Generator) system for its reports.

DWStats allows users to view channel activity, monitor trends, and analyze participation patterns across multiple IRC networks. It is ideal for network administrators, channel operators, and active community members.

== Features ==
* 📈 Track channel activity (lines, words, phrases)
* 🌐 Web-based graphical interface
* 🕵️ Monitor user activity and participation
* 🤖 Supports multiple IRC networks
* 🔄 Real-time updates and periodic reports
* 🧩 Integration with other DarkWorld Bots

== Active Networks ==
* '''DarkWorld''' – Request via channel <code>#DWStats</code>
* '''DalNet''' – Request via channel <code>#DWStats</code>
* More networks available upon request

== Requesting DWStats ==
To request a DWStats bot for your channel:
# Join <code>#DWStats</code> on DarkWorld Network.
# Provide your channel name and purpose for stats collection.
# Our staff will deploy the bot and provide access details.

== More Info ==
* 🌐 [https://stats.darkworld.network Official Website]
* 📘 [https://wiki.darkworld.network/index.php/DWStats/ Wiki Page]
* 📧 Email: bots@darkworld.network

== Subpages / Suggested DWStats Wiki Structure ==
* [[DWStats:Features|Features & Capabilities]] – Detailed stats types, graphs, and bot functionalities
* [[DWStats:Setup|Setup & Configuration]] – How to deploy DWStats for channels
* [[DWStats:Web Interface|Web Interface Guide]] – How to navigate and use the web dashboards
* [[DWStats:Channel Access|Channel Access & Permissions]] – Managing who can view and manage stats
* [[DWStats:Active Networks|Active Networks]] – Full list of networks where DWStats is available
* [[DWStats:PISG Generator|PISG Stats Generator]] – About the stats engine DWStats uses
* [[DWStats:FAQ|Frequently Asked Questions]] – Common questions and troubleshooting
* [[DWStats:Contact|Contact & Support]] – How to reach the bot staff
{{DWFooter}}

2026-08-08T18:32:14Z

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

{{DISPLAYTITLE:DarkWorld IRC Staff Training — Eligibility and Application}}

<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%;">Candidate Eligibility and Application</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Program
| [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
|-
! Application type
| Potential DarkWorld IRC staff candidate
|-
! Minimum recommended age
| 18 years
|-
! Required identity
| Registered DarkWorld IRC account
|-
! Appointment guarantee
| None
|-
! Application review
| Authorized DarkWorld IRC reviewers
|}

= 1. Purpose =

This page explains how a DarkWorld IRC user may apply for the '''DarkWorld IRC Staff Training Program'''.

The program prepares potential staff members to support, moderate, and protect the DarkWorld IRC Network.

DarkWorld IRC is one project operating under the wider DarkWorld Network umbrella. Completing this program does not grant authority over DWShells, DWBouncers, or any other DarkWorld project.

Submitting an application does not guarantee:

* Acceptance into training.
* Staff appointment.
* IRC operator access.
* Services access.
* Server access.
* Access to another DarkWorld project.

= 2. Who Should Apply? =

The program may be suitable for users who:

* Want to help the DarkWorld IRC community.
* Can communicate patiently and professionally.
* Are willing to learn IRC and network policies.
* Can remain neutral during disagreements.
* Respect privacy and confidentiality.
* Are willing to accept supervision.
* Can follow established procedures.
* Are reliable and reasonably active.
* Understand that staff access is a responsibility.
* Are willing to report mistakes honestly.
* Can separate personal relationships from staff decisions.
* Are interested in long-term contribution rather than status.

Technical experience is helpful but not required for every role.

Support, communication, judgment, integrity, and reliability are equally important.

= 3. Basic Eligibility Requirements =

A candidate should:

<pre>
[ ] Be at least 18 years old
[ ] Have a registered DarkWorld IRC account
[ ] Have access to the account’s registered email
[ ] Use a secure TLS connection
[ ] Be willing to configure SASL
[ ] Have a positive or acceptable network history
[ ] Be able to communicate clearly
[ ] Be willing to complete Modules 1–10
[ ] Be willing to complete written and practical assessments
[ ] Accept the Staff Code of Conduct
[ ] Accept supervision during trainee and probation stages
[ ] Disclose relevant staff roles on other networks or projects
[ ] Protect confidential information
[ ] Provide truthful application information
</pre>

Meeting these requirements does not guarantee acceptance.

= 4. Recommended IRC Experience =

Candidates should preferably:

* Understand basic IRC commands.
* Know how to join and leave channels.
* Understand registered nicknames.
* Have used NickServ.
* Understand basic ChanServ functions.
* Be familiar with channel modes.
* Have participated positively in DarkWorld IRC.
* Know where to request help.
* Be familiar with official DarkWorld channels.

Candidates without extensive experience may still apply if they demonstrate maturity and willingness to learn.

= 5. Recommended Activity History =

A candidate should normally have an established presence on DarkWorld IRC.

A recommended guideline is:

* At least 30 days since account registration.
* Reasonable recent activity.
* Participation in one or more legitimate channels.
* No unresolved serious conduct concerns.
* An observable history of respectful behavior.

Management may consider exceptional candidates with a shorter history, but additional observation may be required.

Activity should be evaluated by quality, not raw message count.

= 6. Suitable Candidate Qualities =

Reviewers should look for:

* Patience.
* Honesty.
* Consistency.
* Good judgment.
* Willingness to learn.
* Ability to follow instructions.
* Professional communication.
* Respect for users.
* Security awareness.
* Ability to accept correction.
* Team cooperation.
* Responsible handling of authority.
* Interest in helping rather than controlling.

= 7. Unsuitable Motivations =

The following motivations may indicate that a candidate is not ready:

* Wanting an IRC operator title for status.
* Wanting access to user information.
* Wanting power over channel owners.
* Wanting to punish personal rivals.
* Wanting access to unrelated DarkWorld projects.
* Wanting server access without an operational role.
* Wanting to bypass ordinary channel rules.
* Wanting special treatment for friends.
* Wanting to recruit users for another network.
* Wanting access to confidential investigations.

Reviewers should evaluate conduct and evidence rather than assuming motive without basis.

= 8. Possible Disqualification Conditions =

An applicant may be rejected, deferred, suspended, or removed from training for:

* Providing false application information.
* Harassment or threats.
* Serious or repeated policy violations.
* Ban evasion.
* Staff impersonation.
* Credential phishing.
* Malicious activity.
* Sharing confidential information.
* Attempting unauthorized access.
* Evidence falsification.
* Cheating.
* Retaliation.
* Undisclosed serious conflicts of interest.
* Abuse of staff access elsewhere.
* Refusal to follow training instructions.
* Attempting to bypass the application process.
* Recruiting DarkWorld users for another network in violation of policy.

A previous mistake does not always require permanent rejection. Reviewers should consider severity, time passed, honesty, corrective behavior, and current risk.

= 9. External Roles and Conflicts =

Candidates must disclose relevant roles such as:

* Staff positions on another IRC network.
* Ownership of another IRC network.
* Administration of an external project using DarkWorld IRC.
* Employment or ownership related to a service being reviewed.
* Existing roles within another DarkWorld project.
* Relationships that may create recurring conflicts.
* Previous removal from a trusted position.
* Access to systems that interact with DarkWorld IRC.

Holding another role is not automatically disqualifying.

The purpose of disclosure is to:

* Identify conflicts.
* Protect confidential information.
* Prevent unauthorized recruitment.
* Define project boundaries.
* Assign suitable duties.
* Preserve trust.

= 10. Privacy Notice =

Application information should be used only for:

* Eligibility review.
* Candidate communication.
* Training administration.
* Security review.
* Mentor assignment.
* Assessment.
* Probation.
* Access approval.
* Staff appointment decisions.
* Related appeals or conduct reviews.

Applicants must not be asked to submit:

* Passwords.
* SASL credentials.
* IRC operator credentials.
* Email passwords.
* API tokens.
* Private keys.
* Government identification unless a separately approved and necessary process exists.
* Unrelated private conversations.
* Unnecessary personal information.

Applications and reviewer notes should not be published publicly.

= 11. Application Security =

Applications should be submitted through an approved private system.

Suitable methods may include:

* A secured DarkWorld application website.
* An authenticated staff-training portal.
* A private form with controlled database access.
* Another management-approved system.

Applications should not normally be submitted:

* In a public IRC channel.
* On a public wiki page.
* Through an unrestricted paste.
* To an unofficial bot.
* Through another candidate.
* Through an unverified external form.

<div style="background:#fff8e1; border-left:4px solid #f59e0b; padding:12px; margin:15px 0;">
'''Important:''' This public page explains the application process. Candidate answers and reviewer notes must be stored privately.
</div>

= 12. Application Questions =

The private application form should collect the following information.

== Section A — Account Information ==

<pre>
1. Current IRC nickname:
2. Registered DarkWorld IRC account:
3. Account registration date, if known:
4. Contact email associated with the application:
5. Country or timezone:
6. Languages spoken:
7. Are you at least 18 years old? Yes / No
</pre>

A candidate should not be required to publish their legal name unless DarkWorld adopts a separately approved identity requirement for a specific high-trust role.

== Section B — DarkWorld IRC Experience ==

<pre>
8. How long have you used DarkWorld IRC?
9. Which DarkWorld IRC channels do you normally use?
10. Which IRC clients do you use?
11. Do you use TLS?
12. Do you use SASL?
13. Describe your experience with NickServ.
14. Describe your experience with ChanServ.
15. Describe your understanding of IRC user and channel modes.
16. Have you previously helped users on DarkWorld IRC? Provide examples.
</pre>

== Section C — Motivation ==

<pre>
17. Why do you want to join the DarkWorld IRC staff training program?
18. How would you help DarkWorld IRC users?
19. Which IRC staff responsibilities interest you?
20. Which duties do you believe you are not yet ready to perform?
21. What do you expect to learn from the program?
22. How much time can you reasonably contribute each week?
</pre>

== Section D — Judgment ==

<pre>
23. What would you do if a friend asked you to remove their ban?
24. What would you do if you were unsure whether a message violated policy?
25. What would you do if you accidentally banned an innocent user?
26. What would you do if a user posted their password publicly?
27. What would you do if another staff member asked you to share a private report?
28. Explain why staff should use the least severe effective action.
29. Explain when a channel issue should become a network-level matter.
</pre>

== Section E — Security ==

<pre>
30. How do you protect your IRC account?
31. Do you use unique passwords for important accounts?
32. Do you use a password manager?
33. Do you use multi-factor authentication where available?
34. Is your primary device protected by a password or screen lock?
35. Have any of your DarkWorld or IRC accounts been compromised?
36. If yes, explain what happened and what corrective action you took.
37. Are you willing to report credential exposure immediately?
38. Are you willing to avoid unreviewed scripts on a privileged IRC client?
</pre>

Applicants must not provide actual passwords or authentication secrets.

== Section F — External Roles and Conflicts ==

<pre>
39. Are you staff on another IRC network?
40. Do you own or operate another IRC network?
41. Are you staff in another DarkWorld project?
42. Do you operate a project, relay, bridge, bot, or service using DarkWorld IRC?
43. Have you previously been removed or suspended from a staff position?
44. Do you have any conflict that may affect your neutrality?
45. Are there any access or confidentiality concerns reviewers should know?
</pre>

Applicants should provide honest context. A disclosed issue is not automatically disqualifying.

== Section G — Conduct History ==

<pre>
46. Have you received a DarkWorld IRC warning, restriction, or ban?
47. Have you been involved in a significant abuse or policy case?
48. Is any complaint or appeal involving you currently unresolved?
49. Have you previously used unauthorized access on any IRC network?
50. Is there anything in your history that should be explained to reviewers?
</pre>

Reviewers should verify available records rather than relying only on the applicant’s statement.

== Section H — Candidate Agreement ==

<pre>
51. Will you complete all required training modules?
52. Will you complete written and practical assessments?
53. Will you accept supervision?
54. Will you follow the DarkWorld IRC Staff Code of Conduct?
55. Will you protect confidential information?
56. Will you disclose conflicts of interest?
57. Do you understand that completing training does not guarantee appointment?
58. Do you understand that DWIRC authority does not extend automatically to other projects?
59. Do you confirm that the information provided is accurate?
</pre>

= 13. Candidate Declaration =

The application should end with:

<pre>
I confirm that the information in this application is accurate to the best
of my knowledge.

I understand that submitting an application does not guarantee acceptance,
staff appointment, IRC operator access, Services access, server access, or
authority over another DarkWorld project.

I agree not to submit passwords, tokens, private keys, or other authentication
secrets.

I authorize the designated DarkWorld IRC reviewers to use this information
for candidate evaluation, training administration, security review, probation,
and staff appointment decisions.

I agree to disclose relevant conflicts of interest and external staff roles.

Registered account:
Current nickname:
Application date:
Confirmation method:
</pre>

= 14. Application Reference =

Every application should receive a non-secret reference such as:

<pre>
DWIRC-STAFF-2026-0001
</pre>

The reference may be used to:

* Check application status.
* Associate training records.
* Track assessments.
* Assign a mentor.
* Record probation.
* Reference an appeal.

The reference itself must not provide access to private application details.

= 15. Application Statuses =

{| class="wikitable" style="width:100%;"
! Status
! Meaning
|-
| '''SUBMITTED'''
| Application received
|-
| '''UNDER REVIEW'''
| Eligibility and history review in progress
|-
| '''INFORMATION REQUIRED'''
| Additional non-sensitive information is needed
|-
| '''INTERVIEW'''
| Candidate invited to an interview
|-
| '''ACCEPTED'''
| Candidate accepted into training
|-
| '''DEFERRED'''
| Application may be reconsidered later
|-
| '''REJECTED'''
| Candidate not accepted
|-
| '''WITHDRAWN'''
| Candidate withdrew the application
|-
| '''CANCELLED'''
| Application ended administratively
|-
| '''EXPIRED'''
| Candidate did not respond within the required period
|}

Status information shown publicly should be limited and must not expose reviewer notes.

= 16. Initial Review =

The initial reviewer should confirm:

<pre>
[ ] Registered account exists
[ ] Age requirement confirmed by declaration
[ ] Contact method is available
[ ] Required questions completed
[ ] Candidate history is sufficient for review
[ ] External roles disclosed
[ ] Serious conflicts identified
[ ] Current restrictions checked
[ ] Unresolved cases identified
[ ] No credentials included
[ ] Privacy classification applied
[ ] Application reference assigned
</pre>

= 17. Candidate History Review =

Authorized reviewers may consider:

* Registration history.
* Relevant network conduct.
* Previous warnings or restrictions.
* Support-channel behavior.
* Staff or user reports.
* Ban evasion.
* Project participation.
* Previous applications.
* Existing DarkWorld project roles.
* Disclosed external roles.
* Security incidents.
* Evidence of improvement.

The review must not become an unrestricted search into unrelated personal activity.

Only information relevant to suitability, security, conduct, or conflicts should be considered.

= 18. Application Scoring =

A structured scoring system helps reviewers remain consistent.

{| class="wikitable" style="width:100%;"
! Area
! Weight
|-
| Motivation and service orientation
| 15%
|-
| Communication
| 15%
|-
| IRC knowledge
| 10%
|-
| Judgment
| 20%
|-
| Security awareness
| 15%
|-
| Conduct history
| 10%
|-
| Reliability and availability
| 5%
|-
| Transparency and conflict disclosure
| 10%
! Total
| 100%
|}

A suggested minimum for acceptance into training is '''70%''', provided no serious unresolved security or conduct concern exists.

This score is an aid to judgment, not an automatic appointment formula.

= 19. Reviewer Scoring Form =

<pre>
APPLICATION REVIEW

Application reference:
Candidate:
Registered account:
Primary reviewer:
Secondary reviewer:
Review date:

Motivation and service orientation: /15
Communication: /15
IRC knowledge: /10
Judgment: /20
Security awareness: /15
Conduct history: /10
Reliability and availability: /5
Transparency and conflicts: /10

TOTAL: /100

Minimum eligibility met: Yes / No
Serious unresolved concern: Yes / No
External roles reviewed: Yes / No
Conflict-management plan required: Yes / No
Interview required: Yes / No

Strengths:
Development areas:
Security concerns:
Conduct concerns:
Conflict concerns:
Recommended trainee path:
Reviewer recommendation:
</pre>

= 20. Reviewer Conflicts of Interest =

A reviewer should disclose a conflict when:

* They are a close friend of the candidate.
* They have a serious personal dispute with the candidate.
* They operate a competing project.
* They previously participated in a relevant incident.
* They may benefit from the decision.
* Their neutrality may reasonably be questioned.

A conflicted reviewer may provide relevant factual information but should not control the final decision.

= 21. Interview =

An interview may be conducted in a private approved IRC channel or another authorized system.

Suggested topics include:

* Motivation.
* Understanding of DarkWorld IRC.
* Availability.
* Communication style.
* Response to criticism.
* Conflict handling.
* Security habits.
* External roles.
* Training expectations.
* Preferred trainee path.

The interview should not request passwords, financial information, government identification, or unrelated personal details.

= 22. Interview Scenarios =

The interviewer may ask:

== Scenario 1 ==

A friend asks you to remove their ban. What do you do?

== Scenario 2 ==

A user posts a password publicly. What do you do?

== Scenario 3 ==

You apply the wrong channel ban. What do you do?

== Scenario 4 ==

A staff member asks you to keep an undocumented action secret. What do you do?

== Scenario 5 ==

You are unsure whether a message violates the advertising policy. What do you do?

== Scenario 6 ==

A DWShells user asks you to increase their quota, but you hold only a DWIRC role. What do you do?

Interviewers should evaluate reasoning rather than expecting candidates to memorize exact wording.

= 23. Interview Record =

<pre>
INTERVIEW RECORD

Application reference:
Candidate:
Date and time:
Interviewers:
Location:

Motivation:
Communication:
IRC knowledge:
Judgment:
Security awareness:
Response to feedback:
External roles:
Conflicts:
Suitable trainee path:
Concerns:
Candidate questions:
Follow-up required:
Interview recommendation:
</pre>

= 24. Decision Requirements =

Where practical, acceptance or rejection should involve at least two authorized reviewers.

The decision should consider:

* Application.
* Candidate history.
* Interview.
* Security concerns.
* Conflicts.
* Current network needs.
* Mentor availability.
* Available training capacity.
* Suitable trainee path.

A candidate should not be accepted when safe supervision cannot be provided.

= 25. Acceptance =

An acceptance notice should include:

* Application reference.
* Accepted status.
* Assigned training path.
* Required first module.
* Training channel.
* Trainer or coordinator.
* Completion expectations.
* Code of Conduct requirement.
* Privacy reminder.
* Statement that appointment is not guaranteed.

Example:

<pre>
Your application to the DarkWorld IRC Staff Training Program has been accepted.

Application reference: DWIRC-STAFF-YYYY-NNNN
Training status: Accepted
Assigned trainer:
Initial training path:
Training channel:
Start date:

Acceptance permits participation in training only. It does not grant IRC
operator, Services, server, or other DarkWorld project access.
</pre>

= 26. Deferred Application =

An application may be deferred because:

* The candidate needs more network history.
* Activity is insufficient.
* A mentor is unavailable.
* A relevant issue remains unresolved.
* The candidate needs more IRC experience.
* The training group is full.
* The candidate is temporarily unavailable.
* Management requires a later review.

A deferral should state:

* General reason.
* Whether the candidate may reapply.
* Recommended improvement.
* Earliest review date, where applicable.

= 27. Rejection =

A rejection notice should be respectful and should avoid exposing confidential reviewer information.

Example:

<pre>
Your application has been reviewed and has not been accepted at this time.

This decision does not create an entitlement to confidential reviewer notes.
Where appropriate, we may provide general areas for improvement and information
about whether a future application may be considered.
</pre>

A rejection should not be used to publicly shame the applicant.

= 28. Withdrawal =

A candidate may withdraw voluntarily.

Withdrawal should:

* End active review.
* Cancel pending interviews.
* Remove unnecessary temporary access.
* Preserve the minimum record needed for administration.
* Record whether reapplication is permitted.
* Protect the application’s confidentiality.

= 29. Application Appeal or Review =

Where management permits a review, the candidate should provide:

<pre>
Application reference:
Decision being reviewed:
Reason for requesting review:
Factual error alleged:
Relevant additional information:
Conflict concern:
Requested outcome:
</pre>

A review should not be decided solely by the original reviewer when a credible conflict or serious procedural concern exists.

An appeal does not guarantee acceptance.

= 30. Reapplication =

A rejected or deferred candidate may be allowed to reapply after:

* Completing recommended learning.
* Establishing additional network history.
* Resolving conduct concerns.
* Demonstrating improved security.
* Completing a stated waiting period.
* Providing missing information.

Management may decline reapplication after serious malicious conduct, impersonation, credential theft, or deliberate security abuse.

= 31. Application Retention =

Application records should be retained only as long as required for:

* Training administration.
* Staff selection.
* Security review.
* Appeals.
* Repeat applications.
* Access and conduct accountability.

Access should be restricted.

When information is no longer required, it should be removed or minimized according to the adopted retention procedure.

= 32. Application Audit Record =

Important changes should record:

<pre>
Application reference:
Previous status:
New status:
Date and time:
Action performed by:
Reason:
Candidate notified:
Next action:
Review date:
</pre>

Reviewer notes should not be overwritten to conceal earlier decisions. Corrections should be appended or versioned.

= 33. Application Workflow =

<pre>
SUBMITTED
|
UNDER REVIEW
|
+--> INFORMATION REQUIRED
|
+--> INTERVIEW
|
+--> ACCEPTED --> TRAINING
|
+--> DEFERRED
|
+--> REJECTED
|
+--> WITHDRAWN / CANCELLED / EXPIRED
</pre>

= 34. Candidate Checklist =

Before submitting:

<pre>
[ ] I am at least 18 years old
[ ] I have a registered DarkWorld IRC account
[ ] I have access to my registered email
[ ] I use or will configure TLS
[ ] I use or will configure SASL
[ ] I answered truthfully
[ ] I disclosed relevant external roles
[ ] I disclosed relevant conflicts
[ ] I did not include passwords or tokens
[ ] I understand training does not guarantee appointment
[ ] I understand DWIRC authority is project-specific
[ ] I am willing to accept supervision
[ ] I am willing to complete all assessments
[ ] I am willing to follow the Staff Code of Conduct
</pre>

= 35. Reviewer Checklist =

Before accepting:

<pre>
[ ] Eligibility confirmed
[ ] Account history reviewed
[ ] Conduct history reviewed
[ ] Security concerns reviewed
[ ] External roles reviewed
[ ] Conflicts reviewed
[ ] Interview completed where required
[ ] Second reviewer consulted
[ ] Suitable trainee path identified
[ ] Mentor available
[ ] Training capacity available
[ ] Decision recorded
[ ] Candidate notified
[ ] No privileged access granted prematurely
</pre>

= 36. Next Step for Accepted Candidates =

Accepted candidates begin with:

'''[[DWIRC:Staff Training/Network Introduction|Module 1 — DarkWorld IRC Network Introduction]]'''

They should also review:

* [[DWIRC:Staff Training Program|Program Overview]]
* [[DWIRC:Staff Training/Code of Conduct|Staff Code of Conduct]]
* [[DWIRC:Staff Training/IRC Fundamentals|IRC Fundamentals]]

----

'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
'''First module:''' [[DWIRC:Staff Training/Network Introduction|Module 1 — Network Introduction]]

[[Category:DarkWorld IRC Staff Training]]
[[Category:DWIRC]]
[[Category:Staff Applications]]
[[Category:Staff Recruitment]]
[[Category:Staff Documentation]]

DWIRC:Staff Training/Eligibility and Application

2026-08-08T18:31:26Z

Fizi: Created page with "{{DISPLAYTITLE:DarkWorld IRC Staff Training — Eligibility and Application}} <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%;">Candidate Eligibility and Application</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DWIRC:Staff Training Program|DarkWorld IRC Staff Trai..."

DWIRC:Staff Training/Probation

2026-08-08T18:26:46Z

Fizi: Created page with "{{DISPLAYTITLE:DarkWorld IRC Probationary Staff Program}} <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%;">Probationary Staff Program</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Stage | Pro..."

{{DISPLAYTITLE:DarkWorld IRC Probationary Staff Program}}

<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%;">Probationary Staff Program</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Program
| [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
|-
! Stage
| Probationary IRC Staff
|-
! Recommended duration
| 30–60 days
|-
! Minimum recommended period
| 30 days
|-
! Final passing standard
| 80% with all mandatory competencies
|-
! Supervision
| Assigned mentor and authorized senior staff
|-
! Access
| Limited, role-specific, and reviewable
|}

= 1. Purpose =

The Probationary Staff Program is the final evaluation stage before permanent appointment to the DarkWorld IRC staff team.

During probation, the candidate performs limited real duties with role-appropriate access while remaining under supervision.

The program evaluates whether the probationary staff member can consistently:

* Assist users.
* Apply policy correctly.
* Exercise authority proportionately.
* Protect confidential information.
* Use access securely.
* Coordinate with the staff team.
* Respond to incidents.
* Document important actions.
* Accept correction.
* Remain reliable over time.

Passing training or probation does not create an automatic right to permanent staff status.

= 2. Entry Requirements =

Before entering probation, the candidate must have:

<pre>
[ ] Completed Modules 1–10
[ ] Accepted the Staff Code of Conduct
[ ] Accepted the Security Declaration
[ ] Passed the Final Written Examination
[ ] Passed the Final Practical Assessment
[ ] Completed the Supervised Trainee Evaluation
[ ] Received a trainee score of at least 80%
[ ] Completed all mandatory trainee experiences
[ ] Received a mentor recommendation
[ ] Received a secondary review
[ ] Been assigned a probationary role
[ ] Received a written access plan
[ ] Received management approval
</pre>

= 3. Probationary Status =

A probationary staff member:

* Has been selected for limited live duties.
* Is still under formal evaluation.
* Holds only explicitly approved permissions.
* Remains accountable to an assigned mentor.
* Must follow the Staff Code of Conduct.
* May have access reduced or suspended.
* Is not guaranteed permanent appointment.
* Must identify their status accurately.

Appropriate description:

<pre>
I am a probationary DarkWorld IRC staff member working under supervision.
</pre>

Probationary staff must not misrepresent themselves as senior administrators or representatives of unrelated DarkWorld projects.

= 4. Duration =

The recommended probation period is '''30–60 days'''.

A standard probation may be:

{| class="wikitable" style="width:100%;"
! Period
! General use
|-
| 30 days
| Candidate demonstrates consistent readiness with sufficient observation
|-
| 45 days
| Additional observation is useful
|-
| 60 days
| Higher-risk role, limited activity, or development areas remain
|}

Management may extend probation when:

* There is insufficient activity.
* Required scenarios have not occurred.
* A mentor was unavailable.
* Additional training is required.
* A conduct or security concern requires observation.
* The candidate is moving into a different role.

Time completed alone does not determine the result.

= 5. Probationary Roles =

Possible initial roles include:

{| class="wikitable" style="width:100%;"
! Role
! Primary responsibility
|-
| '''Probationary Support Staff'''
| User assistance and support-channel duties
|-
| '''Probationary Channel Moderator'''
| Supervised moderation in assigned official channels
|-
| '''Probationary Policy Staff'''
| Policy guidance and supervised case preparation
|-
| '''Probationary Relay Compliance Staff'''
| Relay records and supervised compliance actions
|-
| '''Probationary Services Support Staff'''
| Normal Services assistance and escalation
|-
| '''Probationary Incident Staff'''
| Incident records, communications, timelines, and coordination
|-
| '''Probationary IRC Operator'''
| Limited operator duties under enhanced supervision
|}

A candidate may serve in more than one area only when the access plan clearly defines each responsibility.

= 6. Written Role Definition =

Every probationary appointment should record:

<pre>
Candidate:
Registered account:
Probationary title:
Operational purpose:
Assigned responsibilities:
Approved public channels:
Approved restricted channels:
Approved systems:
Approved commands:
Actions requiring prior approval:
Prohibited commands:
Prohibited systems:
Logging requirements:
Primary mentor:
Secondary mentor:
Start date:
Review dates:
Expected end date:
Management approver:
</pre>

Undefined authority should be treated as not granted.

= 7. Access Principles =

Probationary access must be:

* Necessary.
* Explicitly approved.
* Limited to the assigned role.
* Logged where appropriate.
* Reviewed regularly.
* Reversible.
* Removed when no longer required.

Access should not be granted merely because:

* The candidate completed the course.
* Another staff member has it.
* The candidate requests it.
* It may be useful eventually.
* The candidate is a friend.
* The permission is technically easy to add.

= 8. Access Categories =

{| class="wikitable" style="width:100%;"
! Category
! Meaning
|-
| '''Allowed'''
| May be performed within role and policy
|-
| '''Supervised'''
| May be performed only with mentor awareness or observation
|-
| '''Prior Approval Required'''
| Must be approved before each action
|-
| '''Emergency Only'''
| May be used only to stop immediate harm and must be reported immediately
|-
| '''Prohibited'''
| Not authorized during probation
|}

Every sensitive command or system should have an assigned category.

= 9. Typical Allowed Duties =

Depending on the role, probationary staff may:

* Assist in `#Help` and other approved channels.
* Provide official documentation and policy links.
* Troubleshoot TLS, SASL, and normal Services issues.
* Prepare support and incident records.
* Issue approved channel warnings.
* Apply ordinary moderation in assigned channels.
* Escalate network-wide cases.
* Participate in staff coordination.
* Assist with approved documentation updates.
* Observe higher-level investigations.
* Perform limited bot actions explicitly assigned to the role.

= 10. Typical Restricted Duties =

Probationary staff should normally require supervision or prior approval for:

* Long-term channel bans.
* Actions affecting shared hosts.
* Multi-channel enforcement.
* Account or channel suspension recommendations.
* Advertising administrative decisions.
* Relay compliance status changes.
* Access to restricted abuse evidence.
* Network-wide notices.
* Operator kills.
* Network-level bans.
* Services administrative actions.
* Staff-conduct cases.
* Public incident announcements.

= 11. Normally Prohibited Duties =

Unless management explicitly defines otherwise, probationary staff must not:

* Use IRCd server-administration commands.
* Rehash, restart, disconnect, or terminate IRC servers.
* Modify IRCd configuration.
* Modify Anope databases.
* Change channel founders.
* Drop accounts or channels.
* Use unrestricted OperServ.
* Access root credentials.
* Modify production databases.
* Grant staff access.
* Approve their own request.
* Review their own disputed action alone.
* Use OperOverride for non-emergency purposes.
* Share restricted information.
* Access another DarkWorld project without separate authorization.

= 12. Probationary IRC Operator Controls =

A probationary IRC operator should have a specifically restricted operator class where practical.

The access plan should define whether they may:

* View selected server notices.
* Use expanded WHOIS information.
* Issue KILL commands.
* Apply local restrictions.
* Apply temporary restrictions.
* Apply global restrictions.
* Use shuns.
* Use override capabilities.
* Send network notices.
* View sensitive statistics.

Higher-risk capabilities should remain excluded until independently approved.

= 13. First-Week Requirements =

During the first probation week, the candidate should:

* Review the written access plan.
* Confirm access works as intended.
* Verify TLS and SASL.
* Verify staff account security.
* Confirm logging requirements.
* Review escalation contacts.
* Observe at least one senior-staff session.
* Handle only low-risk duties.
* Complete the first mentor review.
* Report any excessive or missing permissions.

If the candidate discovers access beyond their assigned role, they must report it and avoid using it.

= 14. Staff Presence and Activity =

Probationary staff should:

* Maintain reasonable activity in assigned channels.
* Avoid being online only to retain status.
* Participate meaningfully.
* Respond when available.
* Communicate planned absence.
* Hand over active cases.
* Avoid leaving unresolved emergency actions.
* Maintain professional behavior during quiet periods.

Activity should be measured by quality and reliability, not raw message count.

= 15. User Support Expectations =

Probationary staff should consistently:

* Welcome users professionally.
* Identify the actual problem.
* Ask focused questions.
* Give safe instructions.
* Protect passwords.
* Use current official information.
* Respect language differences.
* Confirm outcomes.
* Escalate administrative matters.
* Avoid making promises outside their authority.

= 16. Moderation Expectations =

Probationary moderators should:

* Intervene only when appropriate.
* Use clear warnings.
* Select proportionate actions.
* Use precise masks.
* Consider shared infrastructure.
* Provide professional reasons.
* Record significant actions.
* Review temporary restrictions.
* Avoid personal involvement.
* Escalate network-wide abuse.

= 17. Policy Expectations =

Probationary policy staff should:

* Use current official policy.
* Provide concise public links.
* Keep detailed cases in approved restricted systems.
* Verify advertising or relay status.
* Distinguish approval from general conversation.
* Record evidence accurately.
* Avoid changing statuses without authority.
* Escalate disputed interpretations.
* Respect registered-project boundaries.

= 18. Services Expectations =

Probationary Services support staff should:

* Use current Services help.
* Never request passwords.
* Confirm registered accounts.
* Distinguish live modes from Services access.
* Assist with normal recovery procedures.
* Escalate founder and ownership disputes.
* Avoid restricted OperServ functions.
* Protect account information.
* Recognize Services outages.
* Document administrative referrals.

= 19. Incident Expectations =

During incidents, probationary staff should:

* Follow the incident lead.
* State confirmed facts.
* Record UTC timestamps.
* Protect evidence.
* Avoid duplicate actions.
* Communicate changes.
* Avoid unsupported public claims.
* Maintain handover information.
* Assist with recovery.
* Participate in post-incident review.

= 20. Action Logging =

Significant probationary actions should be recorded:

<pre>
Date and time:
Probationary staff member:
Role used:
Channel or system:
Incident or case reference:
Action:
Target:
Reason:
Policy:
Scope:
Duration:
Authorization:
Mentor notified:
Result:
Users affected:
Review date:
Correction required:
</pre>

The log must not contain credentials.

= 21. Daily Probation Record =

The candidate should maintain:

<pre>
Date:
Hours or sessions active:
Assigned channels:
Support cases:
Moderation actions:
Policy or relay cases:
Incidents:
Escalations:
Reports completed:
Mentor contact:
Mistakes and corrections:
Pending items:
</pre>

This record supports evaluation but should not become unnecessary surveillance of normal conversation.

= 22. Weekly Mentor Review =

A review should occur at least weekly.

{| class="wikitable" style="width:100%;"
! Evaluation area
! Weight
|-
| Support and communication
| 15%
|-
| Policy accuracy
| 10%
|-
| Moderation and operational judgment
| 15%
|-
| Security and confidentiality
| 15%
|-
| Incident response
| 10%
|-
| Documentation and accountability
| 10%
|-
| Teamwork and communication
| 10%
|-
| Reliability and availability
| 10%
|-
| Acceptance of feedback
| 5%
! Total
| 100%
|}

= 23. Weekly Review Form =

<pre>
PROBATIONARY STAFF WEEKLY REVIEW

Candidate:
Registered account:
Probationary role:
Week:
Review period:
Mentor:
Secondary reviewer:

Support and communication: /15
Policy accuracy: /10
Moderation and operational judgment: /15
Security and confidentiality: /15
Incident response: /10
Documentation and accountability: /10
Teamwork and communication: /10
Reliability and availability: /10
Acceptance of feedback: /5

TOTAL: /100

Actions reviewed:
Incidents handled:
Positive observations:
Errors:
Corrections:
Security concerns:
Conduct concerns:
Access concerns:
Required remediation:
Access change recommended:
Candidate comments:
Mentor recommendation:
Next review date:
</pre>

= 24. Permission Review =

Probationary access should be reviewed:

* After the first week.
* At the midpoint.
* After any security incident.
* After a role change.
* After a serious mistake.
* Before permanent appointment.
* When probation is extended.
* When the candidate becomes inactive.

The review should determine:

* Is every permission still required?
* Is any permission excessive?
* Is any required permission missing?
* Were permissions used correctly?
* Are actions properly logged?
* Should any access remain supervised?
* Should any access be suspended?

= 25. Mistakes During Probation =

When a probationary staff member makes a mistake:

# Stop continuing harm.
# Inform the mentor.
# Correct the action where authorized.
# Preserve the original record.
# Document the correction.
# Notify affected users appropriately.
# Identify the cause.
# Complete remediation.
# Review whether access should change.

Factors include:

* Severity.
* Intent.
* Honesty.
* Harm.
* Repetition.
* Cooperation.
* Security impact.
* Whether the candidate exceeded authority.

= 26. Immediate Access Suspension =

Probationary access should be suspended immediately when:

* Credentials are exposed.
* Access is shared.
* A privileged device is compromised.
* Private information is deliberately disclosed.
* Evidence is falsified or destroyed.
* Retaliation occurs.
* Unauthorized high-risk commands are used.
* The candidate accesses another system without authority.
* A serious conflict is concealed.
* The candidate refuses to stop unsafe conduct.
* Continued access creates significant risk.

Suspension should be documented and reviewed by authorized management.

= 27. Security Incident Procedure =

If probationary access may be compromised:

# Stop using the affected access.
# Notify management immediately.
# Preserve relevant logs.
# Rotate credentials.
# Revoke exposed tokens or keys.
# Review actions performed during the exposure period.
# Secure the device.
# Restore access only after approval.
# Complete an incident report.
# Review related accounts for password reuse.

= 28. Staff Complaints During Probation =

A complaint against a probationary staff member should be:

* Acknowledged.
* Preserved.
* Kept confidential.
* Reviewed by an appropriate person.
* Protected from retaliation.
* Compared with action records.
* Considered during the final evaluation.

The mentor should not dismiss a complaint merely to protect the candidate.

The candidate should not contact or pressure the complainant outside the approved process.

= 29. Conflicts of Interest =

Probationary staff must disclose conflicts promptly.

When involved personally:

* Protect against immediate harm if necessary.
* Preserve evidence.
* Step away from the final decision.
* Notify the mentor.
* Transfer the matter.
* Avoid discussing private review details publicly.

Failure to disclose a serious conflict may prevent promotion.

= 30. Required Probation Experiences =

Before permanent appointment, the candidate should complete:

<pre>
[ ] At least ten meaningful support cases
[ ] At least three Services support cases
[ ] At least three documented moderation cases
[ ] At least one shared-host or ban-scope analysis
[ ] At least one policy or compliance case
[ ] At least one incident exercise or supervised incident
[ ] At least one incident timeline
[ ] At least one formal handover
[ ] At least one appeal or complaint simulation
[ ] At least one security exercise
[ ] At least four weekly mentor reviews for a 30-day probation
[ ] At least one midpoint access review
[ ] At least one secondary-review observation
[ ] A final access and conduct review
</pre>

Equivalent simulations may be used when real incidents do not occur.

= 31. Midpoint Review =

At the midpoint, the mentor and candidate should review:

* Progress.
* Weekly scores.
* Required experiences.
* Access usage.
* Security conduct.
* User feedback.
* Staff feedback.
* Mistakes and corrections.
* Remaining weaknesses.
* Suitability of the assigned role.
* Whether probation should continue unchanged.

Possible midpoint outcomes:

* Continue.
* Continue with additional supervision.
* Reduce access.
* Expand low-risk duties.
* Require remediation.
* Change probationary role.
* Pause or end probation.

= 32. Final Evaluation =

At the end of probation:

<pre>
DARKWORLD IRC FINAL PROBATION REVIEW

Candidate:
Registered account:
Probationary role:
Start date:
End date:
Total observed days:
Primary mentor:
Secondary reviewer:
Management reviewer:

Average weekly score:
Required experiences completed: Yes / No
Code of Conduct maintained: Yes / No
Security requirements maintained: Yes / No
Confidentiality maintained: Yes / No
Actions properly documented: Yes / No
Conflicts properly disclosed: Yes / No
Complaints resolved: Yes / No
Access used within scope: Yes / No

Support performance:
Moderation performance:
Policy knowledge:
Services knowledge:
Incident response:
Security:
Documentation:
Teamwork:
Reliability:
Acceptance of feedback:

Strongest areas:
Development areas:
Outstanding concerns:
Unresolved incidents:
Recommended permanent role:
Recommended permanent permissions:
Permissions to exclude:
Additional specialist training:
Final recommendation:
</pre>

= 33. Final Outcomes =

{| class="wikitable" style="width:100%;"
! Outcome
! Meaning
|-
| '''APPOINT PERMANENT STAFF'''
| Candidate is suitable for a defined permanent DWIRC role
|-
| '''EXTEND PROBATION'''
| More observation or remediation is required
|-
| '''REASSIGN ROLE'''
| Candidate may be suitable for a different role
|-
| '''REDUCE ACCESS'''
| Candidate may continue with narrower duties
|-
| '''RETURN TO TRAINING'''
| Candidate must repeat specified modules or assessments
|-
| '''PAUSE'''
| Evaluation cannot continue currently
|-
| '''END CANDIDACY'''
| Candidate is not suitable for appointment
|}

= 34. Promotion Requirements =

For permanent appointment, the candidate should:

* Complete at least the minimum probation period.
* Achieve an average score of at least '''80%'''.
* Complete required experiences.
* Demonstrate consistent reliability.
* Protect credentials and private information.
* Use access within scope.
* Apply proportionate judgment.
* Maintain accurate records.
* Cooperate with staff.
* Accept feedback.
* Resolve or disclose conflicts.
* Have no unresolved serious conduct concern.
* Receive mentor recommendation.
* Receive secondary review.
* Receive management approval.

Management may require a higher standard for IRC operator, Services, security, or infrastructure roles.

= 35. Permanent Role Assignment =

Permanent appointment should define:

<pre>
Staff member:
Registered account:
Official title:
Team:
Operational responsibilities:
Approved public channels:
Approved restricted channels:
Approved Services permissions:
Approved bot or API permissions:
Approved operator permissions:
Server access:
Explicitly excluded permissions:
Reporting line:
Review schedule:
Appointment date:
Approved by:
</pre>

“Full access” should not be used as a role description.

= 36. Permanent Access Activation =

Before activating permanent access:

<pre>
[ ] Final probation review approved
[ ] Role definition recorded
[ ] Permissions reviewed
[ ] Excess probation permissions removed
[ ] Required credentials generated securely
[ ] TLS and SASL verified
[ ] Additional authentication enabled where available
[ ] Logging confirmed
[ ] Emergency contacts confirmed
[ ] Staff channels updated
[ ] Documentation access updated
[ ] Next access-review date scheduled
</pre>

= 37. Staff Announcement =

If an appointment is announced publicly, the notice should include only:

* Staff nickname or approved identity.
* Assigned DWIRC role.
* Relevant official team.
* Effective date.
* Appropriate welcome message.

It should not disclose:

* Private evaluation scores.
* Personal information.
* Credentials.
* Restricted access details.
* Internal concerns.
* Confidential training records.

Example:

<pre>
DarkWorld IRC welcomes ExampleNick as a member of the Support Team following successful completion of the staff training and probation process.
</pre>

= 38. Post-Appointment Review =

A newly appointed staff member should receive an additional review after approximately '''90 days'''.

The review should consider:

* Performance after supervision was reduced.
* Continued security compliance.
* Use of access.
* User and staff feedback.
* Documentation quality.
* Activity.
* Training needs.
* Whether permissions remain appropriate.
* Suitability for specialist training.

Permanent appointment does not end accountability or access review.

= 39. Specialist Development =

After successful appointment, staff may be considered for specialist programs such as:

* IRC Operator Program.
* Services Administration.
* IRCd Administration.
* Policy and Compliance.
* Abuse and Security.
* Relay Compliance.
* Support Team Leadership.

DWShells, DWBouncers, and other DarkWorld projects should maintain separate training and access processes.

= 40. Candidate Acknowledgement =

Before probation begins, the candidate should affirm:

<pre>
I understand that probation is a supervised evaluation and does not guarantee
permanent staff appointment.

I will use only the permissions listed in my written access plan.

I will report mistakes, security concerns, credential exposure, and conflicts
of interest promptly.

I will protect user information, staff communications, incident evidence, and
all other confidential information.

I understand that my access may be restricted, suspended, or removed when
necessary to protect DarkWorld IRC.

Candidate:
Registered account:
Probationary role:
Start date:
Mentor:
Management approver:
</pre>

= 41. Program Completion =

The DarkWorld IRC Staff Training Program is considered successfully completed when:

<pre>
[ ] Modules 1–10 completed
[ ] Staff Code of Conduct accepted
[ ] Security Declaration accepted
[ ] Final Written Examination passed
[ ] Final Practical Assessment passed
[ ] Trainee Evaluation passed
[ ] Probation completed
[ ] Final review approved
[ ] Permanent role defined
[ ] Access approved and recorded
</pre>

= 42. Related Pages =

* [[DWIRC:Staff Training Program|Program Overview]]
* [[DWIRC:Staff Training/Code of Conduct|Staff Code of Conduct]]
* [[DWIRC:Staff Training/Final Examination|Final Written Examination]]
* [[DWIRC:Staff Training/Practical Assessment|Final Practical Assessment]]
* [[DWIRC:Staff Training/Trainee Evaluation|Trainee Evaluation]]
* [[DWIRC:Staff Training/IRC Operator Program|IRC Operator Specialist Program]]
* [[DWIRC:Staff Training/Services Administration|Services Administration Program]]
* [[DWIRC:Staff Training/IRCd Administration|IRCd Administration Program]]
* [[DWIRC:Staff Training/Policy and Compliance|Policy and Compliance Program]]
* [[DWIRC:Staff Training/Abuse and Security|Abuse and Security Program]]

----

'''Previous:''' [[DWIRC:Staff Training/Trainee Evaluation|Trainee Evaluation]]
'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]

[[Category:DarkWorld IRC Staff Training]]
[[Category:DWIRC]]
[[Category:Probationary Staff]]
[[Category:Staff Evaluation]]
[[Category:Staff Documentation]]

DWIRC:Staff Training/Trainee Evaluation

2026-08-08T18:23:45Z

Fizi: Protected "DWIRC:Staff Training/Trainee Evaluation" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:DarkWorld IRC Trainee Evaluation}}

<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%;">Supervised Trainee Evaluation</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Program
| [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
|-
! Stage
| Supervised IRC Trainee
|-
! Recommended duration
| 2–4 weeks
|-
! Minimum recommended observation
| 14 days
|-
! Recommended evaluation score
| 80%
|-
! Supervision
| Assigned mentor or authorized senior staff
|-
! Prerequisites
| Core modules, Code of Conduct, written examination, and practical assessment
|}

= 1. Purpose =

The Trainee Evaluation allows a successful candidate to demonstrate reliability, judgment, communication, and conduct through supervised participation in real DarkWorld IRC activities.

The trainee stage is not a staff appointment and does not guarantee progression to probation.

During this stage, the candidate should perform only approved, low-risk duties while an assigned mentor reviews:

* User support.
* Communication.
* Policy knowledge.
* Moderation judgment.
* Incident awareness.
* Documentation.
* Reliability.
* Security.
* Team cooperation.
* Acceptance of correction.

= 2. Entry Requirements =

Before entering the trainee stage, the candidate must have:

<pre>
[ ] Completed Modules 1–10
[ ] Accepted the Staff Code of Conduct
[ ] Accepted the Security Declaration
[ ] Passed the Final Written Examination
[ ] Passed the Final Practical Assessment
[ ] Passed all mandatory security competencies
[ ] Received a recommended trainee role
[ ] Received management approval
[ ] Been assigned a mentor
[ ] Been informed of allowed and prohibited duties
[ ] Received a trainee reference number
</pre>

= 3. Trainee Status =

A trainee is:

* A candidate under supervised evaluation.
* Permitted to assist with specified duties.
* Required to follow mentor instructions.
* Required to identify themselves accurately.
* Subject to the Staff Code of Conduct.
* Not guaranteed a permanent role.
* Not authorized beyond the recorded trainee permissions.

A trainee must not claim to be:

* A permanent staff member.
* An IRC operator.
* A Services Administrator.
* An IRCd administrator.
* A representative of every DarkWorld project.
* Authorized to make final policy decisions.

= 4. Recommended Duration =

The normal trainee period should last approximately '''2–4 weeks'''.

A minimum observation period of '''14 days''' is recommended so that the candidate can be evaluated across different situations.

Management may:

* Extend the trainee period.
* Pause it during prolonged inactivity.
* Shorten it only where sufficient evidence exists.
* Require remediation.
* End it early for serious concerns.
* Move a candidate to another suitable trainee path.

Completing a certain number of days does not automatically mean the trainee has passed.

= 5. Trainee Roles =

A candidate may be assigned one or more limited trainee paths.

{| class="wikitable" style="width:100%;"
! Trainee path
! Typical supervised duties
|-
| '''Support Trainee'''
| Connection help, NickServ guidance, basic ChanServ assistance, documentation links
|-
| '''Moderation Trainee'''
| Observing channel moderation, preparing warnings, recommending proportionate action
|-
| '''Policy Trainee'''
| Providing public policy links, preparing case summaries, observing application reviews
|-
| '''Relay Compliance Trainee'''
| Recording possible relays, checking public status, preparing supervised follow-up
|-
| '''Services Support Trainee'''
| Normal Services help, account troubleshooting, escalation preparation
|-
| '''Incident Response Trainee'''
| Timelines, evidence records, handovers, and observation during incidents
|-
| '''Operator Candidate'''
| Operator simulations and observation without independent production access
|}

The assigned path should reflect:

* Candidate interests.
* Assessment results.
* Network needs.
* Security readiness.
* Available mentors.
* Areas requiring further observation.

= 6. Mentor Assignment =

Every trainee must have an assigned mentor.

The mentor should:

* Explain the trainee’s role.
* Set permitted duties.
* Observe support interactions.
* Review recommendations before high-impact actions.
* Correct unsafe behavior.
* Review logs and reports.
* Conduct weekly evaluations.
* Identify training needs.
* Report serious concerns.
* Recommend advancement, extension, reassignment, or removal.

Where practical, a mentor should supervise no more trainees than they can evaluate meaningfully.

= 7. Secondary Reviewer =

A secondary reviewer is recommended to:

* Reduce personal bias.
* Review borderline cases.
* Observe at least one trainee session.
* Review serious concerns.
* Confirm final recommendations.
* Provide independent feedback.

A close friend should not be the sole person responsible for approving a candidate.

= 8. Trainee Access Principle =

Trainees should receive the minimum access needed for approved exercises.

Possible access may include:

* Public IRC channels.
* A training channel.
* A trainee coordination channel.
* Public policy information.
* Approved documentation.
* Limited case templates.
* Read-only or observation access where specifically approved.

Trainees should normally not receive:

* IRC operator credentials.
* OperServ access.
* IRCd configuration access.
* Server root or shell access.
* Services database access.
* Advertising approval permissions.
* Relay enforcement permissions.
* Production API tokens.
* Unrestricted abuse evidence.
* Access to unrelated DarkWorld projects.

= 9. Allowed Trainee Duties =

Subject to the assigned role, a trainee may:

* Welcome users.
* Answer basic IRC questions.
* Explain secure connection settings.
* Provide official documentation links.
* Explain public NickServ and ChanServ commands.
* Help users interpret non-sensitive errors.
* Prepare support escalation summaries.
* Observe moderation.
* Draft warnings for mentor approval.
* Recommend channel actions.
* Prepare incident timelines.
* Record publicly observed relay information.
* Assist with documentation updates.
* Shadow experienced staff.
* Participate in approved simulations.
* Report possible security issues.

All activity remains subject to supervision.

= 10. Prohibited Trainee Actions =

Unless separately and explicitly authorized, a trainee must not:

* Use IRC operator commands.
* Apply network-wide bans.
* Use OperOverride.
* Use SAMODE or forced modes.
* Use OperServ administrative commands.
* Suspend accounts or channels.
* Change channel founders.
* Drop registered accounts or channels.
* Approve or reject advertising applications.
* Approve, suspend, or remove relays.
* Access confidential server logs.
* Access hidden user information.
* Modify IRCd or Services configuration.
* Access production servers.
* Share staff-channel information.
* Represent recommendations as final decisions.
* Conduct unsupervised confidential investigations.
* Grant staff or project access.
* Test dangerous commands against real users.

= 11. Supervision Levels =

A trainee task may be assigned one of three supervision levels.

{| class="wikitable" style="width:100%;"
! Level
! Meaning
! Example
|-
| '''Observe'''
| Trainee watches but does not act
| Observe a Services ownership review
|-
| '''Prepare'''
| Trainee drafts a response or recommendation for approval
| Draft a warning or escalation summary
|-
| '''Perform'''
| Trainee completes a specifically approved low-risk task
| Provide connection settings in `#Help`
|}

The mentor should record which duties are approved at each level.

= 12. Trainee Identification =

Trainees must describe their role accurately.

Appropriate wording:

<pre>
I am a supervised DarkWorld IRC trainee. I can help collect the details and refer this to the authorized team.
</pre>

Inappropriate wording:

<pre>
I am an IRC administrator.
I can guarantee your application will be approved.
I will permanently ban them.
I control all DarkWorld projects.
</pre>

Trainee status should not be used to intimidate users.

= 13. Daily Activity Record =

The trainee should maintain a simple activity record:

<pre>
Date:
Start and end time:
Channels attended:
Support cases handled:
Documentation provided:
Cases escalated:
Moderation observed:
Reports prepared:
Mentor consulted:
Mistakes or corrections:
Unresolved items:
</pre>

The record should not contain passwords, unnecessary IP addresses, or unrestricted private evidence.

= 14. Support Case Record =

For each significant support case:

<pre>
Date and time:
Channel:
User nickname:
Issue category:
User’s goal:
Relevant non-sensitive details:
Guidance provided:
Result:
Escalation:
Mentor review:
Documentation improvement suggested:
</pre>

Routine greetings and very simple answers do not require full case reports unless the mentor requests them.

= 15. Moderation Observation Record =

When observing moderation:

<pre>
Date and time:
Channel:
Behavior observed:
Applicable rule:
Was a warning appropriate?
Action recommended by trainee:
Action taken by authorized staff:
Difference between recommendation and action:
Users affected:
Evidence preserved:
What the trainee learned:
</pre>

The trainee should compare their recommendation with the authorized staff decision.

= 16. Incident Observation Record =

For a significant incident:

<pre>
Incident reference:
Date and time:
Initial severity:
Affected channels or services:
Confirmed facts:
User reports:
Trainee task:
Incident lead:
Actions observed:
Evidence prepared:
Handover completed:
Recovery observed:
Follow-up lesson:
</pre>

Trainees must not keep private copies of restricted evidence after the approved task ends.

= 17. Expected Support Performance =

A successful trainee should:

* Acknowledge users promptly where possible.
* Ask useful questions.
* Avoid assuming user error.
* Give clear and safe instructions.
* Use current official information.
* Protect credentials.
* Respect language differences.
* Confirm outcomes.
* Escalate unresolved cases.
* Avoid making unauthorized promises.

= 18. Expected Moderation Judgment =

A successful trainee should:

* Identify the applicable rule.
* Distinguish channel and network authority.
* Recommend proportionate action.
* Consider innocent users.
* Recognize shared hosts.
* Avoid retaliatory responses.
* Preserve relevant evidence.
* Use professional reasons.
* Recommend review dates.
* Request higher authority when required.

= 19. Expected Incident Performance =

A successful trainee should:

* Recognize serious incidents.
* Assign a reasonable initial severity.
* Identify ongoing harm.
* Notify appropriate staff.
* Follow the incident lead.
* Maintain accurate timestamps.
* Separate facts from allegations.
* Protect restricted evidence.
* Prepare useful handovers.
* Assist with recovery and review.

= 20. Expected Security Conduct =

A successful trainee should:

* Use TLS and SASL.
* Protect their NickServ account.
* Use unique credentials.
* Secure their device.
* Avoid untrusted scripts.
* Recognize phishing.
* Report exposed credentials.
* Avoid accessing information without need.
* Maintain staff-channel confidentiality.
* Report security concerns promptly.

= 21. Expected Team Conduct =

A successful trainee should:

* Accept correction professionally.
* Ask questions when uncertain.
* Avoid public staff disagreements.
* Follow the mentor and incident lead.
* Complete assigned records.
* Be honest about mistakes.
* Meet reasonable activity expectations.
* Communicate absence.
* Respect other teams.
* Avoid gossip and favoritism.

= 22. Weekly Evaluation =

The mentor should complete a review at the end of each training week.

{| class="wikitable" style="width:100%;"
! Evaluation area
! Weight
|-
| User support and communication
| 15%
|-
| IRC and Services knowledge
| 10%
|-
| Policy understanding
| 10%
|-
| Moderation judgment
| 15%
|-
| Incident awareness
| 10%
|-
| Privacy and security
| 15%
|-
| Documentation
| 10%
|-
| Reliability and activity
| 5%
|-
| Teamwork and acceptance of feedback
| 10%
! Total
| 100%
|}

= 23. Weekly Scoring Scale =

{| class="wikitable" style="width:100%;"
! Score
! Rating
! Meaning
|-
| 90–100
| Excellent
| Consistently safe, accurate, reliable, and professional
|-
| 80–89
| Ready
| Meets trainee expectations with minor improvement areas
|-
| 70–79
| Developing
| Additional supervision and practice required
|-
| 60–69
| Concern
| Significant weaknesses require remediation
|-
| Below 60
| Unsatisfactory
| Candidate is not currently ready for live trainee duties
|}

Security, integrity, retaliation, and confidentiality concerns must be assessed separately from the numerical score.

= 24. Weekly Review Form =

<pre>
TRAINEE WEEKLY REVIEW

Candidate:
Registered account:
Trainee path:
Week number:
Review period:
Mentor:
Secondary reviewer:

User support and communication: /15
IRC and Services knowledge: /10
Policy understanding: /10
Moderation judgment: /15
Incident awareness: /10
Privacy and security: /15
Documentation: /10
Reliability and activity: /5
Teamwork and feedback: /10

TOTAL: /100

Cases handled:
Exercises completed:
Positive observations:
Mistakes:
Corrections completed:
Security concerns:
Conduct concerns:
Modules to review:
Duties approved for next week:
Duties still prohibited:
Candidate comments:
Mentor recommendation:
Next review date:
</pre>

= 25. Mentor Feedback =

Feedback should be:

* Specific.
* Based on observed behavior.
* Timely.
* Respectful.
* Actionable.
* Connected to policy or procedure.
* Recorded for important concerns.

Good feedback:

<pre>
During the SASL case, you correctly avoided requesting the password. However, you provided several steps at once. Next time, first confirm TLS and the registered account name, then test one change.
</pre>

Poor feedback:

<pre>
You are bad at support.
</pre>

= 26. Candidate Response to Feedback =

The trainee should:

* Listen carefully.
* Ask for clarification.
* Avoid becoming defensive.
* Correct factual misunderstandings respectfully.
* Complete assigned remediation.
* Record what they learned.
* Demonstrate improvement.

A candidate may request review if they believe feedback is unfair, but must use the approved process.

= 27. Mistakes During Training =

A mistake does not automatically end the trainee period.

The mentor should consider:

* Severity.
* Whether the action was authorized.
* Harm caused.
* Whether the trainee reported it.
* Whether it was corrected.
* Whether the trainee understood the cause.
* Whether it was repeated.
* Whether dishonesty or retaliation occurred.

A trainee who honestly reports and corrects a minor mistake may continue.

A trainee who conceals, repeats, or intentionally causes serious harm may be removed.

= 28. Immediate Suspension Conditions =

Trainee duties should be paused immediately when there is:

* Credential sharing.
* Intentional privacy exposure.
* Unauthorized operator or Services action.
* Retaliation.
* Evidence falsification.
* Staff impersonation.
* Malicious activity.
* Unauthorized production-system access.
* Refusal to stop an unsafe action.
* Serious harassment.
* Sharing restricted staff information.
* Attempted approval manipulation.

Suspension protects the network while the matter is reviewed.

= 29. Inactivity =

A trainee should inform their mentor when unable to participate.

The trainee period may be paused when:

* The candidate is absent for an extended period.
* The mentor is unavailable.
* The network cannot provide safe supervision.
* A relevant project or system is under maintenance.
* An investigation is pending.

Inactivity alone is not misconduct, but insufficient observation may prevent advancement.

= 30. Required Trainee Experiences =

Before completing the trainee stage, the candidate should have:

<pre>
[ ] Assisted with at least five support cases
[ ] Completed at least two Services support cases
[ ] Prepared at least two escalation summaries
[ ] Observed at least three moderation cases
[ ] Drafted at least two professional warnings
[ ] Completed at least one moderation record
[ ] Participated in at least one incident simulation or real supervised incident
[ ] Prepared at least one incident timeline
[ ] Completed one incident handover
[ ] Demonstrated project-boundary awareness
[ ] Demonstrated safe credential handling
[ ] Received at least two mentor reviews
[ ] Received one secondary-review observation
</pre>

Real incidents are not required if suitable simulations are available.

= 31. Final Trainee Evaluation =

At the end of the trainee period, the mentor should complete:

<pre>
FINAL TRAINEE EVALUATION

Candidate:
Registered account:
Trainee reference:
Trainee path:
Start date:
End date:
Total observed days:
Mentor:
Secondary reviewer:

Support cases completed:
Services cases completed:
Moderation cases observed:
Incident exercises completed:
Reports completed:
Documentation contributions:

Average weekly score:
Final evaluation score:

Mandatory security competencies passed: Yes / No
Code of Conduct maintained: Yes / No
Confidentiality maintained: Yes / No
Conflicts disclosed: Yes / No
Required experiences completed: Yes / No

Strengths:
Weaknesses:
Unresolved concerns:
Security concerns:
Conduct concerns:
Recommended role:
Recommended permissions:
Explicitly excluded permissions:
Recommended probation duration:
Recommended mentor:
Final recommendation:
</pre>

= 32. Final Evaluation Outcomes =

{| class="wikitable" style="width:100%;"
! Outcome
! Meaning
|-
| '''ADVANCE TO PROBATION'''
| Candidate is ready for limited probationary duties
|-
| '''EXTEND TRAINEE PERIOD'''
| More observation is required
|-
| '''REMEDIATION REQUIRED'''
| Specific modules or skills must be repeated
|-
| '''REASSIGN TRAINEE PATH'''
| Candidate may be better suited to another role
|-
| '''PAUSE'''
| Evaluation cannot continue currently
|-
| '''END CANDIDACY'''
| Candidate is not suitable for progression
|}

= 33. Advancement Requirements =

To advance to probation, the candidate should:

* Achieve an average trainee score of at least '''80%'''.
* Complete required trainee experiences.
* Demonstrate safe credential handling.
* Maintain confidentiality.
* Follow project boundaries.
* Accept mentor feedback.
* Show reliable participation.
* Demonstrate proportionate judgment.
* Have no unresolved serious conduct concern.
* Receive mentor recommendation.
* Receive secondary review.
* Receive management approval.

A numerical score alone does not override a serious security or integrity concern.

= 34. Access Recommendation for Probation =

Before probation, define:

<pre>
Probationary role:
Operational purpose:
Approved channels:
Approved commands:
Approved systems:
Read-only access:
Action requiring mentor approval:
Prohibited commands:
Prohibited systems:
Logging requirements:
Mentor:
Backup mentor:
Start date:
Review date:
End date:
Management approval:
</pre>

No undefined or “all access” permission should be granted to a probationary staff member.

= 35. Candidate Acknowledgement =

Before entering probation, the candidate should affirm:

<pre>
I understand that my trainee evaluation does not guarantee permanent staff
appointment.

I agree to use only the permissions explicitly assigned to my probationary
role.

I will continue to follow the DarkWorld IRC Staff Code of Conduct, protect
confidential information, report mistakes, and accept supervision.

I understand that access may be reduced, suspended, or removed to protect
the network.

Candidate:
Registered account:
Date:
Mentor:
</pre>

= 36. Next Step =

Candidates approved for advancement proceed to:

'''[[DWIRC:Staff Training/Probation|DarkWorld IRC Probationary Staff Program]]'''

----

'''Previous:''' [[DWIRC:Staff Training/Practical Assessment|Final Practical Assessment]]
'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
'''Next:''' [[DWIRC:Staff Training/Probation|Probationary Staff Program]]

[[Category:DarkWorld IRC Staff Training]]
[[Category:DWIRC]]
[[Category:IRC Trainees]]
[[Category:Staff Evaluation]]
[[Category:Staff Documentation]]

DWIRC:Staff Training/Trainee Evaluation

2026-08-08T18:23:19Z

Fizi: Created page with "{{DISPLAYTITLE:DarkWorld IRC Trainee Evaluation}} <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%;">Supervised Trainee Evaluation</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Stage | Supervis..."

DWIRC:Staff Training/Practical Assessment

2026-08-08T18:20:28Z

Fizi: Protected "DWIRC:Staff Training/Practical Assessment" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:DarkWorld IRC Staff Final Practical Assessment}}

<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%;">Final Practical Assessment</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Program
| [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
|-
! Assessment
| Final Practical Assessment
|-
! Maximum score
| 100 points
|-
! Passing score
| 80 points
|-
! Recommended duration
| 90–150 minutes
|-
! Environment
| Approved training channels, test accounts, and simulations
|-
! Prerequisites
| Modules 1–10, Code of Conduct, and Final Written Examination
|}

= 1. Purpose =

The Final Practical Assessment determines whether a candidate can apply their training safely in realistic IRC situations.

The assessment evaluates:

* Secure IRC connection.
* Identity and account verification.
* IRC command accuracy.
* Channel modes.
* NickServ and ChanServ support.
* User communication.
* Moderation judgment.
* Incident handling.
* Evidence and documentation.
* Operator-level decision-making.
* Ethics and security.

Passing the written examination is not sufficient if the candidate cannot perform safely in practical situations.

= 2. Safety Rules =

All exercises must use:

* An approved training channel.
* Trainer-controlled test accounts.
* Simulated evidence.
* Written command proposals.
* A non-production environment where available.

Candidates must not:

* Test commands against real users.
* Apply production network bans.
* Use production operator credentials.
* Request or enter another user’s password.
* Change real channel ownership.
* Modify production IRCd or Services configuration.
* Use OperOverride in production.
* Open simulated malicious links.
* Share restricted assessment information.
* Continue an action after the examiner says to stop.

<div style="background:#fdecec; border-left:4px solid #dc2626; padding:12px; margin:15px 0;">
'''Safety gate:''' A candidate who performs an unauthorized high-risk production action may be stopped and failed immediately.
</div>

= 3. Assessment Structure =

{| class="wikitable" style="width:100%;"
! Station
! Assessment area
! Points
|-
| 1
| Secure connection and identity
| 10
|-
| 2
| IRC commands and information
| 10
|-
| 3
| Channel modes and access
| 15
|-
| 4
| NickServ and ChanServ support
| 15
|-
| 5
| User support and communication
| 10
|-
| 6
| Moderation
| 15
|-
| 7
| Incident response
| 15
|-
| 8
| Operator judgment, ethics, and security
| 10
|-
! colspan="2" | Total
! 100
|}

= 4. Mandatory Competencies =

Regardless of total score, the candidate must demonstrate all of the following:

<pre>
[ ] Does not request or expose passwords
[ ] Uses verified TLS
[ ] Understands project boundaries
[ ] Can reverse training mode changes
[ ] Avoids dangerously broad bans
[ ] Escalates serious incidents
[ ] Protects confidential evidence
[ ] Discloses conflicts of interest
[ ] Reports mistakes honestly
[ ] Does not use production operator access
</pre>

Failure of a mandatory competency may result in failure even when the numerical score reaches 80.

= 5. Candidate Information =

<pre>
Registered account:
Current nickname:
Candidate reference:
Assessment version:
Assessment date:
Start time:
End time:
Timezone:
Primary examiner:
Secondary examiner:
Training channel:
Test identities:
</pre>

= Station 1 — Secure Connection and Identity =

'''Maximum: 10 points'''

== Candidate Tasks ==

The candidate must configure or demonstrate an IRC connection using:

<pre>
Server: irc.darkworld.network
Port: 6697
TLS: Enabled
Certificate verification: Enabled
SASL: Enabled where available
</pre>

The candidate must then:

# Connect successfully.
# Identify the current nickname.
# Identify the ident.
# Identify the displayed hostname.
# Identify the registered Services account.
# Demonstrate WHOIS on their own training identity.
# Explain how the four identity elements differ.
# Explain what should happen if a certificate warning appears.
# Confirm that no credentials appear in public output.

== Scoring ==

{| class="wikitable" style="width:100%;"
! Competency
! Points
|-
| Correct server, port, and TLS
| 2
|-
| Certificate verification retained
| 1
|-
| SASL configured or correctly explained
| 2
|-
| Identity elements correctly identified
| 2
|-
| WHOIS used and interpreted safely
| 2
|-
| No credential exposure
| 1
|}

== Critical Errors ==

* Disabling certificate verification without authorization.
* Posting a password.
* Claiming that WHOIS proves legal identity.
* Connecting to an unapproved server for the exercise.

= Station 2 — IRC Commands and Information =

'''Maximum: 10 points'''

== Candidate Tasks ==

Using an approved training channel, demonstrate:

<pre>
/JOIN #ApprovedTrainingChannel
/NAMES #ApprovedTrainingChannel
/TOPIC #ApprovedTrainingChannel
/WHO #ApprovedTrainingChannel
/WHOIS TestNickname
/MODE #ApprovedTrainingChannel
/MODE YourNickname
/PART #ApprovedTrainingChannel Assessment exercise
</pre>

The examiner may ask the candidate to explain:

* The purpose of each command.
* Which commands change state.
* Which commands require authorization.
* What information must remain confidential.
* How a netsplit differs from a normal quit.

== Scoring ==

{| class="wikitable" style="width:100%;"
! Competency
! Points
|-
| Correct command targets
| 2
|-
| Correct interpretation of results
| 2
|-
| Understands state-changing commands
| 2
|-
| Protects restricted information
| 2
|-
| Correctly explains quits and netsplits
| 2
|}

= Station 3 — Channel Modes and Access =

'''Maximum: 15 points'''

== Candidate Tasks ==

With examiner authorization, the candidate must:

# View current channel modes.
# Record the original mode state.
# Set moderated mode.
# Demonstrate the effect on an unvoiced test user.
# Grant voice to the test user.
# Remove voice.
# Remove moderated mode.
# Apply a trainer-provided temporary ban.
# View the ban list.
# Remove the exact ban.
# Verify that the original channel state is restored.
# Explain `+b`, `+e`, and `+I`.
# Explain the differences between `+v`, `+h`, `+o`, `+a`, and `+q`.

Example training commands may include:

<pre>
/MODE #ApprovedTrainingChannel +m
/MODE #ApprovedTrainingChannel +v TestUser
/MODE #ApprovedTrainingChannel -v TestUser
/MODE #ApprovedTrainingChannel -m
/MODE #ApprovedTrainingChannel +b TrainerProvidedMask
/MODE #ApprovedTrainingChannel +b
/MODE #ApprovedTrainingChannel -b TrainerProvidedMask
</pre>

== Scoring ==

{| class="wikitable" style="width:100%;"
! Competency
! Points
|-
| Records original state
| 2
|-
| Applies modes accurately
| 3
|-
| Uses parameters correctly
| 2
|-
| Understands access hierarchy
| 2
|-
| Explains ban and exception lists
| 2
|-
| Verifies every change
| 2
|-
| Restores original state
| 2
|}

== Critical Errors ==

* Applying a broad `*!*@*` ban.
* Targeting a real user without permission.
* Failing to remove training restrictions.
* Using override commands.
* Changing founder or persistent access without authorization.

= Station 4 — NickServ and ChanServ Support =

'''Maximum: 15 points'''

== Candidate Tasks ==

The candidate must safely assist simulated users with:

=== Case A: NickServ Authentication ===

A user can connect but cannot authenticate.

The candidate should:

* Ask for the exact error.
* Confirm the registered account name.
* Confirm email registration where relevant.
* Confirm TLS.
* Check SASL configuration.
* Use official NickServ help.
* Avoid asking for the password.
* Escalate if normal recovery fails.

=== Case B: Nickname Already in Use ===

The user’s normal nickname is connected elsewhere.

The candidate should:

* Ask the user to connect with a temporary nickname.
* Confirm account authentication.
* Check whether a bouncer or other client is connected.
* Locate the supported recovery help.
* Avoid forcibly disconnecting the nickname without verification.

=== Case C: Missing Channel Operator Status ===

A user says ChanServ did not give them `+o`.

The candidate should distinguish:

* Current nickname.
* Registered account.
* Live `+o`.
* Persistent ChanServ access.
* Channel settings.
* Possible Services failure.

== Scoring ==

{| class="wikitable" style="width:100%;"
! Competency
! Points
|-
| Uses current Services help
| 2
|-
| Protects passwords
| 3
|-
| Correct NickServ troubleshooting
| 3
|-
| Safe nickname-recovery guidance
| 2
|-
| Distinguishes live mode from access
| 3
|-
| Escalates ownership or administrative issues
| 2
|}

== Critical Errors ==

* Asking for a password.
* Asking for an email-confirmation code.
* Identifying to the user’s account.
* Changing a channel founder.
* Dropping a channel.
* Using OperServ without authorization.

= Station 5 — User Support and Communication =

'''Maximum: 10 points'''

== Simulation ==

The examiner acts as a frustrated new user who says:

<blockquote>
“I cannot connect, NickServ does not work, and nobody is helping me.”
</blockquote>

The candidate must:

# Acknowledge the user.
# Clarify whether the problem occurs before or after connection.
# Ask for the client and exact error.
# Confirm the server, port, and TLS.
# Avoid blaming the user.
# Provide one step at a time.
# Explain expected results.
# Recognize a possible wider problem if other reports appear.
# Summarize or escalate the case.
# Close professionally.

== Scoring ==

{| class="wikitable" style="width:100%;"
! Competency
! Points
|-
| Professional acknowledgement
| 1
|-
| Identifies the actual problem
| 2
|-
| Asks useful questions
| 2
|-
| Provides clear steps
| 2
|-
| Protects privacy and credentials
| 1
|-
| De-escalates frustration
| 1
|-
| Confirms outcome or escalates
| 1
|}

= Station 6 — Moderation =

'''Maximum: 15 points'''

== Simulation A: Repeated Flooding ==

A test user repeatedly floods the training channel after a warning.

The candidate must:

* Issue a clear formal warning.
* Preserve the relevant context.
* Select a proportionate response.
* Set a precise trainer-approved ban if required.
* Kick with a professional reason.
* Verify the restriction.
* Complete a moderation record.
* Explain when the ban should be reviewed.

== Simulation B: Shared Host ==

The disruptive test user shares a displayed host with two innocent test users.

The candidate must:

* Recognize the shared-host risk.
* Avoid banning the entire host automatically.
* Recommend a more precise restriction.
* Explain when network assistance is required.
* Protect innocent users.

== Scoring ==

{| class="wikitable" style="width:100%;"
! Competency
! Points
|-
| Warning quality
| 2
|-
| Proportionate response
| 3
|-
| Ban-mask precision
| 3
|-
| Professional kick reason
| 2
|-
| Protects innocent users
| 2
|-
| Verifies and documents action
| 2
|-
| Defines review or expiry
| 1
|}

== Critical Errors ==

* Banning every user to stop one person.
* Using an insult as a kick reason.
* Punishing criticism rather than misconduct.
* Applying network-level commands.
* Ignoring known innocent users affected by the mask.

= Station 7 — Incident Response =

'''Maximum: 15 points'''

== Simulation ==

The examiner presents the following developing incident:

<blockquote>
Three new accounts join `#DarkWorld` and begin posting a fake NickServ login page. Similar links appear in `#Help`. One user says they entered their password. A relay begins importing the same link from an external channel. Staff have not yet assigned an incident lead.
</blockquote>

The candidate must:

# Recognize the incident and assign an initial severity.
# Identify ongoing harm.
# Recommend immediate containment.
# Avoid opening the malicious link.
# Protect the user who exposed credentials.
# Preserve messages, timestamps, accounts, channels, and relay information.
# Notify appropriate staff.
# Request or identify incident leadership.
# Prepare an internal update.
# Prepare a safe public warning.
# Identify confirmed facts and unverified reports.
# Explain recovery requirements.
# Complete an incident handover.

== Scoring ==

{| class="wikitable" style="width:100%;"
! Competency
! Points
|-
| Incident recognition and severity
| 2
|-
| Immediate containment
| 3
|-
| Credential-compromise response
| 2
|-
| Evidence and privacy
| 2
|-
| Correct escalation
| 2
|-
| Internal and public communication
| 2
|-
| Handover and recovery
| 2
|}

== Critical Errors ==

* Opening the simulated malicious link.
* Repeating an exposed password.
* Announcing that all accounts are compromised without evidence.
* Publishing restricted evidence.
* Failing to escalate active phishing.
* Treating the relay operator as the confirmed author without investigation.

= Station 8 — Operator Judgment, Ethics, and Security =

'''Maximum: 10 points'''

== Scenario A: Network Restriction ==

An abusive connection shares a VPN endpoint with twenty legitimate users. The candidate is asked whether to recommend a permanent global host ban.

The candidate must:

* Identify the scope risk.
* Consider narrower options.
* Explain required authorization.
* Propose a proportionate duration.
* Define verification and review.
* Avoid executing the command.

== Scenario B: Conflict of Interest ==

The candidate’s friend asks them to remove a ban.

The candidate must:

* Disclose the conflict.
* Avoid making the final decision.
* Preserve the original action.
* Refer the appeal to a neutral reviewer.

== Scenario C: Credential Exposure ==

A simulated operator password is posted in a restricted channel.

The candidate must:

* Treat it as compromised.
* Avoid repeating it.
* Escalate immediately.
* Recommend credential rotation.
* Review related access.
* Document the incident.

== Scoring ==

{| class="wikitable" style="width:100%;"
! Competency
! Points
|-
| Network-ban judgment
| 3
|-
| Conflict-of-interest handling
| 2
|-
| Credential-compromise response
| 3
|-
| Accountability and documentation
| 2
|}

== Critical Errors ==

* Recommending a broad permanent ban without considering innocent users.
* Removing a friend’s ban.
* Reusing or sharing the exposed credential.
* Hiding the exposure.
* Performing a production network command.

= 6. Mandatory Documentation Tasks =

The candidate must submit:

# One support escalation summary.
# One channel-mode change record.
# One moderation report.
# One incident timeline.
# One incident handover.
# One operator-action proposal.
# One security-incident report.
# One candidate self-review.

Submissions must not contain real credentials or unnecessary private information.

= 7. Candidate Self-Review =

After completing all stations, the candidate should answer:

<pre>
1. Which station was most difficult?
2. Which action required the most caution?
3. Did I make any command or judgment error?
4. How did I correct it?
5. Did any proposed action risk innocent users?
6. What did I escalate rather than handle alone?
7. What further training do I require?
8. Am I ready for supervised trainee duties?
9. Which specialist area interests me?
10. What access do I believe is not yet appropriate for me?
</pre>

A candidate who honestly identifies a limitation should not be penalized merely for recognizing it.

= 8. Examiner Scoring Record =

<pre>
Candidate:
Assessment version:
Date:

Station 1 — Secure connection: /10
Station 2 — IRC commands: /10
Station 3 — Channel modes: /15
Station 4 — IRC Services: /15
Station 5 — User support: /10
Station 6 — Moderation: /15
Station 7 — Incident response: /15
Station 8 — Operator ethics and security: /10

TOTAL: /100

Mandatory competencies passed: Yes / No
Critical error observed: Yes / No
Automatic-failure review required: Yes / No

Strong areas:
Weak areas:
Unsafe actions:
Commands requiring correction:
Privacy or security concerns:
Recommended remediation:
Recommended trainee role:
Recommended access level:
Examiner:
Second examiner:
Final result:
</pre>

= 9. Assessment Results =

{| class="wikitable" style="width:100%;"
! Result
! Meaning
|-
| '''PASS'''
| Candidate scored at least 80 and passed every mandatory competency
|-
| '''CONDITIONAL PASS'''
| Minor, non-safety remediation required
|-
| '''REVISION REQUIRED'''
| Candidate requires additional study and another practical assessment
|-
| '''FAIL'''
| Candidate did not meet the required standard
|-
| '''DISQUALIFIED'''
| Serious safety, integrity, or unauthorized-access violation occurred
|}

A conditional pass cannot be used when the candidate fails a mandatory security or ethics competency.

= 10. Automatic-Failure Review =

Possible automatic-failure conditions include:

* Requesting or exposing a password.
* Using production operator credentials.
* Applying a production network ban.
* Running a dangerous server command.
* Using OperOverride without authorization.
* Intentionally targeting a real user.
* Deliberately falsifying evidence.
* Retaliating during the assessment.
* Sharing restricted assessment material.
* Refusing to stop an unsafe action.
* Impersonating another candidate.
* Attempting to alter the examiner’s record.

Where practical, two authorized reviewers should confirm an automatic-failure decision.

= 11. Remediation =

A candidate requiring additional training should receive:

* A written feedback summary.
* Specific modules to review.
* Required exercises.
* A minimum practice period where appropriate.
* A different assessment scenario.
* A supervised re-attempt date.

Examples:

{| class="wikitable" style="width:100%;"
! Weakness
! Recommended remediation
|-
| Unsafe ban masks
| Repeat Modules 4 and 7 with targeted-ban exercises
|-
| Poor account security
| Repeat Modules 5 and 10
|-
| Weak support communication
| Repeat Module 6 and complete roleplays
|-
| Poor incident coordination
| Repeat Module 8 and handover exercises
|-
| Excessive operator response
| Repeat Modules 7, 8, and 9
|-
| Project-boundary confusion
| Repeat Modules 1 and 10
|}

= 12. Reassessment =

A candidate may normally receive one reassessment after completing assigned remediation.

The reassessment should:

* Use different test identities.
* Use different incident details.
* Retest failed competencies.
* Retest any mandatory safety concern.
* Confirm that earlier weaknesses were corrected.
* Be recorded separately.

A third attempt should require management approval.

= 13. Recommendation for Trainee Placement =

Passing the assessment means the candidate may be considered for supervised trainee duties.

It does not create an automatic right to:

* IRC operator access.
* OperServ access.
* IRCd server access.
* Services database access.
* Policy approval access.
* Relay administrative access.
* Access to another DarkWorld project.

The examiner may recommend:

{| class="wikitable" style="width:100%;"
! Recommendation
! Suitable initial duties
|-
| Support trainee
| Help-channel assistance and documentation
|-
| Moderation trainee
| Supervised channel moderation
|-
| Policy trainee
| Policy links, case preparation, and observation
|-
| Relay compliance trainee
| Discovery records and supervised follow-up
|-
| Services support trainee
| Normal account and channel assistance
|-
| Operator candidate
| Additional supervised operator-specific training
|-
| Further training
| No live duties until remediation is complete
|}

= 14. Access Recommendation =

The examiner should recommend the minimum access required.

Example:

<pre>
Recommended role:
Recommended public channels:
Recommended staff channels:
Recommended bot permissions:
Recommended Services permissions:
Recommended operator permissions:
Explicitly excluded permissions:
Mentor:
Probation duration:
Review date:
Management approval:
</pre>

= 15. Completion Approval =

The candidate may advance only when:

<pre>
[ ] Written examination passed
[ ] Ethics threshold passed
[ ] Practical assessment passed
[ ] Mandatory competencies passed
[ ] Code of Conduct accepted
[ ] Security declaration accepted
[ ] Candidate identity verified
[ ] Mentor assigned
[ ] Role defined
[ ] Access recommendation completed
[ ] Management approval recorded
</pre>

= 16. Next Step =

Candidates who pass proceed to:

'''[[DWIRC:Staff Training/Trainee Evaluation|DarkWorld IRC Trainee Evaluation]]'''

----

'''Previous:''' [[DWIRC:Staff Training/Final Examination|Final Written Examination]]
'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
'''Next:''' [[DWIRC:Staff Training/Trainee Evaluation|Trainee Evaluation]]

[[Category:DarkWorld IRC Staff Training]]
[[Category:DWIRC]]
[[Category:Staff Practical Assessments]]
[[Category:Staff Documentation]]

DWIRC:Staff Training/Practical Assessment

2026-08-08T18:20:19Z

Fizi: Created page with "{{DISPLAYTITLE:DarkWorld IRC Staff Final Practical Assessment}} <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%;">Final Practical Assessment</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Asses..."

DWIRC:Staff Training/Final Examination

2026-08-08T18:18:06Z

Fizi: Protected "DWIRC:Staff Training/Final Examination" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:DarkWorld IRC Staff Final Written Examination}}

<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%;">Final Written Examination</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Program
| [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
|-
! Assessment
| Final Written Examination
|-
! Maximum score
| 100 points
|-
! Overall passing score
| 75 points
|-
! Ethics and security requirement
| At least 26 of 30 points
|-
! Recommended duration
| 120 minutes
|-
! Attempts
| Two attempts unless management authorizes otherwise
|-
! Prerequisites
| Modules 1–10 and acceptance of the [[DWIRC:Staff Training/Code of Conduct|Staff Code of Conduct]]
|}

= 1. Purpose =

The Final Written Examination evaluates whether a candidate understands the knowledge, policies, responsibilities, security requirements, and judgment expected from potential DarkWorld IRC staff.

Passing the written examination does not grant staff access.

Candidates must also pass the:

* [[DWIRC:Staff Training/Practical Assessment|Final Practical Assessment]]
* [[DWIRC:Staff Training/Trainee Evaluation|Trainee Evaluation]]
* [[DWIRC:Staff Training/Probation|Probationary Staff Period]]

= 2. Examination Rules =

Unless the examiner states otherwise:

* The examination is supervised.
* It is completed individually.
* It is closed-book.
* Candidates must answer in their own words.
* Candidates may not receive answers from another person.
* Candidates may not use another candidate’s submission.
* Candidates may not alter examination records.
* Candidates must not perform commands against production users.
* Practical commands must be written or simulated only.
* Sensitive credentials must never be included.
* Questions may be clarified, but examiners must not provide answers.
* All answers must be submitted through the approved process.

Cheating, impersonation, falsification, or unauthorized assistance may result in failure or removal from the training program.

= 3. Examination Structure =

{| class="wikitable" style="width:100%;"
! Section
! Subject
! Points
|-
| A
| IRC and network fundamentals
| 20
|-
| B
| Short-answer operational knowledge
| 20
|-
| C
| Policy and incident scenarios
| 30
|-
| D
| Ethics and security
| 30
|-
! colspan="2" | Total
! 100
|}

The candidate must achieve:

* At least '''75/100 overall'''.
* At least '''26/30 in Section D'''.
* No automatic-failure condition.
* Acceptable judgment in all high-risk scenarios.

= 4. Candidate Information =

<pre>
Registered account:
Current nickname:
Candidate reference:
Exam version:
Exam date:
Start time:
End time:
Timezone:
Examiner:
Submission method:
</pre>

= Section A — IRC and Network Fundamentals =

'''Instructions:''' Select the best answer. Each question is worth '''1 point'''.

== Question 1 ==

What is the relationship between DarkWorld Network and DarkWorld IRC?

A. They are unrelated organizations.
B. DarkWorld IRC is one project under the DarkWorld Network umbrella.
C. DarkWorld IRC controls every DarkWorld project.
D. DarkWorld Network is an IRC channel.

== Question 2 ==

Which setting is recommended for a secure DarkWorld IRC connection?

A. `irc.darkworld.network`, port 6697, TLS enabled
B. `irc.darkworld.network`, port 21, TLS disabled
C. A direct IP address with certificate verification disabled
D. Any server and any open port

== Question 3 ==

Which part of this mask is the ident?

<pre>
Falcon!student@User.DarkWorld.Network
</pre>

A. Falcon
B. student
C. User.DarkWorld.Network
D. DarkWorld

== Question 4 ==

What does SASL normally provide?

A. Channel encryption between users
B. Authentication to a registered IRC account during connection
C. Automatic network bans
D. IRC server administration

== Question 5 ==

What is the primary purpose of TLS?

A. To give channel operator status
B. To register a nickname
C. To encrypt the connection between the client and IRC server
D. To hide messages from other channel members

== Question 6 ==

Which command normally displays information about a connected user?

A. `/WHOIS nickname`
B. `/TOPIC nickname`
C. `/PART nickname`
D. `/MOTD nickname`

== Question 7 ==

What is a netsplit?

A. A user changing nicknames
B. A loss of communication between linked IRC servers
C. A channel ban
D. A failed NickServ registration

== Question 8 ==

Which channel status commonly represents voice?

A. `+o`
B. `+q`
C. `+v`
D. `+a`

== Question 9 ==

What does channel mode `+m` generally do?

A. Deletes the channel
B. Makes the channel moderated
C. Registers the channel
D. Hides every user

== Question 10 ==

Which command normally views a channel’s ban list?

A. `/MODE #channel +b`
B. `/BANLIST nickname`
C. `/WHOIS #channel`
D. `/LISTBAN server`

== Question 11 ==

What does ChanServ access normally provide?

A. Persistent channel permissions associated with an account or access entry
B. A permanent IRC operator account
C. Server shell access
D. Authority over every registered channel

== Question 12 ==

What is the difference between live `+o` and ChanServ access?

A. There is no difference.
B. Live `+o` is current channel status; ChanServ access is persistent authorization.
C. ChanServ access grants root access.
D. Live `+o` registers an account.

== Question 13 ==

What should staff do when a user posts a password publicly?

A. Quote it so the user can confirm it.
B. Test it.
C. Tell the user to change it immediately without repeating it.
D. Save it in the incident report.

== Question 14 ==

Which issue normally belongs to DWShells rather than DWIRC staff?

A. NickServ authentication
B. Increasing a Linux shell account’s disk quota
C. An IRC channel mode
D. A netsplit

== Question 15 ==

What is the least-privilege principle?

A. Every staff member receives every permission.
B. Access is limited to what is required for the assigned role.
C. Only founders may use IRC.
D. Staff may share access when busy.

== Question 16 ==

What does a KILL normally do?

A. Deletes a registered account
B. Disconnects a user’s current IRC connection
C. Deletes an IRC channel
D. Restarts an IRC server

== Question 17 ==

What is a serious risk of banning a shared VPN or bouncer hostname?

A. It may affect many unrelated users.
B. It improves authentication.
C. It registers all matching accounts.
D. It removes channel topics.

== Question 18 ==

What is the correct response to conflicting official policy information?

A. Choose whichever policy permits the strongest action.
B. Ignore both sources.
C. Verify the current authoritative policy and escalate uncertainty.
D. Ask a random channel user.

== Question 19 ==

Does completing the training program automatically grant IRC operator access?

A. Yes
B. Only if the candidate requests it
C. No; access requires a role, approval, and successful evaluation
D. Only during weekends

== Question 20 ==

Which statement about WHOIS is correct?

A. WHOIS proves a user’s legal identity.
B. WHOIS may show connection and account information but does not prove legal identity.
C. WHOIS reveals every password.
D. WHOIS provides server root access.

= Section B — Short-Answer Operational Knowledge =

'''Instructions:''' Answer each question in approximately 50–100 words. Each question is worth '''2 points'''.

== Question 21 ==

Explain the difference between a nickname, ident, displayed hostname, and registered Services account.

== Question 22 ==

Explain why staff should not advise users to disable TLS certificate verification when a warning appears.

== Question 23 ==

Describe the safe procedure for helping a user who cannot identify to NickServ.

== Question 24 ==

Explain the difference between a channel ban, ban exception, and invite exception.

== Question 25 ==

Describe the steps staff should take before applying a significant channel restriction.

== Question 26 ==

Explain why a shared hostname, VPN, shell server, or bouncer does not prove that multiple connections belong to the same person.

== Question 27 ==

Describe the information that should be included in a support-case escalation.

== Question 28 ==

Explain when a channel problem should be escalated to network staff.

== Question 29 ==

Describe what an incident timeline should contain and why UTC should normally be used.

== Question 30 ==

Explain what an IRC operator should verify before applying a network-wide restriction.

= Section C — Policy and Incident Scenarios =

'''Instructions:''' Answer each scenario in approximately 200–350 words. Each scenario is worth '''6 points'''.

Each answer should address:

* Applicable policy or responsibility.
* Confirmed facts.
* Missing information.
* Immediate action.
* Authority boundaries.
* Evidence.
* Escalation.
* Documentation.
* Review or recovery.

== Question 31 — Advertising ==

A user mentions another IRC client’s website once after being asked where it can be downloaded. A trainee immediately accuses the user of prohibited advertising and issues a channel ban.

Explain whether the response was proportionate and what should happen next.

== Question 32 — Relay Compliance ==

A bot relays messages from an external network into a DarkWorld channel. Some messages invite users to join the external network. The channel founder says they approved the bot, but no official relay registration is found.

Explain how the case should be handled.

== Question 33 — Shared Infrastructure ==

One abusive connection and fifteen legitimate DWBouncers users share the same displayed hostname. An operator proposes a permanent global ban of the hostname.

Explain the risks and recommend a safer response.

== Question 34 — Services Ownership ==

A user says they previously owned a registered project channel. They provide an old screenshot and ask a trainee to replace the current founder immediately.

Explain what the trainee should do.

== Question 35 — Coordinated Incident ==

Several new accounts begin posting malicious login links in `#DarkWorld`, `#Help`, and `#Support`. Two users say they entered their NickServ passwords.

Explain the immediate response, escalation, evidence handling, user communication, and recovery requirements.

= Section D — Ethics and Security =

'''Mandatory minimum: 26 of 30 points.'''

Failure in this section cannot be compensated for by a higher score elsewhere.

== Part D1 — Ethical Decisions ==

'''Instructions:''' Select the best answer. Each question is worth '''1 point'''.

=== Question 36 ===

A close friend asks a staff member to remove their ban privately. What should the staff member do?

A. Remove it immediately.
B. Disclose the conflict and direct the appeal to an independent reviewer.
C. Share the ban system password.
D. Delete the original action record.

=== Question 37 ===

A staff member receives a complaint about their own action. Who should make the final review where independence is required?

A. The same staff member alone
B. Their closest friend
C. A neutral authorized reviewer
D. The complainant

=== Question 38 ===

Which action is retaliation?

A. Correcting an incorrect restriction
B. Banning a user because they submitted a staff complaint
C. Recording an incident
D. Asking for an exact error message

=== Question 39 ===

When may staff access private user information?

A. Whenever they are curious
B. When a friend asks
C. When required for an authorized operational duty
D. Whenever the user is offline

=== Question 40 ===

What should happen after an operator password is exposed?

A. Continue using it because only staff saw it
B. Delete the message and say nothing
C. Treat it as compromised, report it, and rotate it
D. Share it with other operators

=== Question 41 ===

May a DWIRC operator use IRC authority to modify a DWShells account?

A. Yes, because both use the DarkWorld name
B. Only with separate DWShells authorization and role-appropriate access
C. Yes, if the user is a friend
D. Yes, without recording it

=== Question 42 ===

A staff member is offered free hosting in exchange for approving an application. What should they do?

A. Accept quietly
B. Approve the application first
C. Decline, preserve the offer, disclose it, and transfer the decision
D. Ask for a larger benefit

=== Question 43 ===

What should staff do after banning the wrong user?

A. Hide the mistake
B. Correct it, report it, preserve the record, and inform the affected user appropriately
C. Blame another operator
D. Add a broader ban

=== Question 44 ===

Does access to a restricted staff channel permit sharing its contents publicly?

A. Yes
B. Only when it proves the staff member was correct
C. No, unless specifically authorized for an operational purpose
D. Yes, after leaving staff

=== Question 45 ===

When do confidentiality obligations end?

A. When a shift ends
B. After resignation
C. After access removal
D. They continue after staff service ends

== Part D2 — Ethics and Security Responses ==

'''Instructions:''' Answer each question in approximately 100–200 words. Each question is worth '''4 points'''.

=== Question 46 — Conflict of Interest ===

You are assigned to investigate a user with whom you recently had a serious personal argument. Explain how you should handle the assignment.

=== Question 47 — Credential Security ===

Describe the security controls you would use to protect NickServ, IRC operator, Services, website, API, and server credentials.

=== Question 48 — Staff Misconduct ===

A user reports that an operator exposed their IP address publicly. The accused operator asks you to send the complaint directly to them and take no further action.

Explain the correct process.

=== Question 49 — Evidence Integrity ===

An operator deletes part of an action log after discovering that their ban affected innocent users.

Explain why this is serious and what should happen.

=== Question 50 — Access Lifecycle ===

Describe the access actions required when a staff member resigns while holding IRC operator, Services, PolicyServ, RelayServ, bot, and restricted-channel access.

= 5. Scoring Guide =

== Section A ==

* 1 point for each correct answer.
* Maximum: 20 points.

== Section B ==

Each answer receives:

* 0 points — Missing, unsafe, or incorrect.
* 1 point — Partially correct but incomplete.
* 2 points — Correct, safe, and clearly explained.

Maximum: 20 points.

== Section C ==

Each scenario receives:

{| class="wikitable"
! Area
! Points
|-
| Correct policy and problem identification
| 1
|-
| Immediate protection
| 1
|-
| Proportionate action
| 1
|-
| Evidence and privacy
| 1
|-
| Authority and escalation
| 1
|-
| Documentation and review
| 1
|}

Maximum: 30 points.

== Section D ==

Part D1:

* 1 point for each correct answer.
* Maximum: 10 points.

Part D2:

* 0 points — Unsafe, missing, or seriously incorrect.
* 1 point — Limited understanding.
* 2 points — Partially correct.
* 3 points — Correct with minor omissions.
* 4 points — Complete, secure, ethical, and well reasoned.

Maximum: 20 points.

Section D maximum: 30 points.
Mandatory minimum: '''26 points'''.

= 6. Automatic-Failure Conditions =

The examination may be failed automatically if the candidate:

* Requests or includes a real password.
* Attempts unauthorized production commands.
* Supports retaliation against a complainant.
* Recommends deliberate evidence destruction.
* Recommends exposing private user information publicly.
* Approves using staff powers for a personal dispute.
* Supports credential sharing.
* Intentionally confuses DWIRC authority with another project’s authority.
* Attempts to obtain examination answers dishonestly.
* Impersonates another candidate.
* Falsifies their submission.

An automatic failure should be reviewed and documented by at least two authorized reviewers where practical.

= 7. Examiner Review =

The examiner should record:

<pre>
Candidate:
Exam version:
Section A score: /20
Section B score: /20
Section C score: /30
Section D1 score: /10
Section D2 score: /20
Section D total: /30
Overall score: /100

Overall threshold met: Yes / No
Ethics threshold met: Yes / No
Automatic-failure issue: Yes / No
Further review required: Yes / No

Strong areas:
Areas requiring improvement:
Security concerns:
Judgment concerns:
Recommended remediation:
Exam result:
Reviewer:
Second reviewer, if required:
Review date:
</pre>

= 8. Examination Results =

Possible results are:

{| class="wikitable" style="width:100%;"
! Result
! Meaning
|-
| '''PASS'''
| Overall and ethics requirements met
|-
| '''CONDITIONAL PASS'''
| Minor remediation required before practical assessment
|-
| '''REVISION REQUIRED'''
| Candidate must review assigned modules before re-examination
|-
| '''FAIL'''
| Requirements not met
|-
| '''DISQUALIFIED'''
| Serious integrity, security, or conduct violation occurred
|}

A conditional pass must not be used to excuse failure of the mandatory ethics threshold.

= 9. Re-Examination =

A candidate who does not pass may normally receive:

* A feedback summary.
* Assigned modules for revision.
* A waiting or study period.
* A different examination version.
* One supervised re-attempt.

The same question set should not be reused where memorization would undermine the assessment.

A third attempt should require specific management approval.

= 10. Examination Security =

The examiner answer key should be stored separately from this candidate-facing page.

It must not be:

* Published on the public wiki.
* Shared in candidate channels.
* Sent to candidates.
* Stored in an unrestricted paste.
* Included in public source code.
* Provided to unauthorized staff.

Examiners should use a restricted page or approved private assessment system.

= 11. Candidate Answer Sheet =

<pre>
DARKWORLD IRC STAFF FINAL WRITTEN EXAMINATION

Candidate:
Registered account:
Candidate reference:
Exam version:
Date:
Examiner:

SECTION A
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.

SECTION B
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.

SECTION C
31.
32.
33.
34.
35.

SECTION D1
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.

SECTION D2
46.
47.
48.
49.
50.

Candidate declaration:

I confirm that I completed this examination independently and did not use
unauthorized assistance, another candidate’s answers, production staff access,
or confidential examination material.

Candidate:
Date:
</pre>

= 12. Next Step =

Candidates who pass the written examination may proceed to:

'''[[DWIRC:Staff Training/Practical Assessment|DarkWorld IRC Staff Final Practical Assessment]]'''

----

'''Previous:''' [[DWIRC:Staff Training/Code of Conduct|DarkWorld IRC Staff Code of Conduct]]
'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
'''Next:''' [[DWIRC:Staff Training/Practical Assessment|Final Practical Assessment]]

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

DWIRC:Staff Training/Final Examination

2026-08-08T18:17:42Z

Fizi: Created page with "{{DISPLAYTITLE:DarkWorld IRC Staff Final Written Examination}} <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%;">Final Written Examination</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Assessm..."

DWIRC:Staff Training/Code of Conduct

2026-08-08T18:14:43Z

Fizi: Protected "DWIRC:Staff Training/Code of Conduct" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:DarkWorld IRC Staff Code of Conduct}}

<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 Network</span><br>
<span style="font-size:125%;">Staff Code of Conduct</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Applies to
| IRC staff candidates, trainees, probationary staff, permanent staff, operators, Services staff, and administrators
|-
! Scope
| DarkWorld IRC Network
|-
! Acceptance
| Mandatory before final assessment and probation
|-
! Enforcement
| DarkWorld IRC management and authorized reviewers
|-
! Related program
| [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
|}

= 1. Purpose =

The '''DarkWorld IRC Staff Code of Conduct''' establishes the standards of behavior, integrity, security, and accountability required from everyone serving or training to serve within the DarkWorld IRC Network.

DarkWorld IRC staff may receive trusted access to:

* IRC users and channels.
* Restricted staff channels.
* IRC operator commands.
* IRC Services.
* Account and channel information.
* Abuse reports.
* Policy and approval systems.
* Logs and operational information.
* Network servers and infrastructure, where separately authorized.

This access must be used only to support, protect, and operate the DarkWorld IRC Network.

= 2. Scope =

This Code applies to:

* Staff applicants where relevant.
* IRC students and trainees.
* Probationary IRC staff.
* Support staff.
* Channel-support staff.
* IRC operators.
* Global IRC operators.
* Services staff.
* Services administrators.
* Policy and compliance staff.
* Abuse and security staff.
* IRCd and network administrators.
* Root administrators.
* Management personnel exercising DWIRC authority.
* Temporary or emergency staff appointments.

The Code applies whenever a person:

* Uses DarkWorld IRC staff access.
* Represents DarkWorld IRC officially.
* Handles DarkWorld IRC information.
* Participates in a DWIRC investigation.
* Uses a staff bot, website, API, or administrative system.
* Performs a task on behalf of the IRC network.

= 3. Relationship to DarkWorld Network =

DarkWorld Network is the wider umbrella under which DarkWorld IRC and other projects operate.

DWIRC staff authority does not automatically grant authority over:

* DWShells.
* DWBouncers.
* DWBots.
* DWGames.
* DWVPN.
* Websites.
* Hosting systems.
* Other DarkWorld projects.
* Registered external projects.

Any role in another project requires separate authorization, training, and access.

= 4. Commitment to Service =

Staff members shall:

* Act in the interests of the IRC network and its community.
* Help users patiently and professionally.
* Protect users from abuse.
* Maintain network stability.
* Apply policies fairly.
* Cooperate with other authorized staff.
* Respect legitimate channel autonomy.
* Escalate matters outside their authority.
* Place operational responsibility above personal status.

Staff access is a responsibility, not a personal entitlement.

= 5. Respectful Conduct =

Staff members shall:

* Treat users and staff respectfully.
* Communicate clearly and professionally.
* Avoid insults, ridicule, humiliation, and intimidation.
* Avoid discriminatory treatment.
* Remain calm during disagreements.
* Recognize language and accessibility barriers.
* Avoid unnecessary public confrontation.
* Correct misinformation without attacking the person.
* Set appropriate boundaries when users become abusive.

Staff members remain entitled to protection from harassment and are not required to tolerate threats or sustained abuse.

= 6. Neutrality and Fairness =

Staff members shall:

* Apply rules consistently.
* Base decisions on policy and evidence.
* Judge conduct rather than personal popularity.
* Avoid favoritism.
* Avoid harsher treatment of personal rivals.
* Avoid special treatment for friends.
* Respect the right to appeal.
* Correct inconsistent enforcement.
* Avoid prejudging cases publicly.

Nationality, race, religion, gender, disability, language, age, political view, technical ability, or social status must not be used as a basis for unfair treatment.

= 7. Proportionate Use of Authority =

Staff shall use the least severe effective action.

Before significant enforcement, staff should consider:

* What happened.
* Which policy applies.
* Whether the incident is ongoing.
* The severity and impact.
* The reliability of the evidence.
* Previous relevant conduct, where authorized.
* Whether a warning is appropriate.
* Whether innocent users may be affected.
* Whether escalation is required.
* Whether the action can be safely reversed.

Emergency protective action may be taken when delay would cause further harm, but it must be reviewed and documented afterward.

= 8. Prohibited Abuse of Authority =

Staff members must not:

* Use access to win a personal dispute.
* Threaten users with staff powers.
* Ban users for respectful criticism.
* Remove access as retaliation.
* Investigate users out of curiosity.
* Enter restricted channels without an operational reason.
* Use OperOverride for personal purposes.
* Use forced mode commands for convenience.
* Disconnect users as a joke.
* Grant unauthorized access to friends.
* Take over channels.
* Manipulate project approvals.
* Override another team without authority.
* Conceal or falsify staff actions.
* Use private information for personal advantage.

= 9. Conflicts of Interest =

Staff must disclose a meaningful conflict when:

* A friend or family member is involved.
* A personal rival is involved.
* The staff member’s own project is involved.
* A competing project is involved.
* The staff member may receive a benefit.
* The staff member previously participated in the dispute.
* Their own action is being appealed.
* Their neutrality may reasonably be questioned.

When a conflict exists, the staff member shall:

# Protect users from immediate harm if required.
# Preserve relevant evidence.
# Disclose the conflict internally.
# Transfer the final decision to a neutral reviewer.
# Avoid improperly influencing the review.
# Record the reassignment.

= 10. No Retaliation =

Staff must not retaliate against anyone for:

* Submitting a complaint.
* Appealing an action.
* Reporting a security concern.
* Providing evidence.
* Reporting staff misconduct.
* Refusing an unauthorized request.
* Respectfully criticizing a decision.
* Participating in an investigation.

Retaliation is considered a serious breach of staff trust.

= 11. Privacy and Confidentiality =

Staff shall protect:

* IP addresses.
* Hidden host information.
* Email addresses.
* Account information.
* Private logs.
* Abuse reports.
* Staff discussions.
* Server notices.
* Security details.
* Application records.
* Bot and API information.
* Credentials.
* Other restricted data.

Confidential information may be accessed only when required for an authorized duty.

Staff must not:

* Post private evidence publicly.
* Share restricted information with friends.
* Relay staff-channel content externally.
* Publish private information on social media.
* Keep unnecessary personal copies.
* Access private information from curiosity.
* Use confidential information after leaving staff.
* Reveal security controls without authorization.

Confidentiality obligations continue after resignation, inactivity, suspension, or removal.

= 12. Credential Security =

Staff shall:

* Use strong and unique passwords.
* Keep NickServ and operator passwords separate.
* Use verified TLS.
* Use SASL where appropriate.
* Enable additional authentication where supported.
* Protect recovery codes.
* Secure IRC clients and devices.
* Protect SSH keys, API tokens, and certificates.
* Remove credentials from retired devices.
* Report exposure immediately.
* Follow credential-rotation instructions.

Staff must never:

* Share passwords.
* Send credentials through IRC.
* Store secrets in public paste services.
* Commit secrets to public repositories.
* Post screenshots containing credentials.
* Ask another staff member to share their access.
* Permit another person to use their staff identity.

Every action performed through a staff account is presumed to be the responsibility of its assigned holder unless a compromise is properly reported and investigated.

= 13. Device and Client Security =

Devices used for staff duties should:

* Receive security updates.
* Use screen locking.
* Use secure user accounts.
* Use device encryption where practical.
* Avoid untrusted software.
* Protect log files.
* Restrict remote access.
* Be reported if lost or stolen.

Privileged sessions must not be left open on public or shared computers.

Unreviewed IRC scripts, plugins, bots, or automation must not be used with privileged access when they could expose credentials or send administrative commands.

= 14. Evidence Integrity =

Staff shall:

* Preserve relevant evidence accurately.
* Keep original evidence where possible.
* Use clear timestamps.
* Distinguish facts from reports and inferences.
* Identify evidence sources.
* Protect restricted evidence.
* Record corrections.
* Preserve records of staff actions.

Staff must not:

* Fabricate messages.
* Alter logs dishonestly.
* Delete records to hide mistakes.
* Present partial evidence as complete.
* Add false timestamps.
* Misrepresent allegations as confirmed facts.
* Collect unrelated personal information.
* Obstruct an authorized investigation.

Intentional evidence falsification may result in immediate access suspension or removal.

= 15. Staff Action Records =

Significant actions should record:

* Date and time.
* Staff member.
* Target.
* Relevant account or channel.
* Action performed.
* Reason.
* Policy.
* Scope.
* Duration.
* Evidence reference.
* Authorization where required.
* Impact on other users.
* Review date.
* Final outcome.

Staff must not falsely claim that:

* A warning was delivered.
* Management approved an action.
* Evidence was reviewed.
* A user admitted an allegation.
* An action was technically required.

= 16. User and Channel Information =

Staff must recognize that:

* A nickname is not proof of legal identity.
* A displayed real name may be false.
* A shared host does not prove users are the same person.
* VPNs, bouncers, shells, gateways, and relays may serve many users.
* Similar behavior is not conclusive identity evidence.
* Registered-account data must be handled appropriately.
* Channel ownership disputes require authorized review.

Staff must avoid applying broad restrictions without considering innocent users.

= 17. Channel Autonomy =

Registered channel founders and authorized channel staff generally manage their channels.

IRC network staff shall not override channel management merely because:

* They dislike a channel rule.
* A friend was removed.
* They want channel access.
* They disagree personally with the founder.
* They hold IRC operator status.

Network intervention may occur when:

* A network policy is violated.
* Serious abuse is occurring.
* Network infrastructure is threatened.
* An authorized appeal requires review.
* Management directs intervention.

= 18. Services Administration =

Account and channel administration must follow authorized Services procedures.

Staff must not:

* Ask for NickServ passwords.
* Identify to a user’s account.
* Change a founder based on friendship.
* Drop a channel casually.
* Transfer account ownership without verification.
* Use OperServ to avoid normal procedures.
* Reveal restricted Services information.
* Suspend accounts for personal reasons.
* Change vhosts to impersonate staff or projects.

High-risk Services actions require the appropriate role, evidence, authorization, and documentation.

= 19. Operator Conduct =

IRC operators shall:

* Use operator access only for network duties.
* Confirm command targets.
* Check restriction scope and duration.
* Consider shared-host effects.
* Use professional reasons.
* Coordinate during incidents.
* Protect server notices.
* Record significant actions.
* Correct mistakes promptly.
* Avoid dangerous server commands without authorization.

Operator access does not place a staff member above the rules.

= 20. Staff Communication =

Staff shall:

* Keep operational communication factual.
* Avoid public arguments with other staff.
* Move internal disagreements to approved staff channels.
* Follow the incident lead during active emergencies.
* Avoid unsupported public claims.
* Distinguish personal views from official statements.
* Protect private evidence.
* Correct inaccurate information.

Restricted staff channels must not be treated as spaces where harassment, discrimination, or dishonest conduct is acceptable.

= 21. Public Representation =

When representing DarkWorld IRC, staff must:

* Use approved information.
* Avoid making unauthorized promises.
* Avoid speaking for unrelated DarkWorld projects.
* Avoid disclosing confidential investigations.
* Avoid announcing unconfirmed incidents.
* Direct users to official documentation.
* Follow authorized announcement procedures.
* Correct errors transparently.

Staff should not create unofficial “staff notices” that may be confused with formal network policy.

= 22. External Roles and Communities =

Relevant positions on other IRC networks or projects should be disclosed when they may create a conflict.

Staff must not:

* Share DarkWorld operational information externally.
* Recruit DarkWorld users for another network.
* Transfer private reports between networks without authority.
* Use DarkWorld information to benefit a competing project.
* Give external administrators access to DarkWorld systems.
* Coordinate external retaliation against a user.

An external role is not automatically prohibited, but strict separation is required.

= 23. Gifts and Personal Benefits =

Staff shall not accept money, services, access, hosting, accounts, subscriptions, favors, or other benefits in exchange for:

* Approving an application.
* Removing a restriction.
* Changing channel ownership.
* Granting staff access.
* Ignoring a violation.
* Sharing private information.
* Granting verified presence.
* Influencing an investigation.

Any attempt to improperly influence a decision should be disclosed.

= 24. Bots, APIs, and Automation =

Staff using PolicyServ, RelayServ, Services, bots, APIs, or administrative websites shall:

* Protect authentication tokens.
* Use only assigned permissions.
* Verify targets and statuses.
* Record administrative actions.
* Investigate unexpected responses.
* Avoid using bots outside approved channels.
* Verify high-impact results.
* Report failed or unauthorized operations.
* Revoke access when no longer required.

Automation assists staff; it does not remove human responsibility.

= 25. Staff Mistakes =

When a staff member makes a mistake, they shall:

# Stop continuing harm.
# Correct the action where authorized.
# Report the mistake.
# Preserve the original record.
# Document the correction.
# Inform affected users appropriately.
# Cooperate with review.
# Complete additional training where required.

Honest reporting and correction will be considered during review.

Concealment, evidence deletion, dishonesty, or retaliation will be treated as separate violations.

= 26. Security and Privacy Incidents =

Staff must immediately report:

* Compromised credentials.
* Lost or stolen devices.
* Unauthorized staff access.
* Exposure of private user information.
* Suspicious operator actions.
* Leaked tokens or keys.
* Malware on a privileged device.
* Serious vulnerabilities.
* Services impersonation.
* Staff-account takeover.

Staff must not continue using credentials believed to be compromised.

= 27. Vulnerability Handling =

Staff discovering a possible vulnerability shall:

* Avoid unnecessary exploitation.
* Avoid accessing unrelated data.
* Preserve minimal evidence.
* Report privately to authorized technical staff.
* Avoid premature public disclosure.
* Follow the responsible investigation process.
* Assist with testing only when authorized.

No staff role automatically authorizes penetration testing against production systems.

= 28. Staff Cooperation =

Staff shall:

* Respect defined responsibilities.
* Share necessary operational information.
* Support incident leadership.
* Avoid duplicate or conflicting commands.
* Hand over active cases properly.
* Respond to authorized reviews.
* Assist with documentation.
* Accept corrections professionally.
* Report unresolved procedural problems.

Staff must not obstruct another authorized team’s investigation or deliberately interfere with network recovery.

= 29. Activity and Reliability =

Staff should:

* Meet reasonable activity expectations.
* Inform the team about extended absence.
* Hand over active cases.
* Review temporary restrictions before leaving.
* Secure privileged sessions.
* Respond to important access reviews.
* Keep contact information current through approved systems.

Inactivity may result in access reduction or removal for security purposes.

= 30. Staff Access Review =

Staff access may be reviewed when:

* A role changes.
* A staff member becomes inactive.
* A credential is exposed.
* An incident occurs.
* A complaint is received.
* New permissions are requested.
* A project relationship changes.
* A staff member resigns.
* Management performs a periodic security review.

Staff shall cooperate with access reviews.

= 31. Suspension of Access =

Access may be temporarily suspended to protect the network when:

* An account may be compromised.
* A device is lost.
* Serious misuse is alleged.
* A staff member repeatedly acts unsafely.
* An independent investigation is required.
* Continued access creates operational risk.
* A role no longer requires the access.

Temporary suspension does not by itself prove misconduct.

Staff must not evade a suspension by using another account.

= 32. Resignation and Removal =

When staff service ends:

* Operator access must be removed.
* Services permissions must be reviewed.
* Staff-channel access must be removed.
* Tokens and keys must be revoked or rotated.
* Active cases must be transferred.
* Restricted documents must remain protected.
* Project-specific roles must be reviewed separately.
* The offboarding process must be documented.

Former staff must not retain, publish, or misuse confidential information.

= 33. Reporting Violations =

Suspected violations of this Code should be reported through an approved confidential process.

A report should include:

<pre>
Date and time:
Reporting person:
Staff member involved:
Location:
Conduct reported:
Evidence available:
Immediate risk:
Actions already taken:
Potential conflict of interest:
Requested review:
</pre>

Reports should be handled by an appropriate and, where necessary, independent reviewer.

Knowingly false reports may themselves violate policy, but an unproven good-faith report is not automatically a false report.

= 34. Protection of Reporters =

Anyone submitting a good-faith report should be protected from retaliation.

Staff must not:

* Reveal a reporter unnecessarily.
* Threaten the reporter.
* Deny support in retaliation.
* Manufacture a sanction.
* Pressure the reporter to withdraw.
* Destroy the report.
* Send the complaint only to the accused person where independent review is required.

= 35. Investigation Principles =

A staff-conduct investigation should be:

* Authorized.
* Confidential.
* Evidence-based.
* Proportionate.
* Independent where required.
* Documented.
* Free from retaliation.
* Completed within a reasonable operational period.
* Open to correction if new evidence appears.

The investigator should distinguish:

* Confirmed facts.
* Reports.
* Inferences.
* Disputed claims.
* Missing evidence.

= 36. Possible Outcomes =

Depending on severity and evidence, outcomes may include:

* No violation found.
* Guidance.
* Informal correction.
* Formal warning.
* Additional training.
* Increased supervision.
* Reduced permissions.
* Temporary suspension.
* Role reassignment.
* Removal from a specific team.
* Removal from DWIRC staff.
* Permanent revocation of privileged access.
* Network action for separate user-policy violations.

Serious intentional misconduct may justify immediate removal.

= 37. Factors in Staff Discipline =

Reviewers may consider:

* Severity.
* Intent.
* Harm caused.
* Number of users affected.
* Whether private information was exposed.
* Whether credentials were compromised.
* Previous relevant conduct.
* Cooperation with the investigation.
* Honesty.
* Corrective action.
* Retaliation.
* Evidence concealment.
* Risk of recurrence.
* Position and level of trust.

Senior access creates greater responsibility, not greater immunity.

= 38. Appeals =

Where an appeal process is available, the affected staff member may request review.

An appeal should:

* Identify the decision.
* State the reason for disagreement.
* Provide relevant evidence.
* Avoid retaliation or disruption.
* Follow the approved process.

An appeal does not automatically restore suspended access.

= 39. Code Acceptance =

Before final assessment or probation, each candidate must affirm:

<pre>
I have read and understood the DarkWorld IRC Staff Code of Conduct.

I understand that staff access exists only for authorized DarkWorld IRC
responsibilities and does not automatically extend to other DarkWorld projects.

I agree to protect credentials, user information, incident evidence, staff
communications, and all other confidential information.

I will not use staff authority for personal disputes, favoritism, retaliation,
financial benefit, curiosity, or unauthorized access.

I will disclose relevant conflicts of interest and will request independent
review when my neutrality may reasonably be questioned.

I will use the least severe effective action, document significant actions,
report mistakes honestly, and cooperate with authorized investigations.

I understand that training completion does not guarantee appointment and that
staff access may be limited, reviewed, suspended, or removed to protect the
DarkWorld IRC Network.

I understand that my confidentiality obligations continue after I leave the
staff team.

Registered account:
Current nickname:
Candidate status:
Date accepted:
Method of acceptance:
Witness or trainer:
</pre>

= 40. Acceptance Methods =

Management may accept the Code through:

* A staff-training website.
* A wiki-linked application system.
* An authenticated IRC bot command.
* A signed digital form.
* A recorded staff-channel procedure.
* Another approved method.

Acceptance should record:

* Registered account.
* Current version of the Code.
* Date and time.
* Acceptance method.
* Candidate status.
* Reviewing staff member.
* Any declared conflicts or external roles.

= 41. Code Versioning =

This Code should include a version and revision date when formally adopted.

Example:

{| class="wikitable"
! Code version
| 1.0
|-
! Effective date
| To be approved
|-
! Last reviewed
| To be recorded
|-
! Approved by
| DarkWorld IRC Management
|}

When material changes are made:

* Staff should be notified.
* The revision should be recorded.
* Significant changes should be explained.
* Re-acceptance may be required.
* Previous versions should be preserved for audit purposes.

= 42. Candidate Review Questions =

Before accepting this Code, answer:

# What is the purpose of staff authority?
# Does DWIRC staff access extend automatically to DWShells or DWBouncers?
# When must a conflict of interest be disclosed?
# What is retaliation?
# May staff reveal a hidden IP address to prove a point?
# What should happen after a credential leak?
# May OperOverride be used to enter a private channel out of curiosity?
# How should a staff mistake be handled?
# What is the difference between suspension and a finding of misconduct?
# Why must significant actions be recorded?
# How should a complaint against a staff member be reviewed?
# Do confidentiality obligations continue after resignation?
# Can a staff member accept free hosting in exchange for an approval?
# What should happen when a user is affected by an incorrect ban?
# Does completing training guarantee a staff appointment?

= 43. Completion Requirement =

To complete this page, the candidate must:

* Read the entire Code.
* Correctly answer at least '''13 of the 15''' review questions.
* Disclose relevant external roles and conflicts.
* Accept the Code through an approved method.
* Receive trainer confirmation.
* Agree to comply throughout training, probation, and staff service.

Refusal to accept the Code makes the candidate ineligible for staff access.

= 44. Next Step =

After accepting the Code, continue to:

'''[[DWIRC:Staff Training/Final Examination|DarkWorld IRC Staff Final Written Examination]]'''

----

'''Previous:''' [[DWIRC:Staff Training/Staff Ethics|Module 10 — Staff Ethics and Security]]
'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
'''Next:''' [[DWIRC:Staff Training/Final Examination|Final Written Examination]]

[[Category:DarkWorld IRC Staff Training]]
[[Category:DWIRC]]
[[Category:Staff Code of Conduct]]
[[Category:Staff Documentation]]

DWIRC:Staff Training/Code of Conduct

2026-08-08T18:14:24Z

Fizi: Created page with "{{DISPLAYTITLE:DarkWorld IRC Staff Code of Conduct}} <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 Network</span><br> <span style="font-size:125%;">Staff Code of Conduct</span> </div> {| class="wikitable" style="width:100%;" |- ! Applies to | IRC staff candidates, trainees, probationary staff, permanent staff, operators, Services staff, and..."

DWIRC:Staff Training/Staff Ethics

2026-08-08T18:09:57Z

Fizi: Protected "DWIRC:Staff Training/Staff Ethics" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:Module 10 — Staff Ethics and Security}}

<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 10: Staff Ethics and Security</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Program
| DarkWorld IRC Staff Training Program
|-
! Module
| 10 of 10
|-
! Difficulty
| Advanced
|-
! Estimated study time
| 4–6 hours
|-
! Assessment
| Ethics examination, security review, scenarios, and written declaration
|-
! Prerequisite
| [[DWIRC:Staff Training/IRC Operator Fundamentals|Module 9 — IRC Operator Fundamentals]]
|}

= Module Overview =

DarkWorld IRC staff may receive access to user information, restricted channels, moderation systems, IRC Services, network commands, documentation, and operational infrastructure.

Technical ability alone is not sufficient for a staff position.

A staff member must also demonstrate:

* Honesty.
* Neutrality.
* Restraint.
* Reliability.
* Respect for privacy.
* Secure handling of access.
* Accountability.
* Willingness to accept review.
* Respect for project boundaries.
* Commitment to the community.

This module defines the ethical and security standards expected from every DarkWorld IRC staff candidate.

<div style="background:#fdecec; border-left:4px solid #dc2626; padding:12px; margin:15px 0;">
'''Mandatory requirement:''' Candidates must pass the ethics and security assessment separately. A high score in technical modules cannot compensate for unsafe, dishonest, retaliatory, or abusive conduct.
</div>

= Learning Objectives =

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

# Explain why staff authority exists.
# Apply least-privilege principles.
# Protect credentials and restricted information.
# Recognize conflicts of interest.
# Avoid favoritism and retaliation.
# Handle staff disagreements professionally.
# Report mistakes and security incidents honestly.
# Respect project and role boundaries.
# Identify social-engineering attempts.
# Secure their IRC client and devices.
# Follow proper onboarding and offboarding procedures.
# Understand when access should be suspended or removed.
# Accept accountability and independent review.

= 1. Purpose of Staff Authority =

Staff authority exists to:

* Serve users.
* Protect the IRC network.
* Enforce policies fairly.
* Maintain technical stability.
* Resolve or escalate incidents.
* Support channels and communities.
* Protect confidential information.
* Preserve trust in DarkWorld IRC.

Staff authority does not exist to:

* Give social status.
* Win arguments.
* Control personal conversations.
* Punish criticism.
* Benefit friends.
* Monitor users for entertainment.
* Gain access to other projects.
* Avoid normal rules.
* Conceal staff mistakes.
* Threaten users.

A staff member’s conduct should increase confidence in the network.

= 2. Core Ethical Principles =

Every staff member should follow these principles:

{| class="wikitable" style="width:100%;"
! Principle
! Meaning
|-
| Service
| Use authority to help the network and its users
|-
| Legitimacy
| Act only for an authorized purpose
|-
| Least privilege
| Use only the access required for the role
|-
| Proportionality
| Use the least severe effective action
|-
| Neutrality
| Apply rules without favoritism or retaliation
|-
| Confidentiality
| Protect private and restricted information
|-
| Accountability
| Record actions and accept review
|-
| Integrity
| Tell the truth and preserve evidence accurately
|-
| Restraint
| Avoid unnecessary use of elevated powers
|-
| Respect
| Treat users and staff professionally
|}

= 3. Least Privilege =

Least privilege means that access should be:

* Limited to assigned responsibilities.
* Granted only after approval.
* Reviewed periodically.
* Reduced when duties change.
* Suspended when security is uncertain.
* Removed when no longer required.

Examples:

* A support trainee does not require IRC operator access.
* An IRC operator does not automatically require OperServ.
* Services staff do not automatically require server shell access.
* An IRCd administrator does not automatically require DWShells administration.
* Membership in a restricted channel does not grant authority to disclose its contents.

Staff should not request additional access merely because it may be useful in the future.

= 4. Separation of DarkWorld Projects =

DarkWorld Network is the umbrella organization. DarkWorld IRC is one project under that umbrella.

DWIRC staff authority does not automatically extend to:

* DWShells.
* DWBouncers.
* DWGames.
* DWBots.
* DWVPN.
* Websites.
* Databases.
* Hosting systems.
* Other registered projects.

A person may hold separate roles in multiple projects, but each role should have:

* Separate approval.
* Defined responsibilities.
* Appropriate training.
* Role-specific access.
* Independent access review.

Staff must state clearly which role they are acting under.

= 5. Conflicts of Interest =

A conflict of interest exists when personal relationships, competing interests, or prior involvement may influence a staff decision.

Examples include:

* Moderating a dispute involving a close friend.
* Investigating a personal rival.
* Reviewing your own contested action.
* Deciding a case involving a project you operate.
* Handling a complaint against a close team member.
* Reviewing an advertising request from a competing service.
* Receiving a personal benefit from an approval.
* Previously making public statements against one party.

== Conflict Procedure ==

When a meaningful conflict exists:

# Protect users from immediate harm if necessary.
# Preserve relevant evidence.
# Disclose the conflict internally.
# Avoid making the final decision.
# Transfer the case to a neutral authorized staff member.
# Do not influence the review improperly.
# Record the reassignment.

Having a conflict does not automatically mean misconduct. Concealing it and continuing to control the decision may create misconduct.

= 6. Favoritism =

Favoritism includes:

* Ignoring violations by friends.
* Giving access based on friendship.
* Accelerating applications for preferred users.
* Sharing restricted information with associates.
* Reversing another staff member’s action for a friend.
* Applying harsher treatment to disliked users.
* Protecting a staff member from legitimate review.
* Giving verified status without completing the required process.

Decisions should be based on:

* Current policy.
* Evidence.
* Role requirements.
* Network needs.
* Consistent procedures.
* Authorized approval.

= 7. Retaliation =

Retaliation means taking harmful action because someone:

* Criticized staff.
* Submitted an appeal.
* Reported misconduct.
* Refused a personal request.
* Disagreed respectfully.
* Provided evidence in an investigation.
* Participated in an independent review.

Examples include:

* Banning a complainant without a separate valid reason.
* Removing access because someone reported a staff member.
* Revealing private information about a critic.
* Encouraging others to harass an appellant.
* Delaying legitimate support as punishment.

Retaliation is prohibited.

= 8. Staff Impartiality =

Staff should:

* Focus on conduct rather than personality.
* Apply the same policy to friends and strangers.
* Separate personal opinions from official decisions.
* Avoid assumptions based on nationality, language, or community.
* Avoid prejudging an incident publicly.
* Seek independent review when personally involved.
* Correct inconsistent enforcement.

Impartiality does not mean ignoring relevant history. It means using relevant history fairly and through authorized procedures.

= 9. Confidential Information =

Staff may encounter:

* IP addresses.
* Hidden host information.
* Email addresses.
* Account records.
* Services information.
* Private abuse reports.
* Channel access records.
* Server notices.
* Security vulnerabilities.
* Staff discussions.
* API tokens.
* Passwords.
* Configuration files.
* Incident evidence.
* Application records.

Access to this information is based on operational need.

Staff must not:

* Share it with friends.
* Post it publicly.
* Use it for personal advantage.
* retain unnecessary copies.
* Move it to personal systems without authorization.
* Discuss it in unrelated project channels.
* Use it to threaten users.
* disclose it after leaving staff.

Confidentiality obligations continue after resignation or removal.

= 10. Need-to-Know Access =

Being a staff member does not create a right to view every case.

Access should depend on:

* Assigned responsibility.
* Incident role.
* Required technical knowledge.
* Management authorization.
* Confidentiality classification.
* Whether the staff member has a conflict.

Curiosity is not a valid operational reason.

= 11. Password and Credential Security =

Staff credentials may include:

* NickServ password.
* IRC operator password.
* Services credentials.
* SSH keys.
* Website administrator passwords.
* Database credentials.
* API tokens.
* Bot tokens.
* Recovery codes.
* TLS client certificates.

Every privileged credential should be:

* Unique.
* Strong.
* Stored securely.
* Shared with no one.
* Rotated when exposed.
* Removed from retired devices.
* Limited to its intended system.
* Protected by additional authentication where supported.

Do not reuse one password across NickServ, IRC operator, email, websites, shells, or other projects.

= 12. Password Managers =

An approved password manager can help staff:

* Generate unique passwords.
* Avoid password reuse.
* Store credentials securely.
* identify weak or duplicated passwords.
* Update credentials after rotation.

Staff should protect the password manager with:

* A strong master password.
* Multi-factor authentication where available.
* Secure recovery methods.
* Device encryption.
* Updated software.

Credentials must not be stored in:

* Public paste services.
* IRC channels.
* Plaintext notes.
* Unprotected scripts.
* Screenshots.
* Shared documents.
* Public source repositories.

= 13. Multi-Factor Authentication =

Where supported, privileged accounts should use multi-factor authentication.

Possible methods include:

* Authenticator applications.
* Hardware security keys.
* Device-bound credentials.
* Secure recovery codes.

Recovery codes should be stored securely and separately from the primary device.

SMS-based authentication may be better than no additional protection but can carry account-recovery and SIM-related risks.

= 14. IRC Client Security =

A privileged IRC client should:

* Be obtained from a trusted source.
* Receive security updates.
* Use verified TLS.
* Use SASL securely.
* Avoid unknown scripts and plugins.
* Protect stored passwords.
* Protect log files.
* Lock the device when unattended.
* Disable unnecessary automatic commands.
* Use separate profiles where appropriate.

IRC scripts may:

* Read messages.
* Send commands.
* Access stored data.
* Automatically respond to events.
* Execute external commands.
* Leak credentials.

Staff must not install unreviewed scripts into a privileged client.

= 15. Device Security =

Devices used for staff duties should have:

* Current security updates.
* Screen locking.
* Disk encryption where practical.
* Malware protection appropriate to the platform.
* Secure user accounts.
* Limited administrative access.
* Protected backups.
* Trusted network connections.
* Remote-access controls.
* A procedure for lost or stolen devices.

Public or shared computers should not be used for privileged staff sessions.

= 16. Secure Connections =

Staff should use:

* Verified TLS for IRC.
* Secure authentication.
* Approved VPN or management paths where required.
* SSH keys instead of passwords where appropriate.
* Host-key verification.
* Trusted DNS and network configuration.
* Authorized administrative interfaces.

Staff must not disable security checks merely to make a connection work.

Certificate or host-key warnings should be investigated.

= 17. Social Engineering =

Social engineering attempts manipulate people into revealing information or taking unsafe action.

Examples include:

* “The founder asked me to get the password.”
* “This is urgent; skip verification.”
* “Send me the operator configuration so I can fix it.”
* “I lost my account, but everyone knows me.”
* “Give my friend temporary access.”
* “Run this script to check your IRC client.”
* “Paste the token so I can test the bot.”
* “Do not tell the other staff.”

Warning signs include:

* Artificial urgency.
* Requests to bypass normal procedures.
* Secrecy.
* Pressure based on authority or friendship.
* Requests for credentials.
* Unexpected files or links.
* Refusal to use official processes.
* Inconsistent identity information.

== Response ==

# Stop and verify independently.
# Use an official communication channel.
# Contact the claimed authority directly.
# Do not open unknown files.
# Do not reveal credentials.
# Preserve suspicious messages.
# Report the attempt.

= 18. Phishing and Impersonation =

Staff may be targeted by:

* Fake NickServ messages.
* Fake staff accounts.
* Imitation login pages.
* Malicious email.
* Compromised project accounts.
* Lookalike domains.
* Fake support requests.
* QR codes leading to credential pages.

Before entering credentials:

* Check the service name.
* Check the domain.
* Check TLS validation.
* Confirm why authentication is required.
* Avoid following unexpected links.
* Use a known bookmark or official address.
* Contact authorized administration if uncertain.

= 19. Security Incident Reporting =

Staff must promptly report:

* Credential exposure.
* Lost or stolen devices.
* Suspicious logins.
* Unexpected operator actions.
* Unauthorized access.
* Malware on a staff device.
* Leaked API tokens.
* Compromised email.
* Unapproved configuration changes.
* Exposure of private user information.
* Vulnerabilities affecting DarkWorld.

A report should include:

<pre>
Date and time:
Affected account or system:
How the issue was discovered:
Possible exposure:
Actions already taken:
Last known legitimate access:
Suspicious activity:
Evidence location:
Immediate assistance required:
</pre>

Do not include active passwords or private keys.

= 20. Responsible Vulnerability Handling =

If staff discover a vulnerability:

# Do not exploit it beyond what is necessary to confirm safely.
# Do not access unrelated user data.
# Preserve minimal evidence.
# Report it privately to authorized technical staff.
# Avoid public disclosure before mitigation.
# Follow management instructions.
# Assist with verification only when authorized.
# Document the resolution.

A trainee must not perform penetration testing against production systems without explicit authorization.

= 21. Staff Channels and Internal Discussions =

Restricted staff channels may contain:

* Incident coordination.
* User reports.
* Policy discussions.
* Server information.
* Staff evaluations.
* Application details.
* Security concerns.

Staff-channel content must not be:

* Copied to public channels.
* Shared with friends.
* Used as gossip.
* Posted on social media.
* Relayed to external networks.
* Used for personal retaliation.
* Disclosed after resignation.

Staff should still communicate professionally in restricted channels. Confidentiality does not make abusive conduct acceptable.

= 22. Public Staff Conduct =

When acting publicly, staff should:

* Be calm and professional.
* Avoid public arguments with other staff.
* Avoid insulting users.
* Avoid unsupported technical claims.
* State when information is not yet confirmed.
* Use official policy links.
* Avoid discussing confidential cases.
* Distinguish personal opinion from official decisions.
* Correct inaccurate statements.

Staff should not claim to speak for all DarkWorld projects unless authorized.

= 23. Personal Accounts and Social Media =

Staff members may have personal accounts and opinions.

However, they should not:

* Publish confidential DarkWorld information.
* Threaten users off-network.
* Coordinate harassment.
* Impersonate official DarkWorld accounts.
* Misrepresent personal statements as official announcements.
* Use private user data on external platforms.
* Damage an active investigation.
* Reveal security controls.

Where practical, official announcements should use official channels and identities.

= 24. External IRC Networks and Projects =

A candidate should disclose relevant positions on other IRC networks or competing services when they may create:

* A conflict of interest.
* An advertising concern.
* Access to confidential information on both sides.
* Divided incident responsibilities.
* Recruitment concerns.
* A risk of sharing operational data.

Holding another role is not automatically prohibited. Transparency and proper separation are required.

DarkWorld information must not be transferred to another network without authorization.

= 25. Gifts, Payments, and Personal Benefits =

Staff must not accept benefits in exchange for:

* Approving an application.
* Removing a restriction.
* Changing channel ownership.
* Granting verified presence.
* Sharing private information.
* Ignoring violations.
* Providing unauthorized access.
* Favoring a project.

Possible benefits include:

* Money.
* Services.
* Free accounts.
* Hosting.
* Game items.
* Subscriptions.
* Personal favors.
* Staff positions elsewhere.

Any offer intended to influence a decision should be reported.

= 26. Use of Bots and Automation =

Staff may use authorized systems such as:

* PolicyServ.
* RelayServ.
* Services.
* Monitoring bots.
* Support tools.
* Logging systems.

Automation may assist with:

* Retrieving policy links.
* Listing applications.
* Reporting statistics.
* Recording actions.
* Detecting possible violations.

Automation must not replace human judgment where a decision affects users.

Staff must:

* Verify high-impact bot results.
* Protect bot credentials.
* Restrict administrative commands.
* Review failed or unexpected actions.
* Avoid treating every alert as confirmed abuse.
* Log administrative bot operations.

= 27. Accuracy and Honesty =

Staff must not:

* Fabricate evidence.
* Alter logs dishonestly.
* Claim an action was authorized when it was not.
* Invent a policy.
* Misrepresent an incident.
* Hide a mistake.
* Blame another staff member falsely.
* Claim technical certainty without evidence.
* Record a warning that was never delivered.

When uncertain, say:

<pre>
This has not yet been confirmed.
</pre>

or:

<pre>
I do not have enough information to make that decision. I will escalate it.
</pre>

= 28. Reporting Staff Mistakes =

If a staff member makes an error:

# Stop continuing harm.
# Correct the error where authorized.
# Report it honestly.
# Preserve the original record.
# Inform affected users appropriately.
# Participate in review.
# Follow any additional training requirement.
# Improve the relevant procedure or documentation.

Honest mistakes can often be corrected. Concealment, falsification, or retaliation creates a separate and more serious issue.

= 29. Staff Accountability =

Staff members may be required to explain:

* What action they took.
* Why they took it.
* What evidence they used.
* Which policy applied.
* Who authorized it.
* Who was affected.
* How it was reviewed.
* Whether it was corrected.

Accountability protects:

* Users.
* The IRC network.
* Other staff.
* The staff member who acted properly.
* The integrity of investigations.

= 30. Staff Complaints =

Complaints against staff should receive:

* Acknowledgement.
* Confidential handling.
* Evidence preservation.
* Independent review where necessary.
* Protection from retaliation.
* A recorded outcome.
* Corrective action where justified.

A complaint is not proof of misconduct, but it must not be dismissed merely because the subject is a staff member.

= 31. Staff Disagreements =

Staff may disagree about:

* Policy interpretation.
* Incident severity.
* Appropriate sanctions.
* Technical causes.
* Access decisions.
* Project responsibilities.

Staff should:

# Avoid arguing publicly.
# Protect users from immediate harm.
# State verified facts.
# Use internal escalation.
# Follow the incident lead during emergencies.
# Request policy or management review.
# Accept the final authorized decision.
# Record unresolved procedural concerns.

Repeatedly reversing another staff member’s actions without coordination may endanger the network.

= 32. Inactivity and Availability =

Staff roles should have reasonable activity expectations.

When a staff member will be unavailable, they should:

* Inform the appropriate team.
* Hand over active cases.
* Avoid leaving temporary restrictions without review.
* Secure or disconnect privileged sessions.
* Identify pending tasks.
* Follow leave or inactivity procedures.

Extended inactivity may result in temporary access reduction or removal.

This protects the network and does not necessarily represent disciplinary action.

= 33. Onboarding =

Before receiving access, a staff member should:

* Complete required training.
* Accept the Staff Code of Conduct.
* Receive a defined role.
* Receive an assigned mentor.
* Complete account-security checks.
* Use verified TLS and SASL.
* Receive only necessary permissions.
* Learn reporting and escalation channels.
* Understand logging requirements.
* Confirm emergency contacts.
* Complete a recorded access approval.

Access should not be granted informally in a public channel.

= 34. Role Changes =

When a staff member changes roles:

* Review existing access.
* Remove permissions no longer required.
* Add only approved new permissions.
* Update documentation.
* Update team-channel access.
* Reassign active cases.
* Review conflicts of interest.
* Confirm any new training requirements.

Access should not accumulate indefinitely.

= 35. Resignation and Offboarding =

When a staff member resigns or is removed:

* IRC operator access should be removed.
* Services permissions should be reviewed.
* Restricted channel access should be removed.
* Shared credentials should be rotated where applicable.
* API or bot tokens should be revoked.
* Server and website access should be reviewed.
* Active cases should be transferred.
* Project roles should be handled separately.
* Devices or files containing restricted information should be addressed.
* The access-removal process should be recorded.

The former staff member remains responsible for protecting information learned during service.

= 36. Emergency Access Removal =

Immediate access suspension may be appropriate when:

* Credentials are exposed.
* A staff account is compromised.
* A device is stolen.
* Serious access abuse is occurring.
* Private information is being exposed.
* A staff member is actively obstructing incident response.
* Continued access creates a serious network risk.

Emergency suspension is a protective action.

A later review should determine:

* What happened.
* Whether misconduct occurred.
* Whether access can be restored.
* Whether credentials must be replaced.
* Whether further training is required.
* Whether permanent removal is appropriate.

= 37. Staff Discipline Principles =

Staff discipline should be:

* Based on evidence.
* Proportionate.
* Documented.
* Free from retaliation.
* Reviewed by appropriate authority.
* Consistent with policy.
* Protective of confidentiality.
* Open to correction where facts change.

Possible outcomes include:

* Guidance.
* Formal warning.
* Additional training.
* Reduced permissions.
* Temporary suspension.
* Role reassignment.
* Removal from staff.
* Permanent access revocation.

Serious intentional abuse may justify immediate removal.

= 38. Ethical Decision Test =

Before a sensitive staff action, ask:

<pre>
1. Is this within my assigned role?
2. What legitimate network purpose does it serve?
3. Which policy authorizes it?
4. Is the evidence sufficient?
5. Am I personally involved?
6. Would I take the same action for a friend or stranger?
7. Is this the least severe effective response?
8. Am I accessing only the information I need?
9. Could I explain this decision in a formal review?
10. Have I documented it correctly?
11. Does another person need to approve it?
12. What harm could occur if I am wrong?
</pre>

If the action cannot withstand this review, pause and escalate.

= 39. Practical Exercises =

== Exercise 1: Conflict of Interest ==

The trainer presents a dispute involving the candidate’s friend.

The candidate must:

* Identify the conflict.
* Protect against immediate harm.
* Preserve evidence.
* Transfer the final decision.
* Record the reassignment.

== Exercise 2: Credential Exposure ==

A simulated IRC operator credential is posted in a staff channel.

The candidate must:

* Treat it as compromised.
* Avoid repeating it.
* Notify authorized staff.
* Recommend rotation.
* Identify related systems requiring review.
* Complete a security report.

== Exercise 3: Social Engineering ==

A person claiming to be senior management asks the trainee to send an API token privately.

The candidate must:

* Refuse to share the token.
* Verify the request through an official method.
* Preserve the request.
* Report the attempt.

== Exercise 4: Staff Complaint ==

A user reports that an operator exposed their IP address after an argument.

The candidate must:

* Protect the report.
* Avoid sending it only to the accused operator.
* Preserve evidence.
* Escalate to an independent reviewer.
* Prevent retaliation.

== Exercise 5: Project Boundary ==

The trainer asks a DWIRC operator to use unrelated DWShells administrative access.

The candidate must explain:

* Which role is being requested.
* Why DWIRC authority is insufficient.
* Which approval and training are required.
* How to redirect the request.

== Exercise 6: Offboarding ==

Prepare an access-removal checklist for a departing IRC operator who also had:

* Services access.
* Policy-team access.
* Relay-team access.
* Bot credentials.
* Restricted documentation.
* Active incident assignments.

= 40. Practical Scenarios =

== Scenario 1: Friend Requests Ban Removal ==

A close friend asks a staff member to remove their network ban privately.

'''Recommended response:'''

Do not remove the ban based on friendship. Disclose the conflict and direct the appeal to an independent authorized reviewer.

== Scenario 2: Unattended Operator Client ==

An operator leaves an authenticated IRC client open on a shared computer.

'''Recommended response:'''

Secure or disconnect the session, report the exposure, review actions and logs, rotate credentials if compromise is possible, and address the device-security failure.

== Scenario 3: Private Staff Log Shared Publicly ==

A staff member posts a screenshot from a restricted channel to prove they were correct.

'''Recommended response:'''

Stop further disclosure, preserve the incident, assess the exposed information, notify management, and conduct an independent review.

== Scenario 4: Vulnerability Discovered ==

A trainee discovers that an administrative page may allow unauthorized access.

'''Recommended response:'''

Do not explore unrelated data. Preserve minimal evidence, report privately to authorized technical staff, and avoid public disclosure before mitigation.

== Scenario 5: Gift for Approval ==

A project owner offers free hosting if their advertising application is approved.

'''Recommended response:'''

Decline the offer, preserve the communication, disclose the conflict, and transfer or escalate the application review.

== Scenario 6: Operator Hides Mistake ==

An operator removes an action record after discovering that they banned the wrong host.

'''Recommended response:'''

Restore or preserve available evidence, correct the restriction, notify management, and investigate both the original mistake and the deliberate concealment.

== Scenario 7: External Network Role ==

A candidate is also an administrator on another IRC network.

'''Recommended response:'''

The role is not automatically disqualifying, but it should be disclosed. Confidential information, recruitment activity, and decision conflicts must be carefully separated.

= 41. Knowledge Check =

Answer the following questions in your own words:

# Why does staff authority exist?
# Name the ten core ethical principles in this module.
# What is least privilege?
# Why should access not accumulate indefinitely?
# Does DWIRC authority provide DWShells authority?
# What is a conflict of interest?
# How should a conflict be handled?
# What is favoritism?
# What is retaliation?
# Is criticism of staff automatically abuse?
# What does staff impartiality require?
# What types of information may be confidential?
# What is need-to-know access?
# Why must privileged credentials be unique?
# Where must credentials not be stored?
# Why is multi-factor authentication useful?
# What risks can IRC scripts create?
# Why should shared computers not be used for privileged sessions?
# What is social engineering?
# Name five warning signs of social engineering.
# How should an unexpected credential request be verified?
# What must be reported as a security incident?
# How should a vulnerability be handled?
# May staff-channel content be shared with friends?
# How should staff distinguish personal opinions from official statements?
# Why should relevant external network roles be disclosed?
# What should happen when someone offers a benefit for an approval?
# Why must automated bot results be verified?
# What does honesty require during an incident?
# What should staff do after making a mistake?
# Why is accountability important?
# How should a complaint against staff be reviewed?
# How should staff disagreements be handled?
# What should happen before a staff member takes extended leave?
# What are the principal onboarding requirements?
# What must happen during a role change?
# What access should be reviewed during offboarding?
# When may emergency access suspension be justified?
# Is suspension by itself proof of misconduct?
# What principles should govern staff discipline?
# What questions belong in the ethical decision test?
# Why do confidentiality obligations continue after staff service ends?

= 42. Written Assignment =

Write approximately '''900–1,200 words''' analyzing this case:

<blockquote>
A DWIRC operator is involved in a personal disagreement with a channel founder. The operator uses override access to enter the founder’s private channel, copies staff and user messages, and shares them with a friend who works on another IRC network. The friend then offers the operator free hosting. When a complaint is submitted, the operator removes part of the action log and globally bans the complainant for “staff harassment.”
</blockquote>

Your analysis must explain:

* Every potential ethical and security violation.
* The conflict of interest.
* The misuse of override access.
* The confidentiality breach.
* The external-network disclosure.
* The offered personal benefit.
* The retaliation.
* The evidence-integrity problem.
* Immediate protective actions.
* Access that should be suspended or reviewed.
* How the complaint should be investigated.
* How affected users should be handled.
* Appropriate disciplinary considerations.
* Improvements needed to prevent recurrence.

= 43. Candidate Security Declaration =

Before completing this module, the candidate should affirm:

<pre>
I understand that DarkWorld IRC staff access exists only for authorized
network responsibilities.

I will not share passwords, tokens, private keys, operator credentials,
restricted logs, or confidential staff information.

I will use secure and updated devices, verified TLS, unique credentials,
and additional authentication where available.

I will disclose relevant conflicts of interest and will not use staff
authority for personal disputes, favoritism, retaliation, or personal benefit.

I will report mistakes, compromised access, privacy incidents, and security
concerns honestly and promptly.

I understand that my access may be limited, suspended, reviewed, or removed
when required to protect DarkWorld IRC.

I understand that confidentiality obligations continue after I leave the
staff team.

Candidate account:
Candidate nickname:
Date:
Accepted through:
Trainer or reviewer:
</pre>

= 44. Module Completion Requirements =

To complete this module, the candidate must:

* Read the complete lesson.
* Complete all six practical exercises.
* Correctly answer at least '''34 of the 42''' knowledge-check questions.
* Achieve at least '''85%''' in the ethics and security assessment.
* Complete the written assignment.
* Accept the Candidate Security Declaration.
* Demonstrate safe credential handling.
* Demonstrate correct conflict-of-interest handling.
* Complete an offboarding checklist.
* Receive trainer and management approval.

A candidate who fails the ethics and security assessment must not receive privileged access, even if their overall program score is above the normal passing requirement.

= 45. Trainer Evaluation =

{| class="wikitable" style="width:100%;"
! Evaluation area
! Maximum points
|-
| Ethical principles and judgment
| 20
|-
| Conflicts, neutrality, and retaliation
| 15
|-
| Confidentiality and privacy
| 15
|-
| Credential and device security
| 15
|-
| Social engineering and incident reporting
| 10
|-
| Accountability and evidence integrity
| 10
|-
| Access lifecycle and project boundaries
| 10
|-
| Written declaration and professionalism
| 5
|-
! Total
! 100
|}

Required passing score: '''85 points'''.

Automatic failure conditions may include:

* Intentional credential sharing.
* Deliberate evidence falsification.
* Retaliation.
* Unauthorized disclosure of private information.
* Use of access for personal benefit.
* Serious undisclosed conflict of interest.
* Unauthorized production-system testing.
* Refusal to report compromised access.
* Deliberate impersonation.
* Intentional abuse of elevated commands.

= 46. Core Program Completion =

After passing this module, the candidate has completed the ten educational modules of the DarkWorld IRC Staff Training Program.

The candidate must still complete:

# [[DWIRC:Staff Training/Code of Conduct|DarkWorld IRC Staff Code of Conduct]]
# [[DWIRC:Staff Training/Final Examination|Final Written Examination]]
# [[DWIRC:Staff Training/Practical Assessment|Final Practical Assessment]]
# [[DWIRC:Staff Training/Trainee Evaluation|Trainee Evaluation]]
# [[DWIRC:Staff Training/Probation|Probationary Staff Period]]

Completion of the educational modules does not guarantee appointment.

= 47. Next Step =

Continue to:

'''[[DWIRC:Staff Training/Code of Conduct|DarkWorld IRC Staff Code of Conduct]]'''

----

'''Previous:''' [[DWIRC:Staff Training/IRC Operator Fundamentals|Module 9 — IRC Operator Fundamentals]]
'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
'''Next:''' [[DWIRC:Staff Training/Code of Conduct|DarkWorld IRC Staff Code of Conduct]]

[[Category:DarkWorld IRC Staff Training]]
[[Category:DWIRC]]
[[Category:Staff Ethics]]
[[Category:Staff Security]]
[[Category:Staff Documentation]]

DWIRC:Staff Training/Staff Ethics

2026-08-08T18:09:49Z

Fizi: Created page with "{{DISPLAYTITLE:Module 10 — Staff Ethics and Security}} <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 10: Staff Ethics and Security</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 10 of 10 |- ! Difficulty |..."

DWIRC:Staff Training/IRC Operator Fundamentals

2026-08-08T18:07:21Z

Fizi: Protected "DWIRC:Staff Training/IRC Operator Fundamentals" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:Module 9 — IRC Operator Fundamentals}}

<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 9: IRC Operator Fundamentals</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Program
| DarkWorld IRC Staff Training Program
|-
! Module
| 9 of 10
|-
! Difficulty
| Advanced
|-
! Estimated study time
| 5–7 hours
|-
! Assessment
| Knowledge check, command simulations, and incident exercises
|-
! Prerequisite
| [[DWIRC:Staff Training/Incident Handling|Module 8 — Abuse and Incident Handling]]
|}

= Module Overview =

An '''IRC operator''', commonly called an '''IRCOp''', is a trusted network staff member with elevated privileges for protecting and operating the IRC network.

IRC operator privileges may allow a staff member to:

* View operational information.
* Receive server notices.
* Investigate network abuse.
* Disconnect users.
* Apply network-level restrictions.
* Assist during floods and attacks.
* Coordinate across multiple IRC servers.
* Use approved override capabilities.
* Support network recovery.

These powers can also disconnect innocent users, block shared networks, expose sensitive connection information, or disrupt IRC services if used incorrectly.

<div style="background:#fdecec; border-left:4px solid #dc2626; padding:12px; margin:15px 0;">
'''Important:''' This lesson does not grant IRC operator access. Operator access requires a defined operational role, management approval, secure credentials, appropriate permissions, and successful probation.
</div>

= Learning Objectives =

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

# Explain the purpose and responsibilities of an IRC operator.
# Distinguish channel moderation from network enforcement.
# Protect operator credentials.
# Recognize common operational notices.
# Collect relevant user and connection information lawfully.
# Explain kills and network-ban types.
# Select the smallest appropriate network response.
# Recognize the risks of host and IP-based restrictions.
# Understand OperOverride and forced mode operations.
# Respond safely to netsplits, floods, and Services failures.
# Record operator actions.
# Recognize commands reserved for senior administrators.
# Escalate high-risk network incidents.

= 1. Purpose of an IRC Operator =

The purpose of an IRC operator is to:

* Protect the IRC network.
* Respond to network-wide abuse.
* Assist users and channel staff.
* Maintain operational stability.
* Enforce network policies.
* Coordinate incident response.
* Protect Services and servers.
* Apply network restrictions when justified.
* Document significant actions.
* Support recovery after incidents.

IRC operator status is not a reward, status symbol, or entitlement.

It is an operational responsibility.

= 2. Channel Operator vs IRC Operator =

{| class="wikitable" style="width:100%;"
! Role
! Scope
! Example responsibilities
|-
| Channel operator
| One or more channels
| Topics, voice, kicks, channel bans, channel rules
|-
| IRC operator
| IRC network
| Network abuse, user disconnections, network bans, server notices
|-
| Services staff
| Anope Services
| Account and registered-channel administration
|-
| IRCd administrator
| IRC server infrastructure
| Configuration, modules, server links, upgrades
|}

An IRC operator is not automatically:

* A channel founder.
* A Services Administrator.
* An IRCd administrator.
* A DWShells administrator.
* A DWBouncers administrator.
* Authorized to interfere in every channel dispute.

= 3. Least-Privilege Operator Access =

Operator permissions should match the staff member’s assigned role.

Possible permission groups may include:

* Local operator.
* Global operator.
* Help operator.
* Services operator.
* Network administrator.
* Root administrator.
* Specialized abuse or security role.

A local operator may have authority limited to one server.

A global operator may have authority across connected servers.

Actual permissions depend on the current UnrealIRCd configuration and security groups.

Staff must not assume that a title grants every available command.

= 4. Operator Authentication =

IRC operator authentication commonly uses the `/OPER` command or an approved automatic authentication method.

General form:

<pre>
/OPER operator-name password
</pre>

Exact credentials and authentication requirements are defined by the current UnrealIRCd configuration.

Operator authentication should occur only:

* Over verified TLS.
* From an approved device.
* Through an approved connection.
* Using a unique operator credential.
* After authenticating the normal Services account where required.
* Without exposing the command in a channel.

== Operator Credential Rules ==

An operator must:

* Use a strong and unique password.
* Never reuse the NickServ password.
* Never share the operator password.
* Never send it through IRC messages or email.
* Avoid storing it in plaintext.
* Protect client configuration files.
* Lock or disconnect unattended devices.
* Report suspected exposure immediately.
* Follow any certificate or authentication requirements.
* Remove credentials from retired devices.

= 5. Failed Operator Authentication =

Repeated `/OPER` failures may indicate:

* Incorrect credentials.
* Wrong operator name.
* An unauthorized host.
* Missing Services authentication.
* Incorrect TLS or certificate state.
* Outdated client configuration.
* A compromised or guessed credential.
* A configuration problem.

Staff must not repeatedly try passwords or ask another operator to share credentials.

The correct response is:

# Stop repeated attempts.
# Record the exact error.
# Confirm the correct operator identity privately.
# Confirm the approved connection requirements.
# Notify authorized administration if unexpected.
# Treat unexplained repeated failures as a possible security event.

= 6. Operator Session Security =

Before using operator access:

* Confirm the device is trusted.
* Confirm the IRC client is updated and securely configured.
* Confirm TLS certificate verification.
* Close unnecessary scripts or plugins.
* Verify the active network and server.
* Confirm the nickname and Services account.
* Know how to remove operator status or disconnect safely.
* Ensure logs are protected.

Do not remain opered unnecessarily on an insecure or unattended device.

= 7. Server Notices =

IRC operators may subscribe to or receive server notices, commonly called '''snotices'''.

These may report:

* New connections.
* Disconnections.
* Failed operator attempts.
* Kills.
* Network bans.
* Flood activity.
* Server links.
* Server disconnections.
* Services activity.
* Security events.
* Override use.
* Configuration or routing problems.

Notice categories and user modes depend on the UnrealIRCd configuration.

Operators should configure only the notices relevant to their role. Excessive notices may hide important events.

= 8. Operational Information Commands =

Common informational commands may include:

{| class="wikitable" style="width:100%;"
! Command
! General purpose
|-
| `/WHOIS nickname`
| View user information
|-
| `/WHOIS nickname nickname`
| Request additional WHOIS information where available
|-
| `/WHO #channel`
| View channel users
|-
| `/USERHOST nickname`
| View basic connection identity
|-
| `/WHOWAS nickname`
| View limited information about a disconnected nickname
|-
| `/LINKS`
| View linked IRC servers
|-
| `/MAP`
| View a network map where supported
|-
| `/LUSERS`
| View network statistics
|-
| `/STATS letter`
| Request a specific server statistics category
|-
| `/VERSION`
| View server software information
|-
| `/TIME`
| View server time
|-
| `/ADMIN`
| View server administration information
|-
| `/MOTD`
| View the Message of the Day
|}

Some information is restricted.

Operator-only information must not be copied into public channels without an operational reason and authorization.

= 9. User Investigation Principles =

An operator may need to examine:

* Nickname.
* Ident.
* Displayed host or cloak.
* Registered account.
* Connected server.
* Secure connection status.
* User modes.
* Channel presence.
* Idle time.
* Connection timing.
* Relevant authorized logs.
* Previous related enforcement.

Operators must not investigate users:

* Out of curiosity.
* Because of a personal disagreement.
* To discover private information for a friend.
* To track someone without an operational reason.
* To expose hidden information publicly.
* Outside their assigned authority.

Every investigation should have a legitimate network purpose.

= 10. Identification Is Not Certainty =

The following do not independently prove that two connections belong to the same person:

* Matching host.
* Matching VPN exit.
* Matching bouncer server.
* Similar nickname.
* Similar writing style.
* Shared channel membership.
* Same country.
* Similar connection time.

Evidence may be combined, but staff must distinguish strong evidence from assumptions.

Shared systems may include:

* VPNs.
* IRC bouncers.
* Shell providers.
* Webchat gateways.
* Mobile carriers.
* Universities.
* Workplaces.
* Residential networks.
* Relays.

= 11. User Kills =

A '''KILL''' forcibly disconnects a user from the IRC network.

General syntax:

<pre>
/KILL nickname reason
</pre>

Example:

<pre>
/KILL ExampleNick Active multi-channel flooding
</pre>

Exact syntax and permissions must be verified through current server help.

A kill:

* Ends the current connection.
* Does not necessarily prevent reconnection.
* May affect a bouncer or automated client.
* Should include a clear operational reason.
* Must be recorded when significant.

A kill may be appropriate when:

* Active abuse must stop immediately.
* A user is flooding multiple channels.
* A malicious client is attacking users.
* A phishing identity is actively collecting credentials.
* A compromised bot is spreading harmful content.
* A user must be disconnected before a restriction is applied.

A kill must not be used:

* As a joke.
* To remove someone from only one channel.
* To win a personal disagreement.
* To punish criticism.
* When a channel kick is sufficient.
* Without checking the correct nickname.

= 12. Network Bans =

A network ban prevents matching connections from using the IRC network.

UnrealIRCd may provide several restriction types. Exact syntax and behavior must be verified with the current server configuration and `/HELPOP`.

Possible types include:

{| class="wikitable" style="width:100%;"
! Restriction
! General purpose
! Main risk
|-
| K-line
| Restricts a user or host, often on one server
| Scope may differ by server
|-
| G-line
| Network-wide user or host restriction
| May affect many users
|-
| Z-line
| IP-based restriction, often processed early
| Can block shared addresses
|-
| Global Z-line
| Network-wide IP-based restriction
| Very broad operational effect
|-
| Shun
| Silently restricts many user commands
| User may remain connected without understanding why
|-
| Temporary shun
| Temporary command restriction
| Must be reviewed and documented
|}

Terminology, propagation, matching, and duration syntax depend on the deployed UnrealIRCd version.

<div style="background:#fff8e1; border-left:4px solid #f59e0b; padding:12px; margin:15px 0;">
'''Before using any network restriction, verify the current syntax with `/HELPOP`, confirm the target and duration, and check how many legitimate users may match.'''
</div>

= 13. Choosing a Network Restriction =

Before applying a restriction, determine:

# What behavior must be stopped?
# Is the behavior still active?
# Is disconnecting the current user sufficient?
# Is a channel restriction sufficient?
# What identity information is reliable?
# Is the IP or host shared?
# Is an account-based response available?
# Should the action be local or network-wide?
# What duration is proportionate?
# Could legitimate DWShells, DWBouncers, VPN, or gateway users be affected?
# Do you have authority?
# Is senior approval required?
# What is the rollback procedure?

The smallest effective restriction is usually preferred.

= 14. Ban Duration =

A restriction may be:

* Very short for immediate containment.
* Temporary pending investigation.
* Time-limited for a confirmed violation.
* Extended after repeated evasion.
* Indefinite or permanent with appropriate senior approval.

The duration should reflect:

* Severity.
* Intent.
* Previous relevant behavior.
* Impact.
* Likelihood of recurrence.
* Risk to innocent users.
* Whether the identity is reliable.
* Whether appeal or review is pending.

Operators must understand the current time format used by UnrealIRCd before entering a duration.

= 15. Ban Reasons =

A network-ban reason should be:

* Factual.
* Concise.
* Professional.
* Related to policy or conduct.
* Useful to other staff.
* Free from unnecessary private information.

Good examples:

<pre>
Active multi-channel flooding
Repeated unsolicited network recruitment after warning
Credential phishing through Services impersonation
Ban evasion during active abuse incident
Malicious bot distributing harmful links
</pre>

Avoid:

<pre>
Bad user
Annoying
Go away
You know why
Staff decision
Personal dispute
</pre>

Where an internal case reference exists, it may be included according to policy without exposing confidential details.

= 16. Confirming a Restriction =

After applying a network restriction:

# Confirm that the command succeeded.
# Confirm the intended target matched.
# Confirm the restriction propagated as expected.
# Check whether innocent users were disconnected.
# Record the exact entry.
# Record the time and duration.
# Record the reason.
# Set a review time.
# Notify the incident lead.
# Correct errors immediately.

Never assume a restriction worked simply because the command was entered.

= 17. Removing a Network Restriction =

Before removal:

* Confirm the exact restriction type.
* Confirm the exact mask or target.
* Review the original reason.
* Check whether the incident remains active.
* Confirm authorization.
* Determine whether another protection is required.
* Record the removal and reason.

Do not remove a restriction merely because the affected user is a friend or complains persistently.

Do not leave incorrect restrictions active to avoid admitting a mistake.

= 18. Shuns =

A shun may leave a user connected while preventing many commands or messages.

Because the user may receive limited feedback, shuns require careful use.

A shun may be considered for:

* Certain active flooding behavior.
* Automated malicious commands.
* Temporary containment during investigation.
* Situations where immediate disconnection is less useful.

Risks include:

* Confusing affected users.
* Hiding the action from ordinary channel staff.
* Leaving legitimate users unable to communicate.
* Forgetting a temporary restriction.
* Applying it to a shared identity.

Shuns must be documented and reviewed.

= 19. OperOverride =

OperOverride allows an authorized IRC operator to bypass certain normal channel restrictions.

It may permit actions such as:

* Joining a restricted channel.
* Acting despite channel access limitations.
* Performing authorized emergency intervention.
* Investigating a serious network incident.

OperOverride must be used only when:

* There is a valid network-level purpose.
* Normal procedures are insufficient.
* The operator has authority.
* The action is proportionate.
* The use is documented.
* Confidentiality is maintained.

It must not be used:

* To enter private channels out of curiosity.
* To monitor personal conversations.
* To bypass a channel founder during an argument.
* To obtain channel operator status for convenience.
* To assist a friend in a private dispute.
* To avoid the Services ownership process.

= 20. SAMODE and Forced Channel Actions =

`SAMODE` or equivalent administrative capabilities may force user or channel mode changes.

These are elevated powers.

Possible legitimate uses include:

* Emergency network protection.
* Correcting a severe mode-lock situation.
* Containing active abuse.
* Restoring a network-managed channel.
* Carrying out an authorized administrative decision.

Risks include:

* Overriding legitimate channel ownership.
* Removing critical protection.
* Affecting many users.
* Concealing who initiated the change.
* Creating conflict with Services.
* Using the wrong target or parameter.

Trainees should learn the concept but must not execute forced mode commands in production.

= 21. Server Routing and Topology =

DarkWorld IRC consists of linked servers.

Operators should understand:

* Users connect through individual servers.
* Channels and messages are shared across the network.
* Services may connect through a dedicated server.
* A server link can fail.
* A server may reconnect and synchronize.
* Round-robin DNS may direct users to different servers.
* A local problem may affect only one server.
* A split may affect a portion of the network.

Useful commands may include:

<pre>
/LINKS
/MAP
/LUSERS
/WHOIS nickname
</pre>

Availability depends on permissions and current configuration.

= 22. Netsplits =

A netsplit occurs when linked IRC servers lose communication.

Signs include:

* Many users quitting together.
* Server names appearing in quit reasons.
* One region or server becoming unreachable.
* Channels temporarily separating.
* Users returning together after reconnection.
* Server-link notices.

Operators should:

# Identify the affected server or link.
# Record the time.
# Check authorized server notices.
# Avoid unnecessary user bans.
# Avoid treating returning users as a raid without evidence.
# Notify network operations.
# Allow synchronization after reconnection.
# Verify Services and channel state.
# Provide an approved status update.
# Document persistent instability.

= 23. Server-Link Commands =

Commands that disconnect, reconnect, restart, or terminate IRC servers are dangerous.

Examples may include:

* Server-connect commands.
* Server-disconnect commands.
* SQUIT.
* REHASH.
* RESTART.
* DIE.

These commands can affect hundreds of users and the entire network.

They belong to the IRCd Administration specialist program and must not be used by general trainees.

= 24. Rehashing =

A rehash reloads IRCd configuration.

An incorrect or unauthorized rehash may:

* Activate a broken configuration.
* Remove required settings.
* Change security controls.
* Affect server links.
* Load unintended modules.
* Produce partial configuration behavior.
* Disrupt users.

General IRC operators should report configuration issues to authorized IRCd administrators.

Knowing that `/REHASH` exists does not authorize its use.

= 25. Flood and Raid Response =

When an attack affects several channels or servers:

# Confirm the scope.
# Assign an incident lead.
# Protect affected channels.
# Collect connection and timing information.
# Apply authorized targeted restrictions.
# Coordinate with IRCd operations.
# Avoid independently applying overlapping broad bans.
# Monitor for changing sources.
# Communicate approved updates.
# Record every emergency action.
# Review and remove temporary controls.

A flood may move between:

* Nicknames.
* Accounts.
* IP addresses.
* IPv4 and IPv6.
* VPN services.
* Proxies.
* Bouncers.
* Servers.
* Channels.

Operators should focus on behavior and verified technical evidence, not nationality or unsupported assumptions.

= 26. Connection Floods and IRCd Protection =

Network connection floods may require IRCd-level controls such as:

* Connection throttling.
* Reputation-based restrictions.
* Server-level flood protection.
* Temporary configuration includes.
* Proxy scanning.
* Firewall or upstream mitigation.

These controls belong to authorized IRCd, security, or infrastructure staff.

An IRC operator should:

* Record the connection pattern.
* Identify affected servers.
* Provide accurate counts where possible.
* Preserve server notices.
* Apply only authorized operator-level containment.
* Escalate infrastructure changes.

= 27. Services Failures =

When Services are unavailable:

* NickServ identification may fail.
* SASL may fail.
* ChanServ may disappear.
* Channel status may not be restored.
* HostServ vhosts may not be applied.
* Registered nickname protection may be unavailable.

Operators should:

# Confirm whether Services are connected.
# Record the start time.
# Notify Services administrators.
# Avoid unnecessary founder or access changes.
# Protect official channels temporarily where needed.
# Allow synchronization after Services return.
# Verify important channel modes and access.
# Communicate accurately.

= 28. Server Notice Privacy =

Operator notices may reveal:

* IP addresses.
* Hidden host information.
* Connection details.
* Authentication events.
* Ban reasons.
* Staff actions.
* Server topology.
* Security controls.

This information must remain within the authorized operational context.

Do not paste raw server notices into:

* Public channels.
* Public websites.
* Unrestricted project channels.
* External communities.
* Personal social-media accounts.

= 29. Operator Action Logging =

Significant operator actions should be logged.

Use a format such as:

<pre>
Date and time:
Operator:
Incident reference:
Target nickname:
Registered account:
Visible mask:
Affected server:
Command category:
Action:
Scope:
Duration:
Reason:
Evidence:
Authorization:
Users affected:
Result:
Review time:
Follow-up:
</pre>

Do not store operator passwords or authentication commands in action records.

= 30. High-Risk Command Checklist =

Before using a high-impact operator command:

<pre>
1. Am I connected to the correct network?
2. Am I targeting the correct nickname, host, IP, or server?
3. Is the evidence sufficient?
4. Is the incident still active?
5. Is a channel-level response sufficient?
6. What is the narrowest effective scope?
7. Could the target be shared?
8. Is the duration correct?
9. Do I have authority?
10. Is senior approval required?
11. Is another operator already acting?
12. How will I verify success?
13. How will I reverse the action?
14. Where will I record it?
</pre>

If the action is not urgent, pause and verify before sending it.

= 31. Command Coordination =

During an active incident, multiple operators may otherwise:

* Apply duplicate bans.
* Use conflicting masks.
* Repeatedly kill the same reconnecting user.
* Remove each other’s restrictions.
* Apply overlapping broad actions.
* Confuse channel staff.
* Lose track of temporary controls.

The incident lead should coordinate:

* Who investigates.
* Who applies restrictions.
* Who records actions.
* Who communicates publicly.
* Who reviews the results.

= 32. Operator Mistakes =

If an operator:

* Kills the wrong user.
* Applies the wrong mask.
* Blocks a shared provider.
* Sets the wrong duration.
* Uses the wrong restriction type.
* Exposes private information.
* Applies an unauthorized override.

They must:

# Stop continuing harm.
# Correct or remove the action.
# Restore affected access where possible.
# Notify the incident lead or senior staff.
# Preserve the original log.
# Record the correction.
# Inform affected users appropriately.
# Participate in review.
# Complete additional training if required.

Concealing an operator mistake is more serious than honestly reporting and correcting it.

= 33. Operator Conduct =

IRC operators must:

* Remain professional.
* Be visibly accountable for actions.
* Avoid threats and intimidation.
* Follow policy.
* Respect channel autonomy.
* Protect confidential data.
* Cooperate with other staff.
* Accept review.
* Avoid public staff arguments.
* Declare conflicts of interest.
* Step back when personally involved.

Operator status does not place a person above DarkWorld rules.

= 34. Temporary Removal of Operator Access =

Operator access may need to be suspended when:

* Credentials are exposed.
* A device is compromised.
* The operator repeatedly acts unsafely.
* A serious misconduct investigation is active.
* The operator is inactive for an extended period.
* Their role no longer requires access.
* Management determines that network safety requires suspension.

Temporary suspension is a protective measure and does not by itself establish misconduct.

= 35. Practical Exercises =

These exercises must use simulations, a training environment, or trainer-approved test identities. Candidates must not apply production network bans.

== Exercise 1: Operator Security Review ==

Prepare a checklist covering:

* TLS.
* Device security.
* Password storage.
* Client scripts.
* Automatic `/OPER`.
* Logs.
* Session locking.
* Credential rotation.
* Compromise reporting.

== Exercise 2: User Investigation ==

Using trainer-provided simulated WHOIS and notice data:

* Identify confirmed account information.
* Identify the connected server.
* Identify displayed connection information.
* Separate facts from assumptions.
* Recommend whether further investigation is justified.

== Exercise 3: Kill Decision ==

For each simulated case, decide whether a kill is appropriate:

* Minor off-topic discussion.
* Active phishing.
* Single-channel flooding.
* Multi-channel automated flooding.
* Respectful criticism of staff.
* Malicious bot distribution.

Explain whether a kick, kill, ban, or no action is most appropriate.

== Exercise 4: Network-Ban Selection ==

Given several simulated masks:

* Choose local or global scope.
* Identify shared-host risks.
* Select a duration.
* Write a professional reason.
* Explain how the restriction would be reviewed.
* Do not execute the command.

== Exercise 5: Netsplit ==

The trainer simulates a server split.

The candidate must:

* Identify the likely split.
* Record the affected server and time.
* Avoid treating returning users as attackers.
* Notify operations.
* Prepare a public status update.
* Verify recovery.

== Exercise 6: Wrong Restriction ==

The trainer simulates a global restriction affecting innocent bouncer users.

The candidate must:

* Identify the excessive scope.
* Recommend immediate correction.
* Preserve the original record.
* Notify senior staff.
* Prepare an affected-user explanation.
* Propose a narrower replacement.

== Exercise 7: Coordinated Flood ==

During a simulated multi-channel flood, the candidate must:

* Report to the incident lead.
* Identify affected channels and servers.
* Recommend operator-level containment.
* Avoid duplicate actions.
* Record all proposed restrictions.
* Define recovery and review steps.

= 36. Practical Scenarios =

== Scenario 1: Channel Argument ==

A user insults a channel operator once. The channel operator asks an IRCOp to permanently ban the user from the network.

'''Recommended response:'''

A normal channel-level response is likely sufficient. Network authority should not be used merely because a channel operator requests disproportionate punishment.

== Scenario 2: Active Phishing ==

A fake Services nickname is sending credential requests in several channels.

'''Recommended response:'''

Immediate network-level containment may be justified. Disconnect or restrict the malicious connection through authorized procedures, preserve evidence, warn users, and escalate compromised accounts.

== Scenario 3: Shared Shell Provider ==

One abusive user connects through a host also used by many legitimate DWShells users.

'''Recommended response:'''

Avoid a broad host restriction where a more precise account, ident, or supported security-based restriction is available. Coordinate with DWShells staff if their infrastructure is relevant.

== Scenario 4: OperOverride Request ==

A friend asks an operator to override an invite-only private channel so they can see what is being discussed.

'''Recommended response:'''

Refuse. This is not a valid network purpose and would misuse elevated access.

== Scenario 5: Persistent Link Failure ==

One server disconnects and reconnects repeatedly.

'''Recommended response:'''

Record the link events, identify affected users, notify IRCd administration, avoid unnecessary user enforcement, and provide an approved operational update.

== Scenario 6: Wrong Global Ban ==

An operator accidentally applies a network-wide ban to a large shared VPN provider.

'''Recommended response:'''

Remove or correct the restriction immediately where authorized, notify the incident lead, identify affected legitimate users, preserve the action record, and complete a formal review.

== Scenario 7: Compromised Operator ==

An operator account begins issuing unexpected kills while its owner says they are offline.

'''Recommended response:'''

Treat the account as compromised. Notify senior management immediately, restrict its access through authorized procedures, preserve logs, rotate credentials, and review all actions performed during the suspected compromise.

= 37. Knowledge Check =

Answer the following questions in your own words:

# What is the purpose of an IRC operator?
# Why is operator access not a reward?
# What is the difference between an IRC operator and an IRCd administrator?
# What is least-privilege operator access?
# Under what conditions should operator authentication occur?
# Why must the NickServ and operator passwords be different?
# What should happen after unexpected `/OPER` failures?
# What are server notices?
# Why should operators subscribe only to relevant notice categories?
# What user information may be relevant to an abuse investigation?
# When is an operator investigation improper?
# Why does a matching host not prove common identity?
# What does a KILL do?
# When is a KILL inappropriate?
# What is the general difference between local and global restrictions?
# Why are IP-based restrictions risky?
# What factors determine a network-ban duration?
# What makes a professional ban reason?
# What must be verified after applying a restriction?
# What should be checked before removing a restriction?
# What is a shun?
# Why must shuns be documented carefully?
# What is OperOverride?
# When must OperOverride not be used?
# What is the risk of forced mode commands?
# What information can `/LINKS` or `/MAP` provide?
# How should an operator respond to a netsplit?
# Why are SQUIT, REHASH, RESTART, and DIE considered high risk?
# Who should handle IRCd configuration changes?
# What is the operator’s role during a connection flood?
# How should Services failure be handled?
# Why must server notices remain confidential?
# What should an operator-action record contain?
# Why is command coordination important?
# What should happen after an operator mistake?
# When might operator access be suspended?
# Why must an operator disclose a personal conflict?
# Does completing this module authorize production operator access?

= 38. Written Assignment =

Write approximately '''900–1,200 words''' analyzing this incident:

<blockquote>
During a coordinated attack, several accounts flood `#DarkWorld`, `#Help`, and `#Support`. Two attackers connect through a VPN also used by twenty legitimate users. A new IRC operator globally bans the entire VPN hostname without checking its scope. Twenty-two users disconnect, including the attackers. Another operator removes the ban without informing anyone, and the attack resumes. A third operator begins issuing repeated KILL commands while no incident lead has been assigned.
</blockquote>

Your analysis must explain:

* Why network-level intervention was justified.
* Why the global hostname ban was risky.
* What narrower responses should have been considered.
* Why removing protection without coordination caused a problem.
* Why repeated KILL commands were insufficient.
* How an incident lead should coordinate operators.
* What evidence should be preserved.
* How innocent users should be restored.
* What public message may be appropriate.
* What operator actions must be recorded.
* How the restrictions should be reviewed.
* What training or access review may be necessary afterward.

= 39. Module Completion Requirements =

To complete this module, the candidate must:

* Read the complete lesson.
* Complete all seven practical exercises.
* Correctly answer at least '''29 of the 38''' knowledge-check questions.
* Complete the written assignment.
* Demonstrate operator credential-security awareness.
* Correctly distinguish channel and network responses.
* Select proportionate simulated restrictions.
* Complete the netsplit and flood simulations.
* Demonstrate accurate action logging.
* Receive trainer approval.

Completion does not guarantee IRC operator appointment.

= 40. Trainer Evaluation =

{| class="wikitable" style="width:100%;"
! Evaluation area
! Maximum points
|-
| Operator role and authority boundaries
| 15
|-
| Credential and session security
| 15
|-
| User investigation and privacy
| 15
|-
| Kill and network-restriction judgment
| 20
|-
| Netsplit, flood, and Services response
| 15
|-
| Coordination and logging
| 10
|-
| Accountability and correction
| 10
|-
! Total
! 100
|}

Recommended passing score: '''80 points'''.

A higher passing score is recommended because operator actions can affect the entire network.

A candidate should not pass if they:

* Share or mishandle operator credentials.
* Use elevated access for personal purposes.
* Repeatedly choose dangerously broad restrictions.
* Publicly expose restricted user information.
* Ignore command scope or duration.
* Conceal operator actions.
* Refuse incident coordination.
* Use dangerous server commands without authorization.
* Retaliate against users or staff.
* Treat training completion as automatic authorization.

= 41. Operator Readiness Checklist =

Before a candidate can be considered for operator probation, they should demonstrate:

<pre>
[ ] Completed Modules 1–9
[ ] Passed operator knowledge assessment
[ ] Passed incident-response simulation
[ ] Accepted the Staff Code of Conduct
[ ] Uses secure TLS and SASL
[ ] Uses unique operator credentials
[ ] Understands least privilege
[ ] Can identify shared-host risks
[ ] Can distinguish channel and network enforcement
[ ] Can document operator actions
[ ] Can correct and report mistakes
[ ] Understands escalation paths
[ ] Has an assigned mentor
[ ] Has management approval
[ ] Has a defined operational role
</pre>

= 42. Next Module =

After passing this module, continue to:

'''[[DWIRC:Staff Training/Staff Ethics|Module 10 — Staff Ethics and Security]]'''

----

'''Previous:''' [[DWIRC:Staff Training/Incident Handling|Module 8 — Abuse and Incident Handling]]
'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
'''Next:''' [[DWIRC:Staff Training/Staff Ethics|Module 10 — Staff Ethics and Security]]

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

DWIRC:Staff Training/IRC Operator Fundamentals

2026-08-08T18:07:12Z

Fizi:

DWIRC:Staff Training/IRC Operator Fundamentals

2026-08-08T18:01:10Z

Fizi: Created page with "{{DISPLAYTITLE:Module 9 — IRC Operator Fundamentals}} <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 9: IRC Operator Fundamentals</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 9 of 10 |- ! Difficulty | Ad..."

DWIRC:Staff Training/Incident Handling

2026-08-08T17:57:01Z

Fizi: Protected "DWIRC:Staff Training/Incident Handling" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:Module 8 — Abuse and Incident Handling}}

<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 8: Abuse and Incident Handling</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Program
| DarkWorld IRC Staff Training Program
|-
! Module
| 8 of 10
|-
! Difficulty
| Advanced
|-
! Estimated study time
| 4–6 hours
|-
! Assessment
| Knowledge check, incident simulations, and formal incident report
|-
! Prerequisite
| [[DWIRC:Staff Training/Moderation|Module 7 — IRC Moderation]]
|}

= Module Overview =

An incident is an event that threatens or disrupts DarkWorld IRC users, channels, Services, servers, policies, or operations.

Incidents may include:

* Serious harassment.
* Threats or exposure of private information.
* Coordinated flooding or raids.
* Spam across multiple channels.
* Credential phishing.
* Malicious bots.
* Ban evasion.
* Unauthorized relays.
* Services failures.
* Server disconnections.
* Network attacks.
* Compromised accounts.
* Staff misconduct.
* Policy or approval violations.

Incident handling requires more than issuing a kick or ban. Staff must identify the problem, protect users, preserve evidence, coordinate actions, communicate accurately, and review the outcome.

= Learning Objectives =

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

# Recognize an incident.
# Classify its urgency and severity.
# Take safe immediate protective action.
# Preserve relevant evidence.
# Separate facts, allegations, and inferences.
# Protect private and security-sensitive information.
# Escalate to the correct team.
# Maintain a clear incident timeline.
# Avoid conflicting staff actions.
# Prepare a professional incident report.
# Hand over an active incident correctly.
# Close and review an incident.
# Identify improvements after an incident.

= 1. What Is an Incident? =

An incident is an event requiring coordinated attention because it:

* Causes significant disruption.
* Affects multiple users, channels, or servers.
* Creates a security or privacy risk.
* Requires more authority than ordinary moderation.
* May continue or spread.
* Requires formal documentation.
* Requires coordination between staff teams.
* Could affect trust in the network.

Not every disagreement or minor rule violation is an incident.

Examples of ordinary moderation include:

* A user posting off-topic content.
* A single accidental flood.
* A minor channel-rule violation.
* A routine kick or temporary channel ban.

The matter may become an incident when it is repeated, coordinated, severe, widespread, security-related, or disputed at a high level.

= 2. Incident Priorities =

During an incident, staff should prioritize:

# '''Safety''' – Protect users and prevent immediate harm.
# '''Containment''' – Stop the incident from spreading.
# '''Evidence''' – Preserve enough reliable information.
# '''Coordination''' – Ensure staff actions do not conflict.
# '''Recovery''' – Restore normal service safely.
# '''Communication''' – Provide accurate and approved information.
# '''Review''' – Learn from the incident and improve controls.

Evidence is important, but staff must not allow serious ongoing harm merely to obtain a more complete log.

= 3. Incident Severity Levels =

DarkWorld IRC may classify incidents using four operational levels.

{| class="wikitable" style="width:100%;"
! Level
! Classification
! Examples
! General response
|-
| '''Level 1'''
| Low
| Minor isolated disruption, first-time low-impact violation
| Guidance, warning, routine moderation
|-
| '''Level 2'''
| Moderate
| Repeated flooding, ongoing harassment, repeated advertising, limited ban evasion
| Contain, document, notify appropriate staff
|-
| '''Level 3'''
| High
| Coordinated raid, multi-channel abuse, phishing, serious threats, unauthorized relay campaign
| Immediate containment and senior escalation
|-
| '''Level 4'''
| Critical
| Network attack, server compromise, staff-account compromise, Services database risk, widespread data exposure
| Emergency escalation, incident leadership, controlled recovery
|}

Severity may change as new information becomes available.

A Level 2 incident may become Level 3 if it spreads across channels. A suspected Level 4 incident may be downgraded after investigation.

= 4. Severity Assessment Factors =

Consider:

* Number of users affected.
* Number of channels or servers affected.
* Whether the incident is ongoing.
* Whether automation is involved.
* Whether private information is exposed.
* Whether credentials are compromised.
* Whether infrastructure is affected.
* Whether the conduct is coordinated.
* Whether the actor is evading restrictions.
* Whether staff access is involved.
* Whether normal service is unavailable.
* Whether harm can spread quickly.
* Whether immediate senior intervention is required.

Do not classify an incident based solely on how angry the reporter appears.

= 5. Incident Response Process =

The general process is:

# Detect or receive the report.
# Acknowledge the incident.
# Perform initial assessment.
# Assign severity.
# Protect affected users.
# Contain active harm.
# Preserve evidence.
# Notify the correct staff.
# Assign or identify incident leadership.
# Investigate within authorization.
# Restore normal operation.
# Communicate the outcome appropriately.
# Close the incident.
# Perform a post-incident review.

= 6. Detecting an Incident =

Incidents may be detected through:

* User reports.
* Staff observation.
* Server notices.
* Services messages.
* Monitoring systems.
* Bot alerts.
* PolicyServ.
* RelayServ.
* Channel logs.
* Repeated support requests.
* Server or Services failures.
* Unusual connection patterns.

An alert is not always proof of an incident. Staff should verify available information while remaining ready to act if the risk is high.

= 7. Receiving an Abuse Report =

When a user reports abuse:

# Acknowledge the report.
# Determine whether harm is still occurring.
# Ask where and when it happened.
# Ask which users or channels are involved.
# Move sensitive evidence to the approved private process.
# Avoid promising a specific punishment.
# Preserve the original report.
# Escalate according to severity.
# Explain the next available step.

Example:

<pre>
Thank you for reporting this. Is the behavior still happening? Please provide the channel, approximate time, and nicknames involved. Do not post IP addresses, passwords, or private evidence publicly.
</pre>

= 8. Immediate Protective Action =

Immediate action may be necessary to:

* Stop active flooding.
* Remove a malicious link.
* Restrict a phishing account.
* Protect a user from repeated harassment.
* Moderate a channel during a raid.
* Remove a malfunctioning bot.
* Stop an unauthorized relay from importing harmful content.
* Prevent further exposure of private information.

The action should:

* Be within the staff member’s authority.
* Target the active harm.
* Minimize impact on legitimate users.
* Be reversible where practical.
* Be documented.
* Be reviewed after the emergency.

A trainee should request assistance immediately when the available response requires higher authority.

= 9. Incident Leadership =

A serious incident should have a clear incident lead.

The incident lead coordinates:

* Priorities.
* Staff assignments.
* Containment actions.
* Evidence collection.
* Internal communication.
* Public updates.
* Recovery decisions.
* Incident closure.
* Post-incident review.

The incident lead should normally be the most appropriate authorized senior staff member—not necessarily the first person who noticed the problem.

Trainees should follow the incident lead’s instructions and report observations clearly.

= 10. Staff Roles During an Incident =

Where enough staff are available, responsibilities may be divided:

{| class="wikitable" style="width:100%;"
! Role
! Responsibility
|-
| Incident lead
| Coordinates the overall response
|-
| Moderation responder
| Applies approved IRC protections
|-
| Technical responder
| Checks servers, Services, or infrastructure
|-
| Evidence recorder
| Maintains logs, timestamps, and the timeline
|-
| Communications contact
| Provides approved user or staff updates
|-
| Policy reviewer
| Confirms applicable rules and approval status
|-
| Liaison
| Coordinates with a DarkWorld project or external operator
|}

One person may perform several roles in a small incident, but responsibilities should remain clear.

= 11. Internal Communication =

During an incident:

* Use the approved staff channel or system.
* Keep messages factual and concise.
* State what was observed.
* State what action was taken.
* Include accurate timestamps.
* Avoid speculation presented as fact.
* Avoid posting credentials.
* Avoid duplicating commands.
* Confirm changes made by other staff.
* Identify who is leading the response.

A useful update is:

<pre>
20:14 UTC — Flooding observed in #Example from six new connections. Channel temporarily set +m. Three targeted bans applied. Network operator assistance requested. No evidence of other affected channels yet.
</pre>

A poor update is:

<pre>
We are being destroyed. Ban everyone.
</pre>

= 12. Incident Timeline =

A timeline records events in chronological order.

Use a consistent timezone, preferably '''UTC''', and state it clearly.

Example:

<pre>
20:11 UTC — First repeated advertisement observed in #Example.
20:12 UTC — Same content observed in #Help.
20:13 UTC — Formal warning issued.
20:14 UTC — Additional connections joined and began flooding.
20:14 UTC — #Example set +m by StaffNick.
20:15 UTC — Senior network staff notified.
20:17 UTC — Targeted channel bans applied.
20:21 UTC — Flooding stopped.
20:28 UTC — Normal channel modes restored.
20:35 UTC — Evidence and action record completed.
</pre>

A timeline should record facts and actions, not emotional commentary.

= 13. Evidence Preservation =

Evidence may include:

* Exact IRC messages.
* Timestamps.
* Channel names.
* Nicknames.
* Visible user masks.
* Registered accounts, where authorized.
* Server notices.
* Mode changes.
* Kick and ban reasons.
* Services responses.
* Bot or relay activity.
* Screenshots.
* Client logs.
* Authorized server logs.
* Policy or application records.
* Staff actions.

== Evidence Principles ==

Evidence should be:

* Relevant.
* Preserved in its original form where possible.
* Complete enough to show context.
* Protected from unauthorized access.
* Linked to the incident record.
* Retained according to approved procedures.
* Shared only with people who require access.

= 14. Evidence Integrity =

Staff must not:

* Alter evidence to change its meaning.
* Delete inconvenient staff actions.
* Fabricate messages.
* Remove timestamps.
* Present a partial log as complete.
* Add assumptions to quoted material.
* Share private evidence publicly.
* Collect unrelated user information.
* Access systems beyond their authorization.

If evidence must be redacted for wider sharing:

* Preserve the protected original.
* Mark the copy as redacted.
* Remove only information not required by the audience.
* Do not change the meaning.

= 15. Facts, Reports, and Inferences =

Incident records should distinguish:

== Direct Observation ==

<pre>
Staff directly observed the user posting the same link four times in #Example.
</pre>

== User Report ==

<pre>
The reporting user stated that similar messages were sent privately.
</pre>

== Technical Evidence ==

<pre>
Authorized logs show twelve connections within the same time window.
</pre>

== Inference ==

<pre>
The matching timing and content suggest coordination, but common control has not yet been confirmed.
</pre>

Clear wording protects the accuracy of the investigation.

= 16. Screenshots and Logs =

Screenshots can be useful, but they may:

* Omit earlier context.
* Be edited.
* Hide timestamps.
* Exclude relevant users.
* Show only client-rendered information.
* Expose unrelated private conversations.

Logs can also be incomplete or locally edited.

Where possible:

# Obtain the relevant time range.
# Preserve surrounding context.
# Compare user-provided evidence with authorized logs.
# Record the source.
# Avoid assuming a screenshot alone proves the entire allegation.
# Protect unrelated private information.

= 17. Confidentiality Levels =

Incident information may be classified operationally as:

{| class="wikitable" style="width:100%;"
! Classification
! Example
! Intended audience
|-
| Public
| Approved service-status message
| Network users
|-
| Internal
| Routine staff coordination
| Authorized DWIRC staff
|-
| Restricted
| Abuse evidence and account information
| Assigned investigation team
|-
| Highly Restricted
| Credentials, vulnerabilities, infrastructure details
| Specifically authorized senior or technical staff
|}

Not every staff member needs access to every incident detail.

= 18. Privacy and Data Minimization =

Collect only the information required to:

* Understand the incident.
* Protect users.
* Apply policy.
* Support an appeal.
* Perform technical recovery.
* Meet an authorized operational requirement.

Do not collect unrelated personal information “in case it becomes useful.”

Incident reports should avoid unnecessary:

* Full email addresses.
* Unmasked IP addresses.
* Private conversations.
* External account details.
* Personal documents.
* Credentials.
* Information about uninvolved users.

= 19. Incident Escalation Paths =

The appropriate destination depends on the incident.

{| class="wikitable" style="width:100%;"
! Incident
! Escalation destination
|-
| Routine channel problem
| Channel founder or authorized channel staff
|-
| Network policy violation
| Authorized DWIRC staff or policy team
|-
| Advertising approval matter
| Policy team
|-
| Relay or bridge violation
| Relay team
|-
| NickServ or ChanServ administration
| Services staff
|-
| Multi-channel abuse
| IRC operators or network administration
|-
| Server or link problem
| IRCd/network operations
|-
| Compromised staff account
| Senior network management and security responders
|-
| Staff misconduct allegation
| Appropriate independent senior reviewer
|-
| Other DarkWorld project issue
| Relevant project team
|}

An incident may require more than one team.

= 20. Advertising Incidents =

For serious or repeated unauthorized advertising:

# Preserve the exact content and context.
# Identify channels and recipients.
# Determine whether private messages were involved.
# Check the approval system.
# Identify repeated or coordinated distribution.
# Contain ongoing spam where authorized.
# Escalate approval decisions to the policy team.
# Record any warning or restriction.
# Monitor for evasion.

Trainees must not change advertising application statuses without authorization.

= 21. Relay and Bridge Incidents =

For relay-related incidents:

# Identify the relay bot.
# Identify the DarkWorld channel.
# Identify the external source where possible.
# Check registration or approval status.
# Determine whether the problem is isolated or repeated.
# Preserve relayed messages.
# Contact the operator through the approved process.
# Apply immediate channel protection if necessary.
# Escalate to the relay team.
# Record compliance notices and deadlines.
# Monitor corrective action.

The relay bot may be the delivery mechanism rather than the original author, but its operator remains responsible for compliance.

= 22. Harassment and Threat Incidents =

For serious harassment:

# Protect the targeted user.
# Ask whether the behavior is continuing.
# Preserve relevant evidence.
# Avoid requiring public disclosure.
# Identify repeated contact or evasion.
# Apply authorized restrictions.
# Escalate credible threats promptly.
# Avoid promising real-world protection beyond DarkWorld’s capabilities.
# Provide appropriate emergency guidance when immediate danger is reported.

DarkWorld IRC staff are not law enforcement or emergency services.

If a person appears to face immediate real-world danger, they should be encouraged to contact the appropriate local emergency or law-enforcement service.

= 23. Doxxing and Private Information Exposure =

Doxxing involves exposing private identifying information without authorization.

Possible examples include:

* Home address.
* Telephone number.
* Private email address.
* Government identification.
* Financial details.
* Hidden IP or connection information.
* Private workplace or family information.

Response priorities:

# Stop further distribution.
# Avoid repeating the information.
# Preserve restricted evidence.
# Remove exposure where technically possible and authorized.
# Restrict the responsible accounts.
# Notify senior staff.
# Inform the affected user appropriately.
# Review whether any staff or system data was compromised.

= 24. Credential Phishing =

Phishing may involve:

* Fake NickServ messages.
* Fake staff accounts.
* Links to imitation login pages.
* Requests for passwords.
* Claims that users must “verify” through an unofficial bot.
* Malicious files or scripts.

Response:

# Stop distribution.
# Warn users through an approved notice.
# Preserve the sender, content, destination, and time.
# Identify affected accounts.
# Advise exposed users to change credentials.
# Escalate immediately.
# Avoid opening malicious content on production systems.
# Record confirmed compromise separately from possible exposure.

= 25. Coordinated Floods and Raids =

A coordinated flood may affect:

* One channel.
* Several channels.
* One IRC server.
* Multiple servers.
* Services.
* Private messages.
* Network connection capacity.

Initial response may include:

* Temporary channel modes.
* Targeted restrictions.
* Requesting IRC operator assistance.
* Reviewing connection patterns.
* Applying approved network protections.
* Keeping public communication brief.
* Recording every emergency change.

Trainees must not make IRCd configuration or firewall changes.

= 26. Server and Network Incidents =

Possible indicators include:

* Many users disconnecting simultaneously.
* A server disappearing from the network.
* Repeated link failures.
* Significant lag.
* Widespread connection failures.
* Unusual server notices.
* Large numbers of automated connections.
* Several servers becoming unreachable.
* TLS problems affecting multiple users.

Trainees should:

# Record the affected server or service.
# Record the time and observed symptoms.
# Determine whether multiple users are affected.
# Notify authorized network operations.
# Avoid making unsupported public claims.
# Avoid confusing a netsplit with a ban.
# Follow the approved status-message process.

= 27. Services Incidents =

Possible Services incidents include:

* NickServ, ChanServ, or HostServ disconnecting.
* Widespread SASL failures.
* Registered channel status not being restored.
* Unexpected account or channel changes.
* Services impersonation.
* Services database errors.
* Repeated Services reconnects.

During instability:

* Avoid unnecessary ownership changes.
* Avoid telling all users to reset passwords unless compromise is confirmed.
* Record affected Services.
* Notify Services administration.
* Allow synchronization after recovery.
* Verify that channel access and modes are restored correctly.

= 28. Compromised Staff Accounts =

Indicators may include:

* Unexpected operator commands.
* Unusual login location or timing.
* Unauthorized access grants.
* Unexplained configuration changes.
* Staff denial of actions recorded under their account.
* Password or token exposure.
* Impersonation combined with valid privileges.

Response:

# Notify senior management immediately.
# Limit the compromised access through authorized procedures.
# Preserve relevant logs.
# Do not confront the suspected attacker publicly.
# Rotate affected credentials.
# Review other systems using related credentials.
# Identify actions performed during the compromise.
# Restore altered settings carefully.
# Record the complete response.

Trainees must not attempt to access another staff member’s account.

= 29. Staff Misconduct Incidents =

A staff misconduct allegation may include:

* Retaliation.
* Unauthorized access.
* Exposure of private information.
* Abuse of operator commands.
* Favoritism.
* Falsified records.
* Improper account or channel changes.
* Sharing staff information.
* Interference with an investigation.

The case should be:

* Handled confidentially.
* Preserved accurately.
* Assigned to an appropriate independent reviewer.
* Protected from retaliation.
* Separated from unrelated personal disagreements.
* Decided using evidence and policy.

The accused staff member should not be the sole investigator or decision-maker.

= 30. Public Communication During an Incident =

Public communication should be:

* Accurate.
* Brief.
* Approved.
* Free from speculation.
* Free from confidential details.
* Updated when meaningful information changes.

Example:

<pre>
We are investigating a service disruption affecting some IRC connections. Network staff are working on recovery. Please avoid repeatedly reconnecting and watch the official channel for updates.
</pre>

Avoid:

<pre>
The server was hacked.
We know who did it.
All accounts are compromised.
Everything is fixed.
</pre>

Unless those statements have been confirmed and approved.

= 31. Incident Handover =

If responsibility passes to another staff member, provide:

<pre>
Incident reference:
Current severity:
Start time:
Current status:
Affected users/channels/servers:
Confirmed facts:
Unverified reports:
Containment actions:
Active restrictions:
Evidence location:
Teams notified:
Pending tasks:
Next review time:
Current incident lead:
</pre>

The outgoing staff member should confirm that the receiving person accepted the handover.

= 32. Recovery =

Recovery means safely returning the network or channel to normal operation.

Recovery may include:

* Removing temporary emergency modes.
* Reviewing bans.
* Reconnecting Services.
* Restoring channel access.
* Correcting account settings.
* Re-enabling approved relays.
* Updating status messages.
* Confirming server synchronization.
* Verifying that abuse has stopped.
* Monitoring for recurrence.

Recovery should not begin blindly. Confirm that removing protection will not immediately restart the incident.

= 33. Closing an Incident =

An incident may be closed when:

* Active harm has stopped.
* Necessary restrictions are in place.
* Affected services are stable.
* Required evidence is preserved.
* Users or teams have received appropriate updates.
* Pending actions have owners.
* The final report is complete.
* Review requirements are identified.

Closing an incident does not necessarily mean all long-term work is finished.

Follow-up tasks may remain open.

= 34. Post-Incident Review =

A post-incident review should ask:

* What happened?
* When was it detected?
* What was the impact?
* What worked well?
* What delayed the response?
* Were actions proportionate?
* Were innocent users affected?
* Were records complete?
* Were policies clear?
* Did staff communication work?
* Were tools or bots reliable?
* What documentation should change?
* What technical controls should improve?
* Who owns each follow-up action?

The purpose is improvement and accountability, not personal blame.

= 35. Incident Report Template =

<pre>
DARKWORLD IRC INCIDENT REPORT

Case reference:
Incident title:
Date:
Timezone:
Reported by:
Incident lead:
Severity:
Current status:

1. Summary
Brief description of the incident.

2. Scope
Affected users:
Affected channels:
Affected servers:
Affected Services:
Affected projects:

3. Timeline
Time — Event or action
Time — Event or action

4. Confirmed Facts
List facts supported by evidence.

5. User or Staff Reports
List relevant claims not directly observed.

6. Inferences and Unknowns
Clearly identify conclusions and unanswered questions.

7. Evidence
Evidence type:
Source:
Location:
Access classification:

8. Immediate Actions
Action:
Performed by:
Time:
Reason:

9. Restrictions Applied
Restriction:
Target:
Scope:
Duration:
Review date:

10. Communications
Internal notices:
Public notices:
Affected-user communication:

11. Escalation
Teams notified:
Time notified:
Response received:

12. Recovery
Services restored:
Modes restored:
Restrictions reviewed:
Verification performed:

13. Impact
Users affected:
Service interruption:
Innocent users affected:
Other consequences:

14. Final Outcome
Resolution:
Remaining risks:
Open follow-up tasks:

15. Review
What worked:
What did not work:
Required improvements:
Responsible person:
Target date:
</pre>

= 36. Practical Exercises =

== Exercise 1: Severity Classification ==

Classify each simulated case:

* One accidental repeated message.
* Repeated private-message advertising.
* A coordinated raid across three channels.
* A fake NickServ collecting passwords.
* A suspected compromised Services Administrator account.
* A persistent server-link failure.

Explain the reason for each classification.

== Exercise 2: Incident Timeline ==

Using trainer-provided logs:

* Convert events into UTC.
* Arrange them chronologically.
* Separate user actions from staff actions.
* Mark unverified reports.
* Identify missing information.

== Exercise 3: Confidential Evidence ==

The trainer provides a simulated report containing:

* A password.
* An IP address.
* A private-message log.
* Unrelated personal information.

The candidate must identify:

* What must be revoked or changed.
* What evidence is relevant.
* What should be redacted.
* Who may receive the restricted original.
* What must not be posted publicly.

== Exercise 4: Coordinated Raid ==

During a simulated raid, the candidate must:

* Identify the incident.
* Notify the trainer acting as incident lead.
* Recommend proportionate containment.
* Record mode changes.
* Preserve relevant evidence.
* Prepare a public status message.
* Restore the channel after authorization.

== Exercise 5: Handover ==

The candidate must hand an active simulated incident to another trainee using the handover template.

The receiving trainee must confirm:

* Current severity.
* Active restrictions.
* Pending actions.
* Evidence location.
* Next review time.

== Exercise 6: Post-Incident Review ==

Prepare a short review identifying:

* What happened.
* What worked.
* What failed.
* Whether innocent users were affected.
* Three specific improvements.
* An owner for each improvement.

= 37. Practical Scenarios =

== Scenario 1: Phishing Nickname ==

A user named `NickServ-Help` messages users asking for passwords.

'''Recommended response:'''

Treat it as a high-severity impersonation and phishing incident. Stop ongoing distribution, warn users, preserve evidence, identify exposed accounts, and escalate immediately.

== Scenario 2: Netsplit Misidentified as Attack ==

Many users quit simultaneously from one server.

'''Recommended response:'''

Check for a server disconnection or netsplit. Record the affected server and time, consult authorized notices, and avoid claiming an attack without evidence.

== Scenario 3: Relay Imports Threats ==

An approved relay imports repeated threats from a remote user.

'''Recommended response:'''

Protect affected users, preserve the relayed messages, identify the relay and external source, contact the relay operator, and escalate to the relay team and senior network staff.

== Scenario 4: Staff Credential Leak ==

An IRC operator accidentally posts an operator password in a restricted channel.

'''Recommended response:'''

Treat the credential as compromised even if the channel is restricted. Notify senior staff, rotate the credential, preserve the event record, and review related access.

== Scenario 5: Public Doxxing ==

A user posts another person’s address and telephone number in a public channel.

'''Recommended response:'''

Stop further distribution, avoid repeating the information, preserve restricted evidence, remove exposure where authorized, protect the affected user, and escalate immediately.

== Scenario 6: Conflicting Staff Actions ==

One staff member sets a channel to `+m`; another repeatedly removes it during an active raid.

'''Recommended response:'''

Establish incident leadership, stop public mode conflict, coordinate in the staff channel, confirm the active protection plan, and review the conflicting actions afterward.

= 38. Knowledge Check =

Answer the following questions in your own words:

# What makes an event an incident rather than routine moderation?
# What are the main incident-response priorities?
# What are the four proposed severity levels?
# Which factors influence severity?
# What is the general incident-response process?
# What should staff ask when receiving an abuse report?
# When may immediate protective action be taken?
# What is the role of an incident lead?
# Why should staff roles be clear during an incident?
# What makes a useful internal incident update?
# Why should one consistent timezone be used?
# What information belongs in an incident timeline?
# What types of evidence may be relevant?
# What is evidence integrity?
# How should redacted evidence be handled?
# What is the difference between direct observation and inference?
# Why should screenshots not always be treated as complete proof?
# What are the proposed confidentiality levels?
# What is data minimization?
# Which team should handle an advertising approval violation?
# Which team should handle relay compliance?
# How should serious threats be handled?
# What are the priorities during a doxxing incident?
# What steps are required during credential phishing?
# What should trainees do during a network flood?
# What may indicate a server or Services incident?
# Why should permanent access changes be avoided during Services instability?
# How should a compromised staff account be handled?
# Who should review a staff-misconduct allegation?
# What makes an appropriate public incident update?
# What information belongs in a handover?
# What is required before recovery protections are removed?
# When may an incident be closed?
# What is the purpose of a post-incident review?
# Why must important staff mistakes remain in the record?

= 39. Written Assignment =

Write a formal incident report for the following case:

<blockquote>
At 19:05 UTC, users in `#DarkWorld` report private messages from `DarkWorldSecurity` containing a link to a fake account-verification page. At 19:08 UTC, the same nickname begins posting the link in `#Help` and `#Support`. Two users say they entered their NickServ passwords. At 19:10 UTC, several affected accounts reconnect and begin distributing the same message. One trainee publicly announces that “all DarkWorld accounts have been hacked,” although no network compromise has been confirmed.
</blockquote>

Your report must include:

* Initial severity.
* Confirmed facts.
* Unverified reports.
* Immediate containment.
* Evidence requirements.
* Credential-response guidance.
* Internal escalation.
* Appropriate public communication.
* Correction of the trainee’s unsupported statement.
* Identification of potentially compromised accounts.
* Recovery steps.
* Follow-up actions.
* Post-incident improvements.

= 40. Module Completion Requirements =

To complete this module, the candidate must:

* Read the complete lesson.
* Complete all six practical exercises.
* Correctly answer at least '''27 of the 35''' knowledge-check questions.
* Complete the formal written incident report.
* Correctly classify simulated incidents.
* Preserve evidence appropriately.
* Complete a successful incident handover.
* Participate in the raid simulation.
* Demonstrate accurate public communication.
* Receive trainer approval.

= 41. Trainer Evaluation =

{| class="wikitable" style="width:100%;"
! Evaluation area
! Maximum points
|-
| Incident recognition and severity
| 15
|-
| Immediate protection and containment
| 15
|-
| Evidence integrity and privacy
| 15
|-
| Timeline and documentation
| 15
|-
| Escalation and coordination
| 15
|-
| Incident communication
| 10
|-
| Recovery and closure
| 10
|-
| Post-incident review
| 5
|-
! Total
! 100
|}

Recommended passing score: '''75 points'''.

A candidate should not pass if they:

* Falsify, conceal, or improperly alter evidence.
* Publicly expose confidential information.
* Ignore a compromised staff account.
* Make unsupported public claims during incidents.
* Repeatedly act outside their authority.
* Obstruct an independent staff review.
* Fail to protect users during serious active harm.
* Refuse to document major actions.

= 42. Quick Incident Checklist =

<pre>
1. What happened?
2. Is it still happening?
3. Who or what is affected?
4. What is the current severity?
5. Is immediate protection required?
6. What action is within my authority?
7. Who is the incident lead?
8. What evidence must be preserved?
9. Is any information confidential?
10. Which team must be notified?
11. What temporary restrictions are active?
12. What can be communicated publicly?
13. What remains unverified?
14. What is required for recovery?
15. Who owns the follow-up actions?
16. When will the incident be reviewed?
</pre>

= 43. Next Module =

After passing this module, continue to:

'''[[DWIRC:Staff Training/IRC Operator Fundamentals|Module 9 — IRC Operator Fundamentals]]'''

----

'''Previous:''' [[DWIRC:Staff Training/Moderation|Module 7 — IRC Moderation]]
'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
'''Next:''' [[DWIRC:Staff Training/IRC Operator Fundamentals|Module 9 — IRC Operator Fundamentals]]

[[Category:DarkWorld IRC Staff Training]]
[[Category:DWIRC]]
[[Category:IRC Incident Response]]
[[Category:Staff Documentation]]

DWIRC:Staff Training/Incident Handling

2026-08-08T17:56:35Z

Fizi: Created page with "{{DISPLAYTITLE:Module 8 — Abuse and Incident Handling}} <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 8: Abuse and Incident Handling</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 8 of 10 |- ! Difficulty..."

DWIRC:Staff Training/Moderation

2026-08-08T17:50:43Z

Fizi: Protected "DWIRC:Staff Training/Moderation" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:Module 7 — IRC Moderation}}

<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 7: IRC Moderation</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Program
| DarkWorld IRC Staff Training Program
|-
! Module
| 7 of 10
|-
! Difficulty
| Intermediate
|-
! Estimated study time
| 4–5 hours
|-
! Assessment
| Knowledge check, moderation simulations, and written case analysis
|-
! Prerequisite
| [[DWIRC:Staff Training/User Support|Module 6 — User Support and Communication]]
|}

= Module Overview =

IRC moderation is the controlled use of channel or network authority to stop harmful or disruptive behavior.

Effective moderation is not measured by the number of users warned, kicked, or banned. It is measured by whether staff:

* Protect users and channels.
* Restore normal communication.
* Apply policies consistently.
* Use proportionate action.
* Minimize harm to innocent users.
* Explain important actions clearly.
* Preserve relevant evidence.
* Escalate serious incidents.
* Review temporary restrictions.
* Remain accountable.

This module focuses primarily on channel moderation and the judgment required before using elevated IRC authority.

Network-wide operator enforcement will be covered in:

'''[[DWIRC:Staff Training/IRC Operator Fundamentals|Module 9 — IRC Operator Fundamentals]]'''

= Learning Objectives =

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

# Distinguish channel moderation from network enforcement.
# Determine when staff intervention is appropriate.
# Use warnings, voice restrictions, kicks, and bans proportionately.
# Select a reasonably precise ban mask.
# Handle spam, flooding, harassment, and ban evasion.
# Respond to bots, raids, and relayed abuse.
# Avoid punishing innocent users.
# Preserve evidence before it disappears.
# Write clear moderation reasons.
# Record significant actions.
# Review temporary restrictions.
# Escalate cases outside their authority.

= 1. Purpose of Moderation =

The purpose of moderation is to:

* Stop disruptive behavior.
* Protect users.
* Preserve the purpose of a channel.
* Restore normal conversation.
* Enforce applicable rules.
* Prevent repeated abuse.
* Provide a fair and reviewable response.

Moderation must not be used to:

* Win arguments.
* Silence reasonable criticism.
* Punish someone for disliking staff.
* Promote a staff member’s personal beliefs.
* Favor friends.
* Take over a channel.
* Demonstrate power.
* Retaliate against complaints.
* Bypass an investigation.
* Conceal staff mistakes.

= 2. Channel Authority and Network Authority =

== Channel Authority ==

Channel founders and authorized channel staff normally manage:

* Channel topics.
* Participation rules.
* Voice and operator status.
* Kicks.
* Channel bans.
* Channel access lists.
* Channel bots.
* Channel-specific moderation.

== Network Authority ==

DarkWorld IRC network staff may handle:

* Network-wide policy violations.
* Spam across multiple channels.
* Network advertising and recruitment.
* Severe harassment.
* Ban evasion across channels.
* Attacks against users or infrastructure.
* Malicious bots.
* Services abuse.
* Staff impersonation.
* Unauthorized relays.
* Incidents affecting multiple servers or channels.

A channel operator should not pretend to have network authority.

An IRC operator should not interfere with legitimate channel management without a valid network-level reason.

= 3. When Should Staff Intervene? =

Staff intervention may be appropriate when:

* A network rule is being violated.
* Harm is ongoing.
* A channel requests authorized assistance.
* Normal channel management is unavailable.
* Multiple channels are affected.
* A bot or relay creates network-wide disruption.
* A serious security or safety issue exists.
* Management assigns the matter.

Staff may decide that no action is required when:

* The issue is a minor personal disagreement.
* A legitimate channel rule was enforced.
* Evidence is insufficient.
* The reported conduct is not prohibited.
* The user is asking staff to retaliate.
* The issue belongs to another project.
* The situation has already ended and requires review rather than immediate intervention.

Choosing not to take enforcement action can be the correct professional decision.

= 4. Moderation Decision Framework =

Before acting, ask:

# What conduct is occurring?
# Is it still happening?
# Which rule applies?
# Who is affected?
# What evidence is available?
# Has the user already been warned?
# Is immediate action necessary?
# What is the least severe effective response?
# Could the response affect innocent users?
# Do I have authority?
# Must the action be recorded?
# Does the case require escalation?

During an emergency, staff may need to act quickly. The action should still be reviewed and documented afterward.

= 5. The Moderation Response Ladder =

A general response ladder is:

# No action.
# Guidance or informal correction.
# Formal warning.
# Targeted speak restriction or removal of voice.
# Kick.
# Temporary channel ban.
# Longer channel restriction.
# Escalation for network-level action.
# Permanent action approved through the proper process.

This is a framework, not a mandatory sequence.

Serious incidents may require immediate protective action without a warning, including:

* Active flooding.
* Malware distribution.
* Credential phishing.
* Credible threats.
* Doxxing.
* Coordinated raids.
* Active ban evasion.
* Attacks against network infrastructure.

= 6. Guidance and Informal Correction =

Guidance is appropriate when:

* The violation is minor.
* The user may not understand the rule.
* The conduct caused limited harm.
* The user is cooperative.
* An immediate sanction is unnecessary.

Example:

<pre>
Please stop repeating the same message. It is disrupting the channel.
</pre>

Guidance should not sound like a threat.

= 7. Formal Warnings =

A formal warning should include:

* The conduct that must stop.
* The applicable rule or policy.
* The required corrective action.
* A possible consequence if it continues.
* An official policy link where relevant.

Example:

<pre>
Formal warning: Stop sending unsolicited external-network invitations. This may violate the DarkWorld IRC advertising and recruitment policy. Continued activity may result in further restrictions.
</pre>

A warning is useful only if:

* It reaches the correct user.
* It is understandable.
* The user has a reasonable opportunity to comply.
* It is documented when significant.

A warning may be skipped when delay would permit serious ongoing harm.

= 8. Speak Restrictions and Moderated Mode =

Sometimes it is sufficient to stop a user from speaking without removing them.

Possible options, depending on current server configuration, include:

* Removing voice.
* Applying a targeted quiet or speak restriction.
* Setting the channel to moderated mode.
* Restricting unidentified users from speaking.
* Restricting notices or CTCP messages.

A targeted restriction is usually less disruptive than moderating an entire channel.

Before using `+m`, consider:

* How many legitimate users will be silenced.
* Whether voiced users can continue.
* Whether staff can manage voice requests.
* Whether a targeted restriction is available.
* How long the mode will remain.
* Who will restore normal operation.

= 9. Kicks =

A kick removes a user from a channel but does not necessarily prevent them from returning.

Syntax:

<pre>
/KICK #channel nickname reason
</pre>

Example:

<pre>
/KICK #Training ExampleUser Repeated flooding after warning
</pre>

A kick may be appropriate when:

* The disruptive conduct must stop immediately.
* A warning was ignored.
* The user needs to be removed from the current discussion.
* A channel rule authorizes removal.
* A ban is not yet necessary.

A professional kick reason should be:

* Short.
* Accurate.
* Neutral.
* Related to the conduct.
* Free from insults.
* Free from unnecessary confidential details.

Poor reasons include:

<pre>
Annoying
Go away
Because I said so
Idiot
Staff decision
</pre>

= 10. Channel Bans =

A channel ban normally prevents a matching user from joining or participating.

Add a ban:

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

Remove a ban:

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

View bans:

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

A ban may be appropriate when:

* A kicked user immediately returns and continues.
* The conduct is serious.
* Ban evasion is occurring.
* A bot repeatedly disrupts the channel.
* The user presents an ongoing risk.
* The channel’s established rules support the restriction.

= 11. Choosing a Ban Mask =

A full user mask appears as:

<pre>
nickname!ident@hostname
</pre>

Possible masks include:

{| class="wikitable" style="width:100%;"
! Mask
! General match
! Limitation
|-
| `ExampleNick!*@*`
| Current nickname
| Easy to evade by changing nickname
|-
| `*!example@*`
| Ident
| Idents may be shared or changed
|-
| `*!*@Example.User.DarkWorld.Network`
| Displayed host
| Host may be shared or changed
|-
| `*!*@*.provider.example`
| Wider provider range
| May affect many innocent users
|-
| `*!*@*`
| Everyone
| Normally dangerously broad
|}

Before selecting a mask, consider:

* Registered account.
* Displayed host or cloak.
* Ident.
* Whether the host is shared.
* Whether a bouncer, VPN, gateway, or relay is involved.
* Whether an extended account-based restriction is available.
* Whether the ban is temporary.
* How many innocent users may match.

The goal is the narrowest reliable restriction that stops the harmful conduct.

= 12. Ban Then Kick =

When both a ban and kick are necessary, the normal sequence is:

# Set the ban.
# Kick the user.
# Confirm the ban entry.
# Record the action.
# Review the ban later.

Example:

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

Setting the ban first helps prevent immediate re-entry between commands.

Staff should verify the exact target and mask before sending either command.

= 13. Temporary and Permanent Restrictions =

Most ordinary moderation bans should be reviewable.

A moderation record should identify:

* Whether the restriction is temporary or indefinite.
* When it was applied.
* Why it was applied.
* Who applied it.
* When it should be reviewed.
* Which evidence supports it.
* Whether the user was warned.
* Whether innocent users may be affected.

An indefinite restriction should not mean “set and forgotten.”

Permanent or long-term network restrictions should require appropriate authorization and review.

= 14. Ban Exceptions =

A ban exception may allow a user to bypass a matching channel ban.

View exceptions:

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

Add:

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

Remove:

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

Exceptions can help users affected by a shared-host ban, but they can also make the ban structure difficult to understand.

Where possible, replace an unnecessarily broad ban with a more precise restriction instead of creating many exceptions.

= 15. Spam Moderation =

Spam may include:

* Repeated messages.
* Mass private messages.
* Repeated links.
* Automated promotions.
* Cross-channel advertising.
* Repetitive irrelevant text.
* Messages distributed through multiple accounts.

Response factors include:

* Number of messages.
* Number of recipients.
* Number of channels.
* Whether automation is involved.
* Whether the user was warned.
* Whether the messages contain malicious links.
* Whether the conduct is continuing.

A single accidental repeated message usually does not require the same response as coordinated mass spam.

= 16. Flood Moderation =

Flooding may include:

* Text flooding.
* Join and part flooding.
* Nickname-change flooding.
* CTCP flooding.
* Notice flooding.
* Private-message flooding.
* Repeated formatting.
* Bot-command flooding.

== Single-User Flood ==

Possible response:

# Warn if practical.
# Apply a targeted restriction.
# Kick if necessary.
# Ban if the behavior continues.
# Record repeated or serious conduct.

== Multi-User Raid ==

Possible response:

# Apply emergency channel modes if authorized.
# Preserve evidence.
# Restrict the active sources.
# Avoid uncontrolled broad bans.
# Request assistance.
# Escalate to network operators.
# Restore normal channel modes afterward.
# Document the complete incident.

= 17. Harassment Moderation =

Harassment cases require attention to:

* Repetition.
* Targeting.
* Whether contact is unwanted.
* Attempts to evade blocks or bans.
* Threats.
* Use of multiple accounts.
* Private-message conduct.
* Exposure of personal information.
* Conduct across several channels.

Staff should not require a targeted user to continue engaging with the harasser.

A normal response may include:

* Advising the target to stop responding.
* Helping the target use client ignore features.
* Preserving evidence.
* Applying channel restrictions.
* Escalating repeated or network-wide conduct.
* Taking immediate protective action for threats or doxxing.

Client-side ignore is useful, but it should not be treated as the only response to serious network abuse.

= 18. Ban Evasion =

Possible indicators of ban evasion include:

* Immediate return under a different nickname.
* Repeated conduct from another connection.
* Use of a different account after restriction.
* Admission of evasion.
* Use of a relay, bot, or another user to continue.
* Strongly matching timing and behavior.

However:

* Similar behavior does not prove identity.
* A shared host does not prove identity.
* A VPN exit may be shared.
* A bouncer may host multiple users.
* A relay may display remote users through one bot.

Staff should combine available evidence and escalate broader enforcement decisions.

= 19. Bots and Automated Clients =

Bots may be legitimate, misconfigured, compromised, or malicious.

Before acting, determine:

* What the bot does.
* Who operates it.
* Whether the channel authorized it.
* Whether it is an official or registered service.
* Whether it is a relay.
* Whether it responds to commands from anyone.
* Whether the behavior is accidental.
* Whether other channels are affected.

An actively flooding bot may need immediate removal even if the cause is accidental.

After containment:

# Notify the operator where appropriate.
# Explain what behavior must be corrected.
# Require testing before return where necessary.
# Escalate malicious or repeated behavior.
# Record significant incidents.

= 20. Relay-Related Moderation =

A relay bot may display messages originating from users outside DarkWorld IRC.

Staff should identify:

* The DarkWorld channel.
* Relay bot nickname.
* External network or platform.
* Remote channel.
* Registration or approval status.
* Whether prohibited advertising is being relayed.
* Whether the relay operator can filter the content.
* Whether the abuse comes from one remote user or the relay system generally.

Do not assume the relay bot’s operator personally wrote every relayed message.

However, relay operators remain responsible for compliance and moderation controls.

Unauthorized or non-compliant relays should be handled through the approved relay-compliance process.

= 21. Advertising and Recruitment Moderation =

When possible advertising is observed:

# Preserve the message and context.
# Determine whether it was requested.
# Check frequency and distribution.
# Determine whether it promotes or recruits for an external network or project.
# Check for an applicable approval.
# Compare the conduct with the approved scope.
# Stop ongoing mass abuse where authorized.
# Escalate administrative decisions.
# Document the result.

A normal relevant link in conversation is not automatically the same as repeated unsolicited recruitment.

= 22. Malicious Links and Phishing =

Possible malicious conduct includes:

* Fake NickServ links.
* Fake login pages.
* Credential requests.
* Malware downloads.
* Shortened links designed to conceal a destination.
* Staff impersonation.
* Messages claiming that users must reveal passwords.

If malicious content is active:

# Stop further distribution.
# Preserve the destination safely without encouraging users to open it.
# Warn affected users.
# Do not publicly repeat sensitive tokens or credentials.
# Escalate immediately.
# Identify potentially compromised accounts.
# Record where the content was distributed.

Trainees should not open suspicious files or links on personal or production systems.

= 23. Channel Takeover Situations =

A channel takeover claim may involve:

* A compromised founder account.
* Unauthorized access-list changes.
* A netsplit or Services outage.
* Former staff retaining access.
* An external project dispute.
* A user misunderstanding live operator status.
* Abuse of IRC operator override.

Staff should:

# Preserve current information.
# Avoid irreversible changes.
# Confirm registered ownership.
# Separate live modes from ChanServ access.
# Protect the channel from immediate harm.
# Escalate founder or ownership changes.
# Record every administrative intervention.

A trainee must not resolve a takeover claim by simply giving founder or owner access to the person who complains first.

= 24. Evidence During Moderation =

Relevant evidence may disappear after:

* A user quits.
* A message scrolls away.
* A bot disconnects.
* A channel mode changes.
* Services resynchronize.
* A netsplit ends.

Where practical, preserve:

* Exact messages.
* Timestamps.
* Channel name.
* Nickname and visible mask.
* Registered account information, where authorized.
* Relevant mode changes.
* Kick or ban reasons.
* User warnings.
* Staff actions.
* Relay or bot information.

Do not delay immediate protection solely to collect perfect evidence.

= 25. Moderation Records =

Use a record such as:

<pre>
Case reference:
Date and time:
Channel:
Moderating staff:
User nickname:
Registered account, if relevant:
Visible user mask:
Conduct observed:
Rule or policy:
Warning issued:
Action taken:
Ban or restriction:
Reason:
Duration:
Other users affected:
Evidence location:
Escalated to:
Review date:
Final outcome:
</pre>

Avoid unnecessary personal information.

= 26. Moderation Reasons =

Good reasons describe conduct:

<pre>
Repeated message flooding after warning
Unsolicited advertising across multiple channels
Continued harassment and ban evasion
Malicious link distribution
Unauthorized relay activity pending compliance review
</pre>

Bad reasons attack the person:

<pre>
Bad person
Annoying
Idiot
Nobody likes you
Staff says so
</pre>

Moderate conduct, not personality.

= 27. Correcting Moderation Mistakes =

If staff make a mistake:

# Stop any continuing harm.
# Remove or correct the incorrect restriction.
# Restore affected access where appropriate.
# Inform the affected user honestly.
# Notify senior staff when required.
# Preserve the original action record.
# Add the correction and reason.
# Identify how to prevent recurrence.

Do not delete or falsify records to hide an error.

An appropriate acknowledgement may be:

<pre>
The restriction was applied to an incorrect mask and has now been removed. We apologize for the disruption. The incident record has been corrected and referred for review.
</pre>

= 28. Appeals =

A user may disagree with a moderation decision.

Staff should:

* Explain the available review process.
* Avoid public arguments.
* Preserve the original record.
* Refer the matter to an authorized reviewer.
* Disclose conflicts of interest.
* Avoid retaliating against the appellant.
* Implement the review outcome.
* Correct confirmed errors.

Where independent review is required, the person who took the disputed action should not be the only person deciding the appeal.

= 29. Staff Disagreement During an Incident =

If staff disagree:

# Protect users from immediate harm.
# Avoid arguing publicly.
# Preserve the relevant facts.
# Follow the current incident leader or senior authority.
# Move the disagreement to an approved staff channel.
# Record major conflicting actions.
# Request review after the incident.

Staff must not repeatedly reverse each other’s modes in public while an incident is active.

= 30. Practical Exercises =

These exercises must be performed only in an approved training channel using test identities.

== Exercise 1: Warning ==

Write and deliver a professional warning for repeated text flooding.

The warning must state:

* What must stop.
* Why it is disruptive.
* What may happen if it continues.

== Exercise 2: Kick ==

With trainer authorization:

<pre>
/KICK #ApprovedTrainingChannel TestUser Repeated flooding after warning
</pre>

The trainer should assess the accuracy and professionalism of the reason.

== Exercise 3: Ban and Removal ==

Using a trainer-provided test identity:

# Inspect the visible user mask.
# Select a precise mask.
# Add the ban.
# Confirm the ban list.
# Kick the test user.
# Remove the exact ban.
# Verify removal.
# Record the exercise.

== Exercise 4: Shared Host ==

The trainer provides three test users sharing a host.

The candidate must propose a restriction targeting only the disruptive identity, using currently supported methods.

No broad ban should be applied without trainer approval.

== Exercise 5: Channel Raid ==

The trainer simulates several flooding users.

The candidate must:

* Identify the raid.
* Apply approved temporary modes.
* Request assistance.
* Preserve evidence.
* Restore the original modes.
* Complete an incident record.

== Exercise 6: Appeal ==

The candidate receives a simulated complaint about their own ban.

They must:

* Avoid arguing.
* Explain the review process.
* Preserve the record.
* Disclose their involvement.
* Refer the decision appropriately.

= 31. Practical Scenarios =

== Scenario 1: First Minor Flood ==

A normally cooperative user accidentally pastes several lines rapidly and immediately apologizes.

'''Recommended response:'''

Guidance may be sufficient. Consider context, harm, and cooperation before using a sanction.

== Scenario 2: Repeated Flood After Warning ==

A user continues flooding after a clear warning.

'''Recommended response:'''

A kick or targeted temporary restriction may be proportionate. Apply a ban if needed to prevent immediate return and continued disruption.

== Scenario 3: Shared VPN Address ==

One abusive user and several innocent users appear through the same VPN host.

'''Recommended response:'''

Do not automatically ban the entire host. Consider account-based or more precise restrictions and escalate if network-level action is needed.

== Scenario 4: Coordinated Raid ==

Twenty new connections join and flood several official channels.

'''Recommended response:'''

Apply authorized emergency protection, request network-operator assistance, preserve evidence, and treat it as a network incident rather than an ordinary single-channel violation.

== Scenario 5: Critical Staff User ==

A user respectfully criticizes a staff decision without flooding or harassment.

'''Recommended response:'''

Do not punish the user for criticism. Direct them to the review process if appropriate.

== Scenario 6: Relay Advertisement ==

An approved relay repeatedly imports invitations to an external network.

'''Recommended response:'''

Contain ongoing disruption if necessary, record the relayed content, notify the relay operator, and escalate through relay compliance. Existing approval does not authorize policy violations.

== Scenario 7: Staff Friend ==

A friend of a staff member repeatedly violates channel rules, and the staff member asks others to ignore it.

'''Recommended response:'''

Apply policy neutrally, document the conflict, and escalate interference or favoritism.

== Scenario 8: Incorrect Ban ==

A ban intended for one user removes several legitimate users.

'''Recommended response:'''

Correct the restriction promptly, restore affected access, acknowledge the error, record the correction, and select a more precise method.

= 32. Knowledge Check =

Answer the following questions in your own words:

# What is the purpose of IRC moderation?
# What must moderation never be used for?
# What is the difference between channel and network authority?
# When may no staff action be the correct decision?
# What questions should be asked before moderating?
# What is the moderation response ladder?
# When may a warning reasonably be skipped?
# What should a formal warning contain?
# When might a targeted speak restriction be preferable to `+m`?
# What is the purpose of a kick?
# Does a kick prevent a user from returning?
# When may a channel ban be appropriate?
# Why should a ban be set before a kick when both are needed?
# What factors determine a suitable ban mask?
# Why are broad provider bans risky?
# What information should a temporary ban record contain?
# What is a ban exception?
# How does single-user flooding differ from a coordinated raid?
# Why is client-side ignore not always sufficient for serious harassment?
# What evidence may indicate ban evasion?
# Why does a shared VPN or bouncer host not prove identity?
# How should a malfunctioning bot be handled?
# What information should be collected about an abusive relay?
# How should possible advertising be evaluated?
# What should staff do about active phishing?
# Why must channel-takeover claims be escalated?
# What evidence should be preserved during moderation?
# What makes a good moderation reason?
# What should staff do after applying an incorrect restriction?
# How should an appeal be handled?
# What should staff do when they disagree during an active incident?
# Why must temporary emergency modes be reviewed?

= 33. Written Assignment =

Write approximately '''800–1,100 words''' analyzing this incident:

<blockquote>
During a busy event in an official DarkWorld channel, ten new users join within one minute. Four begin flooding repeated advertisements for another IRC network. Two use the same VPN hostname as three legitimate users already in the channel. An approved relay also begins importing similar advertisements. A channel operator sets `+m`, bans the entire VPN host, kicks all newly joined users, and leaves the channel without recording the actions.
</blockquote>

Your analysis must explain:

* Which behavior required immediate intervention.
* Whether `+m` was proportionate.
* Why the broad VPN ban requires review.
* Why all newly joined users should not automatically be treated as attackers.
* How the relay should be handled.
* What evidence should be preserved.
* Which actions belong to channel moderation.
* Which issues require network or compliance escalation.
* How innocent users should be restored.
* What should be documented.
* When emergency modes should be removed.
* How the operator’s actions should be reviewed.

= 34. Module Completion Requirements =

To complete this module, the candidate must:

* Read the complete lesson.
* Complete all six practical exercises.
* Correctly answer at least '''24 of the 32''' knowledge-check questions.
* Complete the written assignment.
* Demonstrate accurate warning, kick, and ban procedures.
* Correctly restore all training modes and bans.
* Complete an acceptable moderation record.
* Pass the raid and appeal simulations.
* Receive trainer approval.

= 35. Trainer Evaluation =

{| class="wikitable" style="width:100%;"
! Evaluation area
! Maximum points
|-
| Moderation judgment
| 20
|-
| Warnings and communication
| 10
|-
| Kick and ban accuracy
| 15
|-
| Ban-mask precision
| 15
|-
| Flood and raid response
| 15
|-
| Evidence and documentation
| 10
|-
| Appeals and accountability
| 10
|-
| Authority boundaries
| 5
|-
! Total
! 100
|}

Recommended passing score: '''75 points'''.

A candidate should not pass if they:

* Use moderation for personal retaliation.
* Repeatedly apply dangerously broad restrictions.
* Cannot restore their own mode changes.
* Ignore harm to innocent users.
* Falsify or conceal actions.
* Punish users for legitimate complaints.
* Refuse required escalation.
* Use elevated commands without authorization.

= 36. Quick Moderation Checklist =

<pre>
1. What behavior is occurring?
2. Is the behavior still active?
3. Which rule applies?
4. What evidence is available?
5. Who is affected?
6. Was a warning given or reasonably skipped?
7. What is the smallest effective action?
8. Could innocent users be affected?
9. Do I have authority?
10. Is network-level assistance required?
11. What must be documented?
12. When will the restriction be reviewed?
13. Who will restore temporary modes?
14. Is an independent review required?
</pre>

= 37. Next Module =

After passing this module, continue to:

'''[[DWIRC:Staff Training/Incident Handling|Module 8 — Abuse and Incident Handling]]'''

----

'''Previous:''' [[DWIRC:Staff Training/User Support|Module 6 — User Support and Communication]]
'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
'''Next:''' [[DWIRC:Staff Training/Incident Handling|Module 8 — Abuse and Incident Handling]]

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

DWIRC:Staff Training/Moderation

2026-08-08T17:50:34Z

Fizi: Created page with "{{DISPLAYTITLE:Module 7 — IRC Moderation}} <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 7: IRC Moderation</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 7 of 10 |- ! Difficulty | Intermediate |- ! Estima..."

DWIRC:Staff Training/User Support

2026-08-08T17:44:44Z

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

{{DISPLAYTITLE:Module 6 — User Support and Communication}}

<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 6: User Support and Communication</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Program
| DarkWorld IRC Staff Training Program
|-
! Module
| 6 of 10
|-
! Difficulty
| Intermediate
|-
! Estimated study time
| 3–4 hours
|-
! Assessment
| Knowledge check, roleplay, and support-case exercises
|-
! Prerequisite
| [[DWIRC:Staff Training/IRC Services|Module 5 — IRC Services]]
|}

= Module Overview =

User support is one of the most important responsibilities of DarkWorld IRC staff.

A staff member may understand IRC commands and policies but still be unsuitable for support if they cannot communicate patiently, clearly, neutrally, and securely.

This module teaches candidates how to:

* Receive and understand support requests.
* Ask effective diagnostic questions.
* Provide clear instructions.
* Protect passwords and private information.
* Assist inexperienced users.
* Handle angry or frustrated users.
* De-escalate disagreements.
* Recognize project boundaries.
* Escalate unresolved or high-risk cases.
* Record support activity appropriately.

The purpose of support is to help the user reach a safe and correct outcome—not merely to send commands or close the conversation quickly.

= Learning Objectives =

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

# Greet and assist users professionally.
# Identify the user’s actual problem.
# Ask focused diagnostic questions.
# Provide one clear troubleshooting step at a time.
# Avoid requesting passwords or unnecessary private information.
# Explain technical concepts in accessible language.
# Recognize when a request belongs to another DarkWorld project.
# Handle complaints and frustration without escalating conflict.
# Distinguish support cases from abuse reports.
# Recognize emergencies and security incidents.
# Escalate cases with a useful summary.
# Confirm that a problem is resolved before closing the case.

= 1. Purpose of User Support =

DarkWorld IRC support should help users:

* Connect securely.
* Register and authenticate accounts.
* Configure SASL.
* Recover nicknames through approved procedures.
* Register and manage channels.
* Understand channel and user modes.
* Find official policies.
* Report abuse safely.
* Resolve ordinary IRC client problems.
* Locate the correct DarkWorld project team.
* Understand network notices and errors.
* Use official resources.

Support staff should also help the network by:

* Identifying recurring problems.
* Reporting outdated documentation.
* Recognizing widespread service failures.
* Detecting phishing and impersonation.
* Directing policy cases correctly.
* Preventing unsafe advice from spreading.
* Recording unresolved incidents.

= 2. Official Support Channels =

DarkWorld IRC may use channels such as:

{| class="wikitable" style="width:100%;"
! Channel
! General purpose
|-
| `#Help`
| IRC connection, accounts, channels, Services, and network help
|-
| `#Support`
| Support relating to applicable DarkWorld services or projects
|-
| `#Abuse`
| Abuse reports and policy-related concerns
|-
| `#DarkWorld`
| General network and community discussion
|}

Restricted staff channels may be used for escalation and coordination.

Staff must not move private evidence into a public channel merely because the conversation began there.

= 3. The Support Workflow =

Use the following process:

# '''Acknowledge''' the user.
# '''Understand''' what they are trying to do.
# '''Collect''' only the necessary information.
# '''Classify''' the issue.
# '''Provide''' a safe troubleshooting step.
# '''Confirm''' the result.
# '''Continue or escalate''' as required.
# '''Summarize''' the outcome.
# '''Document''' the case where necessary.

== Step 1: Acknowledge ==

A simple acknowledgement tells the user that someone is listening.

Examples:

<pre>
Hello. I can help you check that.
Please provide the exact error message you receive.
I understand the issue. Let us check your connection settings first.
</pre>

Avoid:

<pre>
What?
It works for me.
You configured it wrong.
Read the website.
That is not my problem.
</pre>

== Step 2: Understand the Goal ==

Ask what the user is trying to accomplish.

For example:

<pre>
Are you trying to register a new account or identify to an existing one?
Are you unable to connect to IRC, or can you connect but not join the channel?
Are you asking about a channel ban or a network-wide restriction?
</pre>

Solving the wrong problem wastes time and may create additional risk.

== Step 3: Collect Necessary Information ==

Useful information may include:

* IRC client and version.
* Device or operating system.
* Server address.
* Port.
* Whether TLS is enabled.
* Exact error message.
* Nickname or registered account.
* Relevant channel.
* Approximate time.
* What changed before the problem began.
* Troubleshooting already attempted.

Do not collect private information merely because it might be interesting.

== Step 4: Classify the Issue ==

Common categories include:

* Connection problem.
* TLS or certificate problem.
* SASL or NickServ problem.
* Channel access problem.
* Services problem.
* Channel-management issue.
* Policy question.
* Abuse report.
* Project-specific request.
* Network incident.
* Security emergency.

== Step 5: Provide a Safe Step ==

Give one or a small number of clear steps.

Example:

<pre>
Please confirm that the server is irc.darkworld.network, the port is 6697, and TLS is enabled. Do not disable certificate verification. Tell me the exact error after trying again.
</pre>

Avoid sending a large block of unrelated commands before identifying the problem.

== Step 6: Confirm the Result ==

Ask:

<pre>
Did the connection complete successfully?
Does WHOIS now show your registered account?
Can you join the channel after identifying?
What exact response does NickServ give now?
</pre>

== Step 7: Escalate When Required ==

Escalate when:

* The issue is outside your authority.
* Normal troubleshooting has failed.
* Multiple users are affected.
* A security problem may exist.
* Administrative Services action is required.
* A policy decision is disputed.
* Confidential evidence must be reviewed.
* The action could affect many users.
* You are uncertain and a wrong action could cause harm.

= 4. Clear Communication =

Good support communication should be:

* Clear.
* Respectful.
* Short enough to follow.
* Accurate.
* Relevant.
* Secure.
* Free from unnecessary jargon.
* Appropriate to the user’s experience.

== Use Plain Language ==

Instead of:

<pre>
Your SASL PLAIN negotiation failed during CAP authentication.
</pre>

Try:

<pre>
Your client could not authenticate your registered account while connecting. Let us check the saved account name, password, and SASL settings.
</pre>

Technical details may be added when they help the user understand or troubleshoot the issue.

== Give Commands Separately ==

Prefer:

<pre>
Open a private NickServ window and enter:

/MSG NickServ INFO YourAccount
</pre>

Avoid placing several password-sensitive commands into a public-channel message.

== Explain Expected Results ==

Do not only provide a command. Explain what should happen.

Example:

<pre>
Run /WHOIS YourNickname. In the response, look for a line showing that you are logged into your registered account. Do not paste any private connection information publicly.
</pre>

= 5. Supporting New IRC Users =

New users may not understand:

* What a nickname is.
* How channels work.
* Why a nickname is already in use.
* The difference between IRC and a website.
* How to send a command.
* What NickServ is.
* Why TLS matters.
* How to open a private query.
* Why they must identify.
* How SASL works.

Staff should not embarrass users for lacking this knowledge.

A helpful sequence is:

# Confirm their IRC client.
# Help them connect securely.
# Help them choose a nickname.
# Explain channels and private messages.
# Direct them to official NickServ help.
# Help them register privately.
# Explain email confirmation.
# Help configure SASL.
# Help them join official channels.
# Point them to current documentation.

= 6. Asking Good Diagnostic Questions =

Good questions are specific and easy to answer.

Examples:

<pre>
What exact error appears when you connect?
Which IRC client are you using?
Are you connecting to irc.darkworld.network on port 6697?
Is TLS enabled?
Does the problem happen before or after you join the network?
What does NickServ say after you identify?
Are you identified to the same account that has channel access?
Does this affect only one channel?
Approximately when did the problem begin?
</pre>

Avoid vague or accusatory questions:

<pre>
Why did you break it?
What did you do?
Are you sure you know how IRC works?
Why did you forget your password?
</pre>

= 7. One Change at a Time =

When practical, ask the user to make one meaningful change and report the result.

This helps identify the cause.

For example:

# Confirm the server and port.
# Attempt the connection.
# Record the exact error.
# Verify the device time if TLS fails.
# Check SASL only after the secure connection succeeds.

If several settings are changed simultaneously, it becomes difficult to know which change solved or worsened the problem.

= 8. Password and Credential Safety =

Staff must never ask users to provide:

* NickServ passwords.
* SASL passwords.
* Email passwords.
* Confirmation codes.
* Password-reset codes.
* Two-factor secrets.
* IRC operator passwords.
* API tokens.
* Server credentials.
* Private keys.

If a user posts a credential publicly:

# Do not repeat or quote it.
# Tell the user to change or revoke it immediately.
# Explain which saved clients or services must be updated.
# Limit further exposure where authorized.
# Escalate if an account or system may be compromised.
# Document the security incident appropriately.

<div style="background:#fdecec; border-left:4px solid #dc2626; padding:12px; margin:15px 0;">
'''Staff reminder:''' A legitimate DarkWorld staff member does not need a user’s password to provide account-support instructions.
</div>

= 9. Public and Private Support =

== Suitable for Public Support ==

Public channels may be used for:

* General connection settings.
* Public commands.
* Links to official documentation.
* Non-sensitive client instructions.
* General explanations of policy.
* Service-status information approved for publication.

== Move to an Approved Private Process ==

Use an approved private method for:

* Account ownership evidence.
* Private-message abuse logs.
* IP or hostname information.
* Email-account details.
* Security vulnerabilities.
* Staff complaints.
* Compromised accounts.
* Confidential project applications.
* Sensitive relay or advertising evidence.

A private message is not automatically an approved permanent evidence system. Important evidence may still need to be transferred to an authorized case record.

= 10. Handling Frustrated or Angry Users =

Users may be upset because:

* They cannot connect.
* They lost account access.
* They were banned.
* They believe staff treated them unfairly.
* They have repeated the same problem.
* They do not understand the instructions.
* They feel ignored.
* The issue affects an important event or project.

Staff should:

* Remain calm.
* Acknowledge the inconvenience.
* Focus on verifiable facts.
* Avoid matching the user’s tone.
* Explain what can and cannot be done.
* Give a clear next step.
* Set boundaries if abuse continues.
* Escalate serious complaints appropriately.

Example:

<pre>
I understand that losing access before your event is frustrating. I cannot change channel ownership without verification, but I can collect the required information and escalate it to the Services team.
</pre>

Avoid:

<pre>
Calm down.
Stop complaining.
I am staff, so do what I say.
If you continue asking, I will ban you.
</pre>

= 11. De-escalation =

De-escalation means reducing conflict while still enforcing necessary boundaries.

Useful techniques include:

* Use the person’s current nickname respectfully.
* Acknowledge the concern without automatically agreeing.
* State verified facts.
* Avoid blame-focused language.
* Give clear choices.
* Explain the next step.
* Avoid arguing about unrelated issues.
* Move sensitive discussion away from public channels.
* Request help from another staff member when needed.

Example:

<pre>
I understand that you disagree with the ban. I will not debate private evidence in the public channel. Please provide the channel, approximate time, and ban reason so the authorized team can review it.
</pre>

De-escalation does not require staff to tolerate threats, flooding, or continued abuse.

= 12. Language and Accessibility =

DarkWorld is an international community. Users may:

* Speak English as a second language.
* Use translation tools.
* Have difficulty with technical terminology.
* Use a mobile client.
* Have visual or other accessibility needs.
* Require additional time to follow steps.

Staff should:

* Use short sentences.
* Avoid unnecessary slang.
* Avoid mocking spelling or grammar.
* Give commands in copyable form.
* Explain one step at a time.
* Confirm understanding.
* Use screenshots only when text instructions are insufficient.
* Provide official translated material where available.
* Request help from another staff member if language prevents accurate support.

= 13. Cultural and Personal Neutrality =

Staff must not discriminate based on:

* Nationality.
* Race or ethnicity.
* Religion.
* Gender.
* Disability.
* Sexual orientation.
* Language.
* Age.
* Political views.
* Social or economic status.
* Technical ability.

Personal disagreement does not justify denying support.

Staff may enforce applicable channel or network rules neutrally without endorsing a user’s beliefs.

= 14. Project Boundaries =

Not every question in `#Support` belongs to DWIRC staff.

Examples:

{| class="wikitable" style="width:100%;"
! Request
! Appropriate destination
|-
| Cannot connect to IRC
| DWIRC support
|-
| NickServ account problem
| DWIRC support or Services staff
|-
| Channel ban appeal
| Channel management or authorized DWIRC review
|-
| Increase shell disk quota
| DWShells staff
|-
| Create or modify ZNC account
| DWBouncers staff
|-
| Game-server issue
| Relevant game or DWGames staff
|-
| Advertising application status
| Policy team
|-
| Relay registration status
| Relay team
|-
| Website account problem
| Relevant website or project administrator
|}

A DWIRC staff member may help identify the correct team but must not make unauthorized changes in another project.

= 15. Support vs Abuse Reports =

A support request asks for help using the network.

An abuse report alleges harmful or prohibited conduct.

Some cases contain both.

Example:

<blockquote>
A user cannot join a channel because another person is repeatedly evading bans and taking their nickname.
</blockquote>

The connection or nickname aspect may be support, while the evasion and impersonation aspect may require an abuse investigation.

Support staff should:

# Help with the immediate safe issue.
# Preserve relevant information.
# Avoid conducting an unauthorized investigation.
# Move sensitive evidence to the approved process.
# Escalate the abuse component.

= 16. Support vs Policy Decisions =

Support staff may explain public policy, but not every support staff member is authorized to:

* Approve advertising.
* Register a relay.
* Decide a complex policy appeal.
* Suspend an approved project.
* Revoke a verified presence.
* Change an account owner.
* Impose a permanent network sanction.

A useful response is:

<pre>
I can explain the policy and help you locate the application status. The final decision must be made by the authorized policy team.
</pre>

= 17. Handling Staff Complaints =

A user may report misconduct by a staff member.

The receiving staff member should:

# Remain neutral.
# Avoid defending or condemning the staff member immediately.
# Identify the action being reported.
# Preserve the relevant information.
# Protect the complainant from retaliation.
# Avoid discussing private staff matters publicly.
# Escalate to an appropriate senior or independent reviewer.
# Record the complaint through the approved process.
# Inform the user of the next available step.

A staff complaint must not be sent solely to the person being accused when independent review is required.

Criticism of staff is not automatically a policy violation.

= 18. Recognizing Network-Wide Problems =

A report may indicate a wider incident when:

* Multiple users cannot connect.
* Many users report SASL failures.
* NickServ and ChanServ are unavailable.
* Users on one server disconnect together.
* Several channels report the same flood.
* Certificate warnings affect multiple users.
* Server links repeatedly fail.
* Network latency becomes widespread.
* Many users receive similar phishing messages.

When this occurs:

# Record the approximate start time.
# Identify the affected server or service.
# Determine whether multiple users are affected.
# Notify authorized operational staff.
# Avoid telling every user to change unrelated settings.
# Provide an approved status message.
# Confirm when service is restored.

= 19. Security Emergencies =

Escalate immediately when support reveals:

* A compromised staff account.
* Services impersonation.
* Credential phishing.
* A serious vulnerability.
* A leaked password or token.
* A network attack.
* Widespread malicious activity.
* Unauthorized administrative access.
* Exposure of private user information.
* Threats involving immediate danger.

Do not investigate high-risk systems beyond your authorization.

Preserve essential information and notify the correct senior staff.

= 20. Giving Safe Commands =

Before giving a command:

# Confirm that it matches the current Services or server version.
# Confirm the target nickname or channel.
# Explain what the command will do.
# Identify whether it is reversible.
# Warn about any destructive effect.
# Keep credentials out of the example.
# Confirm that the user has authority.
# Use official help where possible.

Do not provide destructive commands casually, such as commands that:

* Drop a channel.
* Delete an account.
* Clear access lists.
* Remove all bans.
* Change channel ownership.
* Expose a channel key.
* Disable security.
* Disconnect many users.

= 21. Handling Unknown Problems =

Staff are not expected to know everything.

When uncertain:

<pre>
I am not certain which setting is causing this. I will summarize what we have checked and escalate it to the appropriate team.
</pre>

This is better than guessing.

A useful escalation summary prevents the next staff member from repeating every troubleshooting step.

= 22. Escalation Summary Template =

<pre>
Date and time:
Support channel:
User nickname:
Registered account, if relevant:
Affected service or channel:
User’s goal:
Exact error:
Client and version:
Server and port:
TLS enabled:
SASL enabled:
When the problem started:
Steps already attempted:
Results:
Number of affected users:
Security or privacy concern:
Evidence location:
Recommended next team:
</pre>

Do not include passwords, tokens, private keys, or unnecessary personal information.

= 23. Closing a Support Case =

Before closing, confirm:

* Whether the original problem was resolved.
* Which action solved it.
* Whether the user understands the result.
* Whether any security follow-up is required.
* Whether saved passwords or configurations need updating.
* Whether the case must be documented.
* Whether documentation should be improved.

Example:

<pre>
Your connection is now using TLS on port 6697, and WHOIS confirms that SASL authenticated your account. Please update the same saved password on any other IRC clients or bouncers you use.
</pre>

If unresolved:

<pre>
We confirmed that the issue affects multiple users and is not limited to your client. It has been escalated to the network operations team with the relevant time and error details.
</pre>

= 24. Support Documentation =

A recurring issue should be documented when:

* Many users report it.
* The solution is not obvious.
* Existing instructions are outdated.
* A client uses unusual settings.
* A new Services behavior affects users.
* Staff repeatedly give inconsistent answers.
* A safe recovery process needs clarification.

Documentation should include:

* Problem symptoms.
* Supported environments.
* Safe diagnostic steps.
* Expected results.
* Known limitations.
* Escalation conditions.
* Last verification date.

Passwords, tokens, private logs, and confidential system details must not be included.

= 25. Example Support Conversations =

== Example 1: Connection Failure ==

'''User:'''

<pre>
I cannot connect. IRC is not working.
</pre>

'''Staff:'''

<pre>
Hello. Which IRC client are you using, and what exact error appears? Please also confirm that the server is irc.darkworld.network, the port is 6697, and TLS is enabled.
</pre>

== Example 2: SASL Failure ==

'''User:'''

<pre>
SASL authentication failed.
</pre>

'''Staff:'''

<pre>
Please confirm privately in your client that the SASL username is your registered NickServ account, not necessarily your current nickname. Also confirm that TLS is enabled and that the account has completed email confirmation. Do not post your password here.
</pre>

== Example 3: Channel Access ==

'''User:'''

<pre>
ChanServ did not give me operator status.
</pre>

'''Staff:'''

<pre>
Please identify to your registered account and run WHOIS on your nickname. Confirm which account is shown and the channel involved. We can then check whether the issue concerns your ChanServ access or only the current live channel mode.
</pre>

== Example 4: Project Request ==

'''User:'''

<pre>
Increase my DWShells account storage.
</pre>

'''Staff:'''

<pre>
That request belongs to the DWShells team rather than DWIRC staff. I can direct you to the approved DWShells support channel or request process.
</pre>

== Example 5: Ban Complaint ==

'''User:'''

<pre>
Your staff are corrupt. Remove my ban now.
</pre>

'''Staff:'''

<pre>
I can help you request a review. Please provide the affected channel, approximate time, nickname used, and the ban reason. Private evidence should be submitted through the approved process rather than posted publicly.
</pre>

= 26. Common Support Mistakes =

== Providing Too Many Steps ==

The user receives a large block of commands and cannot determine which one matters.

== Asking for Credentials ==

Staff request a password when only the error message is required.

== Assuming User Error ==

A wider Services or server outage is incorrectly blamed on the user.

== Giving Outdated Commands ==

Commands are copied from another network or Anope version without checking current help.

== Solving the Wrong Project’s Issue ==

DWIRC staff attempt to modify DWShells or DWBouncers resources without authority.

== Arguing Publicly ==

A support discussion becomes a personal conflict.

== Promising an Outcome ==

A trainee promises that an account, channel, or approval will be granted.

== Closing Too Early ==

The staff member gives a command but never confirms whether it worked.

= 27. Practical Exercises =

== Exercise 1: New User Assistance ==

Guide a trainer acting as a new user through:

* Connecting to `irc.darkworld.network`.
* Using port `6697`.
* Enabling TLS.
* Choosing a nickname.
* Joining an approved channel.
* Finding NickServ help.

Do not ask for or handle the user’s password.

== Exercise 2: SASL Troubleshooting ==

The trainer will provide a simulated SASL error.

The candidate must:

# Ask for the exact error.
# Confirm TLS.
# Confirm the account-name field.
# Confirm account registration.
# Identify saved-password problems.
# Escalate if the issue affects multiple users.

== Exercise 3: Channel Access Problem ==

A simulated user is identified but does not receive channel operator status.

The candidate must distinguish between:

* Current nickname.
* Registered account.
* ChanServ access.
* Live channel status.
* Mode lock.
* Possible Services outage.

== Exercise 4: Angry User ==

The trainer acts as an angry user disputing a ban.

The candidate must:

* Remain calm.
* Avoid arguing.
* Collect relevant details.
* Explain the review process.
* Protect private evidence.
* Avoid promising removal.

== Exercise 5: Project Boundary ==

The trainer requests a DWShells or DWBouncers administrative action.

The candidate must direct the request to the correct team without claiming authority.

== Exercise 6: Escalation Summary ==

Using one of the simulated cases, prepare a complete escalation summary without including sensitive credentials.

= 28. Practical Scenarios =

== Scenario 1: New User Posts Password ==

A new user includes their NickServ password while asking why authentication failed.

'''Recommended response:'''

Do not quote the password. Tell the user to change it immediately, update saved SASL credentials, and follow the approved compromised-account procedure if necessary.

== Scenario 2: Widespread Certificate Error ==

Five users report the same TLS certificate error.

'''Recommended response:'''

Treat it as a possible network-side issue. Record the hostname, error, and time; notify operations; and do not advise users to disable certificate verification.

== Scenario 3: Repeated Question ==

A user asks the same question several times because they do not understand the answer.

'''Recommended response:'''

Rephrase the instruction in simpler language, provide one step at a time, and confirm the result after each step.

== Scenario 4: Staff Complaint ==

A user says an IRC operator banned them after a personal argument.

'''Recommended response:'''

Preserve the report, avoid prejudging either side, and escalate it for independent review. Do not send the complaint only to the accused operator.

== Scenario 5: Unknown Client ==

A user uses an IRC client the staff member has never seen.

'''Recommended response:'''

Ask for the client name, version, available connection fields, and exact error. Use protocol-level settings and official client documentation rather than guessing.

== Scenario 6: Multiple Project Issue ==

A user can connect to IRC but their DWBouncers account no longer connects automatically.

'''Recommended response:'''

Confirm that DWIRC itself is reachable, then direct the bouncer-specific account or configuration issue to authorized DWBouncers support.

= 29. Knowledge Check =

Answer the following questions in your own words:

# What is the primary goal of user support?
# What are the main stages of the support workflow?
# Why should staff first understand the user’s goal?
# What information is useful for an IRC connection problem?
# What information should never be requested publicly?
# Why should troubleshooting normally proceed one step at a time?
# What makes a support response easy to follow?
# How should staff explain technical terminology to beginners?
# What should staff do if a user posts a password?
# Is a private message automatically a suitable permanent evidence system?
# How should staff respond to an angry user?
# What is de-escalation?
# Does acknowledging frustration mean agreeing with every claim?
# How should language barriers be handled?
# Can personal disagreement justify denying support?
# Why must DWIRC staff respect other project boundaries?
# What is the difference between support and an abuse investigation?
# May ordinary support staff approve advertising or relay applications?
# How should a staff complaint be handled?
# What signs may indicate a network-wide problem?
# When must a security matter be escalated immediately?
# What should staff verify before providing a sensitive command?
# Why is guessing dangerous in support?
# What information belongs in an escalation summary?
# What must be excluded from an escalation summary?
# What should be confirmed before closing a case?
# When should recurring problems be documented?
# Why should staff avoid promising a particular administrative outcome?
# What should happen if an issue remains unresolved?
# How should a candidate respond after giving incorrect guidance?

= 30. Written Assignment =

Write approximately '''700–1,000 words''' responding to this case:

<blockquote>
A new user cannot connect to DarkWorld IRC. They say their client shows a certificate warning and SASL failure. They publicly paste their account password while asking for help. At the same time, three other users report the same certificate warning. The user becomes angry and accuses staff of ignoring them.
</blockquote>

Your answer must explain:

* How to acknowledge the user.
* What immediate password-security action is required.
* Which diagnostic questions should be asked.
* Why certificate verification should not simply be disabled.
* Why multiple reports change the incident classification.
* How to handle the user’s frustration.
* What must be escalated.
* What information should be recorded.
* What information must not be repeated.
* How the case should be closed or handed over.

= 31. Module Completion Requirements =

To complete this module, the candidate must:

* Read the complete lesson.
* Complete all six practical exercises.
* Correctly answer at least '''23 of the 30''' knowledge-check questions.
* Complete the written assignment.
* Pass the angry-user roleplay.
* Demonstrate safe credential handling.
* Prepare an acceptable escalation summary.
* Receive trainer approval.

= 32. Trainer Evaluation =

{| class="wikitable" style="width:100%;"
! Evaluation area
! Maximum points
|-
| Understanding the user’s problem
| 15
|-
| Diagnostic questioning
| 15
|-
| Accuracy of guidance
| 15
|-
| Communication and clarity
| 15
|-
| De-escalation and professionalism
| 15
|-
| Privacy and credential security
| 15
|-
| Escalation and documentation
| 10
|-
! Total
! 100
|}

Recommended passing score: '''75 points'''.

A candidate should not pass if they:

* Request or expose credentials.
* Insult or threaten users.
* Repeatedly provide unsafe instructions.
* Ignore project boundaries.
* Hide mistakes.
* Fail to escalate serious security issues.
* Use support access for retaliation.

= 33. Quick Support Checklist =

<pre>
1. What is the user trying to do?
2. What exact error occurred?
3. Which client, server, and port are involved?
4. Is TLS enabled and verified?
5. Is the issue limited to one user?
6. Is any password or private information exposed?
7. Does this belong to DWIRC or another project?
8. What is the safest next step?
9. Do I have authority to handle it?
10. Does it require escalation?
11. Has the result been confirmed?
12. Does the case require documentation?
</pre>

= 34. Next Module =

After passing this module, continue to:

'''[[DWIRC:Staff Training/Moderation|Module 7 — IRC Moderation]]'''

----

'''Previous:''' [[DWIRC:Staff Training/IRC Services|Module 5 — IRC Services]]
'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
'''Next:''' [[DWIRC:Staff Training/Moderation|Module 7 — IRC Moderation]]

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

DWIRC:Staff Training/User Support

2026-08-08T17:44:31Z

Fizi: Created page with "{{DISPLAYTITLE:Module 6 — User Support and Communication}} <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 6: User Support and Communication</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 6 of 10 |- ! Diffi..."

DWIRC:Staff Training/IRC Services

2026-08-08T17:39:43Z

Fizi: Protected "DWIRC:Staff Training/IRC Services" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:Module 5 — IRC Services}}

<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 5: IRC Services</span>
</div>

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

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

= Learning Objectives =

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

# Explain the purpose of IRC Services.
# Distinguish a nickname from a registered account.
# Help a user register and identify securely.
# Explain SASL authentication.
# Use NickServ information commands safely.
# Explain ChanServ channel registration and access.
# Distinguish channel status from persistent Services access.
# Understand HostServ and virtual hosts.
# Recognize common account and channel problems.
# Protect passwords and recovery information.
# Identify requests requiring Services Administrator escalation.
# 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:

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

<pre>
/MSG ServiceName COMMAND parameters
</pre>

Example:

<pre>
/MSG NickServ HELP
</pre>

Many clients also support aliases such as:

<pre>
/NS HELP
/CS HELP
/HS HELP
/MS HELP
/BS HELP
/OS HELP
</pre>

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:

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

= 3. Nicknames and Registered Accounts =

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

Example:

{| class="wikitable"
! 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:

<pre>
/MSG NickServ HELP
</pre>

Help for a specific command:

<pre>
/MSG NickServ HELP REGISTER
/MSG NickServ HELP IDENTIFY
/MSG NickServ HELP INFO
</pre>

Candidates should use current Services help before instructing a user.

= 5. Registering a NickServ Account =

The normal registration syntax may resemble:

<pre>
/MSG NickServ REGISTER password email@example.com
</pre>

The exact syntax must be confirmed with:

<pre>
/MSG NickServ HELP REGISTER
</pre>

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:

<pre>
/MSG NickServ IDENTIFY account password
</pre>

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

<pre>
/MSG NickServ IDENTIFY password
</pre>

The current syntax should be checked:

<pre>
/MSG NickServ HELP IDENTIFY
</pre>

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

{| class="wikitable"
! 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:

# The account name.
# Whether the account is confirmed.
# Whether TLS is enabled.
# The selected SASL mechanism.
# Whether the client saved an old password.
# The exact server error.
# 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:

<pre>
/MSG NickServ INFO nickname
</pre>

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:

<pre>
/MSG NickServ STATUS nickname
</pre>

Current availability and status meanings must be confirmed through:

<pre>
/MSG NickServ HELP STATUS
</pre>

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:

<pre>
/MSG NickServ HELP SET
</pre>

Then request help for the specific option.

Example:

<pre>
/MSG NickServ HELP SET PASSWORD
</pre>

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:

<pre>
/MSG NickServ RECOVER nickname
/MSG NickServ RELEASE nickname
/MSG NickServ GHOST nickname
</pre>

Availability and parameters must be verified:

<pre>
/MSG NickServ HELP RECOVER
/MSG NickServ HELP RELEASE
/MSG NickServ HELP GHOST
</pre>

== Recovery Procedure ==

Staff should ask the user to:

# Connect with a temporary nickname.
# Authenticate to the correct account through SASL or NickServ.
# Check the nickname’s account information.
# Use the supported recovery command.
# Change to the recovered nickname.
# Review other connected clients or bouncers.
# 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:

<pre>
/MSG NickServ HELP GROUP
</pre>

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:

<pre>
/MSG ChanServ HELP
</pre>

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:

<pre>
/MSG ChanServ HELP REGISTER
</pre>

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:

# Confirm they are identified.
# Confirm the exact channel name.
# Check whether the channel is already registered.
# Check the exact ChanServ response.
# Check applicable registration requirements.
# Avoid overriding existing ownership.
# Escalate disputes or restricted channels.

= 17. ChanServ INFO =

To view channel registration information:

<pre>
/MSG ChanServ INFO #channel
</pre>

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:

<pre>
/MSG ChanServ HELP ACCESS
</pre>

Depending on configuration, access may use:

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

Common operations may include:

<pre>
/MSG ChanServ ACCESS #channel LIST
/MSG ChanServ ACCESS #channel ADD account level
/MSG ChanServ ACCESS #channel DEL account
</pre>

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:

# The exact channel.
# The exact account.
# The requested privilege.
# The requester’s authority.
# Whether the access is temporary or permanent.
# 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:

<pre>
/MSG ChanServ HELP SET MLOCK
</pre>

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:

<pre>
/MSG ChanServ HELP AKICK
</pre>

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:

<pre>
/MSG ChanServ HELP OP
/MSG ChanServ HELP DEOP
/MSG ChanServ HELP VOICE
/MSG ChanServ HELP DEVOICE
</pre>

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

# Preserve the current state.
# Avoid making irreversible changes.
# Identify the registered founder account.
# Collect relevant dates and records.
# Separate channel ownership from external project ownership.
# Check applicable channel-registration policy.
# Disclose any staff conflict of interest.
# Escalate to authorized Services management.
# 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:

<pre>
User.DarkWorld.Network
</pre>

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

Common user help:

<pre>
/MSG HostServ HELP
/MSG HostServ HELP ON
/MSG HostServ HELP OFF
/MSG HostServ HELP REQUEST
</pre>

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:

<pre>
/MSG MemoServ HELP
</pre>

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:

<pre>
/MSG BotServ HELP
</pre>

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.

<div style="background:#fdecec; border-left:4px solid #dc2626; padding:12px; margin:15px 0;">
'''Restricted area:''' OperServ commands are not part of ordinary candidate training. Knowledge of a command does not authorize its use.
</div>

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:

<pre>
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:
</pre>

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:

# Do not advise everyone to reset passwords.
# Check whether Services are connected.
# Record the approximate start time.
# Notify authorized operational staff.
# Reassure users without making unsupported promises.
# Avoid permanent access changes during unstable synchronization.
# 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:

<pre>
/MSG NickServ HELP
/MSG NickServ HELP INFO
/MSG ChanServ HELP
/MSG ChanServ HELP INFO
/MSG HostServ HELP
</pre>

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

== Exercise 2: Account Verification ==

Using your own account:

# Run WHOIS on your nickname.
# Run NickServ INFO on your nickname.
# Identify the current nickname.
# Identify the registered account.
# 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:

<pre>
/MSG ChanServ INFO #ApprovedTrainingChannel
</pre>

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:

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

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:

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

= 36. Written Assignment =

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

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

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 =

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

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

'''[[DWIRC:Staff Training/User Support|Module 6 — User Support and Communication]]'''

----

'''Previous:''' [[DWIRC:Staff Training/User and Channel Modes|Module 4 — User and Channel Modes]]
'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
'''Next:''' [[DWIRC:Staff Training/User Support|Module 6 — User Support and Communication]]

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

DWIRC:Staff Training/IRC Services

2026-08-08T17:39:30Z

Fizi: Created page with "{{DISPLAYTITLE:Module 5 — IRC Services}} <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 5: IRC Services</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 5 of 10 |- ! Difficulty | Intermediate |- ! Estimated..."

DWIRC:Staff Training/User and Channel Modes

2026-08-08T17:35:26Z

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

DWIRC:Staff Training/User and Channel Modes

2026-08-08T17:34:33Z

Fizi: 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..."

DWIRC:Staff Training/Policies

2026-08-08T17:29:16Z

Fizi: Protected "DWIRC:Staff Training/Policies" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:Module 3 — DarkWorld IRC Rules and Policies}}

<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 3: DarkWorld IRC Rules and Policies</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Program
| DarkWorld IRC Staff Training Program
|-
! Module
| 3 of 10
|-
! Difficulty
| Intermediate
|-
! Estimated study time
| 3–4 hours
|-
! Assessment
| Policy examination, case studies, and written assignment
|-
! Prerequisite
| [[DWIRC:Staff Training/IRC Fundamentals|Module 2 — IRC Fundamentals]]
|}

= Module Overview =

This module teaches candidates how to understand, explain, and apply DarkWorld IRC rules and policies.

Staff members must not enforce rules based on personal preference, rumors, incomplete messages, or assumptions. Every enforcement decision should be based on:

* An applicable network policy.
* Sufficient and reliable evidence.
* The context of the incident.
* The severity and impact of the conduct.
* The user’s previous relevant history, where authorized.
* The least severe effective response.
* Proper documentation and escalation.

This lesson provides an operational framework. The current official policy pages remain authoritative.

<div style="background:#fff8e1; border-left:4px solid #f59e0b; padding:12px; margin:15px 0;">
'''Important:''' If this training material conflicts with a current official policy, the current official policy takes precedence. Report outdated training material to the documentation or policy team.
</div>

= Learning Objectives =

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

# Identify official sources of DarkWorld IRC policy.
# Distinguish network rules from channel rules.
# Identify advertising, invitation, and recruitment violations.
# Explain the relay and bridge registration requirement.
# Understand registered-project and verified-presence concepts.
# Recognize spam, flooding, harassment, impersonation, and ban evasion.
# Handle evidence without exposing private information.
# Apply proportionate enforcement.
# Explain when warnings are appropriate.
# Recognize cases requiring immediate escalation.
# Document important policy actions.
# Separate verified facts from allegations and assumptions.

= 1. Sources of Policy =

DarkWorld IRC policy information may be published through:

* [https://doc.darkworld.network/ DarkWorld IRC Documentation]
* Official policy pages
* The DarkWorld Wiki
* Network rules and guidelines
* Official network notices
* PolicyServ
* RelayServ
* Authorized staff procedures
* Instructions issued by authorized network management

Staff should verify that they are using the current policy before taking significant action.

== PolicyServ ==

PolicyServ may provide links or summaries for official policy information.

For example:

<pre>
!policy advertising
</pre>

Public channels should generally receive concise official links rather than lengthy internal policy discussions.

Detailed application records, evidence, investigation history, or administrative actions belong in approved restricted systems or staff channels.

== Conflicting or Outdated Information ==

If two official pages appear to conflict:

# Do not guess which one applies.
# Check the publication or revision information.
# Ask the policy team or authorized management.
# Follow the confirmed current policy.
# Report the outdated page for correction.
# Record the interpretation if it affects an active case.

= 2. Network Rules and Channel Rules =

Candidates must distinguish between:

* '''Network-wide rules''', enforced by DarkWorld IRC staff.
* '''Channel-specific rules''', normally enforced by channel management.

== Network-Wide Rules ==

Network-wide rules apply across DarkWorld IRC.

They may address:

* Network abuse.
* Malicious activity.
* Prohibited advertising or recruitment.
* Unauthorized relays.
* Severe harassment.
* Threats.
* Spam and flooding.
* Ban evasion.
* Staff impersonation.
* Services abuse.
* Attacks against users or infrastructure.
* Privacy violations.
* Other conduct affecting the network as a whole.

== Channel-Specific Rules ==

Channel owners may establish additional rules, such as:

* Language requirements.
* Topic restrictions.
* No excessive formatting.
* No spoilers.
* No off-topic discussion.
* Participation requirements.
* Rules for bots or games.

A violation of a channel rule does not automatically require network-level punishment.

Network staff should generally respect legitimate channel autonomy unless:

* A network policy is violated.
* Serious abuse is occurring.
* A channel is being used to attack the network or its users.
* Channel management requests authorized assistance.
* The channel’s conduct creates a wider network risk.
* Management directs intervention.

= 3. Policy Decision Framework =

Before taking action, staff should answer:

# '''What happened?'''
# '''Where did it happen?'''
# '''Who was involved?'''
# '''Which policy may apply?'''
# '''What evidence is available?'''
# '''Is the evidence complete and reliable?'''
# '''Is immediate intervention necessary?'''
# '''What is the least severe effective action?'''
# '''Does the case require escalation?'''
# '''What must be documented?'''

A candidate should be able to explain both the action taken and the reason it was proportionate.

= 4. Facts, Allegations, and Inferences =

== Verified Fact ==

A fact is information supported by reliable evidence.

Example:

<blockquote>
The logs show that the user posted the same external-network invitation in five channels within two minutes.
</blockquote>

== Allegation ==

An allegation is a claim that has not yet been verified.

Example:

<blockquote>
A user says that another person threatened them in a private message, but no evidence has yet been reviewed.
</blockquote>

== Inference ==

An inference is a conclusion drawn from available information.

Example:

<blockquote>
Several connections share similar behavior and timing, so staff suspect they may be controlled by the same person.
</blockquote>

An inference may help guide an investigation, but it should not be presented as a confirmed fact without sufficient evidence.

Staff reports should clearly separate:

* What was directly observed.
* What was reported by others.
* What staff reasonably inferred.
* What remains unknown.

= 5. Advertising Policy =

DarkWorld IRC maintains rules concerning advertising, invitations, and recruitment.

The purpose of the policy is not to prevent every mention of another website, community, project, or service. Its purpose is to prevent misuse of DarkWorld IRC for unauthorized promotion or recruitment.

Possible advertising conduct includes:

* Repeatedly promoting another IRC network.
* Posting invitations to external channels or communities.
* Soliciting DarkWorld users to leave for another network.
* Mass-messaging users with promotional content.
* Using bots to distribute advertisements.
* Joining channels primarily to promote a service.
* Disguising promotional messages as support or conversation.
* Recruiting users or staff for an external network or project.
* Circumventing an earlier advertising restriction.

== Context Matters ==

The following are not automatically equivalent:

* A normal conversational mention.
* Answering a direct question.
* Providing a relevant support link.
* A channel owner promoting their approved project in its own channel.
* Repeated unsolicited promotion.
* Mass private-message advertising.
* Recruitment for a competing IRC network.
* A registered and approved advertisement.

Staff must examine purpose, frequency, audience, consent, and policy status.

== Advertising Approval System ==

Where advertising requires approval, the normal process is:

# The applicant reviews the official policy.
# The applicant submits an advertising request.
# Authorized staff review the request.
# The request receives an official status.
# Approved advertising must remain within the approved scope.
# Violations or changed circumstances may result in suspension or revocation.

Possible administrative statuses may include:

{| class="wikitable"
! Status
! General meaning
|-
| '''PENDING'''
| The request is awaiting review.
|-
| '''APPROVED'''
| The request has been approved within its stated conditions.
|-
| '''REJECTED'''
| The request was not approved.
|-
| '''SUSPENDED'''
| Approval has been temporarily disabled.
|-
| '''REVOKED'''
| Approval has been withdrawn.
|-
| '''EXPIRED'''
| The approval is no longer current.
|}

A trainee must not approve, reject, suspend, or revoke an advertising request unless specifically authorized.

== Advertising Response Procedure ==

When possible advertising is reported:

# Preserve the relevant message and context.
# Determine where and how often it was sent.
# Determine whether it was solicited.
# Check whether approval exists.
# Compare the conduct with the approved scope.
# Stop ongoing mass abuse if immediate action is authorized.
# Escalate unclear or administrative cases.
# Document the decision.

= 6. Invitations and Recruitment =

An invitation may become a policy matter when it is used to:

* Move users to another IRC network.
* Recruit staff for an external service.
* Repeatedly redirect users away from DarkWorld.
* Target multiple users through private messages.
* Evade channel rules or advertising restrictions.
* Exploit a DarkWorld channel, relay, or project presence for recruitment.

A single mention is not automatically the same as a coordinated recruitment campaign.

Staff should consider:

* Was the message requested?
* Was it sent publicly or privately?
* How many users received it?
* Was it repeated?
* Was the sender warned previously?
* Was the invitation commercial, competitive, malicious, or harmless?
* Is there an approved project or advertising arrangement?
* Did the conduct disrupt the network or a channel?

= 7. Relay and Bridge Policy =

Relays and bridges allow communication between DarkWorld IRC and an external network, platform, channel, or community.

They may be useful for communication, but they create additional policy and moderation risks.

DarkWorld IRC requires applicable relays and bridges to follow the official relay policy and registration process.

== General Relay Principles ==

A relay or bridge should:

* Be registered or approved where required.
* Identify its purpose accurately.
* Identify the DarkWorld channel involved.
* Identify the relay bot.
* Identify the external network or platform.
* Follow DarkWorld IRC policies.
* Avoid importing prohibited advertising.
* Avoid importing recruitment messages.
* Allow responsible moderation.
* Cooperate with compliance reviews.

== Relay Operators’ Responsibilities ==

Relay operators are responsible for:

* Filtering prohibited external advertisements.
* Preventing recruitment through the relay.
* Responding to compliance notices.
* Maintaining accurate registration information.
* Ensuring the relay does not evade channel or network restrictions.
* Cooperating with DarkWorld IRC staff.
* Suspending or correcting problematic relay behavior when required.

== Possible Relay Statuses ==

{| class="wikitable"
! Status
! General meaning
|-
| '''PENDING'''
| Application awaiting review.
|-
| '''APPROVED'''
| Relay approved under stated conditions.
|-
| '''REJECTED'''
| Relay application not approved.
|-
| '''SUSPENDED'''
| Relay approval temporarily suspended.
|-
| '''VIOLATION'''
| A compliance violation has been recorded.
|-
| '''REMOVED'''
| Relay authorization has been removed.
|}

== Unregistered Relays ==

When an apparent unregistered relay is discovered:

# Verify that it is actually relaying external content.
# Identify the channel and relay bot.
# Avoid accusing users without evidence.
# Check the registration system.
# Record the discovery through the authorized process.
# Notify the relay operator where appropriate.
# Provide the policy and registration information.
# Apply restrictions only through authorized procedures.
# Escalate non-compliance.

Trainees must not independently approve or permanently remove relays.

= 8. Registered Projects and Verified Presence =

DarkWorld IRC may allow DarkWorld projects and eligible external projects to establish an official or verified presence.

A verified presence helps users identify:

* The official project channel.
* Authorized project representatives.
* The project’s approved identity.
* Relevant support resources.
* Whether the project has completed the required review.

Verification does not mean that DarkWorld IRC:

* Owns the external project.
* Guarantees every product or service.
* Accepts responsibility for external transactions.
* Grants unlimited advertising rights.
* Exempts the project from IRC policies.
* Gives project staff network-level authority.

Project staff must still follow DarkWorld IRC rules.

Suspected misuse of a verified identity should be documented and escalated to the appropriate project or policy team.

= 9. Spam =

Spam generally involves unsolicited, repetitive, disruptive, automated, or mass-distributed content.

Examples include:

* Repeating the same message rapidly.
* Sending the same private message to many users.
* Posting unwanted links across many channels.
* Using multiple accounts to repeat a message.
* Automated promotional messages.
* Repeated irrelevant content intended to disrupt discussion.

Staff should consider:

* Frequency.
* Number of recipients.
* Message content.
* Whether the messages were requested.
* Whether automation was involved.
* Whether the conduct stopped after a warning.
* Whether multiple identities were used.

= 10. Flooding =

Flooding is excessive activity that disrupts a channel, user, server, or network.

Possible forms include:

* Message flooding.
* Join and part flooding.
* Nickname-change flooding.
* CTCP flooding.
* Notice flooding.
* Private-message flooding.
* Connection flooding.
* Command flooding.
* Formatting or control-code flooding.

== Immediate Flood Response ==

Depending on authority and severity:

# Protect the affected channel or users.
# Apply an appropriate temporary restriction.
# Avoid unnecessarily broad bans.
# Preserve timestamps and relevant logs.
# Determine whether one or multiple sources are involved.
# Notify senior staff if the network or multiple channels are affected.
# Review the restriction after the incident.
# Document significant actions.

Network-wide connection floods and attacks must be escalated immediately to operational staff.

= 11. Harassment and Threats =

Harassment may include:

* Repeated unwanted contact.
* Targeted abusive messages.
* Coordinated intimidation.
* Threats.
* Stalking across channels.
* Repeatedly evading blocks or bans to contact someone.
* Publishing private information.
* Targeting a person through multiple accounts or relays.

Staff should consider:

* Severity.
* Repetition.
* Credibility of threats.
* Whether the target requested no further contact.
* Whether the conduct crosses multiple channels.
* Whether private information is involved.
* Whether immediate safety concerns exist.

== Threats and Immediate Risk ==

Credible threats, doxxing, compromised accounts, or immediate risks must be escalated promptly.

Staff must not promise outcomes beyond DarkWorld’s authority. Network staff can take appropriate IRC action but are not law enforcement or emergency services.

= 12. Impersonation =

Impersonation occurs when a person intentionally attempts to deceive others into believing they are:

* A DarkWorld staff member.
* Another user.
* An authorized project representative.
* An official service or bot.
* A verified organization or account.

Similar nicknames alone do not always prove impersonation.

Evidence may include:

* False claims of authority.
* Attempts to obtain passwords.
* Copying identity details.
* Using a deceptive nickname.
* Giving fraudulent instructions.
* Pretending to represent an official project.
* Repeated behavior after being corrected.

Possible phishing or credential theft must be treated as a serious security issue.

= 13. Ban Evasion =

Ban evasion occurs when a restricted user deliberately returns or changes identity to bypass an active restriction.

Possible indicators include:

* Rejoining immediately with another nickname.
* Using multiple accounts after a restriction.
* Repeating the same conduct from a different connection.
* Admitting to evasion.
* Using bots, relays, proxies, or other users to bypass restrictions.

Shared hosts, VPNs, bouncers, gateways, or similar behavior do not alone prove that two users are the same person.

Staff should rely on sufficient evidence and authorized information before applying broader restrictions.

= 14. Bots, Automation, and Malicious Activity =

Bots may be permitted for legitimate purposes, including:

* Channel management.
* Games.
* Statistics.
* Relays.
* Support.
* Project services.
* Information delivery.

A bot may become a policy problem when it:

* Floods users or channels.
* Sends unsolicited advertisements.
* Impersonates an official service.
* Collects information deceptively.
* Evades restrictions.
* Distributes malware.
* Coordinates abuse.
* Uses excessive connections.
* Ignores authorized compliance instructions.

Staff should distinguish a malfunctioning bot from intentionally malicious activity. Immediate containment may still be necessary in either case.

= 15. Privacy and Personal Information =

Staff may encounter:

* IP addresses.
* Hostnames.
* Email addresses.
* Account information.
* Private logs.
* Authentication information.
* Abuse reports.
* Staff discussions.
* Project application records.
* Security information.

This information must be accessed and shared only for authorized purposes.

Staff must not:

* Publicly reveal hidden IP addresses.
* Share private logs unnecessarily.
* Request passwords.
* Copy confidential reports into public channels.
* Search user information out of curiosity.
* Retain personal information without a valid purpose.
* Share staff discussions with unauthorized users.
* Use private information for retaliation or personal advantage.

= 16. Evidence Handling =

Useful evidence may include:

* Complete message context.
* Accurate timestamps.
* Channel name.
* Nickname and visible user mask.
* Registered account information, where authorized.
* Relevant server or Services logs.
* Screenshots.
* Reports from affected users.
* Previous related incidents.
* Relay or advertising registration records.

== Evidence Quality ==

Good evidence should be:

* Relevant.
* Authentic.
* Complete enough to understand.
* Time-stamped where possible.
* Collected lawfully and according to policy.
* Shared only with authorized people.

Screenshots can help, but editable images or partial captures may omit important context. Where possible, compare them with server, client, bot, or Services logs.

== Evidence Preservation Rules ==

# Preserve the original material where possible.
# Do not edit evidence to change its meaning.
# Avoid reposting sensitive material.
# Record who provided the evidence.
# Separate facts from interpretations.
# Restrict access appropriately.
# Follow retention and deletion requirements.
# Escalate evidence involving serious security issues.

= 17. Proportionate Enforcement =

The response should be proportionate to:

* The severity of the conduct.
* The immediate risk.
* The number of users affected.
* Whether the conduct was intentional.
* Whether it continued after a warning.
* Relevant previous violations.
* The likelihood of recurrence.
* The effect of the proposed action on innocent users.

Possible responses may include:

# No staff action.
# Guidance.
# Informal correction.
# Formal warning.
# Channel-level moderation.
# Temporary restriction.
# Escalation for network-level action.
# Suspension of an approval.
# Permanent action authorized by senior staff.

Not every violation requires every step. Severe or ongoing incidents may require immediate protective action.

= 18. Warnings =

A useful warning should state:

* What conduct must stop.
* Which rule or policy applies.
* What corrective action is required.
* What may happen if the conduct continues.
* Where the user can find the official policy.

Example:

<pre>
Please stop sending unsolicited network invitations. This conduct may violate the DarkWorld IRC advertising and recruitment policy. Review the official policy at the provided documentation link. Continued violations may be escalated for further action.
</pre>

Warnings must be:

* Clear.
* Professional.
* Specific.
* Free from insults or threats.
* Documented when significant.

Staff should not claim that a warning was issued if it was not successfully delivered.

= 19. Enforcement Reasons =

Enforcement reasons should be factual and understandable.

Good examples:

<pre>
Repeated channel flooding after warning
Unsolicited advertising across multiple channels
Ban evasion following temporary channel restriction
Unauthorized relay continued after compliance notice
Staff impersonation and attempted credential collection
</pre>

Poor examples:

<pre>
Annoying
Bad user
You know what you did
Because staff said so
Go away
</pre>

A reason should not reveal unnecessary private or security-sensitive information.

= 20. Appeals and Complaints =

Users should be able to request review through the approved process.

When receiving an appeal:

# Remain neutral.
# Confirm which action is being appealed.
# Obtain the relevant time, channel, and reason.
# Preserve the original enforcement record.
# Avoid arguing with the user.
# Do not review your own disputed action alone where independent review is required.
# Forward the matter to authorized staff.
# Record the review outcome.
# Correct mistakes when found.

Criticizing or appealing a staff decision is not automatically abuse.

Retaliation against a user for submitting a complaint is prohibited.

= 21. Staff Conflicts of Interest =

A conflict may exist when the staff member:

* Is personally involved in the dispute.
* Has a close relationship with one party.
* Operates a competing project.
* Previously argued with the reported user.
* May personally benefit from the decision.
* Has already made public statements prejudging the case.

When a meaningful conflict exists, the staff member should:

# Protect users from immediate harm if necessary.
# Preserve relevant evidence.
# Disclose the conflict internally.
# Transfer the decision to another authorized staff member.
# Avoid influencing the review improperly.

= 22. Policy Incident Report =

Use the following format:

<pre>
Case reference:
Date and time:
Reporting staff member:
Channel or location:
Users involved:
Relevant accounts:
Policy involved:
Summary of incident:
Directly observed facts:
Information reported by others:
Evidence preserved:
Immediate action taken:
Reason for action:
Users or channels affected:
Warning issued:
Escalated to:
Current status:
Recommended follow-up:
</pre>

Do not place passwords, private keys, tokens, or unnecessary personal information in an incident report.

= 23. Practical Scenarios =

== Scenario 1: Normal Mention ==

A user asks where they can find documentation for a third-party IRC client. Another user provides a relevant official link once.

'''Recommended analysis:'''

This is not automatically prohibited advertising. Consider the context, relevance, and absence of unsolicited promotion.

== Scenario 2: Repeated Recruitment ==

A user sends private messages to several DarkWorld users inviting them to join another IRC network and become staff there.

'''Recommended analysis:'''

Preserve evidence, determine the scope, check the advertising and recruitment policy, stop ongoing abuse if authorized, and escalate for appropriate action.

== Scenario 3: Approved Advertisement Exceeds Scope ==

A project has approval to announce one event in its official channel but posts the advertisement repeatedly across unrelated channels.

'''Recommended analysis:'''

Approval is limited by its conditions. Record the conduct, verify the approval scope, stop ongoing disruption where authorized, and escalate for review or suspension.

== Scenario 4: Unregistered Relay ==

A bot is relaying messages from another network into a DarkWorld channel, but no registration can be found.

'''Recommended analysis:'''

Verify that it is a relay, identify the channel and operator, record the discovery, provide registration information, and follow the relay-compliance procedure. Do not independently approve or permanently remove it.

== Scenario 5: Shared Host ==

A banned user and an unrelated user appear from the same shared provider host.

'''Recommended analysis:'''

Do not assume they are the same person. Review account information, behavior, timing, and other authorized evidence before widening the restriction.

== Scenario 6: Staff Dispute ==

A staff member is personally involved in an argument and asks you to ban the other user.

'''Recommended analysis:'''

Address any immediate safety issue, preserve evidence, disclose the conflict, and refer the enforcement decision to a neutral authorized staff member.

== Scenario 7: Private Threat Report ==

A user reports a serious threat received by private message but asks staff not to post the logs publicly.

'''Recommended analysis:'''

Protect confidentiality, preserve the evidence through the approved process, assess urgency, and escalate immediately where the threat may be credible.

== Scenario 8: Channel Ban Appeal ==

A user demands that network staff reverse a channel ban imposed for repeatedly disrupting a privately managed channel.

'''Recommended analysis:'''

Determine whether a network policy or serious abuse issue is involved. Ordinary channel-management decisions generally remain with the channel’s management.

= 24. Knowledge Check =

Answer the following questions in your own words:

# Which sources should staff use to verify current policy?
# What should happen if training material conflicts with a current policy?
# What is the difference between a network rule and a channel rule?
# When may network staff intervene in a channel matter?
# What is the difference between a fact, allegation, and inference?
# Is every mention of another project automatically advertising?
# What factors help distinguish conversation from prohibited promotion?
# May a trainee approve an advertising application?
# What responsibilities do relay operators have?
# What should staff do when discovering an apparent unregistered relay?
# Does verified presence guarantee an external project’s services?
# What is spam?
# Name four forms of flooding.
# Why does a shared host not prove that users are the same person?
# What evidence may indicate impersonation?
# What should staff consider before applying a broad ban?
# What makes evidence reliable and useful?
# What is proportionate enforcement?
# When might an immediate restriction be necessary?
# What should a professional warning contain?
# Why should staff actions include clear reasons?
# How should an appeal be handled?
# What is a staff conflict of interest?
# Why should staff distinguish observed facts from reported claims?
# What information must never be placed in an incident report?

= 25. Written Assignment =

Prepare a policy analysis of approximately '''600–900 words''' for the following incident:

<blockquote>
A bot joins three DarkWorld channels and begins relaying messages from an external IRC network. Some relayed messages invite DarkWorld users to join the external network. The bot operator says the relay is harmless and that a channel operator gave permission. No relay registration can be located. One trainee wants to immediately ban the bot from the entire network.
</blockquote>

Your analysis must explain:

* Which policies may apply.
* What facts have been established.
* What information remains unknown.
* Whether channel permission is sufficient.
* What evidence should be preserved.
* What immediate action may be proportionate.
* Whether a network-wide ban is justified.
* Who should receive the escalation.
* What should be documented.
* How the bot operator should be informed.

= 26. Module Completion Requirements =

To complete this module, the candidate must:

* Read the full lesson.
* Review the current official policy pages.
* Correctly answer at least '''19 of the 25''' knowledge-check questions.
* Complete the written policy assignment.
* Complete all assigned case studies.
* Demonstrate safe evidence handling.
* Demonstrate proportionate decision-making.
* Receive trainer approval.

= 27. Trainer Evaluation =

{| class="wikitable" style="width:100%;"
! Evaluation area
! Maximum points
|-
| Understanding of policy sources
| 10
|-
| Advertising and recruitment policy
| 15
|-
| Relay and project compliance
| 15
|-
| Abuse and conduct policies
| 15
|-
| Evidence handling
| 15
|-
| Proportionate enforcement
| 15
|-
| Judgment and escalation
| 15
|-
! Total
! 100
|}

Recommended passing score: '''75 points'''.

The candidate must not pass if they demonstrate serious disregard for privacy, evidence integrity, conflicts of interest, or authority boundaries.

= 28. Quick Policy Checklist =

Before taking significant action, ask:

<pre>
1. What exactly happened?
2. Which current policy applies?
3. What did I directly observe?
4. What was reported by someone else?
5. Is the evidence reliable and complete?
6. Is anyone currently at risk?
7. Do I have authority to act?
8. What is the least severe effective response?
9. Could innocent users be affected?
10. Who must be notified?
11. What must be documented?
12. Does the action require independent review?
</pre>

= 29. Next Module =

After passing this module, continue to:

'''[[DWIRC:Staff Training/User and Channel Modes|Module 4 — User and Channel Modes]]'''

----

'''Previous:''' [[DWIRC:Staff Training/IRC Fundamentals|Module 2 — IRC Fundamentals]]
'''Program:''' [[DWIRC:Staff Training Program|DarkWorld IRC Staff Training Program]]
'''Next:''' [[DWIRC:Staff Training/User and Channel Modes|Module 4 — User and Channel Modes]]

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

DWIRC:Staff Training/Policies

2026-08-08T17:29:07Z

Fizi: Created page with "{{DISPLAYTITLE:Module 3 — DarkWorld IRC Rules and Policies}} <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 3: DarkWorld IRC Rules and Policies</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 3 of 10 |- ! D..."

DWIRC:Staff Training/IRC Fundamentals

2026-08-08T17:25:05Z

Fizi: Protected "DWIRC:Staff Training/IRC Fundamentals" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:Module 2 — IRC Fundamentals}}

<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 2: IRC Fundamentals</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Program
| DarkWorld IRC Staff Training Program
|-
! Module
| 2 of 10
|-
! Difficulty
| Beginner
|-
! Estimated study time
| 2–3 hours
|-
! Assessment
| Knowledge check and practical IRC exercises
|-
! Prerequisite
| [[DWIRC:Staff Training/Network Introduction|Module 1 — DarkWorld IRC Network Introduction]]
|}

= Module Overview =

This module teaches the fundamental concepts and commands required to use and understand the DarkWorld IRC Network.

Before a candidate can assist users or perform moderation duties, they must understand:

* How IRC works.
* The difference between an IRC network and an IRC server.
* How users connect securely.
* Nicknames, usernames, idents, hostnames, and account names.
* Channels and private conversations.
* IRC user masks.
* Common IRC commands.
* TLS and SASL.
* Lag, disconnections, reconnections, and netsplits.
* How to collect useful information without violating user privacy.

Commands may appear differently depending on the IRC client. The underlying IRC functions remain generally the same.

= Learning Objectives =

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

# Explain how an IRC network operates.
# Connect securely to DarkWorld IRC.
# Explain the difference between a nickname and a Services account.
# Identify the components of an IRC user mask.
# Use common IRC commands correctly.
# Obtain relevant information using WHOIS and related commands.
# Explain the purpose of TLS and SASL.
# Recognize lag, a normal disconnection, and a netsplit.
# Distinguish between channel messages, private messages, and notices.
# Collect troubleshooting information without exposing confidential data.

= 1. What Is IRC? =

'''Internet Relay Chat''', commonly called '''IRC''', is a real-time communication system.

Users connect through an IRC client to an IRC server. Multiple linked IRC servers together form an IRC network.

Users can then:

* Join public or private channels.
* Send channel messages.
* Send private messages.
* Register nicknames.
* Register and manage channels.
* Participate in project communities.
* Request support.
* Use approved bots and services.

IRC is not a website. Although web-based IRC clients may exist, IRC itself is a separate communication protocol.

= 2. IRC Network, Server, Client, and Services =

== IRC Network ==

An '''IRC network''' is a group of connected IRC servers that share users, channels, and messages.

DarkWorld IRC is the network.

== IRC Server ==

An '''IRC server''' accepts user connections and communicates with other servers on the network.

A user normally connects through the main network address instead of selecting an individual server.

The standard DarkWorld IRC connection address is:

<pre>
irc.darkworld.network
</pre>

== IRC Client ==

An '''IRC client''' is the application used to connect to IRC.

Examples may include:

* DWIRC
* HexChat
* mIRC
* WeeChat
* irssi
* KiwiIRC
* The Lounge
* Revolution IRC
* Other compatible IRC applications

Staff should avoid insisting that every user use the same client. Assistance should focus on the required settings and protocol behavior.

== IRC Services ==

'''IRC Services''' provide persistent account and channel-management features.

Examples include:

* NickServ
* ChanServ
* MemoServ
* HostServ
* BotServ
* OperServ

Services are connected to the IRC network, but they are not ordinary users.

= 3. Connecting to DarkWorld IRC =

The recommended public connection settings are:

{| class="wikitable"
! Setting
! Recommended value
|-
| Network
| DarkWorld IRC
|-
| Server
| irc.darkworld.network
|-
| Port
| 6697
|-
| Encryption
| TLS/SSL enabled
|-
| Accept invalid certificates
| No
|-
| SASL
| Recommended for registered accounts
|}

A typical URI may appear as:

<pre>
ircs://irc.darkworld.network:6697
</pre>

The `ircs://` prefix indicates an encrypted IRC connection.

<div style="background:#fff8e1; border-left:4px solid #f59e0b; padding:12px; margin:15px 0;">
'''Security notice:''' Staff should direct users to the current secure connection settings. Do not recommend an unencrypted port merely to bypass a TLS or certificate problem. Investigate or escalate the underlying problem.
</div>

== Connection Example ==

In clients that support the `/SERVER` command:

<pre>
/SERVER irc.darkworld.network 6697
</pre>

The client must also be configured to use TLS. The exact syntax varies between clients.

== Information to Request During Connection Troubleshooting ==

When a user cannot connect, ask for:

* IRC client name and version.
* Server address.
* Port number.
* Whether TLS is enabled.
* The exact error message.
* Approximate time of the attempt.
* Whether the problem affects one device or multiple devices.
* Whether another network connection was tested.

Do not ask users to publicly post:

* Account passwords.
* SASL passwords.
* Private keys.
* Authentication tokens.
* Full configuration files containing secrets.
* Unnecessarily exposed IP addresses.

= 4. TLS =

'''Transport Layer Security''', or '''TLS''', encrypts the connection between the IRC client and the IRC server.

TLS helps protect:

* Passwords.
* SASL authentication.
* Private messages while travelling between the client and server.
* Channel messages while travelling between the client and server.
* Account and connection information.

TLS does not make public channel messages private. Anyone present in a public channel may read and log its messages.

TLS also does not guarantee that another IRC user will keep a private conversation confidential.

== Certificate Warnings ==

A certificate warning may indicate:

* An incorrect server name.
* An expired certificate.
* A certificate-name mismatch.
* An incomplete certificate chain.
* A local system clock problem.
* A network interception problem.
* An actual server-side configuration problem.

Staff should not automatically tell users to disable certificate verification.

The correct procedure is:

# Record the exact warning.
# Confirm the server hostname.
# Confirm the device date and time.
# Check whether other users are affected.
# Escalate possible server certificate problems.
# Use a temporary alternative only when authorized.

= 5. Nicknames, Usernames, Idents, and Real Names =

An IRC identity contains several separate elements.

== Nickname ==

The '''nickname''' is the visible name used on IRC.

Example:

<pre>
Falcon
</pre>

A nickname can normally be changed:

<pre>
/NICK NewNickname
</pre>

A nickname is not necessarily registered and is not always proof of identity.

== Username or Ident ==

The '''username''', commonly called the '''ident''', is another part of the IRC connection identity.

Example:

<pre>
falcon
</pre>

The ident is different from the nickname.

== Hostname ==

The '''hostname''' identifies the connection’s host information. Networks may hide the original host using cloaks or virtual hosts.

Example:

<pre>
user.example.host
</pre>

IRC staff must not expose a user’s hidden address or confidential host information without an authorized operational reason.

== Real Name or GECOS ==

The '''real name''' field is a user-configurable description sent during connection.

It may contain a real name, nickname, project name, or other text. It should not be treated as verified identity.

== Services Account ==

A '''Services account''' is the registered account recognized by NickServ.

The account name may be different from the user’s current nickname.

For example:

{| class="wikitable"
! Field
! Example
|-
| Current nickname
| Falcon-Away
|-
| Ident
| falcon
|-
| Displayed host
| User.DarkWorld.Network
|-
| NickServ account
| Falcon
|}

Staff should use verified account information where account ownership matters. A current nickname alone is not proof of account ownership.

= 6. Understanding IRC User Masks =

A common IRC user mask has this form:

<pre>
nickname!ident@hostname
</pre>

Example:

<pre>
Falcon!falcon@User.DarkWorld.Network
</pre>

The parts are:

{| class="wikitable"
! Component
! Example
! Meaning
|-
| Nickname
| Falcon
| Current visible nickname
|-
| Separator
| !
| Separates nickname and ident
|-
| Ident
| falcon
| Connection username
|-
| Separator
| @
| Separates ident and hostname
|-
| Hostname
| User.DarkWorld.Network
| Displayed host or cloak
|}

== Wildcards ==

IRC masks commonly use:

* `*` to match any number of characters.
* `?` to match one character, where supported.

Examples:

<pre>
Falcon!*@*
*!falcon@*
*!*@User.DarkWorld.Network
*!*@*.example.net
</pre>

These masks are not equally precise.

{| class="wikitable"
! Mask
! General effect
! Risk
|-
| `Falcon!*@*`
| Matches the nickname regardless of ident or host
| The user may change nickname
|-
| `*!falcon@*`
| Matches connections using the ident
| Other users may use the same ident
|-
| `*!*@User.DarkWorld.Network`
| Matches the displayed host
| May affect multiple users if the host is shared
|-
| `*!*@*.example.net`
| Matches a wider host range
| May affect many unrelated users
|}

Broad masks can affect innocent users. Selecting and applying bans will be covered in the moderation module.

= 7. Registered Nicknames and Accounts =

NickServ allows users to register and manage an account.

Common user commands may include:

<pre>
/MSG NickServ HELP
/MSG NickServ REGISTER
/MSG NickServ IDENTIFY account password
/MSG NickServ INFO nickname
/MSG NickServ STATUS nickname
/MSG NickServ RECOVER nickname
/MSG NickServ RELEASE nickname
/MSG NickServ GROUP nickname
</pre>

The exact command syntax must be confirmed through:

<pre>
/MSG NickServ HELP command
</pre>

Users should enter passwords only in the correct Services query or configured SASL fields.

They must never send a password:

* To a channel.
* To another user.
* To a staff member.
* To an unofficial bot.
* In a public support request.

Staff should never ask a user to reveal their password.

= 8. SASL Authentication =

'''Simple Authentication and Security Layer''', or '''SASL''', allows an IRC client to authenticate to the registered account during the connection process.

Benefits include:

* Authentication before joining channels.
* More reliable account recognition.
* Access to registered-user features immediately after connection.
* Reduced dependence on manually sending an IDENTIFY command.
* Improved security when used over TLS.

Typical SASL settings are:

{| class="wikitable"
! Setting
! Value
|-
| Authentication method
| SASL
|-
| Mechanism
| PLAIN, when supported and used over TLS
|-
| Account
| Registered NickServ account
|-
| Password
| NickServ account password
|}

Despite its name, the SASL PLAIN mechanism is safe only when protected by a properly verified TLS connection. Staff should recommend TLS together with SASL.

= 9. Channels =

IRC channels are shared conversation spaces.

Channel names normally begin with `#`.

Examples:

<pre>
#DarkWorld
#Help
#Support
</pre>

== Joining a Channel ==

<pre>
/JOIN #DarkWorld
</pre>

To join multiple channels where supported:

<pre>
/JOIN #DarkWorld,#Help
</pre>

== Leaving a Channel ==

<pre>
/PART #DarkWorld
</pre>

With a reason:

<pre>
/PART #DarkWorld Leaving for now
</pre>

== Viewing Channel Users ==

<pre>
/NAMES #DarkWorld
</pre>

== Viewing or Changing a Topic ==

View the topic:

<pre>
/TOPIC #DarkWorld
</pre>

Change the topic, when authorized:

<pre>
/TOPIC #DarkWorld New topic text
</pre>

Having technical ability to change a topic does not mean the change is authorized.

== Inviting a User ==

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

This may require channel privileges depending on the channel configuration.

== Kicking a User ==

<pre>
/KICK #channel nickname reason
</pre>

Example:

<pre>
/KICK #Training ExampleUser Repeated flooding after warning
</pre>

Kicks must include a clear and professional reason. Moderation actions will be covered in a later module.

= 10. Channel Messages, Private Messages, and Notices =

== Channel Message ==

A normal message sent while a channel is active is visible to users in that channel.

Depending on the client, the raw command may be:

<pre>
/MSG #channel message
</pre>

== Private Message ==

A private message is sent directly to another nickname:

<pre>
/MSG nickname message
</pre>

Opening a private conversation may also use:

<pre>
/QUERY nickname
</pre>

Private messages may still be logged by the recipient, IRC client, bouncer, bot, or an authorized system. Staff should not promise absolute privacy.

== Notice ==

A notice is generally intended for information that does not require an automatic reply:

<pre>
/NOTICE nickname message
</pre>

Notices should not be used to bypass a user’s communication preferences or harass them.

== Action Message ==

An action is commonly sent using:

<pre>
/ME performs an action
</pre>

In a channel, users may see:

<pre>
* Falcon performs an action
</pre>

= 11. Essential IRC Commands =

{| class="wikitable" style="width:100%;"
! Command
! Purpose
|-
| `/JOIN #channel`
| Join a channel
|-
| `/PART #channel reason`
| Leave a channel
|-
| `/NICK newnick`
| Change nickname
|-
| `/WHOIS nickname`
| View information about a connected user
|-
| `/WHOWAS nickname`
| View limited information about a recently disconnected nickname
|-
| `/USERHOST nickname`
| Request basic user and host information
|-
| `/WHO #channel`
| View information about users in a channel
|-
| `/NAMES #channel`
| View the channel nickname list
|-
| `/MODE nickname`
| View user modes
|-
| `/MODE #channel`
| View channel modes
|-
| `/TOPIC #channel`
| View a channel topic
|-
| `/LIST`
| Request the visible channel list
|-
| `/MOTD`
| View the network Message of the Day
|-
| `/RULES`
| View network rules, where supported
|-
| `/VERSION`
| View server software information
|-
| `/ADMIN`
| View server administration information
|-
| `/LINKS`
| View linked IRC servers, where permitted
|-
| `/LUSERS`
| View network user and server statistics
|-
| `/TIME`
| View server time
|-
| `/PING value`
| Test responsiveness at the protocol level
|-
| `/QUIT reason`
| Disconnect from IRC
|}

Commands that reveal additional information to IRC operators will be covered in the IRC Operator Fundamentals module.

= 12. Using WHOIS Correctly =

The `WHOIS` command provides information about a connected user:

<pre>
/WHOIS nickname
</pre>

Depending on permissions and network configuration, it may show:

* Nickname.
* Ident.
* Displayed hostname.
* Real-name field.
* Connected server.
* Channels.
* Registered account.
* User modes or status.
* Secure connection status.
* Idle time.
* Operator status.
* Virtual host or cloak information.

A more complete query may be available using:

<pre>
/WHOIS nickname nickname
</pre>

Results vary by server and client.

== WHOIS Limitations ==

WHOIS does not automatically prove:

* The user’s legal identity.
* Ownership of an external social account.
* That the real-name field is accurate.
* That two similar nicknames are the same person.
* That every person on a shared connection is responsible for an incident.

Staff must distinguish between displayed information, registered-account information, and verified evidence.

= 13. User Modes and Channel Modes =

The `/MODE` command is used for both users and channels.

View your own user modes:

<pre>
/MODE YourNickname
</pre>

View channel modes:

<pre>
/MODE #channel
</pre>

View a channel ban list:

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

View ban exceptions:

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

View invite exceptions:

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

Modes and their correct use will be covered fully in:

'''[[DWIRC:Staff Training/User and Channel Modes|Module 4 — User and Channel Modes]]'''

= 14. Lag =

'''Lag''' is a delay between sending an IRC command or message and receiving the resulting response.

Possible causes include:

* A slow user connection.
* High latency between the user and server.
* IRC server load.
* Network congestion.
* A temporary routing issue.
* Client or bouncer performance.
* Flood protection delaying commands.

Signs of lag include:

* Delayed messages.
* Slow command responses.
* Ping timeouts.
* Nickname changes appearing late.
* The client showing old channel information.

Staff should determine whether lag affects:

* One user.
* Users connected to one server.
* One geographic region.
* Multiple servers.
* The entire network.

= 15. Ping Timeout =

IRC servers send periodic checks to determine whether clients and linked servers remain responsive.

A user may disconnect with a reason similar to:

<pre>
Ping timeout
</pre>

This may happen because:

* The user’s internet connection failed.
* The device slept or changed networks.
* A firewall interrupted the connection.
* The client stopped responding.
* Network latency became too high.
* A route between the user and server failed.

A ping timeout does not, by itself, prove that the IRC server is malfunctioning.

= 16. Netsplits =

A '''netsplit''' occurs when the connection between two linked IRC servers is lost.

During a netsplit:

* Users on one server may appear to quit together.
* Channels may temporarily appear to lose users.
* Users may continue chatting on separate sides of the network.
* Nickname or channel state may require synchronization.
* Servers may reconnect automatically.
* Users may return in a large group when the link is restored.

A netsplit is different from a normal user disconnection.

== Staff Response to a Netsplit ==

Trainees should:

# Avoid panic.
# Observe which servers and users are affected.
# Record the approximate time.
# Avoid unnecessary channel-mode changes.
# Do not assume departing users were banned.
# Check official server notices where authorized.
# Notify operational staff if the split persists.
# Reassure users without making unsupported claims.
# Allow synchronization to complete after reconnection.

A trainee should not manually recreate access lists or issue broad corrective actions during an active netsplit unless directed by senior staff.

= 17. Server Notices =

Servers may send informational or operational messages called '''server notices'''.

They may report:

* Connections.
* Disconnections.
* Authentication failures.
* Flood activity.
* Server links.
* Netsplits.
* Operator actions.
* Security events.
* Configuration or Services issues.

Many notices are visible only to users with specific modes or privileges.

Staff must not copy confidential server notices into public channels unless specifically authorized.

= 18. Common Connection Errors =

{| class="wikitable" style="width:100%;"
! Error
! Possible meaning
! First response
|-
| Connection refused
| Nothing is accepting the connection on that address or port
| Confirm server, port, and current service status
|-
| Connection timed out
| The server could not be reached
| Check internet, firewall, DNS, and route
|-
| TLS certificate error
| Certificate validation failed
| Record exact error and verify hostname and system time
|-
| Nickname already in use
| Another connection is using the nickname
| Use another nickname or recover the registered nickname
|-
| Password incorrect
| Authentication failed
| Verify account name and use the approved recovery procedure
|-
| SASL authentication failed
| Invalid credentials or SASL configuration
| Check account, password, mechanism, TLS, and client settings
|-
| You are banned
| A channel or network restriction applies
| Determine whether it is a channel ban or network restriction
|-
| Registration timeout
| Client did not complete connection registration
| Check client configuration, network, and authentication
|-
| Ping timeout
| Connection stopped responding
| Check connection stability and whether others are affected
|}

Staff should obtain the exact error instead of relying only on descriptions such as “IRC is not working.”

= 19. Safe Troubleshooting Procedure =

Use the following process:

# Ask the user what they were trying to do.
# Ask for the exact error message.
# Confirm the server and port.
# Confirm whether TLS is enabled.
# Confirm the IRC client and version.
# Determine whether the problem affects other users.
# Check official service information.
# Provide one safe troubleshooting step at a time.
# Confirm the result.
# Escalate if the problem appears network-wide or security-related.
# Record the incident if required.

Avoid requesting more personal information than necessary.

= 20. Practical Exercises =

These exercises should be performed in an approved training channel.

== Exercise 1: Secure Connection ==

Configure an IRC client with:

<pre>
Server: irc.darkworld.network
Port: 6697
TLS: Enabled
Certificate verification: Enabled
</pre>

Record:

* Client name and version.
* Connection time.
* Whether TLS was successfully established.
* Any error received.

Do not submit account passwords.

== Exercise 2: Identity Information ==

Using your own training identity:

# Record your nickname.
# Record your ident.
# Record your displayed hostname.
# Record your registered account name.
# Explain how each value differs.

== Exercise 3: User Mask ==

Given:

<pre>
Trainee!student@Training.DarkWorld.Network
</pre>

Identify:

* Nickname.
* Ident.
* Hostname.
* Full user mask.

Then explain what these masks would generally match:

<pre>
Trainee!*@*
*!student@*
*!*@Training.DarkWorld.Network
</pre>

== Exercise 4: Essential Commands ==

Safely demonstrate:

<pre>
/JOIN #ApprovedTrainingChannel
/NAMES #ApprovedTrainingChannel
/TOPIC #ApprovedTrainingChannel
/WHOIS YourNickname
/MODE YourNickname
/MODE #ApprovedTrainingChannel
/PART #ApprovedTrainingChannel Exercise completed
</pre>

Do not change channel modes or topics unless authorized.

== Exercise 5: Services Help ==

Request official help using:

<pre>
/MSG NickServ HELP
/MSG ChanServ HELP
</pre>

Locate the correct help entry for:

* Account identification.
* Account information.
* Channel information.
* Channel access.

Do not register test accounts or channels without permission.

== Exercise 6: Troubleshooting ==

Prepare a response to this report:

<blockquote>
“I cannot connect to DarkWorld. It just gives an error.”
</blockquote>

Your response should ask for the information required to diagnose the problem without requesting passwords or unnecessary private data.

= 21. Practical Scenarios =

== Scenario 1: Password Posted Publicly ==

A user posts their NickServ password in `#Help`.

'''Correct approach:'''

Tell the user to change the password immediately through the official NickServ procedure. Avoid repeating or quoting the password. If possible and authorized, remove exposure from relevant logs or systems, and escalate if the account may have been compromised.

== Scenario 2: Certificate Warning ==

A user receives a certificate-name mismatch and asks whether they should disable verification.

'''Correct approach:'''

Do not immediately recommend disabling verification. Confirm the server hostname, exact error, device time, and whether others are affected. Escalate a possible certificate problem.

== Scenario 3: Nickname Dispute ==

A user is using a nickname that resembles another person’s nickname.

'''Correct approach:'''

Check registered-account information and the applicable policy. Similarity alone does not always establish impersonation. Collect facts and escalate where necessary.

== Scenario 4: Mass Quit ==

Many users connected through the same server appear to quit simultaneously.

'''Correct approach:'''

Consider a server disconnect or netsplit. Check which server was affected and review authorized notices. Do not assume every user intentionally left or was banned.

== Scenario 5: Shared Host ==

Several users have the same displayed hostname.

'''Correct approach:'''

Do not automatically assume they are the same person. They may use a shared provider, cloak, gateway, bouncer, VPN, or relay. Use additional authorized information and evidence.

= 22. Knowledge Check =

Answer the following questions in your own words:

# What is the difference between an IRC network and an IRC server?
# What is the recommended DarkWorld IRC server address and secure port?
# What does TLS protect?
# Why should certificate verification not be disabled casually?
# What is the difference between a nickname and a NickServ account?
# Identify the three main components of `nickname!ident@hostname`.
# What does the `*` wildcard normally represent in an IRC mask?
# Why can a broad hostname ban affect innocent users?
# What is SASL?
# Why should SASL be used with TLS?
# What information can WHOIS provide?
# What information does WHOIS not prove?
# What is the difference between a private message and a notice?
# What is a ping timeout?
# What is a netsplit?
# What should a trainee do during a persistent netsplit?
# What information should staff request when troubleshooting a connection?
# What confidential information must staff never request in a public channel?
# Why should staff obtain the exact error message?
# What should happen when an apparent connection problem affects many users?

= 23. Written Assignment =

Write approximately '''400–600 words''' explaining how you would help a new user who:

* Has never used IRC.
* Wants to connect securely to DarkWorld IRC.
* Wants to register an account.
* Wants automatic authentication.
* Does not understand the difference between a nickname and an account.
* Receives a “nickname already in use” message.

Your answer must:

* Recommend the correct secure connection settings.
* Explain TLS.
* Explain SASL.
* Avoid requesting or exposing the user’s password.
* Use clear and friendly language.
* Include appropriate escalation if account recovery fails.

= 24. Module Completion Requirements =

To complete this module, the candidate must:

* Read the complete lesson.
* Connect securely to DarkWorld IRC.
* Complete all authorized practical exercises.
* Correctly answer at least '''15 of the 20''' knowledge-check questions.
* Complete the written assignment.
* Demonstrate safe handling of passwords and connection information.
* Receive approval from the assigned trainer.

= 25. Trainer Evaluation =

{| class="wikitable" style="width:100%;"
! Evaluation area
! Maximum points
|-
| Understanding of IRC structure
| 15
|-
| Secure connection and TLS knowledge
| 20
|-
| Identity and user-mask knowledge
| 20
|-
| Command usage
| 15
|-
| Troubleshooting
| 15
|-
| Privacy and security
| 15
|-
! Total
! 100
|}

Recommended passing score: '''75 points'''.

The trainer should record:

* Candidate’s score.
* Practical exercises completed.
* Security or privacy mistakes.
* Topics requiring review.
* Completion date.
* Trainer’s name.
* Result: Pass, Revision Required, or Fail.

= 26. Quick Reference =

{| class="wikitable" style="width:100%;"
! Task
! Command or setting
|-
| Secure server
| `irc.darkworld.network`
|-
| Secure port
| `6697`
|-
| Encryption
| TLS enabled and certificate verified
|-
| Join a channel
| `/JOIN #channel`
|-
| Leave a channel
| `/PART #channel reason`
|-
| Change nickname
| `/NICK newnickname`
|-
| Check a user
| `/WHOIS nickname`
|-
| View channel users
| `/NAMES #channel`
|-
| View channel modes
| `/MODE #channel`
|-
| View own user modes
| `/MODE YourNickname`
|-
| NickServ help
| `/MSG NickServ HELP`
|-
| ChanServ help
| `/MSG ChanServ HELP`
|-
| Disconnect
| `/QUIT reason`
|}

= 27. Next Module =

After passing this module, continue to:

'''[[DWIRC:Staff Training/Policies|Module 3 — DarkWorld IRC Rules and Policies]]'''

----

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

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

DWIRC:Staff Training/IRC Fundamentals

2026-08-08T17:23:51Z

Fizi: Created page with "{{DISPLAYTITLE:Module 2 — IRC Fundamentals}} <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 2: IRC Fundamentals</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 2 of 10 |- ! Difficulty | Beginner |- ! Estima..."

DWIRC:Staff Training/Network Introduction

2026-08-08T17:21:24Z

Fizi: Protected "DWIRC:Staff Training/Network Introduction" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:Module 1 — DarkWorld IRC Network Introduction}}

<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 1: DarkWorld IRC Network Introduction</span>
</div>

{| class="wikitable" style="width:100%;"
|-
! Program
| DarkWorld IRC Staff Training Program
|-
! Module
| 1 of 10
|-
! Difficulty
| Beginner
|-
! Estimated study time
| 60–90 minutes
|-
! Assessment
| Knowledge check and written assignment
|-
! Prerequisite
| Acceptance into the training program
|}

= Module Overview =

This module introduces candidates to the '''DarkWorld IRC Network''', its position within the wider DarkWorld Network, its purpose, community structure, official resources, and staff responsibilities.

Before learning moderation commands or receiving access, every candidate must understand:

* What DarkWorld Network is.
* What the DarkWorld IRC Network is.
* How DWIRC relates to other DarkWorld projects.
* What IRC staff members are expected to do.
* The limits of IRC staff authority.
* How staff decisions should be escalated.
* Why trust, restraint, and accountability are essential.

This module does not provide IRC operator access or authorize a candidate to represent themselves as a DarkWorld staff member.

= Learning Objectives =

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

# Explain the difference between DarkWorld Network and DarkWorld IRC.
# Describe the purpose of the DarkWorld IRC Network.
# Identify the main responsibilities of IRC staff.
# Explain the difference between IRC staff and project staff.
# Identify the limits of a trainee's authority.
# Recognize when a matter should be escalated.
# Identify official sources of DarkWorld IRC information.
# Explain why staff access must follow the principle of least privilege.

= 1. DarkWorld Network =

'''DarkWorld Network''' is the wider organization and community umbrella under which multiple projects and services operate.

These projects may include:

* DarkWorld IRC Network
* DWShells
* DWBouncers
* DWBots
* DWGames
* DWStats
* DWPaste
* DWVPN
* DWTutorials
* Other current or future DarkWorld projects

Each project may have its own:

* Purpose
* Management
* Staff team
* Rules and policies
* Support procedures
* Technical systems
* Access requirements
* Training program

A person may hold a role in one DarkWorld project without holding authority in another.

For example, a DarkWorld IRC operator does not automatically have authority to:

* Create or suspend DWShells accounts.
* Administer DWBouncers users.
* Access a project server.
* Change a website.
* Modify a project database.
* Represent another project’s management.
* Override another project’s policies.

Similarly, staff members from other DarkWorld projects do not automatically receive IRC operator authority.

<div style="background:#fff8e1; border-left:4px solid #f59e0b; padding:12px; margin:15px 0;">
'''Important:''' DarkWorld Network is the umbrella. DarkWorld IRC Network is one project operating under that umbrella.
</div>

= 2. DarkWorld IRC Network =

The '''DarkWorld IRC Network''', also called '''DWIRC''', provides an Internet Relay Chat environment where users can communicate in public channels, private messages, project channels, support channels, and community spaces.

The IRC network is responsible for:

* Maintaining stable IRC connectivity.
* Providing secure TLS connections.
* Operating IRC servers and Services.
* Protecting users and channels from serious abuse.
* Maintaining network-wide rules and policies.
* Supporting registered nicknames and channels.
* Providing official help and support.
* Managing approved relays and bridges.
* Supporting registered projects and communities.
* Maintaining a safe and welcoming environment.
* Responding to technical and security incidents.

The IRC network should be managed fairly and consistently. Staff authority exists to serve and protect the network, not to give individual staff members personal power over users.

= 3. Purpose of IRC Staff =

The purpose of DarkWorld IRC staff is to:

* Assist users.
* Protect the network.
* Apply network policies fairly.
* Resolve or escalate incidents.
* Maintain IRC services and infrastructure where authorized.
* Support channels and registered projects.
* Document important actions.
* Communicate professionally.
* Protect confidential information.
* Work together as a team.

Staff members should not interfere unnecessarily with normal conversations or channel management.

Channel founders and their appointed channel operators are generally responsible for managing their own channels, provided they follow network policies.

Network staff should normally become involved when:

* A network-wide policy is violated.
* Serious abuse affects users or multiple channels.
* A user requests official assistance.
* A channel problem cannot be resolved by its management.
* An IRC server or Services problem occurs.
* A security incident affects the network.
* Staff intervention is required to prevent immediate harm.
* An authorized senior staff member assigns a task.

= 4. Community Moderation and Network Enforcement =

Candidates must understand the difference between channel-level moderation and network-level enforcement.

== Channel-Level Moderation ==

Channel founders and channel operators may manage their channels by:

* Setting channel rules.
* Assigning channel access.
* Giving voice or operator status.
* Removing disruptive users.
* Setting appropriate channel bans.
* Managing topics and channel settings.

A disagreement with a channel operator does not automatically become a network-level issue.

== Network-Level Enforcement ==

DarkWorld IRC staff may become involved when conduct:

* Violates a network-wide policy.
* Involves serious harassment or threats.
* Involves network-wide spam or advertising.
* Includes repeated ban evasion across channels.
* Targets network infrastructure.
* Involves malicious bots, attacks, or exploitation.
* Involves staff impersonation.
* Endangers users or the network.
* Requires Services or IRC operator intervention.

Staff should avoid overriding legitimate channel-management decisions unless a network policy, serious abuse issue, or authorized appeal requires intervention.

= 5. Staff Roles and Responsibilities =

DarkWorld IRC may maintain different staff levels according to operational needs.

Exact titles and permissions may change, but the general structure can include the following roles.

{| class="wikitable" style="width:100%;"
! Role
! General responsibility
! Typical authority
|-
| '''IRC Trainee'''
| Learns procedures and assists under supervision.
| No independent network-level enforcement.
|-
| '''Support Staff'''
| Helps users with connections, accounts, Services, and general questions.
| Support-related access only.
|-
| '''IRC Operator'''
| Responds to network abuse and operational incidents.
| Limited network-level commands appropriate to the role.
|-
| '''Global IRC Operator'''
| Handles incidents affecting multiple servers or the wider network.
| Broader network authority as approved.
|-
| '''Services Staff'''
| Assists with nickname, channel, and Services matters.
| Selected Services permissions.
|-
| '''Services Administrator'''
| Manages advanced Anope Services operations.
| High-level Services permissions.
|-
| '''Network Administrator'''
| Manages network operations, servers, policy, and senior escalations.
| Administrative network authority.
|-
| '''Root Administrator'''
| Maintains critical infrastructure and high-level technical systems.
| Production access assigned according to responsibilities.
|-
| '''Founder/Network Management'''
| Provides overall direction and final authorization.
| Final management responsibility.
|}

Titles alone must not be used to assume access. Actual permissions depend on the staff member’s assigned duties and management approval.

= 6. Reporting and Escalation =

Trainees should follow the established reporting structure.

A normal escalation path is:

# Attempt to understand the issue.
# Collect only the information needed.
# Check the relevant policy or procedure.
# Resolve the issue if it is within your authority.
# Contact a mentor or senior staff member if uncertain.
# Escalate serious incidents immediately.
# Record the action where required.
# Follow up if the case remains unresolved.

== Escalate Immediately When ==

A trainee should immediately contact authorized senior staff when:

* The network appears to be under attack.
* A staff account may be compromised.
* A server or Services system is failing.
* A user makes a credible threat.
* Private or sensitive information has been exposed.
* A serious security vulnerability is discovered.
* A large number of users or channels are affected.
* An action could disconnect or ban many users.
* A senior staff member is accused of serious misconduct.
* The correct response is unclear and could cause significant harm.

Trainees must not attempt high-risk actions merely to demonstrate confidence.

<div style="background:#e8f4fd; border-left:4px solid #2563eb; padding:12px; margin:15px 0;">
'''Good staff judgment includes knowing when not to act alone.'''
</div>

= 7. Limits of Staff Authority =

Staff authority must have a clear operational purpose.

A DarkWorld IRC staff member must not:

* Use staff access to win a personal argument.
* Threaten users with staff powers.
* Investigate users out of curiosity.
* Reveal IP addresses or confidential account details.
* Access private information without an authorized purpose.
* Interfere in channels without a valid reason.
* use network commands as entertainment.
* Grant unauthorized access to friends.
* Give another person access to a staff account.
* Circumvent approval or review procedures.
* Act outside their assigned project or role.
* Present a personal opinion as official DarkWorld policy.
* punish someone merely for criticizing a staff decision.
* Hide or falsify enforcement actions.
* Retaliate against a user who submits a complaint.

Staff members remain accountable for every use of elevated access.

= 8. Least Privilege =

The '''principle of least privilege''' means that a person should receive only the access required to perform their assigned duties.

Examples include:

* A trainee does not require IRC operator access.
* A support team member may not require server access.
* An IRC operator may not require Services database access.
* A Services staff member may not require IRCd configuration access.
* An IRC administrator does not automatically require access to DWShells.
* A project staff member does not automatically require DWIRC staff access.

Least privilege:

* Reduces accidental damage.
* Limits the effect of compromised accounts.
* Protects private information.
* Clarifies staff responsibilities.
* Makes actions easier to review.
* Protects both the network and the staff member.

= 9. Official Information Sources =

Staff should rely on official DarkWorld sources instead of rumors or outdated instructions.

Official resources may include:

* DarkWorld IRC documentation portal
* DarkWorld Wiki
* Approved policy pages
* Official network notices
* Authorized staff channels
* PolicyServ
* RelayServ
* Staff procedures and internal documentation
* Instructions from authorized management

Useful public resources include:

* [https://darkworld.network/ DarkWorld Network]
* [https://doc.darkworld.network/ DarkWorld IRC Documentation]
* [https://wiki.darkworld.network/ DarkWorld Wiki]

When two sources conflict, the candidate should:

# Avoid making assumptions.
# Check which source is current.
# Ask an authorized senior staff member.
# Report outdated documentation.
# Follow the confirmed current policy.

Bots may assist staff by retrieving information, but a bot response does not replace judgment or management authorization.

= 10. Official IRC Channels =

DarkWorld IRC may maintain official channels for different purposes.

{| class="wikitable" style="width:100%;"
! Channel
! General purpose
|-
| '''#DarkWorld'''
| Main network and community channel.
|-
| '''#Help'''
| IRC assistance and user support.
|-
| '''#Support'''
| Support for relevant DarkWorld services and projects.
|-
| '''#Abuse'''
| Reporting or discussing network abuse through approved procedures.
|-
| '''#PolicyTeam'''
| Restricted policy, approval, and compliance operations.
|-
| '''#RelayTeam'''
| Restricted relay and bridge compliance operations.
|}

Additional staff and project channels may exist. Access to a channel does not by itself authorize a trainee to make administrative decisions.

Private evidence, account information, IP addresses, access credentials, or sensitive reports must not be posted in public channels.

= 11. Relationship With Other DarkWorld Projects =

DWIRC provides communication infrastructure that may be used by other DarkWorld projects. Project channels may operate on the IRC network, but their internal management remains separate unless formally assigned otherwise.

For example:

* DWShells may use an IRC channel for user support.
* DWBouncers may use IRC bots for account management.
* DWGames may operate community or gaming channels.
* Registered external projects may maintain a verified presence.
* Relays may connect approved external communities to a DWIRC channel.

IRC staff may enforce network-wide IRC policies in these channels, but should not take over project-management responsibilities.

If an issue concerns both IRC policy and a project’s internal rules:

# Protect the IRC network if immediate action is required.
# Notify the relevant project staff.
# Separate the IRC violation from the project issue.
# Record any network-level action.
# Escalate disagreements between teams to appropriate management.

= 12. Candidate Conduct During Training =

While enrolled, candidates must:

* Follow all DarkWorld IRC rules.
* Treat trainers, users, and other candidates respectfully.
* Complete their own work.
* Ask questions when uncertain.
* Keep training information confidential where required.
* Avoid claiming to be permanent staff.
* Avoid using training as authority over other users.
* Report mistakes honestly.
* Accept correction professionally.
* Follow instructions during practical exercises.

A candidate’s behavior during training is part of the assessment.

Knowledge alone is not sufficient. A candidate must also demonstrate trustworthiness, restraint, reliability, and sound judgment.

= 13. Practical Scenarios =

Review each scenario and decide the correct response.

== Scenario 1: Project Boundary ==

You are a probationary DWIRC support staff member. A user asks you to increase their DWShells disk quota.

'''Correct approach:'''

Explain that DWShells is a separate project and direct or escalate the request to authorized DWShells staff. Do not attempt to modify the account unless you separately hold an authorized DWShells role.

== Scenario 2: Channel Disagreement ==

A user says a channel operator kicked them for being off-topic and demands that network staff remove the operator.

'''Correct approach:'''

Ask for the relevant facts and determine whether a network policy was violated. A normal channel-moderation disagreement usually remains with the channel’s management. Do not override channel staff merely because a user is unhappy.

== Scenario 3: Private Evidence ==

A user posts IP addresses and private logs publicly in an abuse channel.

'''Correct approach:'''

Ask the user to stop posting sensitive material publicly. Preserve only what is necessary and direct the report through the approved private process. Escalate if personal information has been widely exposed.

== Scenario 4: Possible Network Attack ==

Several servers begin disconnecting while many automated connections join the network.

'''Correct approach:'''

Notify senior operational staff immediately, preserve relevant timestamps and observations, and follow the incident procedure. A trainee must not issue broad bans or change server configurations without authorization.

== Scenario 5: Friend Requests Access ==

A friend asks you to give them temporary access to a restricted staff channel.

'''Correct approach:'''

Refuse the request. Access must be approved through the authorized process and must never be granted based on friendship.

== Scenario 6: Uncertain Policy ==

You believe a message may violate the advertising policy, but the case is unclear.

'''Correct approach:'''

Preserve the relevant context, consult the official policy, and ask an authorized policy or senior staff member. Avoid issuing a serious sanction based only on uncertainty.

= 14. Knowledge Check =

Answer the following questions in your own words.

# What is the difference between DarkWorld Network and DarkWorld IRC Network?
# Does completing DWIRC staff training grant authority over DWShells or DWBouncers?
# What is the primary purpose of IRC staff authority?
# When should network staff intervene in a channel matter?
# What is the principle of least privilege?
# Give three examples of matters that must be escalated immediately.
# Why must private evidence not be posted publicly?
# What should you do when two official sources appear to conflict?
# Can a trainee independently issue major network-level sanctions?
# Why is good judgment as important as technical knowledge?
# What should a staff member do after making a mistake?
# What is the difference between channel moderation and network enforcement?

= 15. Written Assignment =

Write a response of approximately '''300–500 words''' covering the following:

# Explain the role of DarkWorld IRC within the wider DarkWorld Network.
# Describe why you want to serve as a DarkWorld IRC staff member.
# Explain how you would support and protect IRC users.
# Describe what you would do if you were unsure whether enforcement was necessary.
# Explain why IRC staff authority must not extend automatically to other DarkWorld projects.

The assignment should be submitted through the approved training process.

Do not post personal information, passwords, IP addresses, confidential reports, or private staff information in the assignment.

= 16. Module Completion Requirements =

To complete this module, the candidate must:

* Read the complete lesson.
* Correctly answer at least '''9 of the 12''' knowledge-check questions.
* Complete the written assignment.
* Demonstrate an understanding of project boundaries.
* Accept that training does not guarantee a staff appointment.
* Receive approval from the assigned trainer or mentor.

A candidate who does not pass may review the material and attempt the module again.

= 17. Trainer Evaluation =

{| class="wikitable" style="width:100%;"
! Evaluation area
! Maximum points
|-
| Understanding of DarkWorld and DWIRC structure
| 20
|-
| Understanding of staff responsibilities
| 20
|-
| Understanding of authority boundaries
| 20
|-
| Escalation and judgment
| 20
|-
| Written communication and professionalism
| 20
|-
! Total
! 100
|}

Recommended passing score: '''75 points'''.

The trainer should record:

* Candidate’s score.
* Areas requiring improvement.
* Any conduct concerns.
* Whether resubmission is required.
* Completion date.
* Trainer’s name.
* Final result: Pass, Revision Required, or Fail.

= 18. Next Module =

After passing this module, continue to:

'''[[DWIRC:Staff Training/IRC Fundamentals|Module 2 — IRC Fundamentals]]'''

Candidates should not skip modules unless specifically authorized by the training coordinator.

----

'''Previous:''' [[DWIRC:Staff Training Program|Program Overview]]
'''Next:''' [[DWIRC:Staff Training/IRC Fundamentals|Module 2 — IRC Fundamentals]]

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

DWIRC:Staff Training/Network Introduction

2026-08-08T17:20:41Z

Fizi: Created page with "{{DISPLAYTITLE:Module 1 — DarkWorld IRC Network Introduction}} <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 1: DarkWorld IRC Network Introduction</span> </div> {| class="wikitable" style="width:100%;" |- ! Program | DarkWorld IRC Staff Training Program |- ! Module | 1 of 10 |-..."

DWIRC:Staff Training Program

2026-08-08T17:17:49Z

Fizi: Protected "DWIRC:Staff Training Program" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:DarkWorld IRC Staff Training Program}}

= DarkWorld IRC Staff Training Program =

The '''DarkWorld IRC Staff Training Program''' prepares potential staff members to support, moderate, and protect the DarkWorld IRC Network.

DarkWorld IRC is one of several projects operating under the wider '''DarkWorld Network''' umbrella. Other DarkWorld projects include DWShells, DWBouncers, DWBots, DWGames, DWStats, DWPaste, DWVPN, and DWTutorials.

Completion of this program applies only to roles within the '''DarkWorld IRC Network'''. It does not automatically grant authority, administrative access, or staff membership in any other DarkWorld project.

== Purpose of the Program ==

The program ensures that potential IRC staff members understand:

* How IRC works.
* How the DarkWorld IRC Network operates.
* DarkWorld IRC rules and policies.
* User and channel modes.
* NickServ, ChanServ, HostServ, and other IRC Services.
* User-support procedures.
* Channel moderation.
* Abuse and incident handling.
* Staff ethics, privacy, and security.
* The responsible use of IRC operator privileges.

Candidates must demonstrate knowledge, sound judgment, professional conduct, and reliability before receiving permanent staff access.

== Core Principles ==

Every trainee must follow these principles:

# '''Learn before acting''' – Candidates must understand the network and its policies before receiving authority.
# '''Use the least privilege''' – Access must be limited to what is required for the assigned role.
# '''Protect the community''' – Staff powers exist to protect users and the network.
# '''Remain neutral''' – Staff access must never be used in personal arguments.
# '''Respect privacy''' – Private reports, IP addresses, logs, and account information must remain confidential.
# '''Use proportionate action''' – Staff should use the least severe effective response.
# '''Document important actions''' – Serious incidents and enforcement actions must be recorded.
# '''Escalate when uncertain''' – Trainees should ask a senior staff member instead of guessing.
# '''Accept accountability''' – Staff decisions may be reviewed by senior management.
# '''Respect project boundaries''' – IRC staff authority does not extend to other DarkWorld projects.

== Who May Apply? ==

A candidate should:

* Be a registered and active DarkWorld IRC user.
* Have a positive history within the community.
* Demonstrate maturity, patience, and professionalism.
* Be willing to help users without expecting personal benefits.
* Be able to communicate clearly.
* Be willing to follow DarkWorld IRC rules and staff procedures.
* Protect confidential information.
* Complete all required lessons and assessments.
* Accept supervision during training and probation.
* Disclose any relevant staff positions held on other IRC networks or communities.

Previous IRC staff experience may be helpful, but it is not required. Experienced candidates must still complete the DarkWorld IRC-specific policy, ethics, and practical assessments.

== Disqualifying Conduct ==

A candidate may be rejected or removed from training for:

* Repeated violations of DarkWorld IRC rules.
* Harassment, discrimination, threats, or malicious conduct.
* Ban evasion.
* Sharing private or confidential information.
* Impersonating staff.
* Providing false information in an application.
* Attempting to obtain access without authorization.
* Using training knowledge to disrupt the network.
* Serious abuse of access on another network or project.
* Refusing to follow instructions from authorized trainers.
* Cheating during an assessment.
* Using another person to complete training work.

Removal from training does not always mean permanent rejection. Management may allow a candidate to apply again after a suitable period, depending on the reason for removal.

== Training Stages ==

{| class="wikitable"
! Stage
! Description
! Access
|-
| '''Applicant'''
| A user who has submitted an application.
| Normal public user access only.
|-
| '''IRC Student'''
| A candidate accepted into the training program.
| Training materials and approved training channels.
|-
| '''IRC Trainee'''
| A student who has passed the initial lessons and assessments.
| Supervised practical duties only.
|-
| '''Probationary IRC Staff'''
| A trainee who has passed the core program and has been selected for probation.
| Limited role-appropriate access.
|-
| '''DWIRC Staff Member'''
| A candidate who has successfully completed probation.
| Access appropriate to the assigned IRC staff role.
|-
| '''IRC Specialist'''
| A staff member who has completed an additional specialist program.
| Specialist access approved separately.
|}

== Training Process ==

The normal training process is:

# Candidate submits an application.
# The application is reviewed.
# Approved candidates join the core training program.
# The candidate completes all required lessons.
# The candidate completes assignments and practical exercises.
# The candidate passes the written assessment.
# The candidate passes the practical assessment.
# The candidate signs or accepts the Staff Code of Conduct.
# Successful candidates enter supervised trainee duties.
# Selected trainees enter probation.
# A final review determines whether the candidate becomes a permanent staff member.

Passing the course does not create an automatic right to a staff position. Staff appointments depend on conduct, trust, network requirements, available roles, and final management approval.

== Core Training Curriculum ==

=== Module 1: DarkWorld IRC Network Introduction ===

Candidates learn about:

* DarkWorld Network as the parent organization.
* The purpose of the DarkWorld IRC Network.
* Official IRC servers and channels.
* IRC staff roles and reporting structures.
* The boundaries of IRC staff authority.
* The relationship between DWIRC and other DarkWorld projects.

'''Lesson:''' [[DWIRC:Staff Training/Network Introduction|DarkWorld IRC Network Introduction]]

=== Module 2: IRC Fundamentals ===

Candidates learn about:

* IRC clients and servers.
* Secure TLS connections.
* Nicknames, usernames, idents, hostnames, and cloaks.
* Channels and private messages.
* IRC masks.
* IRC commands.
* Netsplits, lag, reconnections, and server notices.

'''Lesson:''' [[DWIRC:Staff Training/IRC Fundamentals|IRC Fundamentals]]

=== Module 3: DarkWorld IRC Policies ===

Candidates study:

* General network guidelines.
* Advertising, invitation, and recruitment rules.
* Relay and bridge policy.
* Channel registration requirements.
* Project registration and verified presence.
* Spam, flooding, harassment, and ban evasion.
* Privacy and evidence handling.
* Staff conduct requirements.

'''Lesson:''' [[DWIRC:Staff Training/Policies|DarkWorld IRC Policies]]

=== Module 4: User and Channel Modes ===

Candidates learn about:

* User modes.
* IRC operator modes.
* Channel modes.
* Channel access levels.
* Ban masks.
* Ban exceptions.
* Invite exceptions.
* Moderated and restricted channels.
* Flood-protection modes.

'''Lesson:''' [[DWIRC:Staff Training/User and Channel Modes|User and Channel Modes]]

=== Module 5: IRC Services ===

Candidates learn about:

* NickServ.
* ChanServ.
* MemoServ.
* HostServ.
* BotServ, where applicable.
* Account assistance.
* Channel access.
* Channel ownership disputes.
* Appropriate escalation to Services Administrators.

'''Lesson:''' [[DWIRC:Staff Training/IRC Services|IRC Services]]

=== Module 6: User Support ===

Candidates learn how to:

* Assist users in official help channels.
* Ask useful diagnostic questions.
* Help users connect securely.
* Provide NickServ and ChanServ assistance.
* Handle complaints professionally.
* De-escalate disagreements.
* Protect confidential information.
* Escalate complex cases.

'''Lesson:''' [[DWIRC:Staff Training/User Support|User Support and Communication]]

=== Module 7: IRC Moderation ===

Candidates learn about:

* Warnings.
* Mutes.
* Kicks.
* Channel bans.
* Spam and flood response.
* Advertising violations.
* Harassment.
* Ban evasion.
* Proportionate enforcement.
* Avoiding unnecessarily broad actions.

'''Lesson:''' [[DWIRC:Staff Training/Moderation|IRC Moderation]]

=== Module 8: Abuse and Incident Handling ===

Candidates learn how to:

* Receive an abuse report.
* Verify evidence.
* Protect private information.
* Preserve logs and timestamps.
* Classify incident severity.
* Take immediate protective action.
* Escalate serious cases.
* Prepare an incident report.
* Follow up on unresolved incidents.

'''Lesson:''' [[DWIRC:Staff Training/Incident Handling|Abuse and Incident Handling]]

=== Module 9: IRC Operator Fundamentals ===

Candidates selected for network-level roles learn about:

* IRC operator responsibilities.
* Operator-account security.
* Network notices.
* User investigations.
* Kills and network bans.
* OperOverride and SAMODE.
* Netsplits and server routing.
* Flood and attack response.
* Recording operator actions.

This module does not grant IRC operator access. Access requires separate management approval.

'''Lesson:''' [[DWIRC:Staff Training/IRC Operator Fundamentals|IRC Operator Fundamentals]]

=== Module 10: Staff Ethics and Security ===

Candidates learn about:

* Least-privilege access.
* Neutrality.
* Confidentiality.
* Account security.
* Conflicts of interest.
* Staff accountability.
* Internal escalation.
* Compromised-access reporting.
* Separation between IRC authority and other DarkWorld projects.

'''Lesson:''' [[DWIRC:Staff Training/Staff Ethics|Staff Ethics and Security]]

== Assessment System ==

Candidates are evaluated through written, practical, and behavioral assessments.

{| class="wikitable"
! Assessment
! Weight
! Minimum expectation
|-
| Written assessment
| 30%
| Demonstrates knowledge of IRC, policies, and procedures.
|-
| Practical IRC assessment
| 35%
| Correctly performs support, moderation, and IRC tasks.
|-
| Communication and judgment
| 25%
| Remains professional, neutral, and proportionate.
|-
| Participation and reliability
| 10%
| Completes assignments and follows training procedures.
|}

The normal minimum passing score is '''75%'''.

Candidates must also pass the ethics and security section independently. A high overall score cannot compensate for unsafe conduct, abuse of access, dishonesty, or serious privacy violations.

== Practical Training ==

Practical exercises should take place in an approved training environment.

Exercises may include:

* Registering and securing an IRC account.
* Identifying parts of an IRC user mask.
* Using user-information commands.
* Managing channel modes.
* Selecting an appropriate ban mask.
* Handling a support request.
* Responding to flooding.
* Responding to prohibited advertising.
* Handling a channel dispute.
* Preparing an incident report.
* Escalating a serious case.
* Recognizing when no staff action is required.

Candidates must not experiment with moderation or operator commands against real users without authorization.

== Mentorship ==

Every IRC trainee should be assigned a mentor.

The mentor should:

* Answer training questions.
* Review assignments.
* Observe practical exercises.
* Correct unsafe actions.
* Provide feedback.
* Monitor trainee conduct.
* Review incident reports.
* Recommend advancement, additional training, or removal.

A mentor must not approve a candidate solely because of friendship or personal association.

== Trainee Period ==

After passing the core assessments, a candidate may become an '''IRC Trainee'''.

During this period, the trainee may:

* Help users in approved support channels.
* Observe experienced staff.
* Participate in supervised exercises.
* Prepare reports.
* Recommend actions to authorized staff.
* Handle approved low-risk duties.

Unless specifically authorized, a trainee must not:

* Use unrestricted IRC operator access.
* Use administrative OperServ commands.
* Issue permanent network-level sanctions.
* Access production server configurations.
* Handle confidential investigations alone.
* Modify IRC Services or network databases.
* Represent personal decisions as official policy.

== Probation ==

Selected trainees may enter a probationary staff period lasting approximately '''30 to 60 days'''.

During probation, candidates are evaluated on:

* Activity.
* Reliability.
* Policy knowledge.
* Support quality.
* Professional conduct.
* Accuracy of actions.
* Team communication.
* Security awareness.
* Incident documentation.
* Willingness to accept correction.

At the end of probation, management may:

* Appoint the candidate as a permanent DWIRC staff member.
* Extend probation.
* Require additional training.
* Return the candidate to trainee status.
* End the candidacy.

== Staff Access Policy ==

Completing training does not automatically grant access.

All staff access must be:

* Approved by authorized management.
* Appropriate to the assigned role.
* Limited according to the principle of least privilege.
* Removed when no longer required.
* Reviewed after role changes or security incidents.

Staff access must never be shared with another person.

== Specialist Training ==

After completing the core program, eligible staff members may apply for specialist training.

Planned specialist programs include:

* [[DWIRC:Staff Training/IRC Operator Program|IRC Operator Program]]
* [[DWIRC:Staff Training/Services Administration|Services Administration]]
* [[DWIRC:Staff Training/IRCd Administration|IRCd Administration]]
* [[DWIRC:Staff Training/Policy and Compliance|Policy and Compliance]]
* [[DWIRC:Staff Training/Abuse and Security|Abuse and Security]]
* [[DWIRC:Staff Training/Support Team|Support Team]]

DWShells, DWBouncers, and other DarkWorld projects will maintain separate project-specific training programs.

== Staff Code of Conduct ==

All candidates and staff members must read and accept the:

'''[[DWIRC:Staff Training/Code of Conduct|DarkWorld IRC Staff Code of Conduct]]'''

Acceptance of the Code of Conduct is mandatory before a candidate may enter probation.

== Important Notice ==

The DarkWorld IRC Staff Training Program is an educational and evaluation process. Completing it does not guarantee appointment to a staff position.

DarkWorld IRC management reserves the right to accept, defer, reject, remove, or require further training for a candidate based on the security, operational requirements, and best interests of the network and its community.

== Related Resources ==

* [https://darkworld.network/ DarkWorld Network]
* [https://doc.darkworld.network/ DarkWorld IRC Documentation]
* [[DWIRC|DarkWorld IRC Network]]
* [[DWTutorials:Linux Basics for Beginners|Linux Basics for Beginners]]

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

DWIRC:Staff Training Program

2026-08-08T17:16:50Z

Fizi: Created page with "{{DISPLAYTITLE:DarkWorld IRC Staff Training Program}} = DarkWorld IRC Staff Training Program = The '''DarkWorld IRC Staff Training Program''' prepares potential staff members to support, moderate, and protect the DarkWorld IRC Network. DarkWorld IRC is one of several projects operating under the wider '''DarkWorld Network''' umbrella. Other DarkWorld projects include DWShells, DWBouncers, DWBots, DWGames, DWStats, DWPaste, DWVPN, and DWTutorials. Completion of this p..."

DWTutorials:Linux Basics for Beginners

2026-07-21T21:25:21Z

Fizi: Protected "DWTutorials:Linux Basics for Beginners" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

{{DISPLAYTITLE:DWShells Linux Basics for Beginners}}
[[File:DWShells-Linux-Basics-Cover.png|center|frameless|1000px|alt=DWShells Linux Basics for Beginners course banner]]

= Linux Basics for Beginners =

'''Debian Shell Course for DWShells'''

{| class="wikitable" style="width:100%;"
|-
! Course level
| Complete beginner
! Suggested time
| 12–16 hours
|-
! Platform
| Debian GNU/Linux
! Access
| DWShells account through SSH
|-
! Permissions
| Normal user account; no root access required
! Course version
| 1.0 — July 2026
|}

This course teaches the Linux command line from the beginning. You will learn by running safe commands in your own DWShells home directory. By the end, you will be able to navigate Linux, manage files, understand permissions, combine commands, monitor your own processes, transfer files securely, and write a small Bash script.

'''Copyright:''' © 2026 DarkWorld Network. All rights reserved.

== Before you begin ==

=== What you need ===

* An active DWShells account.
* Your DWShells username, password or SSH key, hostname, and SSH port.
* An SSH program:
** '''Windows 10/11:''' Windows Terminal, PowerShell, or PuTTY.
** '''Linux:''' a terminal application.
** '''macOS:''' Terminal.
** '''Android/iOS:''' a reputable SSH client.
* About one hour per lesson.

Examples use the hostname <code>dwshells.darkworld.network</code>. If your welcome email gives a different hostname or port, always use the details in that email.

=== How to read command examples ===

When you see:

<syntaxhighlight lang="bash">
$ pwd
/home/free/alex
</syntaxhighlight>

the dollar sign is the shell prompt. '''Type only <code>pwd</code>; do not type the dollar sign.''' Lines after the command show example output. Your username, hostname, dates, file sizes, and other details will be different.

=== Safety rules ===

{| class="wikitable" style="width:100%;"
|-
! Rule
! Reason
|-
| Work inside <code>$HOME</code> unless a lesson clearly says otherwise.
| This is your personal directory and the safest place to practise.
|-
| Read a command before pressing Enter.
| Linux assumes that you mean what you type.
|-
| Do not copy unknown commands from websites or strangers.
| A short command can steal data, misuse the server, or delete files.
|-
| Never practise with <code>root</code>, <code>sudo</code>, <code>su</code>, or system files.
| DWShells learners do not need administrator access.
|-
| Never use network scanners, miners, attack tools, spam tools, or prohibited long-running services.
| Follow the DWShells Acceptable Use Policy and protect other users.
|-
| Ask DWShells staff if you are unsure.
| It is better to check first than to damage data or violate policy.
|}

=== Course workspace ===

Create one directory for all labs:

<syntaxhighlight lang="bash">
mkdir -p "$HOME/linux-course"
cd "$HOME/linux-course"
pwd
</syntaxhighlight>

Expected final line:

<pre>/your/home/path/linux-course</pre>

The exact home path may be <code>/home/free/USERNAME</code>, <code>/home/support/USERNAME</code>, or another path assigned by DWShells. Use <code>$HOME</code> so your commands work in every case.

[[File:DWShells-Learning-Journey.png|center|frameless|1000px|alt=Illustration showing the journey from a local terminal through Linux skills to a remote server]]

__TOC__

----

= Lesson 1 — Meet Linux and connect to DWShells =

'''Goal:''' Understand the basic vocabulary, connect securely, run simple commands, and leave the session correctly.

== 1.1 What is Linux? ==

Linux is the core, or '''kernel''', that manages the computer's CPU, memory, storage, devices, and processes. A complete operating system combines the Linux kernel with programs and tools.

'''Debian''' is the Linux distribution used by DWShells. Debian is known for stability, security, and careful software packaging.

{| class="wikitable"
|-
! Term
! Simple meaning
|-
| Linux
| The kernel that manages the system.
|-
| Debian
| The Linux distribution running on the server.
|-
| Terminal
| The window or application where you type commands.
|-
| Shell
| The program that reads and runs your commands. This course uses Bash examples.
|-
| SSH
| Secure Shell: the encrypted method used to connect to DWShells.
|-
| Command
| An instruction given to the shell.
|}

== 1.2 Connect with SSH ==

From Windows Terminal, PowerShell, Linux, or macOS, run this on '''your own computer''':

<syntaxhighlight lang="bash">
ssh USERNAME@dwshells.darkworld.network
</syntaxhighlight>

If DWShells uses a custom port:

<syntaxhighlight lang="bash">
ssh -p PORT_NUMBER USERNAME@dwshells.darkworld.network
</syntaxhighlight>

Replace <code>USERNAME</code> and <code>PORT_NUMBER</code> with the details in your welcome email.

The first connection may display a server host-key fingerprint and ask whether you trust it. Compare it with the fingerprint published by DWShells or ask staff to verify it. Do not accept an unexpected or changed fingerprint without checking.

When asked for a password, type it and press Enter. The terminal normally shows '''no dots and no stars''' while you type a Linux password. This is normal.

== 1.3 Understand the prompt ==

A prompt may look like:

<pre>alex@dwshells:~$</pre>

* <code>alex</code> — your username.
* <code>dwshells</code> — the server hostname.
* <code>~</code> — your home directory.
* <code>$</code> — a normal user's prompt. A <code>#</code> prompt usually represents an administrator and is not used in this course.

[[File:DWShells-Command-Anatomy.png|center|frameless|1000px|alt=Diagram explaining the command, options, and argument parts of a Linux command]]

== 1.4 Run your first commands ==

Run one line at a time:

<syntaxhighlight lang="bash">
whoami
hostname
pwd
date
echo "Hello from DWShells"
</syntaxhighlight>

{| class="wikitable"
|-
! Command
! Purpose
|-
| <code>whoami</code>
| Shows the current username.
|-
| <code>hostname</code>
| Shows the server's name.
|-
| <code>pwd</code>
| Prints the working directory—your current location.
|-
| <code>date</code>
| Shows the server's current date and time.
|-
| <code>echo</code>
| Prints text or a variable's value.
|}

Linux commands and filenames are case-sensitive. <code>pwd</code>, <code>PWD</code>, and <code>Pwd</code> are not the same.

== 1.5 Essential keyboard controls ==

{| class="wikitable"
|-
! Key
! Action
|-
| Up / Down arrows
| Move through recently entered commands.
|-
| Tab
| Complete a command or filename. Press twice to show possibilities.
|-
| Ctrl+C
| Interrupt the command currently running.
|-
| Ctrl+L
| Clear the visible terminal screen without deleting history.
|-
| Ctrl+D
| Send end-of-file; at an empty prompt it logs out.
|}

To leave DWShells normally:

<syntaxhighlight lang="bash">
exit
</syntaxhighlight>

== Lesson 1 lab ==

# Connect to DWShells.
# Display your username, hostname, home directory, and the current date.
# Print the sentence <code>I am learning Debian Linux</code>.
# Use the Up arrow to recall your previous command.
# Log out using <code>exit</code>, then connect again.

== Lesson 1 review ==

# What is the difference between a terminal and a shell?
# What secure protocol connects you to DWShells?
# Why does the password appear invisible while you type?
# Which command prints your current directory?
# Which key combination stops a running command?

----

= Lesson 2 — Navigate the filesystem =

'''Goal:''' List directory contents and move confidently using absolute paths, relative paths, and shortcuts.

== 2.1 The filesystem is a tree ==

Linux uses one directory tree beginning at <code>/</code>, called the '''root directory'''. This is different from the <code>root</code> administrator account.

[[File:DWShells-Filesystem-Map.png|center|frameless|1000px|alt=Beginner map of the Debian filesystem showing home, etc, var, tmp, and usr]]

Important locations:

{| class="wikitable"
|-
! Path
! Purpose
! Beginner guidance
|-
| <code>/</code>
| Top of the entire filesystem.
| Browse only; do not try to modify it.
|-
| <code>/home</code>
| Contains user home directories.
| Your own home is your normal workspace.
|-
| <code>/etc</code>
| System configuration.
| Usually readable but not writable by normal users.
|-
| <code>/var</code>
| Logs, cache, mail, and changing system data.
| Mostly managed by services and administrators.
|-
| <code>/tmp</code>
| Temporary files.
| Files may be deleted automatically; never store valuables here.
|-
| <code>/usr</code>
| Programs, libraries, and shared read-only data.
| Useful to understand, but not your workspace.
|}

== 2.2 List files with ls ==

<syntaxhighlight lang="bash">
ls
ls -l
ls -a
ls -lah
</syntaxhighlight>

Common options:

* <code>-l</code> — long format with permissions, owner, size, and date.
* <code>-a</code> — include hidden names beginning with a dot.
* <code>-h</code> — display sizes in a human-readable form such as KiB or MiB.

Options can be combined: <code>ls -l -a -h</code> and <code>ls -lah</code> are equivalent.

List another directory without moving there:

<syntaxhighlight lang="bash">
ls -lah /etc
ls -lah "$HOME"
</syntaxhighlight>

== 2.3 Move with cd ==

<syntaxhighlight lang="bash">
cd "$HOME"
cd /
cd /etc
cd ..
cd -
cd ~
</syntaxhighlight>

{| class="wikitable"
|-
! Path or command
! Meaning
|-
| <code>cd /etc</code>
| Move to the absolute path <code>/etc</code>.
|-
| <code>cd ..</code>
| Move to the parent directory.
|-
| <code>cd .</code>
| Stay in the current directory. A single dot means “here.”
|-
| <code>cd -</code>
| Return to the previous directory.
|-
| <code>cd</code> or <code>cd ~</code>
| Return to your home directory.
|}

An '''absolute path''' begins with <code>/</code>, such as <code>/etc/hosts</code>. A '''relative path''' begins from your current directory, such as <code>lesson-02/notes.txt</code>.

== 2.4 Hidden files ==

Names beginning with a dot are hidden from a normal <code>ls</code> listing:

<syntaxhighlight lang="bash">
ls -la "$HOME"
</syntaxhighlight>

Configuration files such as <code>.bashrc</code> and directories such as <code>.ssh</code> are hidden to reduce clutter, not to provide security.

== Lesson 2 lab ==

Run each task and use <code>pwd</code> after every <code>cd</code>:

# Go to your home directory.
# Go to the root directory.
# List the root directory in long, human-readable format.
# Go to <code>/etc</code>.
# Return to the previous directory using <code>cd -</code>.
# Return home using the shortest command you know.
# List all hidden names in your home directory.

== Lesson 2 review ==

# What is the difference between <code>/</code> and <code>/root</code>?
# What does <code>~</code> represent?
# Which <code>ls</code> option shows hidden files?
# Is <code>/etc/hosts</code> an absolute or relative path?
# What do <code>.</code> and <code>..</code> mean?

----

= Lesson 3 — Create, copy, move, and remove files =

'''Goal:''' Organize data in your course workspace and delete items safely.

== 3.1 Create directories and files ==

<syntaxhighlight lang="bash">
cd "$HOME/linux-course"
mkdir lesson-03
cd lesson-03
mkdir documents backups
touch notes.txt
ls -lah
</syntaxhighlight>

* <code>mkdir</code> creates a directory.
* <code>touch</code> creates an empty file if it does not exist, or updates its timestamp if it does.
* <code>mkdir -p</code> creates missing parent directories and does not complain if they already exist.

Example:

<syntaxhighlight lang="bash">
mkdir -p project/docs/drafts
</syntaxhighlight>

== 3.2 Copy files and directories ==

<syntaxhighlight lang="bash">
cp notes.txt notes-copy.txt
cp notes.txt documents/
cp -i notes.txt documents/notes.txt
cp -r documents backups/
</syntaxhighlight>

* <code>cp SOURCE DESTINATION</code> copies a file.
* <code>-r</code> copies a directory and its contents recursively.
* <code>-i</code> asks before overwriting an existing destination.
* <code>-v</code> displays what is being copied.

For an important copy, check the destination:

<syntaxhighlight lang="bash">
ls -lah documents backups
</syntaxhighlight>

== 3.3 Move and rename ==

The same <code>mv</code> command moves and renames:

<syntaxhighlight lang="bash">
mv notes-copy.txt old-notes.txt
mv old-notes.txt documents/
mv -i notes.txt main-notes.txt
</syntaxhighlight>

== 3.4 Remove safely ==

<syntaxhighlight lang="bash">
rm -i main-notes.txt
rm -i backups/documents/notes.txt
rmdir backups/documents
rmdir backups
</syntaxhighlight>

* <code>rm</code> removes files.
* <code>rmdir</code> removes an empty directory.
* <code>rm -r DIRECTORY</code> removes a directory tree recursively.
* <code>rm -f</code> forces removal without a question. Beginners should avoid it.

'''Important:''' Shell deletion normally does not use a recycle bin. Always run <code>pwd</code> and <code>ls</code> first. Prefer <code>rm -i</code> while learning.

Never run destructive examples such as <code>rm -rf</code> on broad paths. Do not combine recursive deletion with <code>/</code>, <code>~</code>, <code>$HOME</code>, unknown variables, or an unreviewed wildcard.

== 3.5 Wildcards in file operations ==

The shell expands patterns before running a command:

{| class="wikitable"
|-
! Pattern
! Meaning
! Example
|-
| <code>*</code>
| Any number of characters.
| <code>ls *.txt</code>
|-
| <code>?</code>
| Exactly one character.
| <code>ls note?.txt</code>
|-
| <code>[abc]</code>
| One character from the brackets.
| <code>ls file[123].txt</code>
|}

Preview a wildcard with <code>printf</code> or <code>ls</code> before using it with <code>cp</code>, <code>mv</code>, or <code>rm</code>:

<syntaxhighlight lang="bash">
printf '%s\n' *.txt
</syntaxhighlight>

== Lesson 3 lab ==

Work only in <code>$HOME/linux-course/lesson-03</code>:

# Create directories named <code>practice</code> and <code>practice/archive</code>.
# Create empty files <code>one.txt</code>, <code>two.txt</code>, and <code>three.log</code>.
# Copy the two <code>.txt</code> files into <code>practice</code>.
# Rename <code>three.log</code> to <code>activity.log</code>.
# Copy <code>activity.log</code> into <code>practice/archive</code>.
# List the complete result with <code>ls -lR</code>.
# Remove only <code>two.txt</code> from the current directory using interactive mode.

== Lesson 3 review ==

# Which command creates parent directories automatically?
# How do you copy a directory and its contents?
# Which command renames a file?
# Why should you use <code>rm -i</code> while learning?
# What does <code>*.txt</code> match?

----

= Lesson 4 — Read and edit text files =

'''Goal:''' Inspect text safely, edit with Nano, and compare files.

== 4.1 Identify and display files ==

Create lesson data:

<syntaxhighlight lang="bash">
mkdir -p "$HOME/linux-course/lesson-04"
cd "$HOME/linux-course/lesson-04"
printf 'alpha\nbeta\ngamma\ndelta\nepsilon\n' > words.txt
</syntaxhighlight>

Now inspect it:

<syntaxhighlight lang="bash">
file words.txt
cat words.txt
head -n 3 words.txt
tail -n 2 words.txt
wc -l words.txt
</syntaxhighlight>

{| class="wikitable"
|-
! Command
! Use
|-
| <code>file NAME</code>
| Guess the file type.
|-
| <code>cat NAME</code>
| Display a short text file.
|-
| <code>less NAME</code>
| Read a long file one screen at a time.
|-
| <code>head -n N NAME</code>
| Show the first N lines.
|-
| <code>tail -n N NAME</code>
| Show the last N lines.
|-
| <code>wc</code>
| Count lines, words, or bytes.
|}

Inside <code>less</code>:

* Arrow keys or Page Up/Page Down — move.
* <code>/word</code> — search forward.
* <code>n</code> — next match.
* <code>q</code> — quit.

Follow a file as new lines are added:

<syntaxhighlight lang="bash">
tail -f filename.log
</syntaxhighlight>

Press Ctrl+C to stop following. Use this only on logs you are permitted to read.

== 4.2 Edit with Nano ==

Open a file:

<syntaxhighlight lang="bash">
nano notes.txt
</syntaxhighlight>

Nano shows shortcuts at the bottom. The <code>^</code> character means Ctrl.

{| class="wikitable"
|-
! Shortcut
! Action
|-
| Ctrl+O
| Write (save) the file.
|-
| Ctrl+X
| Exit Nano.
|-
| Ctrl+W
| Search.
|-
| Ctrl+K
| Cut the current line.
|-
| Ctrl+U
| Paste the cut line.
|-
| Alt+U
| Undo, where supported.
|}

If Nano is not available, ask DWShells staff which editor is supported. Do not edit unfamiliar system configuration files while learning.

== 4.3 Write predictable text with printf ==

<syntaxhighlight lang="bash">
printf '%s\n' "DWShells Linux Course" "Lesson 4" > summary.txt
printf '%s\n' "Completed" >> summary.txt
cat summary.txt
</syntaxhighlight>

The single <code>></code> replaces a file's content. The double <code>>></code> appends. Lesson 7 explains this in detail.

== 4.4 Compare files ==

<syntaxhighlight lang="bash">
cp words.txt words-copy.txt
printf '%s\n' "zeta" >> words-copy.txt
diff -u words.txt words-copy.txt
</syntaxhighlight>

No output from <code>diff</code> means the files are identical.

== Lesson 4 lab ==

# Create <code>$HOME/linux-course/lesson-04/profile.txt</code>.
# Use Nano to write your username, the course name, and three Linux commands you have learned.
# Save and exit.
# Display the first two lines with <code>head</code>.
# Display the last line with <code>tail</code>.
# Count the number of lines with <code>wc</code>.
# Copy the file, add one new line to the copy, and compare both files with <code>diff -u</code>.

== Lesson 4 review ==

# When is <code>less</code> better than <code>cat</code>?
# How do you quit <code>less</code>?
# Which Nano shortcut saves a file?
# What is the difference between <code>head</code> and <code>tail</code>?
# What does no output from <code>diff</code> normally mean?

----

= Lesson 5 — Find help and understand commands =

'''Goal:''' Use built-in documentation instead of guessing.

== 5.1 Quick help ==

Most programs support:

<syntaxhighlight lang="bash">
ls --help
cp --help
grep --help
</syntaxhighlight>

Because help can be long, send it to <code>less</code>:

<syntaxhighlight lang="bash">
ls --help | less
</syntaxhighlight>

== 5.2 Manual pages ==

<syntaxhighlight lang="bash">
man ls
man cp
man chmod
</syntaxhighlight>

Useful keys in <code>man</code> are the same as in <code>less</code>: <code>/</code> searches, <code>n</code> finds the next result, and <code>q</code> quits.

Search manual descriptions:

<syntaxhighlight lang="bash">
whatis ls
apropos "copy files"
man -k "search text"
</syntaxhighlight>

<code>apropos</code> and <code>man -k</code> are equivalent. On a minimal server, the manual index or some pages may not be installed.

== 5.3 Learn what the shell will run ==

<syntaxhighlight lang="bash">
type cd
type ls
command -v bash
command -v nano
</syntaxhighlight>

* <code>type</code> can identify an alias, function, shell builtin, or executable.
* <code>command -v</code> checks whether a command is available and shows what will run.
* <code>cd</code> is normally a shell builtin because it must change the current shell's directory.

== 5.4 Command history ==

<syntaxhighlight lang="bash">
history
history | tail -n 20
</syntaxhighlight>

History can contain sensitive data if you type passwords, tokens, or private URLs directly on the command line. '''Never put a password or API key in a command unless the tool provides a secure method.'''

To search previous commands interactively, press Ctrl+R and type part of a command. Press Ctrl+R again for an older match, Enter to run it, or Ctrl+C to cancel.

== 5.5 Read syntax notation ==

Manuals often use:

* <code>COMMAND [OPTION]... [FILE]...</code>
* Square brackets mean optional.
* Three dots mean an item can be repeated.
* A vertical list separated by <code>|</code> means choose one item.
* Uppercase words such as <code>FILE</code> are placeholders, not literal text.

== Lesson 5 lab ==

# Open the manual for <code>mkdir</code>.
# Search inside it for <code>parents</code>.
# Find the option that creates parent directories.
# Use <code>type</code> on <code>cd</code>, <code>pwd</code>, and <code>ls</code>.
# Use <code>command -v</code> to check for <code>nano</code>, <code>vim</code>, and <code>curl</code>.
# Show only your last ten history entries.

== Lesson 5 review ==

# What is the fastest common option for brief command help?
# Which command opens a manual page?
# Which key exits a manual page?
# What does <code>command -v</code> tell you?
# Why should secrets not appear in command history?

----

= Lesson 6 — Understand permissions and ownership =

'''Goal:''' Read permission strings and protect your own files.

== 6.1 Read a long listing ==

<syntaxhighlight lang="bash">
cd "$HOME/linux-course"
ls -ld .
ls -l
</syntaxhighlight>

A long listing may look like:

<pre>-rwxr-x--- 1 alex support 812 Jul 22 10:30 report.sh</pre>

It contains:

# File type and permissions: <code>-rwxr-x---</code>
# Link count: <code>1</code>
# Owner: <code>alex</code>
# Group: <code>support</code>
# Size in bytes: <code>812</code>
# Last modification time
# Filename: <code>report.sh</code>

[[File:DWShells-Permissions.png|center|frameless|1000px|alt=Diagram explaining Linux owner, group, others, read, write, execute, and numeric permissions]]

== 6.2 File types ==

The first character commonly means:

{| class="wikitable"
|-
! Character
! Type
|-
| <code>-</code>
| Regular file
|-
| <code>d</code>
| Directory
|-
| <code>l</code>
| Symbolic link
|}

== 6.3 Read, write, and execute ==

Permissions are shown for '''owner''', '''group''', and '''others'''.

{| class="wikitable"
|-
! Permission
! On a file
! On a directory
|-
| <code>r</code> — read
| Read file contents.
| List names in the directory, subject to other permissions.
|-
| <code>w</code> — write
| Modify the file.
| Create, delete, or rename entries in the directory.
|-
| <code>x</code> — execute
| Run a program or script.
| Enter/traverse the directory and access known names.
|}

Directory permissions are especially important: read and execute have different jobs.

== 6.4 Change permissions symbolically ==

Create a practice script:

<syntaxhighlight lang="bash">
mkdir -p "$HOME/linux-course/lesson-06"
cd "$HOME/linux-course/lesson-06"
printf '%s\n' '#!/bin/bash' 'echo "Permission test successful"' > test.sh
ls -l test.sh
chmod u+x test.sh
ls -l test.sh
./test.sh
</syntaxhighlight>

Symbolic targets and operations:

* <code>u</code> owner/user, <code>g</code> group, <code>o</code> others, <code>a</code> all.
* <code>+</code> add, <code>-</code> remove, <code>=</code> set exactly.

Examples:

<syntaxhighlight lang="bash">
chmod u+x script.sh
chmod go-rwx private.txt
chmod u=rw,go= notes.txt
chmod g+r shared.txt
</syntaxhighlight>

== 6.5 Numeric permissions ==

The values are:

* read = 4
* write = 2
* execute = 1

Add each set:

{| class="wikitable"
|-
! Number
! Permission
! Common use
|-
| 7
| <code>rwx</code>
| Full access
|-
| 6
| <code>rw-</code>
| Read and write
|-
| 5
| <code>r-x</code>
| Read and execute
|-
| 4
| <code>r--</code>
| Read only
|-
| 0
| <code>---</code>
| No access
|}

Examples:

<syntaxhighlight lang="bash">
chmod 700 private-directory
chmod 600 private.txt
chmod 750 script.sh
chmod 640 shared-report.txt
</syntaxhighlight>

Avoid <code>chmod 777</code>. It allows every local user to modify the item and is almost never the correct fix.

== 6.6 Ownership, groups, and umask ==

<syntaxhighlight lang="bash">
whoami
id
groups
umask
</syntaxhighlight>

* <code>id</code> shows your numeric user ID, group ID, and group memberships.
* <code>chgrp GROUP FILE</code> changes a file's group only when you are permitted to use that group.
* <code>chown</code> changes ownership and normally requires administrator privileges. It is not a learner exercise.
* <code>umask</code> controls which permissions are removed from newly created files and directories.

For SSH files, secure permissions are normally:

<syntaxhighlight lang="bash">
chmod 700 "$HOME/.ssh"
chmod 600 "$HOME/.ssh/authorized_keys"
</syntaxhighlight>

Run those commands only if the paths exist and belong to you.

== Lesson 6 lab ==

In <code>$HOME/linux-course/lesson-06</code>:

# Create <code>private.txt</code> and set it to owner read/write only.
# Create <code>shared.txt</code> and set it to owner read/write, group read, others none.
# Create a directory <code>private-dir</code> with owner-only access.
# Use <code>ls -l</code> and <code>ls -ld</code> to verify all three.
# Remove execute permission from <code>test.sh</code>, try to run it directly, then restore execute permission.
# Display your user and group memberships with <code>id</code>.

== Lesson 6 review ==

# What do the three permission groups represent?
# What is the numeric value of <code>r-x</code>?
# What does execute permission mean on a directory?
# Which command changes permissions?
# Why is <code>777</code> unsafe?

----
= Lesson 7 — Redirect output and build pipelines =

'''Goal:''' Save command output, separate errors, and connect small tools with pipes.

== 7.1 Standard input, output, and error ==

Every command starts with three standard data streams:

{| class="wikitable"
|-
! Stream
! Number
! Normal source or destination
|-
| Standard input (stdin)
| 0
| Your keyboard
|-
| Standard output (stdout)
| 1
| Your terminal
|-
| Standard error (stderr)
| 2
| Your terminal
|}

Redirection changes where these streams go.

== 7.2 Replace or append a file ==

<syntaxhighlight lang="bash">
mkdir -p "$HOME/linux-course/lesson-07"
cd "$HOME/linux-course/lesson-07"
printf '%s\n' "first line" > output.txt
printf '%s\n' "second line" >> output.txt
cat output.txt
</syntaxhighlight>

* <code>></code> creates a file or '''replaces all existing content'''.
* <code>>></code> creates a file or appends to the end.

Always inspect an important filename before using <code>></code>.

Save command output:

<syntaxhighlight lang="bash">
date > current-date.txt
ls -lah "$HOME" > home-listing.txt
</syntaxhighlight>

== 7.3 Redirect errors ==

<syntaxhighlight lang="bash">
touch existing-file
ls existing-file missing-file > normal.txt 2> errors.txt
cat normal.txt
cat errors.txt
</syntaxhighlight>

Combine normal output and errors:

<syntaxhighlight lang="bash">
ls existing-file missing-file > everything.txt 2>&1
</syntaxhighlight>

Discard output only when you intentionally do not need it:

<syntaxhighlight lang="bash">
command -v nano > /dev/null 2>&1
echo "$?"
</syntaxhighlight>

<code>/dev/null</code> discards data. The value <code>$?</code> is the previous command's exit status: <code>0</code> usually means success and a non-zero value means an error or another special result.

== 7.4 Pipes ==

A pipe <code>|</code> sends one command's standard output to the next command's standard input.

[[File:DWShells-Pipeline.png|center|frameless|1000px|alt=Diagram showing cat output piped through grep and then wc to count matching lines]]

Create safe practice data:

<syntaxhighlight lang="bash">
printf '%s\n' \
"INFO login accepted" \
"ERROR invalid password" \
"INFO session opened" \
"ERROR disk quota warning" \
"INFO session closed" > activity.log
</syntaxhighlight>

Now build pipelines:

<syntaxhighlight lang="bash">
cat activity.log | grep "ERROR"
grep "ERROR" activity.log | wc -l
sort activity.log
sort activity.log | uniq
</syntaxhighlight>

<code>grep "ERROR" activity.log</code> is more direct than piping <code>cat</code> into <code>grep</code>, but both forms help demonstrate the data flow.

== 7.5 Useful filter commands ==

{| class="wikitable"
|-
! Command
! Purpose
! Example
|-
| <code>grep</code>
| Keep lines matching a pattern.
| <code>grep -i "error" activity.log</code>
|-
| <code>sort</code>
| Sort lines.
| <code>sort names.txt</code>
|-
| <code>uniq</code>
| Remove or count adjacent duplicate lines.
| <code>sort names.txt | uniq -c</code>
|-
| <code>wc</code>
| Count lines, words, or bytes.
| <code>wc -l activity.log</code>
|-
| <code>cut</code>
| Select delimited fields.
| <code>cut -d: -f1 /etc/passwd</code>
|-
| <code>tr</code>
| Translate or delete characters.
| <code>printf 'hello\n' | tr 'a-z' 'A-Z'</code>
|-
| <code>tee</code>
| Display and save output at the same time.
| <code>date | tee date.txt</code>
|}

The <code>/etc/passwd</code> example displays local account names from a normally public system file. It does not reveal passwords; modern Linux stores password hashes elsewhere with restricted access.

== Lesson 7 lab ==

# Create a file containing at least six lines, including three lines with the word <code>PASS</code> and two with <code>FAIL</code>.
# Display only <code>FAIL</code> lines, ignoring case.
# Count the <code>PASS</code> lines using a pipeline.
# Save the sorted content to <code>sorted.txt</code>.
# Append the current date to <code>sorted.txt</code>.
# Run a command using a nonexistent filename and save its error to <code>error.txt</code>.
# Use <code>tee</code> to display and save <code>whoami</code>.

== Lesson 7 review ==

# What is the difference between <code>></code> and <code>>></code>?
# Which number represents standard error?
# What does a pipe do?
# Why is <code>sort</code> often placed before <code>uniq</code>?
# What does exit status zero usually mean?

----

= Lesson 8 — Search, match, and quote safely =

'''Goal:''' Locate files and text without scanning the whole server, and understand how the shell treats special characters.

== 8.1 Search text with grep ==

<syntaxhighlight lang="bash">
grep "ERROR" "$HOME/linux-course/lesson-07/activity.log"
grep -i "error" "$HOME/linux-course/lesson-07/activity.log"
grep -n "INFO" "$HOME/linux-course/lesson-07/activity.log"
grep -v "INFO" "$HOME/linux-course/lesson-07/activity.log"
</syntaxhighlight>

Common options:

* <code>-i</code> — ignore letter case.
* <code>-n</code> — show line numbers.
* <code>-v</code> — show non-matching lines.
* <code>-r</code> — search directories recursively.
* <code>-l</code> — show filenames containing a match.

Search only your course directory:

<syntaxhighlight lang="bash">
grep -Rin "linux" "$HOME/linux-course"
</syntaxhighlight>

Avoid broad recursive searches from <code>/</code>. They are slow, generate permission errors, and consume shared server resources.

== 8.2 Find files by name and type ==

<syntaxhighlight lang="bash">
find "$HOME/linux-course" -type f -name "*.txt"
find "$HOME/linux-course" -type d -name "lesson-*"
find "$HOME/linux-course" -type f -size +1k
find "$HOME/linux-course" -type f -mtime -1
</syntaxhighlight>

* <code>-type f</code> — regular files.
* <code>-type d</code> — directories.
* <code>-name</code> — case-sensitive name pattern.
* <code>-iname</code> — case-insensitive name pattern.
* <code>-size +1k</code> — larger than 1 KiB.
* <code>-mtime -1</code> — modified within about the last day.

Keep the search starting point narrow. Search <code>$HOME</code> or a project directory, not the entire server.

== 8.3 Shell expansion and quoting ==

Before a command runs, Bash processes variables, wildcards, quotes, and substitutions.

<syntaxhighlight lang="bash">
course="Linux Basics"
printf '%s\n' "$course"
printf '%s\n' '$course'
</syntaxhighlight>

Output:

<pre>Linux Basics
$course</pre>

{| class="wikitable"
|-
! Form
! Behavior
|-
| <code>"double quotes"</code>
| Preserve spaces but expand variables and command substitutions.
|-
| <code>'single quotes'</code>
| Treat nearly everything literally.
|-
| <code>\</code>
| Escape the next special character outside single quotes.
|-
| Unquoted text
| May be split at spaces and expanded as a wildcard.
|}

Correctly handle spaces in names:

<syntaxhighlight lang="bash">
mkdir -p "$HOME/linux-course/lesson 08"
touch "$HOME/linux-course/lesson 08/my notes.txt"
ls -l "$HOME/linux-course/lesson 08/my notes.txt"
</syntaxhighlight>

Quoting variables is a vital habit:

<syntaxhighlight lang="bash">
file="$HOME/linux-course/lesson 08/my notes.txt"
cat "$file"
</syntaxhighlight>

== 8.4 Command substitution ==

Command substitution places output inside another command:

<syntaxhighlight lang="bash">
today="$(date +%F)"
printf 'Today is %s\n' "$today"
</syntaxhighlight>

The modern <code>$(command)</code> form is easier to read and nest than old backquote syntax.

== 8.5 Environment variables ==

<syntaxhighlight lang="bash">
printf '%s\n' "$HOME"
printf '%s\n' "$USER"
printf '%s\n' "$SHELL"
printf '%s\n' "$PATH"
env | sort | less
</syntaxhighlight>

<code>PATH</code> is the list of directories Bash searches for commands. Do not add unsafe or world-writable directories to it.

== Lesson 8 lab ==

# Find all <code>.txt</code> files inside <code>$HOME/linux-course</code>.
# Search those course files recursively for the word <code>DWShells</code>, ignoring case.
# Create a directory containing a space and a file containing a space.
# Store that file's full path in a variable and display it using correct quoting.
# Store the current date in <code>today</code> using command substitution.
# Print <code>Course date: YYYY-MM-DD</code> using that variable.

== Lesson 8 review ==

# Why should a <code>find</code> search start from a narrow directory?
# What is the difference between <code>grep -i</code> and <code>grep -v</code>?
# Do variables expand inside single quotes?
# Why should path variables normally be double-quoted?
# What does <code>$(date +%F)</code> do?

----

= Lesson 9 — Manage your processes and jobs =

'''Goal:''' Inspect your own programs, use foreground and background jobs, and stop a process gracefully.

== 9.1 What is a process? ==

A process is a running instance of a program. Every process has a process ID, or '''PID''', an owner, resource usage, and a state.

View your processes:

<syntaxhighlight lang="bash">
ps
ps -u "$USER"
ps -f -u "$USER"
pgrep -a -u "$USER" .
</syntaxhighlight>

The dot is a regular-expression pattern that matches process names. This command is an alternative that does not require <code>pgrep</code>:

<syntaxhighlight lang="bash">
ps -f -u "$USER"
</syntaxhighlight>

For a live display:

<syntaxhighlight lang="bash">
top -u "$USER"
</syntaxhighlight>

Press <code>q</code> to leave <code>top</code>.

== 9.2 Foreground and background jobs ==

Start a harmless practice command:

<syntaxhighlight lang="bash">
sleep 300
</syntaxhighlight>

Press Ctrl+Z to suspend it, then:

<syntaxhighlight lang="bash">
jobs
bg
jobs
fg
</syntaxhighlight>

Press Ctrl+C to stop it.

Start directly in the background:

<syntaxhighlight lang="bash">
sleep 10 &
jobs
wait
</syntaxhighlight>

* <code>&</code> starts a command as a background job.
* <code>jobs</code> shows jobs started from the current shell.
* <code>fg</code> brings a job to the foreground.
* <code>bg</code> continues a suspended job in the background.
* <code>wait</code> waits for background jobs to finish.

== 9.3 Stop processes safely ==

First identify the correct PID and confirm it belongs to you:

<syntaxhighlight lang="bash">
ps -f -u "$USER"
kill PID
</syntaxhighlight>

Plain <code>kill PID</code> sends SIGTERM, a request to exit cleanly. If the program remains after you wait and recheck, SIGKILL is a last resort:

<syntaxhighlight lang="bash">
kill -KILL PID
</syntaxhighlight>

SIGKILL prevents cleanup and may corrupt data. Never signal a PID that you have not verified. Normal users cannot manage another user's protected processes.

You can stop a process by a matching name that belongs to you, but verify carefully:

<syntaxhighlight lang="bash">
pgrep -a -u "$USER" sleep
pkill -u "$USER" -x sleep
</syntaxhighlight>

== 9.4 Resource responsibility ==

DWShells is shared. A process that uses excessive CPU, memory, disk, network traffic, or process slots harms other learners.

* Run only software allowed by the DWShells Acceptable Use Policy.
* Stop experiments when you finish.
* Do not create fork bombs or uncontrolled loops.
* Do not run cryptocurrency miners, scanners, attacks, spam, proxies, or unauthorized public services.
* Use persistent background programs only when your account plan and DWShells staff permit them.

<code>nohup</code>, terminal multiplexers, schedulers, and long-running services are useful tools, but their availability does not mean every use is allowed. Check policy first.

== 9.5 Administrator services ==

You may see tutorials using:

<syntaxhighlight lang="bash">
systemctl status SERVICE
journalctl -u SERVICE
</syntaxhighlight>

These are service-administration tools. Some read-only views may work, but changing services requires authorization and is outside this beginner shell course. Do not try to bypass account restrictions.

== Lesson 9 lab ==

# Start <code>sleep 180</code> in the foreground.
# Suspend it with Ctrl+Z.
# Continue it in the background.
# Show it with <code>jobs</code> and <code>ps</code>.
# Bring it back with <code>fg</code>.
# Stop it with Ctrl+C.
# Start <code>sleep 120 &</code>, find its PID, and stop it using normal <code>kill</code>.
# Confirm that no practice <code>sleep</code> process remains.

== Lesson 9 review ==

# What does PID mean?
# What is the difference between <code>jobs</code> and <code>ps</code>?
# Which signal does plain <code>kill PID</code> normally send?
# Why is SIGKILL a last resort?
# Why must long-running programs follow DWShells policy?

----

= Lesson 10 — Inspect the system, use network tools, and transfer files =

'''Goal:''' Gather read-only system information, perform limited connectivity checks, create archives, and move files securely.

== 10.1 System information ==

<syntaxhighlight lang="bash">
cat /etc/os-release
uname -r
uname -m
hostname
uptime
date
</syntaxhighlight>

* <code>/etc/os-release</code> identifies Debian and its version.
* <code>uname -r</code> shows the kernel release.
* <code>uname -m</code> shows the hardware architecture.
* <code>uptime</code> shows how long the server has run and its load averages.

Load average is not simply a CPU percentage. It represents work running or waiting; interpretation depends on CPU count and workload.

== 10.2 Memory, disk, and quota ==

<syntaxhighlight lang="bash">
free -h
df -h "$HOME"
du -sh "$HOME/linux-course"
du -h --max-depth=1 "$HOME/linux-course" | sort -h
quota -s
</syntaxhighlight>

* <code>free -h</code> summarizes system memory.
* <code>df -h</code> shows filesystem capacity and free space.
* <code>du -sh</code> measures the space used by a directory.
* <code>quota -s</code> shows your assigned quota when quotas and the command are enabled.

Do not run broad <code>du</code> searches over the whole server. Measure only paths you own or need.

== 10.3 Read-only network checks ==

Availability depends on DWShells policy:

<syntaxhighlight lang="bash">
ip address show
getent hosts darkworld.network
ping -c 4 darkworld.network
curl -I https://darkworld.network/
</syntaxhighlight>

* <code>ip address show</code> displays configured interfaces and addresses.
* <code>getent hosts</code> resolves a hostname using system configuration.
* <code>ping -c 4</code> sends four ICMP echo requests; some sites block them.
* <code>curl -I</code> retrieves HTTP response headers without downloading the page body.

These tools are for legitimate troubleshooting. Do not probe addresses, enumerate ports, bypass filters, or scan systems without explicit authorization.

== 10.4 Create and inspect tar archives ==

Prepare an archive:

<syntaxhighlight lang="bash">
cd "$HOME/linux-course"
tar -czf lesson-04-backup.tar.gz lesson-04/
tar -tzf lesson-04-backup.tar.gz
</syntaxhighlight>

Options:

* <code>-c</code> create an archive.
* <code>-t</code> list archive contents.
* <code>-x</code> extract.
* <code>-z</code> use gzip compression.
* <code>-f</code> the next argument is the archive filename.

Extract into a new, empty directory:

<syntaxhighlight lang="bash">
mkdir -p "$HOME/linux-course/restore-test"
tar -xzf lesson-04-backup.tar.gz -C "$HOME/linux-course/restore-test"
find "$HOME/linux-course/restore-test" -maxdepth 2 -type f
</syntaxhighlight>

List an untrusted archive before extraction. Archives can contain unexpected paths or links. Ask staff before extracting unknown downloads.

If installed, ZIP commands are:

<syntaxhighlight lang="bash">
zip -r lesson-04.zip lesson-04/
unzip -l lesson-04.zip
</syntaxhighlight>

== 10.5 Copy files with SCP ==

Run these commands on '''your local computer''', not inside the existing SSH session.

Upload a local file:

<syntaxhighlight lang="bash">
scp local-notes.txt USERNAME@shells.darkworld.network:~/linux-course/
</syntaxhighlight>

Download your archive:

<syntaxhighlight lang="bash">
scp USERNAME@shells.darkworld.network:~/linux-course/lesson-04-backup.tar.gz .
</syntaxhighlight>

With a custom SSH port, SCP uses uppercase <code>-P</code>:

<syntaxhighlight lang="bash">
scp -P PORT_NUMBER local-notes.txt USERNAME@shells.darkworld.network:~/linux-course/
</syntaxhighlight>

Note the difference: SSH uses lowercase <code>-p</code>, while SCP uses uppercase <code>-P</code>.

For an interactive file-transfer session:

<syntaxhighlight lang="bash">
sftp USERNAME@shells.darkworld.network
</syntaxhighlight>

Useful SFTP commands include <code>pwd</code>, <code>lpwd</code>, <code>ls</code>, <code>lls</code>, <code>put</code>, <code>get</code>, and <code>exit</code>. Commands beginning with <code>l</code> refer to the local computer.

== Lesson 10 lab ==

# Record the Debian version, kernel version, architecture, hostname, and date in <code>$HOME/linux-course/lesson-10-system.txt</code>.
# Measure the size of your course directory.
# Check available space on the filesystem containing your home directory.
# Resolve <code>darkworld.network</code> using <code>getent</code>.
# Create a compressed tar archive of one lesson directory.
# List its content without extracting it.
# Extract it into a new <code>restore-test</code> directory and compare the restored files.
# If you have a local SSH client, download the archive with SCP.

== Lesson 10 review ==

# Which file identifies the Debian release?
# What is the difference between <code>df</code> and <code>du</code>?
# Why can a failed <code>ping</code> be inconclusive?
# Which tar option lists an archive?
# Which SCP option specifies a custom port?

----

= Lesson 11 — Write your first Bash scripts =

'''Goal:''' Combine commands into a reusable script with variables, input, tests, and a loop.

== 11.1 A first script ==

Create a script:

<syntaxhighlight lang="bash">
mkdir -p "$HOME/linux-course/lesson-11"
cd "$HOME/linux-course/lesson-11"
nano hello.sh
</syntaxhighlight>

Enter:

<syntaxhighlight lang="bash">
#!/bin/bash

echo "Hello, $USER"
echo "Your home directory is $HOME"
echo "Today is $(date +%F)"
</syntaxhighlight>

Save, then run it:

<syntaxhighlight lang="bash">
chmod u+x hello.sh
./hello.sh
</syntaxhighlight>

The first line is the '''shebang'''. It tells Linux to run the file with Bash. <code>./</code> means “the file in the current directory.”

You can also run a script without execute permission by explicitly starting Bash:

<syntaxhighlight lang="bash">
bash hello.sh
</syntaxhighlight>

== 11.2 Variables and arguments ==

Create <code>greet.sh</code>:

<syntaxhighlight lang="bash">
#!/bin/bash

name="$1"

if [ -z "$name" ]; then
echo "Usage: $0 NAME" >&2
exit 1
fi

echo "Welcome to DWShells, $name!"
exit 0
</syntaxhighlight>

Run:

<syntaxhighlight lang="bash">
chmod u+x greet.sh
./greet.sh
./greet.sh "New Learner"
echo "$?"
</syntaxhighlight>

* <code>$0</code> — the script name.
* <code>$1</code> — the first argument.
* <code>-z</code> — true when a string is empty.
* <code>>&2</code> — send the usage message to standard error.
* <code>exit 0</code> — success; <code>exit 1</code> — failure.

== 11.3 Tests ==

Common safe tests:

{| class="wikitable"
|-
! Test
! Meaning
|-
| <code>[ -f "$path" ]</code>
| A regular file exists.
|-
| <code>[ -d "$path" ]</code>
| A directory exists.
|-
| <code>[ -r "$path" ]</code>
| The path is readable.
|-
| <code>[ -w "$path" ]</code>
| The path is writable.
|-
| <code>[ "$a" = "$b" ]</code>
| Two strings are equal.
|-
| <code>[ "$number" -gt 10 ]</code>
| The integer is greater than 10.
|}

Spaces after <code>[</code> and before <code>]</code> are required.

== 11.4 Loops ==

Create three files and report their line counts:

<syntaxhighlight lang="bash">
printf '%s\n' "one" > one.txt
printf '%s\n' "one" "two" > two.txt
printf '%s\n' "one" "two" "three" > three.txt

for file in *.txt; do
printf '%s: ' "$file"
wc -l < "$file"
done
</syntaxhighlight>

Because <code>"$file"</code> is quoted, names containing spaces are handled safely.

== 11.5 A practical system report ==

Create <code>system-report.sh</code>:

<syntaxhighlight lang="bash">
#!/bin/bash

set -u

output="$HOME/linux-course/system-report.txt"

{
echo "DWShells learner system report"
echo "Generated: $(date --iso-8601=seconds)"
echo "User: $USER"
echo "Host: $(hostname)"
echo "Kernel: $(uname -r)"
echo "Architecture: $(uname -m)"
echo "Home: $HOME"
echo
echo "Course directory size:"
du -sh "$HOME/linux-course"
echo
echo "Home filesystem:"
df -h "$HOME"
} > "$output"

chmod 600 "$output"
echo "Report written to $output"
</syntaxhighlight>

Run and inspect:

<syntaxhighlight lang="bash">
chmod u+x system-report.sh
bash -n system-report.sh
./system-report.sh
less "$HOME/linux-course/system-report.txt"
</syntaxhighlight>

<code>bash -n</code> checks Bash syntax without running the script. It cannot detect every logical problem, so still review the code.

== 11.6 Script safety habits ==

* Quote variables: <code>"$file"</code>, <code>"$HOME"</code>, <code>"$1"</code>.
* Validate required arguments and paths.
* Use absolute paths or known directories for important data.
* Do not put passwords, tokens, or private keys inside scripts.
* Avoid recursive deletion in early scripts.
* Check exit statuses when failure matters.
* Run <code>bash -n script.sh</code> before the first execution.
* Read every downloaded script before running it.

== Lesson 11 lab ==

# Create an executable script named <code>course-summary.sh</code>.
# Make it print the current user, date, working directory, Debian version, and course-directory size.
# Accept one argument as the learner's display name.
# If no name is supplied, print a usage message to standard error and exit non-zero.
# Write the report to <code>$HOME/linux-course/summary.txt</code>.
# Set the report to permission <code>600</code>.
# Check the script with <code>bash -n</code>, run it, and inspect the result.

== Lesson 11 review ==

# What is a shebang?
# Why is <code>./</code> used to run a script in the current directory?
# What do <code>$0</code> and <code>$1</code> represent?
# What exit status normally means success?
# Why should variables containing paths be quoted?

----

= Lesson 12 — Secure your account and complete the final project =

'''Goal:''' Use SSH keys safely, recognize risky behavior, follow shared-server rules, and demonstrate the skills learned.

== 12.1 Account security ==

* Use a unique, long password that you do not use on another website.
* Never share your DWShells account.
* Do not send passwords or private keys through IRC, email, screenshots, or paste sites.
* Check the hostname and SSH host-key warning before entering credentials.
* Log out from computers you do not control.
* Keep your local computer and SSH client updated.
* Report unexpected logins, altered files, or host-key changes to DWShells staff.

Change your password, if the service permits:

<syntaxhighlight lang="bash">
passwd
</syntaxhighlight>

The command asks for the current password and then the new password twice. None of them are displayed.

== 12.2 SSH keys ==

Generate a modern key on '''your local computer''':

<syntaxhighlight lang="bash">
ssh-keygen -t ed25519 -a 64
</syntaxhighlight>

Choose a strong passphrase. The private key stays on your computer. The public key, usually ending in <code>.pub</code>, may be added to the server.

If supported:

<syntaxhighlight lang="bash">
ssh-copy-id USERNAME@shells.darkworld.network
</syntaxhighlight>

Or copy the single public-key line into:

<pre>$HOME/.ssh/authorized_keys</pre>

Then secure the paths:

<syntaxhighlight lang="bash">
chmod 700 "$HOME/.ssh"
chmod 600 "$HOME/.ssh/authorized_keys"
</syntaxhighlight>

'''Never upload or share the private-key file.''' Public keys may be shared for access setup; private keys must remain private.

== 12.3 Recognize dangerous command patterns ==

Pause and investigate commands that:

* download something and immediately pipe it into <code>sh</code> or <code>bash</code>;
* use <code>sudo</code>, <code>su</code>, or request administrator credentials;
* contain broad recursive deletion;
* change many permissions to <code>777</code>;
* hide output and errors while making system changes;
* use encoded or deliberately unreadable text;
* ask for your password, token, cookie, private key, or wallet;
* start scanners, miners, proxies, spam, denial-of-service tools, or unexplained background programs.

A command being popular online does not make it safe for a shared server.

== 12.4 Shared-shell responsibility ==

Follow the current DWShells Acceptable Use Policy and the limits of your free or support account. At minimum:

* Use only resources assigned to your account.
* Do not try to read, modify, or enter another user's private data.
* Do not evade quotas, restrictions, monitoring, or network controls.
* Do not scan, attack, exploit, spam, phish, mine cryptocurrency, or host prohibited content.
* Do not expose public services without approval.
* Keep permissions restrictive and remove abandoned data and processes.
* Contact staff before an experiment that may create unusual resource or network use.

Technical ability is not permission. If a command works but policy does not allow it, do not use it.

== Lesson 12 lab — Final project: Learner system report package ==

Build a safe project that demonstrates the course.

=== Required structure ===

<pre>
linux-final/
├── README.txt
├── bin/
│ └── learner-report.sh
├── output/
│ └── learner-report.txt
└── notes/
└── commands.txt
</pre>

=== Requirements ===

# Create the structure inside <code>$HOME/linux-course/linux-final</code>.
# Write <code>README.txt</code> explaining the project's purpose and how to run it.
# Write <code>notes/commands.txt</code> containing ten useful commands from this course and a one-line explanation of each.
# Write <code>bin/learner-report.sh</code>.
# The script must accept the learner's display name as its first argument.
# When the argument is missing, it must show usage and exit non-zero.
# The report must include:
## learner display name;
## DWShells username;
## hostname;
## current date in ISO format;
## Debian version;
## kernel release and architecture;
## home directory;
## course-directory disk usage;
## home-filesystem free space.
# The script must write <code>output/learner-report.txt</code>.
# The script must quote variables and must not use <code>sudo</code>, <code>su</code>, broad searches, or destructive commands.
# Set the script to <code>700</code> and its report to <code>600</code>.
# Check it using <code>bash -n</code>.
# Run it twice to prove it can safely replace its own report.
# Create <code>$HOME/linux-course/linux-final.tar.gz</code>.
# List the archive content and extract it into a separate test directory.
# Confirm that the restored project contains all required files.

=== Suggested commands to begin ===

<syntaxhighlight lang="bash">
mkdir -p "$HOME/linux-course/linux-final"/{bin,output,notes}
cd "$HOME/linux-course/linux-final"
touch README.txt notes/commands.txt
nano bin/learner-report.sh
</syntaxhighlight>

The brace expression creates the three directories under the same parent. If you prefer, create each one with a separate <code>mkdir</code> command.

=== Self-check ===

<syntaxhighlight lang="bash">
cd "$HOME/linux-course/linux-final"
find . -maxdepth 3 -print | sort
ls -l bin/learner-report.sh output/learner-report.txt
bash -n bin/learner-report.sh
bin/learner-report.sh "Your Display Name"
cat output/learner-report.txt
cd "$HOME/linux-course"
tar -czf linux-final.tar.gz linux-final/
tar -tzf linux-final.tar.gz
</syntaxhighlight>

== Lesson 12 review ==

# Where should an SSH private key be stored and who may receive it?
# What permissions are recommended for <code>~/.ssh</code> and <code>authorized_keys</code>?
# Why is piping a new download directly to Bash risky?
# Does technical access automatically grant permission?
# What should you do when a planned activity may create unusual server load?

----

= Command cheat sheet =

{| class="wikitable sortable" style="width:100%;"
|-
! Task
! Command example
|-
| Show current directory
| <code>pwd</code>
|-
| List all files in detail
| <code>ls -lah</code>
|-
| Return home
| <code>cd</code>
|-
| Create nested directories
| <code>mkdir -p project/docs</code>
|-
| Create an empty file
| <code>touch notes.txt</code>
|-
| Copy a file safely
| <code>cp -i source destination</code>
|-
| Move or rename safely
| <code>mv -i old new</code>
|-
| Remove with confirmation
| <code>rm -i file</code>
|-
| Read a long text file
| <code>less file</code>
|-
| Edit a text file
| <code>nano file</code>
|-
| Search text
| <code>grep -in "word" file</code>
|-
| Find files in your home
| <code>find "$HOME" -type f -name "*.txt"</code>
|-
| Count lines
| <code>wc -l file</code>
|-
| View permissions
| <code>ls -l file</code>
|-
| Protect a private file
| <code>chmod 600 file</code>
|-
| Make your script executable
| <code>chmod u+x script.sh</code>
|-
| Show your processes
| <code>ps -f -u "$USER"</code>
|-
| Stop your process gracefully
| <code>kill PID</code>
|-
| Measure a directory
| <code>du -sh directory</code>
|-
| Check filesystem space
| <code>df -h "$HOME"</code>
|-
| Create a compressed archive
| <code>tar -czf backup.tar.gz directory/</code>
|-
| List an archive
| <code>tar -tzf backup.tar.gz</code>
|-
| Check Bash syntax
| <code>bash -n script.sh</code>
|-
| Log out
| <code>exit</code>
|}

= Beginner glossary =

{| class="wikitable sortable" style="width:100%;"
|-
! Term
! Meaning
|-
| Argument
| The target or value supplied to a command.
|-
| Bash
| A common command shell and scripting language.
|-
| Command
| An instruction executed by the shell.
|-
| Current directory
| The directory in which your shell is presently working.
|-
| Debian
| The Linux distribution used by DWShells.
|-
| Directory
| A container for files and other directories.
|-
| Environment variable
| A named value, such as <code>HOME</code> or <code>PATH</code>, available to programs.
|-
| Exit status
| A numeric result from a command; zero normally means success.
|-
| Filesystem
| The organized tree of files and directories beginning at <code>/</code>.
|-
| Home directory
| A user's personal workspace, represented by <code>~</code> and <code>$HOME</code>.
|-
| Option
| A switch that changes command behavior, such as <code>-l</code>.
|-
| Path
| A file or directory location.
|-
| Permission
| A rule controlling read, write, or execute access.
|-
| PID
| Process ID: the unique numeric identifier of a running process.
|-
| Pipe
| The <code>|</code> operator that sends one command's output to another command.
|-
| Process
| A running instance of a program.
|-
| Prompt
| The shell's signal that it is ready for a command.
|-
| root directory
| <code>/</code>, the top of the filesystem tree.
|-
| root user
| The system administrator account; different from the root directory.
|-
| Shell
| A program that reads commands and starts programs.
|-
| SSH
| An encrypted protocol for secure remote shell access.
|-
| Standard error
| A stream used for diagnostic and error messages.
|-
| Standard input
| A stream from which a command reads data.
|-
| Standard output
| A stream to which a command writes normal results.
|-
| Terminal
| The application or interface used to interact with a shell.
|}

= Where to go next =

After completing the final project, good next topics are:

* Intermediate Bash scripting and error handling.
* Git version control.
* Text processing with <code>sed</code> and <code>awk</code>.
* Secure use of SSH keys and agents.
* Linux networking fundamentals.
* System administration in a dedicated lab virtual machine where you are authorized to use <code>sudo</code>.

Practise administration in your own disposable virtual machine, not in a shared DWShells account. Keep using <code>man</code>, <code>--help</code>, small tests, restrictive permissions, and verified backups.

'''Course complete — welcome to the Linux command line!'''

----

''DWTutorials Linux Basics for Beginners — © 2026 DarkWorld Network. All rights reserved.''

[[Category:DWTutorials]]
[[Category:DWShells]]
[[Category:Linux]]
[[Category:Debian]]
[[Category:Beginner courses]]

2026-07-21T21:20:46Z

Fizi:

{{DISPLAYTITLE:DWTutorials Linux Basics — Instructor Answer Key}}
__NOTOC__

= Instructor Answer Key =

'''For DWShells staff and course mentors'''

This page supports the student course {{DISPLAYTITLE:DWTutorials:Linux Basics for Beginners}}. Protect it if you do not want learners to see suggested answers before completing their work.

'''Copyright:''' © 2026 DarkWorld Network. All rights reserved.

== Assessment model ==

{| class="wikitable"
|-
! Component
! Weight
! Evidence
|-
| Lesson review questions
| 30%
| Accurate explanations in the learner's own words
|-
| Hands-on labs
| 40%
| Correct files, command output, permissions, and safe working habits
|-
| Final project
| 30%
| Script, report, documentation, permissions, archive, and restore test
|}

Suggested pass mark: '''70%'''. Safety violations should be corrected before the learner passes, even if the numeric score is high.

Accept equivalent commands when they are safe and produce the required outcome. Do not require output to match usernames, paths, dates, process IDs, hostnames, package versions, or file sizes shown in the course.

----

= Lesson 1 answers =

# A '''terminal''' is the interface/application used to enter commands; a '''shell''' is the program that interprets those commands.
# SSH (Secure Shell).
# Linux deliberately does not echo password characters, reducing information visible to someone watching.
# <code>pwd</code>.
# Ctrl+C.

'''Lab check:''' Learner can connect, identify the current user and host, print the requested sentence, recall history with the Up arrow, log out with <code>exit</code>, and reconnect.

= Lesson 2 answers =

# <code>/</code> is the top of the filesystem; <code>/root</code> is normally the root administrator's home directory.
# The current user's home directory.
# <code>-a</code>.
# Absolute, because it begins with <code>/</code>.
# <code>.</code> is the current directory; <code>..</code> is its parent.

'''Lab check:''' Ask the learner to move to <code>/etc</code>, report <code>pwd</code>, return home, and explain why <code>cd -</code> may produce a different location than <code>cd ..</code>.

= Lesson 3 answers =

# <code>mkdir -p</code>.
# <code>cp -r SOURCE DESTINATION</code>.
# <code>mv</code>.
# It asks before removal and helps prevent an accidental deletion.
# Non-hidden names ending in <code>.txt</code> in the selected directory.

'''Expected lab structure:'''

<pre>
lesson-03/
├── activity.log
├── one.txt
└── practice/
├── archive/
│ └── activity.log
├── one.txt
└── two.txt
</pre>

The top-level <code>two.txt</code> should have been removed. Extra files from earlier examples are acceptable.

= Lesson 4 answers =

# <code>less</code> is better for long content because it supports paging and searching.
# <code>q</code>.
# Ctrl+O.
# <code>head</code> displays the beginning; <code>tail</code> displays the end.
# The compared files are identical.

'''Lab check:''' <code>profile.txt</code> contains the requested content. The learner can save and exit Nano, select first/last lines, count lines, and explain the <code>diff -u</code> result.

= Lesson 5 answers =

# <code>--help</code>.
# <code>man COMMAND</code>.
# <code>q</code>.
# Whether a command exists and what executable, builtin, function, or alias the shell will use.
# They may be saved in history and exposed later.

'''Lab check:''' The learner identifies <code>mkdir -p</code>, understands that <code>cd</code> is a shell builtin, and uses <code>history | tail -n 10</code> or an equivalent safe command.

= Lesson 6 answers =

# Owner, group, and others.
# 5: read (4) plus execute (1).
# It permits traversal/entry and access to known names, subject to other directory permissions.
# <code>chmod</code>.
# It grants read, write, and execute permissions to everyone, allowing unauthorized modification.

'''Expected permissions:'''

<pre>-rw------- private.txt
-rw-r----- shared.txt
drwx------ private-dir</pre>

The learner should demonstrate the difference between <code>ls -l</code> and <code>ls -ld</code> for a directory.

= Lesson 7 answers =

# <code>></code> replaces/truncates; <code>>></code> appends.
# 2.
# It connects one command's standard output to the next command's standard input.
# <code>uniq</code> normally recognizes only adjacent duplicates, so sorting brings equal lines together.
# Success.

'''Lab check:''' The learner can use <code>grep -i</code>, <code>wc -l</code>, <code>sort</code>, <code>>></code>, <code>2></code>, and <code>tee</code>, and can explain where normal and error output went.

= Lesson 8 answers =

# To avoid slow, resource-intensive traversal and irrelevant permission errors.
# <code>-i</code> ignores case; <code>-v</code> inverts the match.
# No.
# To preserve the entire value as one argument and prevent wildcard expansion or word splitting.
# It runs <code>date +%F</code> and substitutes its YYYY-MM-DD output.

'''Lab check:''' The learner creates and accesses a filename containing a space without accidental splitting, and uses a quoted variable correctly.

= Lesson 9 answers =

# Process ID.
# <code>jobs</code> shows jobs associated with the current shell; <code>ps</code> queries system processes according to its options.
# SIGTERM.
# It prevents the process from cleaning up files, locks, and state.
# The server is shared, resource limits protect everyone, and technical availability is not authorization.

'''Lab check:''' No practice <code>sleep</code> process should remain. The learner must verify ownership and PID before sending a signal.

= Lesson 10 answers =

# <code>/etc/os-release</code>.
# <code>df</code> reports filesystem capacity; <code>du</code> estimates space used by files/directories.
# ICMP may be filtered even while the destination and other services are available.
# <code>-t</code>.
# Uppercase <code>-P</code>.

'''Lab check:''' The archive lists and extracts successfully into a separate directory. The original data remains unchanged. If SCP cannot be tested, the learner should still explain local and remote sides correctly.

= Lesson 11 answers =

# The first line that selects the script interpreter, such as <code>#!/bin/bash</code>.
# The current directory is not normally searched through <code>PATH</code>; <code>./</code> names the path explicitly.
# <code>$0</code> is the script name and <code>$1</code> is the first argument.
# 0.
# To preserve spaces and prevent unintended splitting or wildcard expansion.

'''Lab check:''' <code>course-summary.sh</code> passes <code>bash -n</code>, rejects a missing name with a non-zero exit status, writes the required fields, and sets the output to <code>600</code>.

= Lesson 12 answers =

# The private key stays on the learner's local device and is never shared. Only the public key is installed on the server or sent to authorized staff.
# <code>700</code> for <code>~/.ssh</code> and <code>600</code> for <code>authorized_keys</code>.
# The downloaded content runs before the learner has inspected or verified it.
# No. Technical access is not authorization.
# Stop and ask DWShells staff before proceeding.

'''Lab check:''' The learner can explain host-key checking, password/key privacy, safe permissions, shared-resource responsibility, and why policy applies even to technically possible actions.

----

= Final project reference implementation =

This is one valid implementation of <code>bin/learner-report.sh</code>. Learners may organize their code differently.

<syntaxhighlight lang="bash">
#!/bin/bash

set -u
umask 077

if [ "$#" -ne 1 ]; then
echo "Usage: $0 DISPLAY_NAME" >&2
exit 1
fi

display_name="$1"
script_dir="$(cd -- "$(dirname -- "$0")" && pwd)"
project_dir="$(dirname -- "$script_dir")"
output_dir="$project_dir/output"
output="$output_dir/learner-report.txt"

mkdir -p "$output_dir"

if [ -r /etc/os-release ]; then
debian_version="$(. /etc/os-release; printf '%s' "$PRETTY_NAME")"
else
debian_version="Unknown"
fi

{
echo "DWShells Linux learner report"
echo "Learner: $display_name"
echo "Username: $USER"
echo "Hostname: $(hostname)"
echo "Generated: $(date --iso-8601=seconds)"
echo "Debian: $debian_version"
echo "Kernel: $(uname -r)"
echo "Architecture: $(uname -m)"
echo "Home: $HOME"
echo
echo "Linux course usage:"
du -sh "$HOME/linux-course"
echo
echo "Home filesystem:"
df -h "$HOME"
} > "$output"

chmod 600 "$output"
echo "Report written to $output"
exit 0
</syntaxhighlight>

Suggested checks:

<syntaxhighlight lang="bash">
cd "$HOME/linux-course/linux-final"
bash -n bin/learner-report.sh
bin/learner-report.sh
echo "$?"
bin/learner-report.sh "Test Learner"
echo "$?"
stat -c '%a %n' bin/learner-report.sh output/learner-report.txt
cat output/learner-report.txt
</syntaxhighlight>

Expected permissions are <code>700</code> for the script and <code>600</code> for the report. A missing name should produce a non-zero status; a successful run should produce status zero.

== Final project rubric ==

{| class="wikitable" style="width:100%;"
|-
! Area
! Points
! Full-credit standard
|-
| Required directory structure
| 3
| All required directories and files exist in the correct locations.
|-
| README
| 3
| Clearly explains purpose, requirements, command syntax, and output.
|-
| Command notes
| 3
| Ten correct commands with clear one-line explanations.
|-
| Argument validation
| 3
| Missing display name produces usage on stderr and exits non-zero.
|-
| Report content
| 6
| All nine required fields are present and accurate.
|-
| Quoting and safe paths
| 3
| Variables are quoted; script works regardless of the caller's current directory.
|-
| Permissions
| 2
| Script is 700 and report is 600.
|-
| Syntax and repeatability
| 2
| Passes <code>bash -n</code> and runs twice without unsafe side effects.
|-
| Archive and restore
| 3
| Archive lists correctly and restores all files into a separate test location.
|-
| Security and policy
| 2
| No secrets, privilege escalation, broad searches, destructive operations, or prohibited activity.
|-
! Total
! 30
! Suggested pass for this component: 21/30
|}

== Common deductions and coaching ==

{| class="wikitable"
|-
! Issue
! Coaching response
|-
| Learner typed the example <code>$</code> prompt.
| Re-explain prompt versus command; have them retry.
|-
| Paths or variables are unquoted.
| Test with a display name or path containing a space and explain word splitting.
|-
| Learner used <code>chmod 777</code>.
| Ask which identities need each permission, then choose the minimum required mode.
|-
| Learner used SIGKILL first.
| Practise SIGTERM, wait, recheck, and reserve SIGKILL for a verified last resort.
|-
| Learner searched from <code>/</code>.
| Stop the command and narrow the starting path to <code>$HOME</code> or the project.
|-
| Learner copied a command without understanding it.
| Ask them to explain every program, option, argument, redirection, and expansion before rerunning.
|-
| Report exposes secrets.
| Remove the data, rotate any exposed credential, correct the script, and explain secure secret handling.
|}

== Pre-publication staff checklist ==

Before each course intake:

# Confirm the current SSH hostname and port.
# Publish or provide the current SSH host-key fingerprint through a trusted channel.
# Confirm which account home layouts are active, such as <code>/home/free/USER</code> and <code>/home/support/USER</code>.
# Test command availability: <code>bash</code>, <code>nano</code>, <code>man</code>, <code>less</code>, <code>find</code>, <code>grep</code>, <code>tar</code>, <code>getent</code>, <code>curl</code>, <code>ping</code>, <code>quota</code>, and <code>stat</code>.
# Mark unavailable optional commands in the student page.
# Link the current DWShells Acceptable Use Policy and support channel.
# Verify storage, process, CPU, memory, and network limits.
# Test every lab using an ordinary free account and an ordinary support account—not root.
# Confirm that home-directory permissions prevent cross-user data exposure.
# Confirm that the answer-key page is protected as intended.

----

''DWTutorials Linux Basics Instructor Answer Key — © 2026 DarkWorld Network. All rights reserved.''

[[Category:DWShells]]
[[Category:Linux course administration]]