DarkWorld-Wiki - User contributions [en]

DWShells:IPv6 and DNS

2026-10-05T20:24:35Z

Fizi: Protected "DWShells:IPv6 and DNS" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading]

'''IPv6, DNS and assigned application ports'''

Understand which address and port belongs to SSH, your website and your IRC applications.

'''Last verified:''' 6 October 2026. This page covers the connection policy and basic panel workflow. Follow the current fields and validation shown in the panel for hostname changes.

[[DWShells:Documentation|← Documentation hub]]

== Three different connections ==
{| class="wikitable"
!Connection
!Where to get its settings
|-
|SSH / SFTP
|Shell Access and shell connection details; shared login host <code>shells.darkworld.network</code>
|-
|Personal website
|The selected shell's personal HTTPS link
|-
|ZNC / Eggdrop listener
|Packages, for the selected app instance; use its assigned listener port and TLS details
|}
A hostname can point to the same server while a port selects a different service. Do not enter an application's port in your SSH settings or use the network's IRC server port as your ZNC listener port.

== Inbound versus outbound ==
{| class="wikitable"
!Direction
!Meaning
!Policy
|-
|Client → application
|Your IRC client connects to your shell's ZNC listener
|Use assigned addresses/port. IPv4 requires confirmed forwarding.
|-
|Application → IRC network
|ZNC, Eggdrop or an IRC client connects outward
|Free uses IPv6 for IRC. Other permitted plans prefer assigned IPv6 with allowed IPv4 fallback.
|}
Inbound IPv4 forwarding does not grant a Free shell outbound IPv4 IRC access. Use only your assigned bind addresses and ports. Do not create tunnels or proxies to evade restrictions.

== Inspect IPv6 and DNS ==

# Select the correct shell in the customer panel.
# Open '''IPv6 / DNS''' and read the current addresses, hostname information and status.
# Use '''Refresh DNS status''' to read current records and pending operations.
# If the portal offers an extra managed hostname, select an assigned IPv6 address and supply the allowed hostname label.
# Review the result and any queued or running operation; wait for its completion before expecting the hostname to work.

Do not copy an address from another user's guide or account. Field availability and hostname validation depend on the current panel and your allocation.

== DNS records and certificates ==
An A record maps a hostname to an IPv4 address; an AAAA record maps it to an IPv6 address. Reverse DNS is a separate mapping from an address back to a name. None of these records alone grants an application port, confirms forwarding or issues a valid TLS certificate for an arbitrary hostname.

Use the hostname and certificate information displayed by the application manager. If the name does not match the certificate, ask staff to review it rather than disabling verification. A DNS change may not immediately replace records cached by your device or resolver.

== Troubleshooting ==
{| class="wikitable"
!Symptom
!Check
|-
|Website works, ZNC fails
|The ZNC process, allocated listener port, TLS and forwarding status; these are separate from HTTPS hosting.
|-
|ZNC works via IPv6, IPv4 fails
|Confirm the manager explicitly reports IPv4 forwarding for that listener. Report the port and error to staff without credentials.
|-
|ZNC accepts a client but its network is offline
|Check outbound network/server/port/TLS and IPv6 support on Free.
|-
|New hostname is unavailable
|Check job status and DNS records; verify it points to your assignment and account for cached records.
|-
|IRC network is blocked
|Request staff review of the network; do not bypass approved-destination rules.
|}

== References ==

* [[DWShells:Signup and Rules|Signup and Rules]]
* [[DWShells:ZNC|ZNC guide]]
* [[DWShells:Eggdrop|Eggdrop guide]]
* [https://panel.shells.darkworld.network/customer/ Customer panel]

DWShells:IPv6 and DNS

2026-10-05T20:24:25Z

Fizi: Created page with "'''IPv6, DNS and assigned application ports''' Understand which address and port belongs to SSH, your website and your IRC applications. '''Last verified:''' 6 October 2026. This page covers the connection policy and basic panel workflow. Follow the current fields and validation shown in the panel for hostname changes. ← Documentation hub == Three different connections == {| class="wikitable" !Con..."

DWShells:Security and Backups

2026-10-05T20:24:00Z

Fizi: Protected "DWShells:Security and Backups" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading]

'''Protect your account and important files'''

Use dashboard 2FA, public SSH keys and realistic backup expectations.

'''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples.

[[DWShells:Documentation|← Documentation hub]] · [https://shells.darkworld.network/guides/security-and-backups/ Visual website guide]

== Protect access and recovery ==
{| class="wikitable"
!Step
!What it means
|-
|01 · Dashboard
|Enable 2FA and save recovery codes.
|-
|02 · Shell
|Manage authorised public SSH keys.
|-
|03 · Files
|Keep independent copies and inspect backup coverage.
|}

== Dashboard two-factor authentication ==

# '''Open Security Centre.''' Select the shell if required and enter the current dashboard password for sensitive actions.
# '''Start authenticator setup.''' Follow the setup controls, scan the QR code with your authenticator and enter a current code to enable 2FA. Do not share the QR code or setup secret.
# '''Save recovery codes.''' Store them somewhere secure outside this shell. Replacing recovery codes invalidates the older set; security changes can sign out other sessions.

== Public SSH keys ==
Generate and protect a key pair on your own device. In Security Centre, add only the public SSH key and a useful label; confirm using your dashboard password. The matching private key stays on your device. Removing a key prevents future key logins but does not close an already open SSH session. Keep a working recovery method before removing your only key.

== What the panel backups cover ==
'''Before you continue:''' Current panel home-directory copies are stored on the shell server, with three recent copies retained. Off-server protection is not verified in the customer interface. These copies do not protect against loss of the server.

== Request file recovery ==

# '''Inspect the available copies.''' Open Backups & Restore. Read the backup time, integrity/coverage details and any stale status or warnings.
# '''Choose the copy and explain the need.''' Submit a recovery request with the affected paths and the problem. Approval is a review decision, not an immediate restore.
# '''Wait for actual recovery.''' Staff stage and inspect an approved copy and arrange manual recovery. Check the request status and completion notes; do not assume approved means your files have been restored.

== Keep your own backup ==
Download important files using SFTP and retain a separate copy outside the VPS. Copy website sources and app configurations before editing or fresh installation. A home copy may omit sockets or unreadable files and can include changing files; it does not promise an application-consistent database or live-session restore.

== If you suspect compromise ==
Contact staff promptly with your username, approximate time and the issue. Never send passwords, private keys, recovery codes or verification links. Review public keys and running applications, and follow staff advice on resetting credentials and ending sessions.

== You are protected when ==

* 2FA is enabled and recovery codes are stored independently.
* You recognise all authorised SSH keys.
* Important files have a separate off-server copy.
* You understand the coverage of a backup before requesting recovery.

== Backup request states ==
{| class="wikitable"
!State
!Meaning
|-
|Submitted
|Staff review is pending
|-
|Approved
|Awaiting manual recovery; files have not necessarily been restored
|-
|Completed
|Staff have reported manual recovery; read the completion notes and verify the files
|}
When requesting recovery, give the relevant paths, the approximate time the problem occurred, which copy you need and whether current files should be preserved. Staff must inspect and coordinate the recovery.

== Independent backup checklist ==

* Keep an off-server copy of website sources and essential application configuration.
* Store credentials securely; do not publish backup archives in <code>public_html</code>.
* Check that your copy contains the files you need and can be opened.
* Use application-specific export methods for databases where permitted; a changing home-directory copy does not guarantee a consistent database restore.

== Rules and support ==
This guide describes how to use the service; it does not replace [[DWShells:Signup and Rules|Signup and Rules]]. Join '''#DWShells''' on <code>irc.darkworld.chat</code> using TLS port '''6697''' for help. Use [https://panel.shells.darkworld.network/customer/ the customer portal] for your actual status and connection details. Never share credentials or recovery links.

[[DWShells:Documentation|Back to documentation]]

DWShells:Security and Backups

2026-10-05T20:23:52Z

Fizi: Created page with "'''Protect your account and important files''' Use dashboard 2FA, public SSH keys and realistic backup expectations. '''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples. ← Documentation hub · [https://shells.darkworld.network/guides/security-and-backups/ Visual webs..."

DWShells:Python and Tmux

2026-10-05T20:23:33Z

Fizi: Protected "DWShells:Python and Tmux" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading]

'''Run Python and persistent sessions'''

Use approved Python environments and reconnect to portal-managed tmux sessions.

'''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples.

[[DWShells:Documentation|← Documentation hub]] · [https://shells.darkworld.network/guides/python-and-sessions/ Visual website guide]

== Two ways to manage work ==
{| class="wikitable"
!Step
!What it means
|-
|01 · Python app
|Environment → uploaded script → managed Run script.
|-
|02 · Persistent terminal
|Session → attach in Shell Access → detach and return.
|}

== Check your plan ==
'''Before you continue:''' Python and development permissions vary by plan. Use only approved workloads. All programs share the shell’s resource limits. A persistent session does not override Keep, account expiry, process limits or service restarts.

== A Python environment ==

# '''Create an environment.''' Open Python in Packages, choose an environment name and use Create environment.
# '''Upload a script.''' Select a UTF-8 .py file. The current portal upload limit is 64 KiB. Use Upload script, then select the uploaded script or its returned path.
# '''Install required dependencies.''' Enter the packages your script actually needs and use Install dependencies. Inspect the result before running the script.
# '''Run and inspect.''' Select the correct environment and script path relative to your home, then use Run script. Check View logs. Stop an unused application before changing or deleting its environment.

== A simple first script ==
Save as hello.py locally, upload it and use it to check that your environment works:<pre>
print("Hello from my DWShells Python environment")
</pre>This script prints one line and exits normally. A finished process is expected, not a failed always-on app. Deleting an unused environment keeps uploaded scripts, but you should still save independent copies.

== Persistent terminal work ==

# '''Create a session.''' In the appropriate Packages session manager, choose a session name and use Create session. Available IRC clients are shown by the panel.
# '''Attach in Shell Access.''' Use Copy attach command and run the exact command in your browser terminal or SSH connection. Portal-managed sessions use a dedicated tmux socket.
# '''Detach and return.''' Press Ctrl+B, release, then D to detach from tmux. Reconnect later and run the same attach command. Closing the session is different from detaching and terminates that session’s work.

== Example attach command ==
For a portal-managed session named ircsession:<pre>
tmux -S ~/.dwshell-tmux.sock attach -t ircsession
</pre>Use the name and command copied from your panel. A plain tmux attach can look for a different socket and miss the portal-managed session.

== Troubleshooting ==
{| class="wikitable"
!What you see
!What to do
|-
|Python is unavailable
|Check your plan and ask staff if your intended work needs additional permission.
|-
|Module not found
|Install the dependency in the selected environment and inspect its installation output.
|-
|Script exits immediately
|Read logs. A short script may have completed normally.
|-
|No tmux session found
|Check selected shell, session name and the dedicated socket in the copied command.
|}

== Environment, script and process ==
{| class="wikitable"
!Item
!Meaning
|-
|Environment
|The selected Python environment and its installed dependencies
|-
|Script
|A uploaded source file; choose its path relative to your home
|-
|Process
|The currently running invocation; a short script can exit normally
|}
Choose the same environment for dependency installation and script execution. Avoid pasting secrets into script source that you intend to share.

== Detach, exit and close ==
'''Detach''' leaves the tmux session available for reattachment. '''Exit''' ends the program or shell you are using. '''Close session''' terminates that managed session's work. Persistent sessions still depend on account status, Keep, resource limits and host availability; they are not an uptime guarantee.

== Rules and support ==
This guide describes how to use the service; it does not replace [[DWShells:Signup and Rules|Signup and Rules]]. Join '''#DWShells''' on <code>irc.darkworld.chat</code> using TLS port '''6697''' for help. Use [https://panel.shells.darkworld.network/customer/ the customer portal] for your actual status and connection details. Never share credentials or recovery links.

[[DWShells:Documentation|Back to documentation]]

DWShells:Python and Tmux

2026-10-05T20:23:20Z

Fizi: Created page with "'''Run Python and persistent sessions''' Use approved Python environments and reconnect to portal-managed tmux sessions. '''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples. ← Documentation hub · [https://shells.darkworld.network/guides/python-and-sessions/ Visual websit..."

DWShells:Keep Renewal

2026-10-05T20:23:00Z

Fizi: Protected "DWShells:Keep Renewal" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading]

'''Keep your Free shell renewed'''

Read your countdown, renew before the deadline and understand the daily allowance.

'''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples.

[[DWShells:Documentation|← Documentation hub]] · [https://shells.darkworld.network/guides/keep-renewal/ Visual website guide]

== The renewal check ==
{| class="wikitable"
!Step
!What it means
|-
|01 · Select shell
|Each linked shell has its own status.
|-
|02 · Read countdown
|Check deadline, eligibility and allowance.
|-
|03 · Keep
|Complete renewal before expiry.
|-
|04 · Verify
|Confirm the deadline changed successfully.
|}

== What Keep does ==
Keep is enabled by default for Free shells. It is a dashboard renewal action, not a measurement of how long SSH or a bot has been connected. Leaving an application running does not replace renewal.

== Renew through the panel ==

# '''Open Keep / Renewal.''' Select the Free shell and open its Keep / Renewal page. Read the status, expiration date and remaining allowance.
# '''Use the available Keep action.''' Renew before the deadline. Wait for the response instead of repeatedly clicking.
# '''Check the new deadline.''' A normal successful Keep provides at least 14 days from renewal. Repeated Keeps do not accumulate unlimited time; a later staff-approved deadline is preserved.

== Daily allowance ==
At most two successful user Keeps are allowed per shell per UTC day. The allowance resets at midnight UTC—5:00 a.m. in Pakistan. Use the actual deadline in the dashboard; do not calculate eligibility from your local calendar alone.

== Disabled, expired or paused ==
{| class="wikitable"
!What you see
!What to do
|-
|Keep is off on another plan
|This is the default for non-Free plans. Paid renewal remains separate.
|-
|Keep enabled on a paid plan
|It records activity and does not extend the paid subscription.
|-
|No allowance left today
|Wait for the next UTC day if the deadline permits. Contact staff if renewal is urgent.
|-
|Expired, locked or suspended
|Ask staff to review the account. Keep does not bypass suspension.
|-
|Travel or illness
|Contact staff before expiry to request an extension or timer pause. These need staff review.
|}

== A useful routine ==

* Check the selected shell’s deadline after signing in.
* Set your own reminder ahead of that deadline.
* Verify a successful Keep rather than relying on the click alone.
* Read Inbox and service notices for account changes.

== How to read the deadline ==
Use the expiration date and remaining time displayed for the selected shell. Browser display dates can be localised, while the daily allowance resets according to UTC. If the page shows a paused timer or a staff extension, follow that state rather than adding days yourself.

== Keep is not a subscription payment ==
Keep renews eligible Free access. On other plans, where staff has enabled it, Keep records activity only and does not move the paid subscription deadline. If renewal is urgent and the normal action is unavailable, contact staff before the displayed deadline.

== Rules and support ==
This guide describes how to use the service; it does not replace [[DWShells:Signup and Rules|Signup and Rules]]. Join '''#DWShells''' on <code>irc.darkworld.chat</code> using TLS port '''6697''' for help. Use [https://panel.shells.darkworld.network/customer/ the customer portal] for your actual status and connection details. Never share credentials or recovery links.

[[DWShells:Documentation|Back to documentation]]

DWShells:Keep Renewal

2026-10-05T20:22:51Z

Fizi: Created page with "'''Keep your Free shell renewed''' Read your countdown, renew before the deadline and understand the daily allowance. '''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples. ← Documentation hub · [https://shells.darkworld.network/guides/keep-renewal/ Visual website guide] ==..."

DWShells:Eggdrop

2026-10-05T20:22:27Z

Fizi: Protected "DWShells:Eggdrop" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading]

'''Create and manage an Eggdrop bot'''

Create an instance, edit its own configuration and keep other bots running during changes.

'''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples.

[[DWShells:Documentation|← Documentation hub]] · [https://shells.darkworld.network/guides/eggdrop/ Visual website guide]

== One bot, one configuration ==
{| class="wikitable"
!Step
!What it means
|-
|01 · Packages
|Create or choose a named instance.
|-
|02 · File Manager
|Edit that instance’s configuration and scripts.
|-
|03 · Restart + logs
|Apply settings and verify the bot’s connection.
|}

== Before creating a bot ==
'''Before you continue:''' Eggdrop must be allowed by your plan, and you need a free assigned listener port plus available app and IRC connection capacity. Obtain permission to operate the bot on your chosen network and channel.

== Create your first instance ==

# '''Open Eggdrop in Packages.''' Select the correct shell and expand Create a new Eggdrop instance. Choose a unique instance name, such as mybot. It is separate from the IRC nickname.
# '''Fill the bot settings.''' Enter the IRC nickname, owner handle, a separate owner password of at least 14 characters and its confirmation. The current owner-handle field allows up to nine characters.
# '''Choose server and channels.''' Use a permitted IRC server and its server port; keep TLS enabled when the server supports the chosen TLS port. Channels are entered as names such as #DWShells #MyChannel. Join only channels where your bot is welcome.
# '''Set up and start bot.''' The portal selects an available allocated listener port, excluding existing ZNC and bot reservations. Read the result, confirm the running state and open View logs.

== Edit one bot safely ==

# '''Choose the instance card.''' Use Edit configuration or Files and scripts on the bot you intend to change. Do not edit a similarly named bot by mistake.
# '''Save a copy and edit.''' File Manager lets you choose Eggdrop · INSTANCE. Save a local copy before modifying eggdrop.conf or scripts. SFTP locations are under ~/apps/eggdrop/instances/.
# '''Restart that instance.''' Save the text, then return to Packages and Restart the same bot to apply configuration changes. Other instances have their own controls.
# '''Check the result.''' Inspect View logs and the bot’s presence on IRC. A running process alone does not prove that it joined the correct network or channel.

== Learn from the installed reference ==
Full reference opens the configuration reference for that instance. Use it to understand settings rather than pasting an unrelated configuration with another account’s bind address, ports or owner credentials. The owner listener uses TLS; follow the displayed port and certificate fingerprint when connecting.

== Fresh install and deletion ==
Stop the instance and copy anything you want to keep. Install fresh or Delete bot permanently removes that instance’s configuration, credentials, logs and scripts after the typed confirmation. Fresh install opens new setup. Other instances are preserved, but choosing the wrong name still destroys the selected bot.

== Troubleshooting ==
{| class="wikitable"
!What you see
!What to do
|-
|Bot is stopped after setup
|Read the action result and logs; check configuration syntax and permissions.
|-
|Bot runs but is not on IRC
|Check server, TLS, nickname conflicts, network access and IPv6 on Free.
|-
|Cannot create another bot
|Check allowed instance count, assigned port reservations and resource limits.
|-
|Changes have no effect
|Save the correct instance’s file and restart that instance.
|}

== Instance name, nickname and owner handle ==
{| class="wikitable"
!Name
!Purpose
|-
|Instance name
|Identifies the bot's directory and panel controls, for example <code>mybot</code>
|-
|IRC nickname
|Name other IRC users see on the network
|-
|Owner handle
|Eggdrop's owner identity; follow the current field limit
|}
Changing one name does not necessarily change the other two.

== Add a script carefully ==

# Read the script's documentation and confirm that its commands and resource use fit your plan and network rules.
# Copy the selected instance's configuration and scripts to your own computer.
# Open '''Files and scripts''' for that instance, or use SFTP into its instance directory.
# Upload the script and edit the configuration according to the installed reference and the script's documented loading instructions.
# Save and restart that instance, then inspect '''View logs'''.

Do not source untrusted scripts or copy another user's passwords, bind addresses or allocated ports. A syntax error can prevent the bot from starting; retain a known-good configuration to restore.

== Rules and support ==
This guide describes how to use the service; it does not replace [[DWShells:Signup and Rules|Signup and Rules]]. Join '''#DWShells''' on <code>irc.darkworld.chat</code> using TLS port '''6697''' for help. Use [https://panel.shells.darkworld.network/customer/ the customer portal] for your actual status and connection details. Never share credentials or recovery links.

[[DWShells:Documentation|Back to documentation]]

DWShells:Eggdrop

2026-10-05T20:22:18Z

Fizi: Created page with "'''Create and manage an Eggdrop bot''' Create an instance, edit its own configuration and keep other bots running during changes. '''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples. ← Documentation hub · [https://shells.darkworld.network/guides/eggdrop/ Visual website guide] =..."

DWShells:ZNC

2026-10-05T20:21:58Z

Fizi: Protected "DWShells:ZNC" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading]

'''Set up and connect to ZNC'''

Create a managed bouncer, connect your IRC client and understand the two network connections.

'''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples.

[[DWShells:Documentation|← Documentation hub]] · [https://shells.darkworld.network/guides/znc/ Visual website guide]

== ZNC has two separate connections ==
{| class="wikitable"
!Step
!What it means
|-
|01 · Your IRC client
|Connects inbound using ZNC login and assigned listener port.
|-
|02 · Your ZNC
|Runs on the shell and keeps its network session.
|-
|03 · IRC network
|Receives the outbound connection on its server port.
|}

== Check permissions and ports ==
'''Before you continue:''' Open Packages for the selected active shell. ZNC must be permitted and an assigned listener port must be available. If your allocation has only one listener port, ZNC and Eggdrop cannot both reserve it. Do not copy a port from another user.

== Create a managed instance ==

# '''Open the ZNC manager.''' In Packages, choose ZNC. If an existing instance is already configured, inspect its details instead of running setup again.
# '''Enter the ZNC identity.''' Choose the ZNC username, IRC nickname and a separate ZNC password of at least 14 characters. Confirm the password.
# '''Choose the IRC network.''' Enter a network name and a permitted IRC server. DarkWorld community connections use irc.darkworld.chat with TLS on 6697. Keep Use TLS to IRC server enabled for that connection. Other networks must meet shell network policy.
# '''Set up and start.''' Use Set up and start ZNC. The portal chooses an available assigned listener port. Wait for the result, then check status and View logs.

== Connect your IRC client ==
Use the Client connection details shown by the manager: hostname/address, listener port, TLS setting and login. The displayed login can include the network, such as ZNC_USERNAME/NETWORK_NAME. Use the ZNC password, not the shell or dashboard password.
{| class="wikitable"
!What you see
!What to do
|-
|Client → ZNC
|Your assigned application listener port, shown in Packages. Use the displayed SSL/TLS setting.
|-
|ZNC → IRC network
|The network server’s port, for example TLS 6697. This is not your allocated listener port.
|-
|IPv4 inbound
|Use only a connection marked IPv4 forwarding confirmed. Otherwise follow the IPv6 details or contact staff.
|-
|Free outbound
|IRC connections use assigned IPv6. IPv4 access from your client does not change that policy.
|-
|Other plans outbound
|Managed configuration prefers assigned IPv6 with permitted IPv4 fallback.
|}

== TLS and the web interface ==
Match the displayed hostname to the certificate. Verify a fingerprint when the portal supplies one; do not disable certificate verification to hide a warning. Use Open ZNC web only when the manager shows it. “Web Access is not enabled” means the web interface is not available, not necessarily that the IRC listener is down.

== Manage or replace ZNC ==
Use Start, Stop, Restart and View logs. Install fresh and Delete ZNC are destructive: stop first and make an independent copy of needed settings. The confirmation removes configuration, credentials, logs and scripts. Install fresh reopens setup; it is not a repair that preserves your existing account.

== Troubleshooting ==
{| class="wikitable"
!What you see
!What to do
|-
|Client cannot connect
|Check assigned listener port, TLS and forwarding status, then the running state and logs.
|-
|Client connects, network is offline
|Check IRC server, server port, TLS, permitted destinations and IPv6 support on Free.
|-
|Login rejected
|Use the displayed ZNC login and ZNC password. Network names matter.
|-
|No available port
|Review existing app reservations and your allocation; ask staff before changing ports.
|}

== Client connection checklist ==

# Open the selected shell's ZNC manager and confirm it is running.
# Copy the displayed hostname or address and allocated listener port.
# Match the displayed client TLS setting.
# Use the displayed ZNC login, including <code>/NETWORK_NAME</code> when present.
# Enter the separate ZNC password in your IRC client's appropriate credential field.
# Inspect the ZNC network connection after the client has authenticated.

For irssi, the panel provides '''Copy irssi command''' and, when forwarding is confirmed, '''Copy IPv4 command'''. Read the generated command, replace its password placeholder locally, and verify the displayed certificate information. Do not post the completed command in a public channel or support ticket.

== Recover without unnecessary reinstallation ==
Start with running state and logs. Restart only when appropriate. An inbound connection problem is different from an offline IRC network connection. Installing fresh destroys the selected configuration and credentials; use it only when you intentionally want a new setup and have copied what you need.

== Rules and support ==
This guide describes how to use the service; it does not replace [[DWShells:Signup and Rules|Signup and Rules]]. Join '''#DWShells''' on <code>irc.darkworld.chat</code> using TLS port '''6697''' for help. Use [https://panel.shells.darkworld.network/customer/ the customer portal] for your actual status and connection details. Never share credentials or recovery links.

[[DWShells:Documentation|Back to documentation]]

DWShells:ZNC

2026-10-05T20:21:41Z

Fizi: Created page with "'''Set up and connect to ZNC''' Create a managed bouncer, connect your IRC client and understand the two network connections. '''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples. ← Documentation hub · [https://shells.darkworld.network/guides/znc/ Visual website guide] == ZNC has tw..."

DWShells:Website Hosting

2026-10-05T20:21:18Z

Fizi: Protected "DWShells:Website Hosting" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading]

'''Publish your personal website'''

Upload a first page, use File Manager and keep private material out of public_html.

'''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples.

[[DWShells:Documentation|← Documentation hub]] · [https://shells.darkworld.network/guides/personal-website/ Visual website guide]

== From a file to a public page ==
{| class="wikitable"
!Step
!What it means
|-
|01 · Your computer
|Prepare index.html and a backup copy.
|-
|02 · public_html
|Upload using File Manager or SFTP.
|-
|03 · Personal HTTPS URL
|Open the website address from your dashboard.
|}

== What becomes public ==
'''Before you continue:''' Files in public_html are website content. Never place passwords, private keys, application configs, database dumps or backup archives there. Hosting must fit your approved use and plan.

== Publish a first page ==

# '''Select the website location.''' Open File Manager for the correct shell. Set File location to Website · public_html. The Eggdrop location is for bot files, not public web content.
# '''Upload index.html.''' Use Upload file for a file from your computer. For folders or larger transfers, use SFTP. Copy your existing site before overwriting files.
# '''Visit the right URL.''' Open the personal HTTPS website link in your dashboard. Do not add an SSH or ZNC port. The hostname alone is not a substitute for the exact dashboard link.
# '''Edit and check.''' Use the file editor for a text change and Save file. Reload the website and check that links, images and filenames match, including letter case.

== A minimal page to try ==
Save this as index.html on your computer. Replace the sample heading before uploading:<pre>
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>My shell website</title>
</head>
<body>
<h1>Hello from my DWShells website</h1>
<p>This is my personal page.</p>
</body>
</html>
</pre>

== Files and scripts ==
New folder creates a directory in the current location. Upload file transfers one file. The editor saves text files; it does not build a framework or enable unsupported runtimes. Static HTML is a good first check. PHP or other dynamic hosting depends on your effective permissions. Deletion is permanent in the file manager; keep your own copies.

== Troubleshooting ==
{| class="wikitable"
!What you see
!What to do
|-
|Old page still appears
|Check you edited the selected shell’s public_html, saved the file and refreshed the browser.
|-
|An image is missing
|Match the filename and relative path exactly; Linux paths are case-sensitive.
|-
|Upload is too large or a folder will not upload
|Use SFTP and check the disk allocation.
|-
|Page is unavailable
|Check shell status and the exact HTTPS link, then report the URL and error to staff.
|}

== Example directory layout ==
{| class="wikitable"
!Location
!Purpose
|-
|<code>public_html/index.html</code>
|Your entry page
|-
|<code>public_html/style.css</code>
|Public stylesheet
|-
|<code>public_html/images/logo.png</code>
|Public image referenced by your HTML
|-
|Outside <code>public_html</code>
|Private account files; keep credentials and backups out of the website
|}
Use relative links such as <code>images/logo.png</code> when the page is in <code>public_html</code>. A file named <code>Logo.png</code> is different from <code>logo.png</code>.

== Safe updates ==
Download a copy of the existing page, upload your replacement, then test the live HTTPS link. Do not use world-writable permissions or publish configuration secrets to fix a hosting error. Ask staff about unsupported runtimes and commercial hosting before deploying them.

== Rules and support ==
This guide describes how to use the service; it does not replace [[DWShells:Signup and Rules|Signup and Rules]]. Join '''#DWShells''' on <code>irc.darkworld.chat</code> using TLS port '''6697''' for help. Use [https://panel.shells.darkworld.network/customer/ the customer portal] for your actual status and connection details. Never share credentials or recovery links.

[[DWShells:Documentation|Back to documentation]]

DWShells:Website Hosting

2026-10-05T20:21:02Z

Fizi: Created page with "'''Publish your personal website''' Upload a first page, use File Manager and keep private material out of public_html. '''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples. ← Documentation hub · [https://shells.darkworld.network/guides/personal-website/ Visual website gu..."

DWShells:SSH and SFTP

2026-10-05T20:20:41Z

Fizi: Protected "DWShells:SSH and SFTP" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading]

'''Connect through SSH and SFTP'''

Use the browser terminal or your own SSH client, then transfer files securely.

'''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples.

[[DWShells:Documentation|← Documentation hub]] · [https://shells.darkworld.network/guides/ssh-and-sftp/ Visual website guide]

== Choose your connection ==
{| class="wikitable"
!Step
!What it means
|-
|01 · Browser
|Panel → Shell Access → shell password.
|-
|02 · SSH client
|Terminal → shared login host → shell username.
|-
|03 · SFTP
|File client → same host and shell credentials.
|}

== Before connecting ==
'''Before you continue:''' Your shell must be active. Replace YOUR_USERNAME with the exact Linux shell username shown in your dashboard. Do not type it literally.

== Browser terminal ==

# '''Open Shell Access.''' Select the correct shell, open Shell Access and enter your shell password.
# '''Connect and focus.''' Click Connect to shell, then click inside the terminal and type at the visible prompt. The dashboard password is not the SSH password.
# '''Finish deliberately.''' Use Disconnect when finished. A normal foreground program can stop when its SSH session ends; use an approved persistent session for work that must stay attached elsewhere.

== SSH from your computer ==
Open a terminal such as PowerShell, Windows Terminal, macOS Terminal or a Linux terminal and run:<pre>
ssh YOUR_USERNAME@shells.darkworld.network
</pre>The shared login host is shells.darkworld.network. Use the SSH port shown in your dashboard; the command above uses the standard SSH port. A personal website address or application listener port is a different service. On a first connection, verify the server host-key fingerprint through a trusted staff channel before accepting it. Do not dismiss a changed-host-key warning without checking.

== Transfer files with SFTP ==
<pre>
sftp YOUR_USERNAME@shells.darkworld.network
</pre>For a desktop file client, select SFTP, enter the shared host and your shell username, then use the shell password or an authorised SSH key. Do not select plain FTP. Upload website content into public_html and keep private files outside it.<pre>
pwd
ls
cd public_html
put index.html
bye
</pre>These are example SFTP commands: inspect the current location before uploading; put index.html can replace an existing file. Keep a copy first.

== If the connection fails ==
{| class="wikitable"
!What you see
!What to do
|-
|Permission denied
|Confirm the Linux username, active status and shell password. Use the supplied reset process if needed.
|-
|Timeout or refusal
|Check hostname, displayed SSH port and service notices. Report the exact error and time.
|-
|Host key changed
|Pause and ask staff to verify the fingerprint; do not blindly remove the saved key.
|-
|Typing is not visible
|Password entry normally has no visible characters. In browser SSH, click inside the terminal after connecting.
|}

== Useful first shell commands ==
These commands inspect your own account and files:<pre>
pwd
ls -la
whoami
</pre><code>pwd</code> prints your current directory, <code>ls -la</code> lists entries including hidden names, and <code>whoami</code> prints the logged-in Linux username. Do not publish command output containing private paths or credentials.

== SSH keys and host keys are different ==
Your personal public key authorises your login and can be managed in Security Centre. The server host key identifies the SSH server to your client. Confirm an unfamiliar or changed server fingerprint with staff; uploading your personal key does not verify the server's identity.

== Desktop SFTP settings ==
{| class="wikitable"
!Setting
!Value
|-
|Protocol
|SFTP (SSH File Transfer Protocol)
|-
|Host
|<code>shells.darkworld.network</code>
|-
|Username
|Your Linux shell username
|-
|Port
|The displayed SSH port; do not use a ZNC/Eggdrop listener port
|-
|Authentication
|Shell password or your authorised private key on your own device
|}

== Rules and support ==
This guide describes how to use the service; it does not replace [[DWShells:Signup and Rules|Signup and Rules]]. Join '''#DWShells''' on <code>irc.darkworld.chat</code> using TLS port '''6697''' for help. Use [https://panel.shells.darkworld.network/customer/ the customer portal] for your actual status and connection details. Never share credentials or recovery links.

[[DWShells:Documentation|Back to documentation]]

DWShells:SSH and SFTP

2026-10-05T20:20:20Z

Fizi: Created page with "'''Connect through SSH and SFTP''' Use the browser terminal or your own SSH client, then transfer files securely. '''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples. ← Documentation hub · [https://shells.darkworld.network/guides/ssh-and-sftp/ Visual website guide] == Choo..."

DWShells:Customer Panel

2026-10-05T20:19:53Z

Fizi: Protected "DWShells:Customer Panel" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading]

'''Find your way around the panel'''

Choose the correct shell and know which page handles files, apps, access and renewal.

'''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples.

[[DWShells:Documentation|← Documentation hub]] · [https://shells.darkworld.network/guides/dashboard/ Visual website guide]

== One account, selected-shell controls ==
{| class="wikitable"
!Step
!What it means
|-
|01 · Dashboard account
|Your sign-in and Inbox belong to the customer account.
|-
|02 · Shell selector
|Choose the shell before making changes.
|-
|03 · Section
|Open files, packages, access or renewal for that shell.
|}

== Start with the selected shell ==
Use the shell selector when more than one shell is linked. Read the username and status before starting an app, editing files or renewing. Limits and network allocations can differ between shells. An inactive shell may have unavailable controls.

== Where to go ==
{| class="wikitable"
!What you see
!What to do
|-
|Overview
|Shell status, connection facts and next steps.
|-
|Plans
|Available plans and the request workflow.
|-
|Shell Access
|Browser SSH terminal using your shell password.
|-
|File Manager
|Website files or an installed Eggdrop instance.
|-
|Packages
|Manage permitted ZNC, Eggdrop, Python or persistent sessions.
|-
|Resource Usage
|Measured usage and the selected shell’s limits.
|-
|IPv6 / DNS
|Assigned addresses and supported hostname controls.
|-
|Keep / Renewal
|The selected shell’s deadline and renewal allowance.
|-
|Security Centre
|Dashboard 2FA and public SSH keys for the shell.
|-
|Backups & Restore
|Available home copies and recovery requests.
|-
|Inbox
|Messages for the customer account, shared across linked shells.
|}

== A safe daily routine ==

# '''Read notices.''' Check Overview and Inbox before assuming a service is ready.
# '''Check renewal and resources.''' Review Keep / Renewal if required, then Resource Usage. An app shares CPU, memory, disk and process limits with everything else on the shell.
# '''Make one change at a time.''' Choose the instance, apply the change and inspect the result or logs. Confirm the selected username again before destructive operations.

== Three credentials to distinguish ==

* Dashboard password: signs you into the portal and confirms sensitive security actions.
* Shell password: connects to SSH/SFTP and the browser terminal.
* Application password: connects to your ZNC or Eggdrop owner account; it is not your shell password.

== When controls are unavailable ==
Read the displayed explanation. A plan restriction, inactive shell or exhausted allocation can disable an action. Contact staff for changes rather than starting duplicate instances to bypass a limit.

== Diagnose a problem before contacting staff ==
Record the selected shell username, the panel section, the action you attempted, the exact error and the approximate time with timezone. Redact passwords, tokens, private keys and private messages. A screenshot should show the error and relevant status only.

A successful page refresh does not mean a queued operation has completed. Read the action result and the selected shell's current state. Changing shells changes the target of the controls; check it before every write operation.

== Rules and support ==
This guide describes how to use the service; it does not replace [[DWShells:Signup and Rules|Signup and Rules]]. Join '''#DWShells''' on <code>irc.darkworld.chat</code> using TLS port '''6697''' for help. Use [https://panel.shells.darkworld.network/customer/ the customer portal] for your actual status and connection details. Never share credentials or recovery links.

[[DWShells:Documentation|Back to documentation]]

DWShells:Customer Panel

2026-10-05T20:19:41Z

Fizi: Created page with "'''Find your way around the panel''' Choose the correct shell and know which page handles files, apps, access and renewal. '''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples. ← Documentation hub · [https://shells.darkworld.network/guides/dashboard/ Visual website guide]..."

DWShells:Documentation

2026-10-05T20:19:20Z

Fizi: Protected "DWShells:Documentation" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading]

'''DWShells documentation'''

Practical documentation for the DarkWorld shell service. Start with signup, learn your dashboard, then choose a guide for the task you want to perform.

'''Last verified:''' 6 October 2026.

The [https://shells.darkworld.network/guides/ website guides] provide illustrated introductions. This wiki contains the detailed instructions and [[DWShells:Signup and Rules|authoritative service rules]]. Your selected shell's dashboard shows its actual permissions, limits, assigned ports and status.

== Start here ==

* [[DWShells:Getting Started|Getting Started]] — Register, request a plan, complete verification and recognise when your shell is ready.
* [[DWShells:Customer Panel|Customer Panel]] — Choose the correct shell and know which page handles files, apps, access and renewal.
* [[DWShells:SSH and SFTP|SSH and SFTP]] — Use the browser terminal or your own SSH client, then transfer files securely.
* [[DWShells:Website Hosting|Website Hosting]] — Upload a first page, use File Manager and keep private material out of public_html.
* [[DWShells:ZNC|ZNC]] — Create a managed bouncer, connect your IRC client and understand the two network connections.
* [[DWShells:Eggdrop|Eggdrop]] — Create an instance, edit its own configuration and keep other bots running during changes.
* [[DWShells:Keep Renewal|Keep Renewal]] — Read your countdown, renew before the deadline and understand the daily allowance.
* [[DWShells:Python and Tmux|Python and Tmux]] — Use approved Python environments and reconnect to portal-managed tmux sessions.
* [[DWShells:Security and Backups|Security and Backups]] — Use dashboard 2FA, public SSH keys and realistic backup expectations.
* [[DWShells:IPv6 and DNS|IPv6 and DNS]] — Assigned IPv6, DNS status and inbound/outbound application connectivity.

== Important distinctions ==

* Dashboard registration and email verification do not immediately activate a Linux shell.
* Dashboard, shell and application passwords serve different purposes.
* Your application listener port is separate from the IRC network's server port.
* Inbound IPv4 forwarding does not change the Free outbound IPv6 policy.
* Keep renewal is separate from paid subscription renewal.
* Backup approval is separate from completed manual recovery.

== Rules and help ==

* [[DWShells:Signup and Rules|Signup and Rules]] — the single authoritative rules page; do not duplicate rules across guides.
* [https://panel.shells.darkworld.network/customer/ Customer panel] — requests, actual account status and management controls.
* [https://shells.darkworld.network/contact/ Contact staff] — corrections and enquiries.
* '''#DWShells''' on <code>irc.darkworld.chat</code>, TLS port '''6697''' — community support and announcements.

Never post passwords, SSH private keys, application credentials, recovery codes, verification links or private customer data in wiki examples or support requests.

DWShells:Getting Started

2026-10-05T20:19:03Z

Fizi: Protected "DWShells:Getting Started" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)) [cascading]

'''From signup to your first shell'''

Register, request a plan, complete verification and recognise when your shell is ready.

'''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples.

[[DWShells:Documentation|← Documentation hub]] · [https://shells.darkworld.network/guides/getting-started/ Visual website guide]

== Your path to an active shell ==
{| class="wikitable"
!Step
!What it means
|-
|01 · Register
|Create and verify the dashboard account.
|-
|02 · Request
|Choose a plan and complete its checks.
|-
|03 · Review
|Staff approve and provision the shell.
|-
|04 · Connect
|Set the shell password and check active status.
|}

== What you need ==
A supported Gmail or googlemail.com address, your intended use and—when requesting Free—your DarkWorld IRC identity. Registration creates a dashboard account; it does not immediately create a Linux shell.

== Follow the dashboard ==

# '''Register and verify.''' Open the [https://panel.shells.darkworld.network/customer/ customer portal]. Complete registration and the email verification requested there. Use the customer URL ending in /customer/.
# '''Choose the right plan.''' Open Plans. Free is intended for IRC-related use. Other plans may allow broader approved work. Read the limits and submit an accurate request. Follow payment-review instructions for a paid request.
# '''Complete Free verification.''' Register and identify your nickname with NickServ on DarkWorld IRC. Follow the dashboard’s DWShells challenge and community information steps exactly. Join #DWShells on irc.darkworld.chat with TLS on port 6697 for help; merely joining the channel does not complete every check.
# '''Watch the request status.''' Respond to staff questions and check Inbox. Approval and provisioning are separate stages. Do not submit repeated requests while review is pending.
# '''Set your shell password.''' Use the password form or recovery process provided when requested. This is separate from your dashboard password. Wait until the shell shows active before attempting SSH.

== Already have a shell? ==
Register and verify the dashboard account, then ask staff to link your existing shell after ownership checks. Do not request a duplicate. Linking does not automatically renew a subscription, reset the shell password or reactivate a suspended shell.

== You are ready when ==

* Your shell appears in the dashboard and is active.
* You have set the shell password and can see your connection details.
* You understand the plan’s permissions and any Keep requirement.

== If something blocks progress ==
{| class="wikitable"
!What you see
!What to do
|-
|Verified account, no shell
|Check request and provisioning status. Verification alone does not create a shell.
|-
|Request needs information
|Read Inbox and the eligibility instructions; complete the missing step.
|-
|Existing username not linked
|Contact staff with ownership details. Never send passwords or verification links.
|}

== Registration, approval and activation are different ==
{| class="wikitable"
!Stage
!Meaning
|-
|Dashboard registered
|A customer account exists; shell access has not been granted.
|-
|Email verified
|Ownership of the email is confirmed; the request can still need other checks.
|-
|Request approved
|Staff have accepted the request; provisioning or password setup may still be pending.
|-
|Shell active
|Use the assigned connection details and your shell password.
|}
Do not publish verification tokens, reset links or customer dashboard screenshots containing private details.

== Rules and support ==
This guide describes how to use the service; it does not replace [[DWShells:Signup and Rules|Signup and Rules]]. Join '''#DWShells''' on <code>irc.darkworld.chat</code> using TLS port '''6697''' for help. Use [https://panel.shells.darkworld.network/customer/ the customer portal] for your actual status and connection details. Never share credentials or recovery links.

[[DWShells:Documentation|Back to documentation]]

DWShells:Getting Started

2026-10-05T20:18:35Z

Fizi: Created page with "'''From signup to your first shell''' Register, request a plan, complete verification and recognise when your shell is ready. '''Last verified:''' 6 October 2026, against the current customer panel and service rules. Your effective dashboard permissions and assigned values take precedence over examples. ← Documentation hub · [https://shells.darkworld.network/guides/getting-started/ Visual websi..."

DWShells:Documentation

2026-10-05T20:17:43Z

Fizi: Created page with "'''DWShells documentation''' Practical documentation for the DarkWorld shell service. Start with signup, learn your dashboard, then choose a guide for the task you want to perform. '''Last verified:''' 6 October 2026. The [https://shells.darkworld.network/guides/ website guides] provide illustrated introductions. This wiki contains the detailed instructions and authoritative service rules. Your s..."

DWShells:Signup and Rules

2026-10-04T17:27:43Z

Fizi: Protected "DWShells:Signup and Rules" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

DWShells provides Linux shell accounts for IRC and other approved uses. These rules apply to every account, including Free, Support, Support-Plus, Premium, Staff and Developer. Available applications and resources depend on your plan and any approved account-specific limits.

== Signup process ==

=== 1. Register and verify your email ===

Open the [https://panel.shells.darkworld.network/customer/ DWShells customer portal] and complete registration. Registration currently accepts Gmail addresses, including the supported googlemail.com domain. Complete the email verification requested by the portal.

Your dashboard account and your Linux shell account are separate. Registering or verifying your email does not immediately create or activate a shell.

=== 2. Choose your plan and submit a request ===

Choose Free or an available paid plan through the dashboard. Provide accurate information and explain your intended use. Free shells are intended for IRC-related use; other plans may support broader approved uses.

For a Free request, complete the portal's IRC identity and community verification steps. Register and identify your nickname with NickServ on DarkWorld IRC, then follow the dashboard's instructions to complete the DWShells verification challenge and supply the requested community information.

For a paid plan, follow the displayed request and payment-review instructions. Payment or a donation does not bypass approval or these rules.

=== 3. Wait for staff review ===

Staff review your customer account, request, verification and eligibility. Respond to requests for additional information. Approval and provisioning are separate stages, and activation time depends on review and service availability.

=== 4. Set your shell password and await activation ===

When the dashboard requests it, set your shell password through the provided form. Follow the status shown until your shell is active. Never send your password, verification link or recovery codes to staff or post them in IRC.

=== 5. Connect and manage your shell ===

Once activated, use the connection details in your dashboard. The shared SSH and SFTP login host is <code>shells.darkworld.network</code>:

<pre>
ssh YOUR_USERNAME@shells.darkworld.network
sftp YOUR_USERNAME@shells.darkworld.network
</pre>

Your personal hostname, website and application ports are listed separately. Use Packages to manage permitted applications and Keep / Renewal to check renewal requirements.

=== Existing shell users ===

Register and verify your dashboard account, then contact staff to have your existing shell linked after ownership checks. Do not submit a duplicate new-shell request for an account you already own. Linking does not reset your shell password, renew a paid subscription or reactivate a suspended account.

== Account and security rules ==

* Use your account only for its approved purpose and plan.
* Keep registration and ownership information accurate. Do not impersonate another person or claim a shell you do not own.
* Do not share, lend, sell or transfer your shell or dashboard access. Additional shells require staff approval; do not create duplicate registrations to bypass limits or a suspension.
* Protect passwords, SSH keys, application credentials and recovery codes. Report suspected compromise promptly.
* Do not access another user's files, credentials, processes or private information, or attempt to gain elevated privileges.
* Do not bypass quotas, application limits, network restrictions, renewal controls or security monitoring.

== Prohibited activity ==

* Port scanning, vulnerability scanning or probing third-party Internet hosts from DWShells is prohibited. Security testing requires prior written staff permission and authorization from the target owner.
* DoS/DDoS attacks, flooding, brute-force attacks, credential theft and other disruptive activity are prohibited.
* Do not run or distribute malware, trojans, backdoors or exploit code intended to compromise systems.
* Cryptocurrency mining and unauthorized distributed computing are prohibited.
* Do not send spam, phishing messages or unsolicited bulk messages through email, IRC or another service.
* Do not store or publish illegal material, pirated software, stolen data or links intended to distribute such material.
* Do not operate public proxies, open relays, VPN gateways, Tor relays/exits or similar traffic-forwarding services without explicit staff approval. A plan-authorized personal ZNC bouncer is permitted within its limits.

== IRC and applications ==

* Follow the rules of every IRC network and channel you use. Do not evade bans, abuse channels, flood users or operate abusive bots.
* Use only permitted IRC destinations and ports. Request staff review when a required network is unavailable; do not tunnel around restrictions.
* ZNC, Eggdrop, IRC clients and other background applications are allowed only within your plan's permissions and account limits. Python environments and other development features depend on your plan.
* Stay within the displayed IRC connection and application limits. Do not run unnecessary duplicate clients or instances, or provide bouncer access to other people without approval.
* Use only your assigned IP addresses and ports. Do not bind another account's allocation or expose an unapproved service.
* Free shells use IPv6 for outbound IRC connections. Support and other non-Free plans can use IPv4 and IPv6 where permitted, with IPv6 preferred by the managed configuration.
* Allocated inbound IPv4 access to ZNC or another permitted application does not grant Free shells outbound IPv4 IRC access.
* Use encrypted connections wherever supported. Follow the application's displayed TLS settings, hostname and assigned listener port.

== Resources and hosting ==

* Respect your disk, memory, CPU, process, bandwidth, connection and application limits. Your dashboard shows your effective allocation, including approved overrides.
* Stop unused services and keep logs and temporary files under control. Do not use the shell for resource-intensive workloads outside its approved purpose.
* Request extra resources before exceeding limits. A paid account remains subject to fair use and security rules.
* Keep websites and scripts lawful, secure and within the permitted scope of your plan. Free hosting must support the approved personal or IRC-related use.
* Business use, resale, paid hosting for others and commercial workloads require explicit staff approval and a suitable plan.
* You are responsible for uploaded files, scripts, application configuration and website content. Do not leave an insecure application exposed.

== Free account Keep / Renewal ==

* Keep is enabled by default for Free shells. Check the selected shell's countdown and use the dashboard's Keep / Renewal page before its deadline.
* A normal successful Keep provides at least 14 days from renewal. Repeated Keeps do not accumulate unlimited time, and a later staff-approved deadline is preserved.
* You may complete at most two successful user Keeps per shell per UTC day. The allowance resets at midnight UTC, which is 5:00 a.m. in Pakistan.
* Each shell has its own renewal status. SSH activity or leaving a bot running does not replace Keep renewal.
* Contact staff before expiry if illness, travel or an emergency prevents renewal. Extensions and timer pauses require staff review.
* An expired, locked or suspended account may require staff review before access can be restored. Keep does not bypass suspension.
* Keep is off by default for other plans. If staff enables it there, it records activity and does not replace paid renewal or extend a subscription.

== Community and support ==

Join '''#DWShells on DarkWorld IRC''', using <code>irc.darkworld.chat</code> with TLS on port '''6697''', for help and service announcements. Add the channel to autojoin where practical and check dashboard notices regularly.

Treat users and staff respectfully. Do not harass, threaten, impersonate or publish another person's private information. Support volunteers may take time to respond; keep your question available and check back later.

== Backups and enforcement ==

Keep your own independent copies of important files. Available backup and restore features have coverage limits and do not guarantee recovery of every file or live application state. Review the warnings shown for your shell before relying on a backup.

Staff may stop an application, restrict access or suspend an account to contain abuse or protect the service. Minor issues may receive a warning and an opportunity to correct them; serious or repeated violations may result in immediate suspension or account closure. These rules apply equally to paid accounts.

If you believe an action was taken in error, contact staff with your username and relevant details. Do not create another account to evade the restriction.

[[Category:DWShells]]

DWShells:Rules

2026-10-04T17:27:27Z

Fizi: Fizi moved page DWShells:Rules to DWShells:Signup and Rules

#REDIRECT [[DWShells:Signup and Rules]]

DWShells:Signup and Rules

2026-10-04T17:27:27Z

Fizi: Fizi moved page DWShells:Rules to DWShells:Signup and Rules

DWShells:Signup and Rules

2026-10-04T17:21:25Z

Fizi: Created page with " DWShells provides Linux shell accounts for IRC and other approved uses. These rules apply to every account, including Free, Support, Support-Plus, Premium, Staff and Developer. Available applications and resources depend on your plan and any approved account-specific limits. == Signup process == === 1. Register and verify your email === Open the [https://panel.shells.darkworld.network/customer/ DWShells customer..."

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