From ffdc325e9610e3760cfc7d0c5d82c1739e552d9d Mon Sep 17 00:00:00 2001
From: acidvegas <acid.vegas@acid.vegas>
Date: Sat, 14 Feb 2026 20:18:39 -0500
Subject: [PATCH] Initial commit

---
 README.md             |   13 +
 wiki/BAN-POLICY.md    |   41 +
 wiki/CHANNEL-MODES.md |   78 ++
 wiki/CHANNELS.md      |   16 +
 wiki/CLIENTS.md       |   48 +
 wiki/COMMANDS.md      |  112 ++
 wiki/Home.md          |    1 +
 wiki/MODES.md         |    4 +
 wiki/RFC.md           |    4 +
 wiki/RFC2810.md       |  267 +++++
 wiki/RFC2811.md       |  460 ++++++++
 wiki/RFC2812.md       | 2432 +++++++++++++++++++++++++++++++++++++++++
 wiki/RFC2813.md       |  627 +++++++++++
 wiki/SNOMASKS.md      |   38 +
 wiki/USER-MODES.md    |   42 +
 wiki/USERS.md         |    1 +
 wiki/_Footer.md       |    1 +
 wiki/_Sidebar.md      |   14 +
 18 files changed, 4199 insertions(+)
 create mode 100644 README.md
 create mode 100644 wiki/BAN-POLICY.md
 create mode 100644 wiki/CHANNEL-MODES.md
 create mode 100644 wiki/CHANNELS.md
 create mode 100644 wiki/CLIENTS.md
 create mode 100644 wiki/COMMANDS.md
 create mode 100644 wiki/Home.md
 create mode 100644 wiki/MODES.md
 create mode 100644 wiki/RFC.md
 create mode 100644 wiki/RFC2810.md
 create mode 100644 wiki/RFC2811.md
 create mode 100644 wiki/RFC2812.md
 create mode 100644 wiki/RFC2813.md
 create mode 100644 wiki/SNOMASKS.md
 create mode 100644 wiki/USER-MODES.md
 create mode 100644 wiki/USERS.md
 create mode 100644 wiki/_Footer.md
 create mode 100644 wiki/_Sidebar.md

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..dd096f6
--- /dev/null
+++ b/README.md
@@ -0,0 +1,13 @@
+# SuperNets Wiki
+
+Lore, shenanigans, memes, and lulz from the [SuperNets](irc://irc.supernets.org) IRC network.
+
+📖 **Read the wiki:** https://git.supernets.org/supernets/wiki/wiki
+
+---
+
+### Contribute
+
+Got SuperNets lore, memes, or tales of degeneracy to share? Open an [issue](https://git.supernets.org/supernets/wiki/issues) or submit a [pull request](https://git.supernets.org/supernets/wiki/pulls).
+
+All contributions welcome — the more unhinged, the better.
diff --git a/wiki/BAN-POLICY.md b/wiki/BAN-POLICY.md
new file mode 100644
index 0000000..55e817f
--- /dev/null
+++ b/wiki/BAN-POLICY.md
@@ -0,0 +1,41 @@
+# Ban Policy
+
+## Channel Bans
+
+Bans made in a channel are controlled only by the channels operators. If you have been banned from a channel and would like to be un-banned, you will have to contact one of the channels operators via private message.
+
+**The network operators do not interfere with channel bans.**
+
+## Network Bans
+
+Bans made on a network-wide level are only ever really done to mitigate spam.
+
+The network uses a DNSBL system in an effort to mitigate spam from known blacklisted hosts. We use the [DroneBL](https://www.dronebl.org/), [EFNetRBL](https://rbl.efnetrbl.org/), & [TorBL](https://www.dan.me.uk/dnsbl) lists actively. Matching hosts on any of these lists will be automatically banned from the network upon connection.
+
+**DNSBL based bans will expire after 30 days.**
+
+---
+
+## Ban Evasion
+
+We are aware that this is IRC and people will try to evade bans by changing their host. By all means, go ahead and try. You may carry on and chat, but there is nothing stopping an operator from placing another ban on your host again if they notice or care.
+
+---
+
+## Ban Exemptions
+
+There are times where your host may be on the same host as a user who has been banned, making the ban affect you by accident.
+
+There are also times where you may hit a connection limit from too many people connected from the same IP address. This most commonly occurs with people using a web client such as [Mibbit](https://www.mibbit.com/) or [KiwiIRC](https://kiwiirc.com/), and people using [IRCCloud](https://www.irccloud.com/).
+
+#### Channel Exemptions
+
+Channel exemptions can be done through use of the `+e` mode. Exemptions include host based, nickserv account based, & SSL client certificate fingerprint based.
+
+You can request a channel ban exemption by asking one of the channels operators.
+
+#### Network Exemptions
+
+If your host was added to the DNSBL lists by accident you may request a ban exemption.
+
+These exemptions are given out scarcely and only to known trusted users. You may contact us if you feel you qualify for a ban exemption.
\ No newline at end of file
diff --git a/wiki/CHANNEL-MODES.md b/wiki/CHANNEL-MODES.md
new file mode 100644
index 0000000..a2fcb2b
--- /dev/null
+++ b/wiki/CHANNEL-MODES.md
@@ -0,0 +1,78 @@
+# CHANNEL MODES
+
+#### Usage:
+
+```
+/mode #channel [+|-]<MODE> [ARGUMENTS]
+```
+
+#### Examples:
+
+```
+/mode #superbowl -m
+/mode #superbowl +k secretpassword
+```
+
+---
+
+#### Key
+
+`✅ = Set by default ` `🔒 = Can not be turned off`
+
+## Access Levels
+
+| Mode  | Name   | Description                                                    |
+|-------|--------|----------------------------------------------------------------|
+| **v** | Voice  | Can speak in moderated *(+m)* channels                         |
+| **h** | Halfop | Same as channel operator, just can't `/KICK` channel operators |
+| **o** | Op     | Channel operator                                               |
+
+---
+
+## List Modes
+
+| Mode  | Name   | Description                              |
+|-------|--------|------------------------------------------|
+| **b** | Ban    | Prevent users matching mask from joining |
+| **e** | Except | Exception to ban list                    |
+| **I** | Invite | Exception to invite-only mode            |
+
+---
+
+## Channel Modes
+
+|    | Mode  | Name          | Description                         | Restriction |
+|----|-------|---------------|-------------------------------------|-------------|
+|    | **c** | NoColor       | Block color                         |             |
+|    | **C** | NoCTCP        | Block CTCP                          |             |
+|    | **d** | DelayJoinTemp | Temporary processing delayed users  | *Server*    |
+|    | **D** | DelayJoin     | Hide joins until user speaks        |             |
+|    | **f** | Flood         | Custom anti-flood settings          |             |
+|    | **F** | FloodProfile  | Anti-flood protection profile       |             |
+|    | **G** | Censor        | Filter bad words                    |             |
+|    | **H** | History       | Show message history                |             |
+|    | **i** | InviteOnly    | Require `/INVITE` to join           |             |
+|    | **k** | Key           | Require password to join            |             |
+|    | **K** | NoKnock       | Block `/KNOCK`                      |             |
+|    | **l** | Limit         | Max users limit                     |             |
+| 🔒 | **L** | Link          | Forward users to another channel    |             |
+|    | **m** | Moderated     | Only voiced *(+v)* users can speak  |             |
+|    | **M** | RegSpeak      | Only registered users can speak     |             |
+| 🔒 | **n** | NoExternal    | Block outside messages              |             |
+|    | **N** | NoNickChange  | Prevent `/NICK`                     |             |
+|    | **O** | OperOnly      | Only IRC operators can join         | *Oper*      |
+| 🔒 | **p** | Private       | Hide channel from `/WHOIS`          |             |
+| 🔒 | **P** | Permanent     | Channel persists when empty         | *Oper*      |
+|    | **Q** | NoKick        | Block `/KICK`                       |             |
+|    | **r** | Registered    | Channel is registered with services | *Server*    |
+|    | **R** | RegOnly       | Only registered users can join      |             |
+| 🔒 | **s** | Secret        | Hidden from `/LIST` & `/WHOIS`      |             |
+|    | **S** | StripColor    | Strip color                         |             |
+|    | **t** | TopicLimit    | Only channel operators can `/TOPIC` |             |
+|    | **T** | NoNotice      | Block `/NOTICE`                     |             |
+|    | **V** | NoInvite      | Block `/INVITE`                     |             |
+|    | **z** | SecureOnly    | Only SSL/TLS users can join         |             |
+|    | **Z** | AllSecure     | All users are using TLS             | *Server*    |
+
+---
+
diff --git a/wiki/CHANNELS.md b/wiki/CHANNELS.md
new file mode 100644
index 0000000..d7643a9
--- /dev/null
+++ b/wiki/CHANNELS.md
@@ -0,0 +1,16 @@
+# Channels
+
+| Channel                            | Description                                                                                                                |
+|------------------------------------|----------------------------------------------------------------------------------------------------------------------------|
+| [**#5000**](#5000)                 | **THE BEST 5000 CHANNELS ON IRC**                                                                                          |
+| [**#anythinggoes**](#anythinggoes) | **NO KICKS NO BANS NO OPS NO RULES**                                                                                       |
+| [**#blackhole**](#blackhole)       | ENTER THE VOID *(Honeypot)*                                                                                                |
+| [**#comms**](#comms)               | Radio chats focused on SDR, LoRa, Meshtastic, etc                                                                          |
+| [**#dev**](#dev)                   | Programming & development discussion & testing                                                                             |
+| [**#exchange**](#exchange)         | IRC cryptocurrency exchange                                                                                                |
+| [**#hardchats**](#hardchats)       | [hardchats.com](https://hardchats.com)                                                                                     |
+| [**#mensa**](#mensa)               | REAL NIGGAS ONLY                                                                                                           |
+| [**#scroll**](#scroll)             | ASCII/ANSI Art                                                                                                             |
+| [**#superbowl**](#superbowl)       | THE THUNDERDOME, psychotherapy, `/dev/urandom`, toxic HATE mongering, HARD fucking CHATS *(warning: sociopaths prevalent)* |
+
+**Note:** ALL channels on the network have the `+s` *(secret)* mode by locked on by default, making them hidden from `/LIST`. You can request to have your channel set to `-s` to make it visible, but this is only granted to channels that are actively being used and have a substantial user base. Small private channels with only 2-3 people will remain secret.
\ No newline at end of file
diff --git a/wiki/CLIENTS.md b/wiki/CLIENTS.md
new file mode 100644
index 0000000..924ebb1
--- /dev/null
+++ b/wiki/CLIENTS.md
@@ -0,0 +1,48 @@
+# IRC Clients
+
+## Terminal
+
+### [WeeChat](https://weechat.org/)
+A fast, light, and extensible chat client. WeeChat is highly customizable with scripts and plugins, supports multiple protocols, and features a clean interface with powerful features like split windows, mouse support, and scripting in multiple languages (Python, Perl, Ruby, Lua, etc.).
+
+### [Irssi](https://irssi.org/)
+A modular text-mode IRC client known for its active development and flexibility. Irssi is highly scriptable with Perl and features a robust set of features for power users, including excellent logging, proxy support, and a strong plugin ecosystem.
+
+---
+
+## Desktop
+
+### [HexChat](https://hexchat.github.io/)
+A popular graphical IRC client based on XChat, available for Windows and Linux. HexChat offers a user-friendly interface with spell checking, multiple server connections, customizable alerts, and extensive scripting support through Python and Perl plugins.
+
+**Warning:** This client is has hit its [sunset](https://hexchat.github.io/news/2.16.2.htmlhttps://hexchat.github.io/news/2.16.2.html) & is no longer being maintained. Watch out for 0days!
+
+### [mIRC](https://www.mirc.com/)
+The classic Windows IRC client that has been around since 1995. mIRC features a powerful scripting language, file sharing via DCC, customizable interface, and extensive sound and event triggering capabilities. It remains one of the most popular IRC clients on Windows.
+
+---
+
+## Web
+
+### [HardLounge](https://webchat.supernets.org)
+A fork of [TheLounge](https://thelounge.chat/) customized for dark mode, better color support, monospace font & no line spacing for ASCII support.
+
+### [TheLounge](https://thelounge.chat/)
+A modern, self-hosted web IRC client that runs 24/7 on your server. TheLounge features a responsive interface, persistent connections, message history, and multi-device support. It's perfect for users who want to stay connected without running a local client.
+
+### [Glowing Bear](https://www.glowing-bear.org/)
+A web-based frontend for WeeChat that connects via the WeeChat relay protocol. Glowing Bear provides a sleek, modern interface to access your WeeChat instance from any browser, complete with notifications, multi-device sync, and mobile support.
+
+---
+
+## Mobile
+
+### [WeeChat Relay](https://weechat.org/about/features/)
+Mobile applications that connect to your WeeChat instance via the relay protocol. These apps allow you to access your persistent WeeChat session from your phone, maintaining your connection, scrollback, and configuration.
+
+**Apps:**
+- [Weechat-Android](https://github.com/ubergeek42/weechat-android) - Android client
+- [weechat-ios](https://github.com/mhoran/weechatRN) - iOS client
+
+### [IRCCloud](https://www.irccloud.com/)
+A commercial IRC bouncer and client service with native mobile apps. IRCCloud keeps you connected 24/7 with push notifications, searchable message history, file uploads, and a polished interface across iOS and Android. Offers both free and paid tiers.
\ No newline at end of file
diff --git a/wiki/COMMANDS.md b/wiki/COMMANDS.md
new file mode 100644
index 0000000..5c49a23
--- /dev/null
+++ b/wiki/COMMANDS.md
@@ -0,0 +1,112 @@
+# COMMANDS
+
+#### Usage:
+
+```
+/<COMMAND> [ARGUMENTS]
+```
+
+#### Examples:
+
+```
+/whois acidvegas
+/mode #superbowl +m
+/kick #superbowl baduser Stop spamming!
+```
+
+---
+
+## Public Commands
+
+| Command      | Arguments                   | Description                             |
+|--------------|-----------------------------|-----------------------------------------|
+| **ADMIN**    |                             | Show server administrator information   |
+| **AWAY**     |                             | Marked as away or back                  |
+| **CAP**      |                             | Set IRCv3 capabilities                  |
+| **CYCLE**    | `<channel>`                 | Rejoin a channel                        |
+| **INVITE**   | `<nick> <channel>`          | Invite a user to a channel              |
+| **ISON**     | `<nick> [nick] ...`         | Check if users are online               |
+| **JOIN**     | `<channel>`                 | Join a channel                          |
+| **KICK**     | `<channel> <nick> [reason]` | Kick a user from a channel              |
+| **KNOCK**    | `<channel> [message]`       | Request invitation to channel           |
+| **LAG**      |                             | Check server lag and connection quality |
+| **LINKS**    |                             | Show linked servers                     |
+| **LIST**     | `[options]`                 | List channels and their topics          |
+| **LUSERS**   |                             | Show statistics about users and servers |
+| **MAP**      |                             | Display network server map              |
+| **MODE**     | `<target> <modes>`          | Change user or channel modes            |
+| **MOTD**     | `[server]`                  | Show Message Of The Day                 |
+| **NAMES**    | `<channel>`                 | Show users in a channel                 |
+| **NICK**     | `<newnick>`                 | Change your nickname                    |
+| **NOTICE**   | `<target> <message>`        | Send a notice message                   |
+| **OPER**     | `<username> <password>`     | Authenticate as an IRC operator         |
+| **PART**     | `<channel> [reason]`        | Leave a channel                         |
+| **PASS**     | `<password>`                | Server password                         |
+| **PING**     | `<target>`                  | Test connection latency                 |
+| **PONG**     | `<target>`                  | Response to PING                        |
+| **PRIVMSG**  | `<target> <message>`        | Send a private message                  |
+| **QUIT**     | `[reason]`                  | Disconnect from IRC                     |
+| **RULES**    |                             | Show server rules                       |
+| **SETNAME**  | `<realname>`                | Change your own real name               |
+| **SILENCE**  | `[+/-]<mask>`               | Block private messages from users       |
+| **TAGMSG**   |                             | Send message tags without text          |
+| **TIME**     | `[server]`                  | Show server time                        |
+| **TOPIC**    | `<channel> [topic]`         | View or set channel topic               |
+| **USER**     |                             | Set username during connection          |
+| **USERHOST** | `<nick>`                    | Show nick, user, and host information   |
+| **USERIP**   | `<nick>`                    | Show user IP address                    |
+| **VERSION**  | `[server]`                  | Show server version information         |
+| **VHOST**    | `<login> <password>`        | Authenticate for a virtual host         |
+| **WATCH**    |                             | Monitor online/offline status of users  |
+| **WHO**      | `[mask] [options]`          | Search and display user information     |
+| **WHOIS**    | `<nick> [nick]`             | Show detailed user information          |
+
+---
+
+## IRCOp Commands
+
+| Command        | Arguments                     | Description                          |
+|----------------|-------------------------------|--------------------------------------|
+| **CHGHOST**    | `<nick> <host>`               | Change hostname of someone           |
+| **CHGIDENT**   | `<nick> <ident>`              | Change ident/username of someone     |
+| **CHGNAME**    | `<nick> <name>`               | Change real-name of someone          |
+| **GLINE**      | `<user@host> <time> <reason>` | Add a global ban                     |
+| **GZLINE**     | `<IP> <time> <reason>`        | Add a global IP ban                  |
+| **KILL**       | `<nick> <reason>`             | Disconnect a user from IRC           |
+| **KLINE**      | `<user@host> <time> <reason>` | Add a local server ban               |
+| **QLINE**      | `<nickname> <time> <reason>`  | Ban a nickname pattern               |
+| **SAJOIN**     | `<nick> <channel>`            | Force a user to join a channel       |
+| **SAMODE**     | `<target> <modes>`            | Force mode changes                   |
+| **SANICK**     | `<nick> <newnick>`            | Force a user to change nickname      |
+| **SAPART**     | `<nick> <channel>`            | Force a user to leave a channel      |
+| **SAQUIT**     | `<nick> <reason>`             | Force a user to disconnect           |
+| **SATOPIC**    | `<channel> <topic>`           | Force set a channel topic            |
+| **SETHOST**    | `<host>`                      | Change your own hostname             |
+| **SETIDENT**   | `<ident>`                     | Change your own ident                |
+| **SHUN**       | `<user@host> <time> <reason>` | Prevent user from executing commands |
+| **SPAMFILTER** |                               | Manage spam filters                  |
+| **SQLINE**     | `<mask> <reason>`             | Ban nickname patterns                |
+| **STATS**      | `<type> [server]`             | Show various server statistics       |
+| **TRACE**      | `<server\|nick>`              | Trace the path to server or nick     |
+
+---
+
+## Server Commands
+
+| Command           | Arguments           | Description                             |
+|-------------------|---------------------|-----------------------------------------|
+| **CLOSE**         |                     | Close pending connections               |
+| **CONNECT**       | `<server>`          | Start linking to server                 |
+| **DIE**           |                     | Shutdown the IRC server                 |
+| **GLOADMODULE**   |                     | Globally load a module on all servers   |
+| **GRELOADMODULE** |                     | Globally reload a module on all servers |
+| **GUNLOADMODULE** |                     | Globally unload a module on all servers |
+| **LOADMODULE**    |                     | Load a module on local server           |
+| **MKPASSWD**      | `<password>`        | Generate encrypted password hash        |
+| **MODULES**       |                     | List loaded modules                     |
+| **REHASH**        | `[options]`         | Reload server configuration             |
+| **RELOADMODULE**  |                     | Reload a module on local server         |
+| **RESTART**       |                     | Restart the IRC server                  |
+| **SERVER**        |                     | Server linking command                  |
+| **SQUIT**         | `<server> <reason>` | Disconnect a server from the network    |
+| **TSCTL**         |                     | Time synchronization control            |
\ No newline at end of file
diff --git a/wiki/Home.md b/wiki/Home.md
new file mode 100644
index 0000000..5d08b7b
--- /dev/null
+++ b/wiki/Home.md
@@ -0,0 +1 @@
+Welcome to the Wiki.
\ No newline at end of file
diff --git a/wiki/MODES.md b/wiki/MODES.md
new file mode 100644
index 0000000..c18f970
--- /dev/null
+++ b/wiki/MODES.md
@@ -0,0 +1,4 @@
+- [Channel Modes](./CHANNEL-MODES)
+- [Extended Modes](./EXTENDED-MODES)
+- [Snomasks](./SNOMASKS)
+- [User Modes](./USER-MODES)
\ No newline at end of file
diff --git a/wiki/RFC.md b/wiki/RFC.md
new file mode 100644
index 0000000..de9afdf
--- /dev/null
+++ b/wiki/RFC.md
@@ -0,0 +1,4 @@
+  - [RFC2810 - Architecture](./RFC2810)
+  - [RFC2811 - Channel Management](./RFC2811)
+  - [RFC2812 - Client Protocol](./RFC2812)
+  - [RFC2813 - Server Protocol](./RFC2813)
\ No newline at end of file
diff --git a/wiki/RFC2810.md b/wiki/RFC2810.md
new file mode 100644
index 0000000..fa1be49
--- /dev/null
+++ b/wiki/RFC2810.md
@@ -0,0 +1,267 @@
+# RFC 2810 - Internet Relay Chat: Architecture
+
+**Network Working Group:** C. Kalt  
+**Request for Comments:** 2810  
+**Updates:** 1459  
+**Category:** Informational  
+**Date:** April 2000
+
+## Status of this Memo
+
+This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
+
+## Copyright Notice
+
+Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+## Abstract
+
+The IRC (Internet Relay Chat) protocol is for use with text based conferencing. It has been developed since 1989 when it was originally implemented as a mean for users on a BBS to chat amongst themselves.
+
+First formally documented in May 1993 by RFC 1459 [IRC], the protocol has kept evolving. This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here.
+
+## Table of Contents
+
+- [1. Introduction](#1-introduction)
+- [2. Components](#2-components)
+  - [2.1 Servers](#21-servers)
+  - [2.2 Clients](#22-clients)
+    - [2.2.1 User Clients](#221-user-clients)
+    - [2.2.2 Service Clients](#222-service-clients)
+- [3. Architecture](#3-architecture)
+- [4. IRC Protocol Services](#4-irc-protocol-services)
+  - [4.1 Client Locator](#41-client-locator)
+  - [4.2 Message Relaying](#42-message-relaying)
+  - [4.3 Channel Hosting And Management](#43-channel-hosting-and-management)
+- [5. IRC Concepts](#5-irc-concepts)
+  - [5.1 One-To-One Communication](#51-one-to-one-communication)
+  - [5.2 One-To-Many](#52-one-to-many)
+    - [5.2.1 To A Channel](#521-to-a-channel)
+    - [5.2.2 To A Host/Server Mask](#522-to-a-hostserver-mask)
+    - [5.2.3 To A List](#523-to-a-list)
+  - [5.3 One-To-All](#53-one-to-all)
+    - [5.3.1 Client-to-Client](#531-client-to-client)
+    - [5.3.2 Client-to-Server](#532-client-to-server)
+    - [5.3.3 Server-to-Server](#533-server-to-server)
+- [6. Current Problems](#6-current-problems)
+  - [6.1 Scalability](#61-scalability)
+  - [6.2 Reliability](#62-reliability)
+  - [6.3 Network Congestion](#63-network-congestion)
+  - [6.4 Privacy](#64-privacy)
+- [7. Security Considerations](#7-security-considerations)
+- [8. Current Support And Availability](#8-current-support-and-availability)
+- [9. Acknowledgements](#9-acknowledgements)
+- [10. References](#10-references)
+- [11. Author's Address](#11-authors-address)
+- [12. Full Copyright Statement](#12-full-copyright-statement)
+
+## 1. Introduction
+
+The IRC (Internet Relay Chat) protocol has been designed over a number of years for use with text based conferencing. This document describes its current architecture.
+
+The IRC Protocol is based on the client-server model, and is well suited to running on many machines in a distributed fashion. A typical setup involves a single process (the server) forming a central point for clients (or other servers) to connect to, performing the required message delivery/multiplexing and other functions.
+
+This distributed model, which requires each server to have a copy of the global state information, is still the most flagrant problem of the protocol as it is a serious handicap, which limits the maximum size a network can reach. If the existing networks have been able to keep growing at an incredible pace, we must thank hardware manufacturers for giving us ever more powerful systems.
+
+## 2. Components
+
+The following paragraphs define the basic components of the IRC protocol.
+
+### 2.1 Servers
+
+The server forms the backbone of IRC as it is the only component of the protocol which is able to link all the other components together: it provides a point to which clients may connect to talk to each other [IRC-CLIENT], and a point for other servers to connect to [IRC-SERVER]. The server is also responsible for providing the basic services defined by the IRC protocol.
+
+### 2.2 Clients
+
+A client is anything connecting to a server that is not another server. There are two types of clients which both serve a different purpose.
+
+#### 2.2.1 User Clients
+
+User clients are generally programs providing a text based interface that is used to communicate interactively via IRC. This particular type of clients is often referred as "users".
+
+#### 2.2.2 Service Clients
+
+Unlike users, service clients are not intended to be used manually nor for talking. They have a more limited access to the chat functions of the protocol, while optionally having access to more private data from the servers.
+
+Services are typically automatons used to provide some kind of service (not necessarily related to IRC itself) to users. An example is a service collecting statistics about the origin of users connected on the IRC network.
+
+## 3. Architecture
+
+An IRC network is defined by a group of servers connected to each other. A single server forms the simplest IRC network.
+
+The only network configuration allowed for IRC servers is that of a spanning tree where each server acts as a central node for the rest of the network it sees.
+
+```
+                   1--\
+                       A        D---4
+                   2--/ \      /
+                         B----C
+                        /      \
+                       3        E
+
+Servers: A, B, C, D, E         Clients: 1, 2, 3, 4
+```
+
+**Figure 1.** Sample small IRC network
+
+The IRC protocol provides no mean for two clients to directly communicate. All communication between clients is relayed by the server(s).
+
+## 4. IRC Protocol Services
+
+This section describes the services offered by the IRC protocol. The combination of these services allow real-time conferencing.
+
+### 4.1 Client Locator
+
+To be able to exchange messages, two clients must be able to locate each other.
+
+Upon connecting to a server, a client registers using a label which is then used by other servers and clients to know where the client is located. Servers are responsible for keeping track of all the labels being used.
+
+### 4.2 Message Relaying
+
+The IRC protocol provides no mean for two clients to directly communicate. All communication between clients is relayed by the server(s).
+
+### 4.3 Channel Hosting And Management
+
+A channel is a named group of one or more users which will all receive messages addressed to that channel. A channel is characterized by its name and current members, it also has a set of properties which can be manipulated by (some of) its members.
+
+Channels provide a mean for a message to be sent to several clients. Servers host channels, providing the necessary message multiplexing. Servers are also responsible for managing channels by keeping track of the channel members. The exact role of servers is defined in "Internet Relay Chat: Channel Management" [IRC-CHAN].
+
+## 5. IRC Concepts
+
+This section is devoted to describing the actual concepts behind the organization of the IRC protocol and how different classes of messages are delivered.
+
+### 5.1 One-To-One Communication
+
+Communication on a one-to-one basis is usually performed by clients, since most server-server traffic is not a result of servers talking only to each other. To provide a means for clients to talk to each other, it is REQUIRED that all servers be able to send a message in exactly one direction along the spanning tree in order to reach any client. Thus the path of a message being delivered is the shortest path between any two points on the spanning tree.
+
+The following examples all refer to Figure 1 above.
+
+**Example 1:** A message between clients 1 and 2 is only seen by server A, which sends it straight to client 2.
+
+**Example 2:** A message between clients 1 and 3 is seen by servers A & B, and client 3. No other clients or servers are allowed see the message.
+
+**Example 3:** A message between clients 2 and 4 is seen by servers A, B, C & D and client 4 only.
+
+### 5.2 One-To-Many
+
+The main goal of IRC is to provide a forum which allows easy and efficient conferencing (one to many conversations). IRC offers several means to achieve this, each serving its own purpose.
+
+#### 5.2.1 To A Channel
+
+In IRC the channel has a role equivalent to that of the multicast group; their existence is dynamic and the actual conversation carried out on a channel MUST only be sent to servers which are supporting users on a given channel. Moreover, the message SHALL only be sent once to every local link as each server is responsible to fan the original message to ensure that it will reach all the recipients.
+
+The following examples all refer to Figure 2.
+
+**Example 4:** Any channel with 1 client in it. Messages to the channel go to the server and then nowhere else.
+
+**Example 5:** 2 clients in a channel. All messages traverse a path as if they were private messages between the two clients outside a channel.
+
+**Example 6:** Clients 1, 2 and 3 in a channel. All messages to the channel are sent to all clients and only those servers which must be traversed by the message if it were a private message to a single client. If client 1 sends a message, it goes back to client 2 and then via server B to client 3.
+
+#### 5.2.2 To A Host/Server Mask
+
+To provide with some mechanism to send messages to a large body of related users, host and server mask messages are available. These messages are sent to users whose host or server information match that of the mask. The messages are only sent to locations where users are, in a fashion similar to that of channels.
+
+#### 5.2.3 To A List
+
+The least efficient style of one-to-many conversation is through clients talking to a 'list' of targets (client, channel, mask). How this is done is almost self explanatory: the client gives a list of destinations to which the message is to be delivered and the server breaks it up and dispatches a separate copy of the message to each given destination.
+
+This is not as efficient as using a channel since the destination list MAY be broken up and the dispatch sent without checking to make sure duplicates aren't sent down each path.
+
+### 5.3 One-To-All
+
+The one-to-all type of message is better described as a broadcast message, sent to all clients or servers or both. On a large network of users and servers, a single message can result in a lot of traffic being sent over the network in an effort to reach all of the desired destinations.
+
+For some class of messages, there is no option but to broadcast it to all servers so that the state information held by each server is consistent between servers.
+
+#### 5.3.1 Client-to-Client
+
+There is no class of message which, from a single message, results in a message being sent to every other client.
+
+#### 5.3.2 Client-to-Server
+
+Most of the commands which result in a change of state information (such as channel membership, channel mode, user status, etc.) MUST be sent to all servers by default, and this distribution SHALL NOT be changed by the client.
+
+#### 5.3.3 Server-to-Server
+
+While most messages between servers are distributed to all 'other' servers, this is only required for any message that affects a user, channel or server. Since these are the basic items found in IRC, nearly all messages originating from a server are broadcast to all other connected servers.
+
+## 6. Current Problems
+
+There are a number of recognized problems with this protocol, this section only addresses the problems related to the architecture of the protocol.
+
+### 6.1 Scalability
+
+It is widely recognized that this protocol does not scale sufficiently well when used in a large arena. The main problem comes from the requirement that all servers know about all other servers, clients and channels and that information regarding them be updated as soon as it changes.
+
+### 6.2 Reliability
+
+As the only network configuration allowed for IRC servers is that of a spanning tree, each link between two servers is an obvious and quite serious point of failure. This particular issue is addressed more in detail in "Internet Relay Chat: Server Protocol" [IRC-SERVER].
+
+### 6.3 Network Congestion
+
+Another problem related to the scalability and reliability issues, as well as the spanning tree architecture, is that the protocol and architecture for IRC are extremely vulnerable to network congestions. This problem is endemic, and should be solved for the next generation: if congestion and high traffic volume cause a link between two servers to fail, not only this failure generates more network traffic, but the reconnection (eventually elsewhere) of two servers also generates more traffic.
+
+In an attempt to minimize the impact of these problems, it is strongly RECOMMENDED that servers do not automatically try to reconnect too fast, in order to avoid aggravating the situation.
+
+### 6.4 Privacy
+
+Besides not scaling well, the fact that servers need to know all information about other entities, the issue of privacy is also a concern. This is in particular true for channels, as the related information is quite a lot more revealing than whether a user is online or not.
+
+## 7. Security Considerations
+
+Asides from the privacy concerns mentioned in section 6.4 (Privacy), security is believed to be irrelevant to this document.
+
+## 8. Current Support And Availability
+
+**Mailing lists for IRC related discussion:**
+- General discussion: ircd-users@irc.org
+- Protocol development: ircd-dev@irc.org
+
+**Software implementations:**
+- ftp://ftp.irc.org/irc/server
+- ftp://ftp.funet.fi/pub/unix/irc
+- ftp://coombs.anu.edu.au/pub/irc
+
+**Newsgroup:** alt.irc
+
+## 9. Acknowledgements
+
+Parts of this document were copied from the RFC 1459 [IRC] which first formally documented the IRC Protocol. It has also benefited from many rounds of review and comments. In particular, the following people have made significant contributions to this document:
+
+Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
+
+## 10. References
+
+**[KEYWORDS]** Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+**[IRC]** Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
+
+**[IRC-CLIENT]** Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
+
+**[IRC-SERVER]** Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
+
+**[IRC-CHAN]** Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
+
+## 11. Author's Address
+
+Christophe Kalt  
+99 Teaneck Rd, Apt #117  
+Ridgefield Park, NJ 07660  
+USA
+
+EMail: kalt@stealth.net
+
+## 12. Full Copyright Statement
+
+Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+### Acknowledgement
+
+Funding for the RFC Editor function is currently provided by the Internet Society.
diff --git a/wiki/RFC2811.md b/wiki/RFC2811.md
new file mode 100644
index 0000000..24ffc02
--- /dev/null
+++ b/wiki/RFC2811.md
@@ -0,0 +1,460 @@
+# RFC 2811 - Internet Relay Chat: Channel Management
+
+**Network Working Group:** C. Kalt  
+**Request for Comments:** 2811  
+**Updates:** 1459  
+**Category:** Informational  
+**Date:** April 2000
+
+## Status of this Memo
+
+This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
+
+## Copyright Notice
+
+Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+## Abstract
+
+One of the most notable characteristics of the IRC (Internet Relay Chat) protocol is to allow for users to be grouped in forums, called channels, providing a mean for multiple users to communicate together.
+
+There was originally a unique type of channels, but with the years, new types appeared either as a response to a need, or for experimental purposes.
+
+This document specifies how channels, their characteristics and properties are managed by IRC servers.
+
+## Table of Contents
+
+- [1. Introduction](#1-introduction)
+- [2. Channel Characteristics](#2-channel-characteristics)
+  - [2.1 Namespace](#21-namespace)
+  - [2.2 Channel Scope](#22-channel-scope)
+  - [2.3 Channel Properties](#23-channel-properties)
+  - [2.4 Privileged Channel Members](#24-privileged-channel-members)
+    - [2.4.1 Channel Operators](#241-channel-operators)
+    - [2.4.2 Channel Creator](#242-channel-creator)
+- [3. Channel Lifetime](#3-channel-lifetime)
+  - [3.1 Standard Channels](#31-standard-channels)
+  - [3.2 Safe Channels](#32-safe-channels)
+- [4. Channel Modes](#4-channel-modes)
+  - [4.1 Member Status](#41-member-status)
+    - [4.1.1 "Channel Creator" Status](#411-channel-creator-status)
+    - [4.1.2 Channel Operator Status](#412-channel-operator-status)
+    - [4.1.3 Voice Privilege](#413-voice-privilege)
+  - [4.2 Channel Flags](#42-channel-flags)
+    - [4.2.1 Anonymous Flag](#421-anonymous-flag)
+    - [4.2.2 Invite Only Flag](#422-invite-only-flag)
+    - [4.2.3 Moderated Channel Flag](#423-moderated-channel-flag)
+    - [4.2.4 No Messages To Channel From Clients On The Outside](#424-no-messages-to-channel-from-clients-on-the-outside)
+    - [4.2.5 Quiet Channel](#425-quiet-channel)
+    - [4.2.6 Private and Secret Channels](#426-private-and-secret-channels)
+    - [4.2.7 Server Reop Flag](#427-server-reop-flag)
+    - [4.2.8 Topic](#428-topic)
+    - [4.2.9 User Limit](#429-user-limit)
+    - [4.2.10 Channel Key](#4210-channel-key)
+  - [4.3 Channel Access Control](#43-channel-access-control)
+    - [4.3.1 Channel Ban and Exception](#431-channel-ban-and-exception)
+    - [4.3.2 Channel Invitation](#432-channel-invitation)
+- [5. Current Implementations](#5-current-implementations)
+  - [5.1 Tracking Recently Used Channels](#51-tracking-recently-used-channels)
+  - [5.2 Safe Channels](#52-safe-channels)
+    - [5.2.1 Channel Identifier](#521-channel-identifier)
+    - [5.2.2 Channel Delay](#522-channel-delay)
+    - [5.2.3 Abuse Window](#523-abuse-window)
+    - [5.2.4 Preserving Sanity In The Name Space](#524-preserving-sanity-in-the-name-space)
+    - [5.2.5 Server Reop Mechanism](#525-server-reop-mechanism)
+- [6. Current Problems](#6-current-problems)
+  - [6.1 Labels](#61-labels)
+    - [6.1.1 Channel Delay](#611-channel-delay)
+    - [6.1.2 Safe Channels](#612-safe-channels)
+  - [6.2 Mode Propagation Delays](#62-mode-propagation-delays)
+  - [6.3 Collisions And Channel Modes](#63-collisions-and-channel-modes)
+  - [6.4 Resource Exhaustion](#64-resource-exhaustion)
+- [7. Security Considerations](#7-security-considerations)
+  - [7.1 Access Control](#71-access-control)
+  - [7.2 Channel Privacy](#72-channel-privacy)
+  - [7.3 Anonymity](#73-anonymity)
+- [8. Current Support and Availability](#8-current-support-and-availability)
+- [9. Acknowledgements](#9-acknowledgements)
+- [10. References](#10-references)
+- [11. Author's Address](#11-authors-address)
+- [12. Full Copyright Statement](#12-full-copyright-statement)
+
+## 1. Introduction
+
+This document defines in detail on how channels are managed by the IRC servers and will be mostly useful to people working on implementing an IRC server.
+
+While the concepts defined here are an important part of IRC, they remain non essential for implementing clients. While the trend seems to be towards more and more complex and "intelligent" clients which are able to take advantage of knowing the internal workings of channels to provide the users with a more friendly interface, simple clients can be implemented without reading this document.
+
+Many of the concepts defined here were designed with the IRC architecture [IRC-ARCH] in mind and mostly make sense in this context. However, many others could be applied to other architectures in order to provide forums for a conferencing system.
+
+Finally, it is to be noted that IRC users may find some of the following sections of interest, in particular sections 2 (Channel Characteristics) and 4 (Channel Modes).
+
+## 2. Channel Characteristics
+
+A channel is a named group of one or more users which will all receive messages addressed to that channel. A channel is characterized by its name, properties and current members.
+
+### 2.1 Namespace
+
+Channels names are strings (beginning with a '&', '#', '+' or '!' character) of length up to fifty (50) characters. Channel names are case insensitive.
+
+Apart from the the requirement that the first character being either '&', '#', '+' or '!' (hereafter called "channel prefix"). The only restriction on a channel name is that it SHALL NOT contain any spaces (' '), a control G (^G or ASCII 7), a comma (',' which is used as a list item separator by the protocol). Also, a colon (':') is used as a delimiter for the channel mask. The exact syntax of a channel name is defined in "IRC Server Protocol" [IRC-SERVER].
+
+The use of different prefixes effectively creates four (4) distinct namespaces for channel names. This is important because of the protocol limitations regarding namespaces (in general). See section 6.1 (Labels) for more details on these limitations.
+
+### 2.2 Channel Scope
+
+A channel entity is known by one or more servers on the IRC network. A user can only become member of a channel known by the server to which the user is directly connected. The list of servers which know of the existence of a particular channel MUST be a contiguous part of the IRC network, in order for the messages addressed to the channel to be sent to all the channel members.
+
+Channels with '&' as prefix are local to the server where they are created.
+
+Other channels are known to one (1) or more servers that are connected to the network, depending on the channel mask:
+
+- If there is no channel mask, then the channel is known to all the servers.
+
+- If there is a channel mask, then the channel MUST only be known to servers which has a local user on the channel, and to its neighbours if the mask matches both the local and neighbouring server names. Since other servers have absolutely no knowledge of the existence of such a channel, the area formed by the servers having a name matching the mask has to be contiguous for the channel to be known by all these servers. Channel masks are best used in conjunction with server hostmasking [IRC-SERVER].
+
+### 2.3 Channel Properties
+
+Each channel has its own properties, which are defined by channel modes. Channel modes can be manipulated by the channel members. The modes affect the way servers manage the channels.
+
+Channels with '+' as prefix do not support channel modes. This means that all the modes are unset, with the exception of the 't' channel flag which is set.
+
+### 2.4 Privileged Channel Members
+
+In order for the channel members to keep some control over a channel, and some kind of sanity, some channel members are privileged. Only these members are allowed to perform the following actions on the channel:
+
+- **INVITE** - Invite a client to an invite-only channel (mode +i)
+- **KICK** - Eject a client from the channel
+- **MODE** - Change the channel's mode, as well as members' privileges
+- **PRIVMSG** - Sending messages to the channel (mode +n, +m, +v)
+- **TOPIC** - Change the channel topic in a mode +t channel
+
+#### 2.4.1 Channel Operators
+
+The channel operators (also referred to as a "chop" or "chanop") on a given channel are considered to 'own' that channel. Ownership of a channel is shared among channel operators.
+
+Channel operators are identified by the '@' symbol next to their nickname whenever it is associated with a channel (i.e., replies to the NAMES, WHO and WHOIS commands).
+
+Since channels starting with the character '+' as prefix do not support channel modes, no member can therefore have the status of channel operator.
+
+#### 2.4.2 Channel Creator
+
+A user who creates a channel with the character '!' as prefix is identified as the "channel creator". Upon creation of the channel, this user is also given channel operator status.
+
+In recognition of this status, the channel creators are endowed with the ability to toggle certain modes of the channel which channel operators may not manipulate.
+
+A "channel creator" can be distinguished from a channel operator by issuing the proper MODE command. See the "IRC Client Protocol" [IRC-CLIENT] for more information on this topic.
+
+## 3. Channel Lifetime
+
+In regard to the lifetime of a channel, there are typically two groups of channels: standard channels which prefix is either '&', '#' or '+', and "safe channels" which prefix is '!'.
+
+### 3.1 Standard Channels
+
+These channels are created implicitly when the first user joins it, and cease to exist when the last user leaves it. While the channel exists, any client can reference the channel using the name of the channel.
+
+The user creating a channel automatically becomes channel operator with the notable exception of channels which name is prefixed by the character '+', see section 4 (Channel modes). See section 2.4.1 (Channel Operators) for more details on this title.
+
+In order to avoid the creation of duplicate channels (typically when the IRC network becomes disjoint because of a split between two servers), channel names SHOULD NOT be allowed to be reused by a user if a channel operator (See Section 2.4.1 (Channel Operators)) has recently left the channel because of a network split. If this happens, the channel name is temporarily unavailable. The duration while a channel remains unavailable should be tuned on a per IRC network basis. It is important to note that this prevents local users from creating a channel using the same name, but does not prevent the channel to be recreated by a remote user. The latter typically happens when the IRC network rejoins. Obviously, this mechanism only makes sense for channels which name begins with the character '#', but MAY be used for channels which name begins with the character '+'. This mechanism is commonly known as "Channel Delay".
+
+### 3.2 Safe Channels
+
+Unlike other channels, "safe channels" are not implicitly created. A user wishing to create such a channel MUST request the creation by sending a special JOIN command to the server in which the channel identifier (then unknown) is replaced by the character '!'. The creation process for this type of channel is strictly controlled. The user only chooses part of the channel name (known as the channel "short name"), the server automatically prepends the user provided name with a channel identifier consisting of five (5) characters. The channel name resulting from the combination of these two elements is unique, making the channel safe from abuses based on network splits.
+
+The user who creates such a channel automatically becomes "channel creator". See section 2.4.2 (Channel Creator) for more details on this title.
+
+A server MUST NOT allow the creation of a new channel if another channel with the same short name exists; or if another channel with the same short name existed recently AND any of its member(s) left because of a network split. Such channel ceases to exist after last user leaves AND no other member recently left the channel because of a network split.
+
+Unlike the mechanism described in section 5.2.2 (Channel Delay), in this case, channel names do not become unavailable: these channels may continue to exist after the last user left. Only the user creating the channel becomes "channel creator", users joining an existing empty channel do not automatically become "channel creator" nor "channel operator".
+
+To ensure the uniqueness of the channel names, the channel identifier created by the server MUST follow specific rules. For more details on this, see section 5.2.1 (Channel Identifier).
+
+## 4. Channel Modes
+
+The various modes available for channels are as follows:
+
+- **O** - give "channel creator" status;
+- **o** - give/take channel operator privilege;
+- **v** - give/take the voice privilege;
+- **a** - toggle the anonymous channel flag;
+- **i** - toggle the invite-only channel flag;
+- **m** - toggle the moderated channel;
+- **n** - toggle the no messages to channel from clients on the outside;
+- **q** - toggle the quiet channel flag;
+- **p** - toggle the private channel flag;
+- **s** - toggle the secret channel flag;
+- **r** - toggle the server reop channel flag;
+- **t** - toggle the topic settable by channel operator only flag;
+- **k** - set/remove the channel key (password);
+- **l** - set/remove the user limit to channel;
+- **b** - set/remove ban mask to keep users out;
+- **e** - set/remove an exception mask to override a ban mask;
+- **I** - set/remove an invitation mask to automatically override the invite-only flag;
+
+Unless mentioned otherwise below, all these modes can be manipulated by "channel operators" by using the MODE command defined in "IRC Client Protocol" [IRC-CLIENT].
+
+### 4.1 Member Status
+
+The modes in this category take a channel member nickname as argument and affect the privileges given to this user.
+
+#### 4.1.1 "Channel Creator" Status
+
+The mode 'O' is only used in conjunction with "safe channels" and SHALL NOT be manipulated by users. Servers use it to give the user creating the channel the status of "channel creator".
+
+#### 4.1.2 Channel Operator Status
+
+The mode 'o' is used to toggle the operator status of a channel member.
+
+#### 4.1.3 Voice Privilege
+
+The mode 'v' is used to give and take voice privilege to/from a channel member. Users with this privilege can talk on moderated channels. (See section 4.2.3 (Moderated Channel Flag).
+
+### 4.2 Channel Flags
+
+The modes in this category are used to define properties which affects how channels operate.
+
+#### 4.2.1 Anonymous Flag
+
+The channel flag 'a' defines an anonymous channel. This means that when a message sent to the channel is sent by the server to users, and the origin is a user, then it MUST be masked. To mask the message, the origin is changed to "anonymous!anonymous@anonymous." (e.g., a user with the nickname "anonymous", the username "anonymous" and from a host called "anonymous."). Because of this, servers MUST forbid users from using the nickname "anonymous". Servers MUST also NOT send QUIT messages for users leaving such channels to the other channel members but generate a PART message instead.
+
+On channels with the character '&' as prefix, this flag MAY be toggled by channel operators, but on channels with the character '!' as prefix, this flag can be set (but SHALL NOT be unset) by the "channel creator" only. This flag MUST NOT be made available on other types of channels.
+
+Replies to the WHOIS, WHO and NAMES commands MUST NOT reveal the presence of other users on channels for which the anonymous flag is set.
+
+#### 4.2.2 Invite Only Flag
+
+When the channel flag 'i' is set, new members are only accepted if their mask matches Invite-list (See section 4.3.2) or they have been invited by a channel operator. This flag also restricts the usage of the INVITE command (See "IRC Client Protocol" [IRC-CLIENT]) to channel operators.
+
+#### 4.2.3 Moderated Channel Flag
+
+The channel flag 'm' is used to control who may speak on a channel. When it is set, only channel operators, and members who have been given the voice privilege may send messages to the channel.
+
+This flag only affects users.
+
+#### 4.2.4 No Messages To Channel From Clients On The Outside
+
+When the channel flag 'n' is set, only channel members MAY send messages to the channel.
+
+This flag only affects users.
+
+#### 4.2.5 Quiet Channel
+
+The channel flag 'q' is for use by servers only. When set, it restricts the type of data sent to users about the channel operations: other user joins, parts and nick changes are not sent. From a user's point of view, the channel contains only one user.
+
+This is typically used to create special local channels on which the server sends notices related to its operations. This was used as a more efficient and flexible way to replace the user mode 's' defined in RFC 1459 [IRC].
+
+#### 4.2.6 Private and Secret Channels
+
+The channel flag 'p' is used to mark a channel "private" and the channel flag 's' to mark a channel "secret". Both properties are similar and conceal the existence of the channel from other users.
+
+This means that there is no way of getting this channel's name from the server without being a member. In other words, these channels MUST be omitted from replies to queries like the WHOIS command.
+
+When a channel is "secret", in addition to the restriction above, the server will act as if the channel does not exist for queries like the TOPIC, LIST, NAMES commands. Note that there is one exception to this rule: servers will correctly reply to the MODE command. Finally, secret channels are not accounted for in the reply to the LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC-CLIENT]) when the <mask> parameter is specified.
+
+The channel flags 'p' and 's' MUST NOT both be set at the same time. If a MODE message originating from a server sets the flag 'p' and the flag 's' is already set for the channel, the change is silently ignored. This should only happen during a split healing phase (mentioned in the "IRC Server Protocol" document [IRC-SERVER]).
+
+#### 4.2.7 Server Reop Flag
+
+The channel flag 'r' is only available on channels which name begins with the character '!' and MAY only be toggled by the "channel creator".
+
+This flag is used to prevent a channel from having no channel operator for an extended period of time. When this flag is set, any channel that has lost all its channel operators for longer than the "reop delay" period triggers a mechanism in servers to reop some or all of the channel inhabitants. This mechanism is described more in detail in section 5.2.4 (Channel Reop Mechanism).
+
+#### 4.2.8 Topic
+
+The channel flag 't' is used to restrict the usage of the TOPIC command to channel operators.
+
+#### 4.2.9 User Limit
+
+A user limit may be set on channels by using the channel flag 'l'. When the limit is reached, servers MUST forbid their local users to join the channel.
+
+The value of the limit MUST only be made available to the channel members in the reply sent by the server to a MODE query.
+
+#### 4.2.10 Channel Key
+
+When a channel key is set (by using the mode 'k'), servers MUST reject their local users request to join the channel unless this key is given.
+
+The channel key MUST only be made visible to the channel members in the reply sent by the server to a MODE query.
+
+### 4.3 Channel Access Control
+
+The last category of modes is used to control access to the channel, they take a mask as argument.
+
+In order to reduce the size of the global database for control access modes set for channels, servers MAY put a maximum limit on the number of such modes set for a particular channel. If such restriction is imposed, it MUST only affect user requests. The limit SHOULD be homogeneous on a per IRC network basis.
+
+#### 4.3.1 Channel Ban and Exception
+
+When a user requests to join a channel, his local server checks if the user's address matches any of the ban masks set for the channel. If a match is found, the user request is denied unless the address also matches an exception mask set for the channel.
+
+Servers MUST NOT allow a channel member who is banned from the channel to speak on the channel, unless this member is a channel operator or has voice privilege. (See Section 4.1.3 (Voice Privilege)).
+
+A user who is banned from a channel and who carries an invitation sent by a channel operator is allowed to join the channel.
+
+#### 4.3.2 Channel Invitation
+
+For channels which have the invite-only flag set (See Section 4.2.2 (Invite Only Flag)), users whose address matches an invitation mask set for the channel are allowed to join the channel without any invitation.
+
+## 5. Current Implementations
+
+The only current implementation of these rules as part of the IRC protocol is the IRC server, version 2.10.
+
+The rest of this section deals with issues that are mostly of importance to those who wish to implement a server but some parts may also be of interest for client writers.
+
+### 5.1 Tracking Recently Used Channels
+
+This mechanism is commonly known as "Channel Delay" and generally only applies to channels which names is prefixed with the character '#' (See Section 3.1 "Standard channels").
+
+When a network split occurs, servers SHOULD keep track of which channels lost a "channel operator" as the result of the break. These channels are then in a special state which lasts for a certain period of time. In this particular state, the channels cannot cease to exist. If all the channel members leave the channel, the channel becomes unavailable: the server local clients cannot join the channel as long as it is empty.
+
+Once a channel is unavailable, it will become available again either because a remote user has joined the channel (most likely because the network is healing), or because the delay period has expired (in which case the channel ceases to exist and may be re-created).
+
+The duration for which a channel death is delayed SHOULD be set considering many factors among which are the size (user wise) of the IRC network, and the usual duration of network splits. It SHOULD be uniform on all servers for a given IRC network.
+
+### 5.2 Safe Channels
+
+This document introduces the notion of "safe channels". These channels have a name prefixed with the character '!' and great effort is made to avoid collisions in this name space. Collisions are not impossible, however they are very unlikely.
+
+#### 5.2.1 Channel Identifier
+
+The channel identifier is a function of the time. The current time (as defined under UNIX by the number of seconds elapsed since 00:00:00 GMT, January 1, 1970) is converted in a string of five (5) characters using the following base: "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890" (each character has a decimal value starting from 0 for 'A' to 35 for '0').
+
+The channel identifier therefore has a periodicity of 36^5 seconds (about 700 days).
+
+#### 5.2.2 Channel Delay
+
+These channels MUST be subject to the "channel delay" mechanism described in section 5.1 (Channel Delay). However, the mechanism is slightly adapted to fit better.
+
+Servers MUST keep track of all such channels which lose members as the result of a network split, no matter whether the user is a "channel operator" or not.
+
+However, these channels do NOT ever become unavailable, it is always possible to join them even when they are empty.
+
+#### 5.2.3 Abuse Window
+
+Because the periodicity is so long, attacks on a particular channel (name) may only occur once in a very long while. However, with luck and patience, it is still possible for a user to cause a channel collision. In order to avoid this, servers MUST "look in the future" and keep a list of channel names which identifier is about to be used (in the coming few days for example). Such list should remain small, not be a burden for servers to maintain and be used to avoid channel collisions by preventing the re-creation of such channel for a longer period of time than channel delay does.
+
+Eventually a server MAY choose to extend this procedure to forbid creation of channels with the same shortname only (then ignoring the channel identifier).
+
+#### 5.2.4 Preserving Sanity In The Name Space
+
+The combination of the mechanisms described in sections 5.2.2 and 5.2.3 makes it quite difficult for a user to create a channel collision. However, another type of abuse consists of creating many channels having the same shortname, but different identifiers. To prevent this from happening, servers MUST forbid the creation of a new channel which has the same shortname of a channel currently existing.
+
+#### 5.2.5 Server Reop Mechanism
+
+When a channel has been opless for longer than the "reop delay" period and has the channel flag 'r' set (See Section 4.2.7 (Server Reop Flag)), IRC servers are responsible for giving the channel operator status randomly to some of the members.
+
+The exact logic used for this mechanism by the current implementation is described below. Servers MAY use a different logic, but that it is strongly RECOMMENDED that all servers use the same logic on a particular IRC network to maintain coherence as well as fairness. For the same reason, the "reop delay" SHOULD be uniform on all servers for a given IRC network. As for the "channel delay", the value of the "reop delay" SHOULD be set considering many factors among which are the size (user wise) of the IRC network, and the usual duration of network splits.
+
+**a)** the reop mechanism is triggered after a random time following the expiration of the "reop delay". This should limit the eventuality of the mechanism being triggered at the same time (for the same channel) on two separate servers.
+
+**b)** If the channel is small (five (5) users or less), and the "channel delay" for this channel has expired, then reop all channel members if at least one member is local to the server.
+
+**c)** If the channel is small (five (5) users or less), and the "channel delay" for this channel has expired, and the "reop delay" has expired for longer than its value, then reop all channel members.
+
+**d)** For other cases, reop at most one member on the channel, based on some method build into the server. If you don't reop a member, the method should be such that another server will probably op someone. The method SHOULD be the same over the whole network. A good heuristic could be just random reop. (The current implementation actually tries to choose a member local to the server who has not been idle for too long, eventually postponing action, therefore letting other servers have a chance to find a "not too idle" member. This is over complicated due to the fact that servers only know the "idle" time of their local users)
+
+## 6. Current Problems
+
+There are a number of recognized problems with the way IRC channels are managed. Some of these can be directly attributed to the rules defined in this document, while others are the result of the underlying "IRC Server Protocol" [IRC-SERVER]. Although derived from RFC 1459 [IRC], this document introduces several novelties in an attempt to solve some of the known problems.
+
+### 6.1 Labels
+
+This document defines one of the many labels used by the IRC protocol. Although there are several distinct namespaces (based on the channel name prefix), duplicates inside each of these are not allowed. Currently, it is possible for users on different servers to pick the label which may result in collisions (with the exception of channels known to only one server where they can be averted).
+
+#### 6.1.1 Channel Delay
+
+The channel delay mechanism described in section 5.1 (Tracking Recently Used Channels) and used for channels prefixed with the character '#' is a simple attempt at preventing collisions from happening. Experience has shown that, under normal circumstances, it is very efficient; however, it obviously has severe limitations keeping it from being an adequate solution to the problem discussed here.
+
+#### 6.1.2 Safe Channels
+
+"Safe channels" described in section 3.2 (Safe Channels) are a better way to prevent collisions from happening as it prevents users from having total control over the label they choose. The obvious drawback for such labels is that they are not user friendly. However, it is fairly trivial for a client program to improve on this.
+
+### 6.2 Mode Propagation Delays
+
+Because of network delays induced by the network, and because each server on the path is REQUIRED to check the validity of mode changes (e.g., user exists and has the right privileges), it is not unusual for a MODE message to only affect part of the network, often creating a discrepancy between servers on the current state of a channel.
+
+While this may seem easy to fix (by having only the original server check the validity of mode changes), it was decided not to do so for various reasons. One concern is that servers cannot trust each other, and that a misbehaving servers can easily be detected. This way of doing so also stops wave effects on channels which are out of synch when mode changes are issued from different directions.
+
+### 6.3 Collisions And Channel Modes
+
+The "Internet Relay Chat: Server Protocol" document [IRC-SERVER] describes how channel data is exchanged when two servers connect to each other. Channel collisions (either legitimate or not) are treated as inclusive events, meaning that the resulting channel has for members all the users who are members of the channel on either server prior to the connection.
+
+Similarly, each server sends the channel modes to the other one. Therefore, each server also receives these channel modes. There are three types of modes for a given channel: flags, masks, and data. The first two types are easy to deal with as they are either set or unset. If such a mode is set on one server, it MUST be set on the other server as a result of the connection.
+
+As topics are not sent as part of this exchange, they are not a problem. However, channel modes 'l' and 'k' are exchanged, and if they are set on both servers prior to the connection, there is no mechanism to decide which of the two values takes precedence. It is left up to the users to fix the resulting discrepancy.
+
+### 6.4 Resource Exhaustion
+
+The mode based on masks defined in section 4.3 make the IRC servers (and network) vulnerable to a simple abuse of the system: a single channel operator can set as many different masks as possible on a particular channel. This can easily cause the server to waste memory, as well as network bandwidth (since the info is propagated to other servers). For this reason it is RECOMMENDED that a limit be put on the number of such masks per channels as mentioned in section 4.3.
+
+Moreover, more complex mechanisms MAY be used to avoid having redundant masks set for the same channel.
+
+## 7. Security Considerations
+
+### 7.1 Access Control
+
+One of the main ways to control access to a channel is to use masks which are based on the username and hostname of the user connections. This mechanism can only be efficient and safe if the IRC servers have an accurate way of authenticating user connections, and if users cannot easily get around it. While it is in theory possible to implement such a strict authentication mechanism, most IRC networks (especially public networks) do not have anything like this in place and provide little guaranty about the accuracy of the username and hostname for a particular client connection.
+
+Another way to control access is to use a channel key, but since this key is sent in plaintext, it is vulnerable to traditional man in the middle attacks.
+
+### 7.2 Channel Privacy
+
+Because channel collisions are treated as inclusive events (See Section 6.3), it is possible for users to join a channel overriding its access control settings. This method has long been used by individuals to "take over" channels by "illegitimately" gaining channel operator status on the channel. The same method can be used to find out the exact list of members of a channel, as well as to eventually receive some of the messages sent to the channel.
+
+### 7.3 Anonymity
+
+The anonymous channel flag (See Section 4.2.1) can be used to render all users on such channel "anonymous" by presenting all messages to the channel as originating from a pseudo user which nickname is "anonymous". This is done at the client-server level, and no anonymity is provided at the server-server level.
+
+It should be obvious to readers, that the level of anonymity offered is quite poor and insecure, and that clients SHOULD display strong warnings for users joining such channels.
+
+## 8. Current Support and Availability
+
+**Mailing lists for IRC related discussion:**
+- General discussion: ircd-users@irc.org
+- Protocol development: ircd-dev@irc.org
+
+**Software implementations:**
+- ftp://ftp.irc.org/irc/server
+- ftp://ftp.funet.fi/pub/unix/irc
+- ftp://coombs.anu.edu.au/pub/irc
+
+**Newsgroup:** alt.irc
+
+## 9. Acknowledgements
+
+Parts of this document were copied from the RFC 1459 [IRC] which first formally documented the IRC Protocol. It has also benefited from many rounds of review and comments. In particular, the following people have made significant contributions to this document:
+
+Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
+
+## 10. References
+
+**[KEYWORDS]** Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+**[IRC]** Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
+
+**[IRC-ARCH]** Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
+
+**[IRC-CLIENT]** Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
+
+**[IRC-SERVER]** Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
+
+## 11. Author's Address
+
+Christophe Kalt  
+99 Teaneck Rd, Apt #117  
+Ridgefield Park, NJ 07660  
+USA
+
+EMail: kalt@stealth.net
+
+## 12. Full Copyright Statement
+
+Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+### Acknowledgement
+
+Funding for the RFC Editor function is currently provided by the Internet Society.
diff --git a/wiki/RFC2812.md b/wiki/RFC2812.md
new file mode 100644
index 0000000..8e69a2a
--- /dev/null
+++ b/wiki/RFC2812.md
@@ -0,0 +1,2432 @@
+# RFC 2812 - Internet Relay Chat: Client Protocol
+
+**Network Working Group:** C. Kalt  
+**Request for Comments:** 2812  
+**Updates:** 1459  
+**Category:** Informational  
+**Date:** April 2000
+
+## Status of this Memo
+
+This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
+
+## Copyright Notice
+
+Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+## IESG NOTE
+
+The IRC protocol itself enables several possibilities of transferring data between clients, and just like with other transfer mechanisms like email, the receiver of the data has to be careful about how the data is handled. For more information on security issues with the IRC protocol, see for example http://www.irchelp.org/irchelp/security/.
+
+## Abstract
+
+The IRC (Internet Relay Chat) protocol is for use with text based conferencing; the simplest client being any socket program capable of connecting to the server.
+
+This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture [IRC-ARCH].
+
+## Table of Contents
+
+- [1. Labels](#1-labels)
+  - [1.1 Servers](#11-servers)
+  - [1.2 Clients](#12-clients)
+    - [1.2.1 Users](#121-users)
+      - [1.2.1.1 Operators](#1211-operators)
+    - [1.2.2 Services](#122-services)
+  - [1.3 Channels](#13-channels)
+- [2. The IRC Client Specification](#2-the-irc-client-specification)
+  - [2.1 Overview](#21-overview)
+  - [2.2 Character codes](#22-character-codes)
+  - [2.3 Messages](#23-messages)
+    - [2.3.1 Message format in Augmented BNF](#231-message-format-in-augmented-bnf)
+  - [2.4 Numeric replies](#24-numeric-replies)
+  - [2.5 Wildcard expressions](#25-wildcard-expressions)
+- [3. Message Details](#3-message-details)
+  - [3.1 Connection Registration](#31-connection-registration)
+    - [3.1.1 Password message](#311-password-message)
+    - [3.1.2 Nick message](#312-nick-message)
+    - [3.1.3 User message](#313-user-message)
+    - [3.1.4 Oper message](#314-oper-message)
+    - [3.1.5 User mode message](#315-user-mode-message)
+    - [3.1.6 Service message](#316-service-message)
+    - [3.1.7 Quit](#317-quit)
+    - [3.1.8 Squit](#318-squit)
+  - [3.2 Channel operations](#32-channel-operations)
+    - [3.2.1 Join message](#321-join-message)
+    - [3.2.2 Part message](#322-part-message)
+    - [3.2.3 Channel mode message](#323-channel-mode-message)
+    - [3.2.4 Topic message](#324-topic-message)
+    - [3.2.5 Names message](#325-names-message)
+    - [3.2.6 List message](#326-list-message)
+    - [3.2.7 Invite message](#327-invite-message)
+    - [3.2.8 Kick command](#328-kick-command)
+  - [3.3 Sending messages](#33-sending-messages)
+    - [3.3.1 Private messages](#331-private-messages)
+    - [3.3.2 Notice](#332-notice)
+  - [3.4 Server queries and commands](#34-server-queries-and-commands)
+    - [3.4.1 Motd message](#341-motd-message)
+    - [3.4.2 Lusers message](#342-lusers-message)
+    - [3.4.3 Version message](#343-version-message)
+    - [3.4.4 Stats message](#344-stats-message)
+    - [3.4.5 Links message](#345-links-message)
+    - [3.4.6 Time message](#346-time-message)
+    - [3.4.7 Connect message](#347-connect-message)
+    - [3.4.8 Trace message](#348-trace-message)
+    - [3.4.9 Admin command](#349-admin-command)
+    - [3.4.10 Info command](#3410-info-command)
+  - [3.5 Service Query and Commands](#35-service-query-and-commands)
+    - [3.5.1 Servlist message](#351-servlist-message)
+    - [3.5.2 Squery](#352-squery)
+  - [3.6 User based queries](#36-user-based-queries)
+    - [3.6.1 Who query](#361-who-query)
+    - [3.6.2 Whois query](#362-whois-query)
+    - [3.6.3 Whowas](#363-whowas)
+  - [3.7 Miscellaneous messages](#37-miscellaneous-messages)
+    - [3.7.1 Kill message](#371-kill-message)
+    - [3.7.2 Ping message](#372-ping-message)
+    - [3.7.3 Pong message](#373-pong-message)
+    - [3.7.4 Error](#374-error)
+- [4. Optional features](#4-optional-features)
+  - [4.1 Away](#41-away)
+  - [4.2 Rehash message](#42-rehash-message)
+  - [4.3 Die message](#43-die-message)
+  - [4.4 Restart message](#44-restart-message)
+  - [4.5 Summon message](#45-summon-message)
+  - [4.6 Users](#46-users)
+  - [4.7 Operwall message](#47-operwall-message)
+  - [4.8 Userhost message](#48-userhost-message)
+  - [4.9 Ison message](#49-ison-message)
+- [5. Replies](#5-replies)
+  - [5.1 Command responses](#51-command-responses)
+  - [5.2 Error Replies](#52-error-replies)
+  - [5.3 Reserved numerics](#53-reserved-numerics)
+- [6. Current implementations](#6-current-implementations)
+- [7. Current problems](#7-current-problems)
+  - [7.1 Nicknames](#71-nicknames)
+  - [7.2 Limitation of wildcards](#72-limitation-of-wildcards)
+  - [7.3 Security considerations](#73-security-considerations)
+- [8. Current support and availability](#8-current-support-and-availability)
+- [9. Acknowledgements](#9-acknowledgements)
+- [10. References](#10-references)
+- [11. Author's Address](#11-authors-address)
+- [12. Full Copyright Statement](#12-full-copyright-statement)
+
+
+## 1. Labels
+
+This section defines the identifiers used for the various components of the IRC protocol.
+
+### 1.1 Servers
+
+Servers are uniquely identified by their name, which has a maximum length of sixty three (63) characters. See the protocol grammar rules (section 2.3.1) for what may and may not be used in a server name.
+
+### 1.2 Clients
+
+For each client all servers MUST have the following information: a netwide unique identifier (whose format depends on the type of client) and the server which introduced the client.
+
+#### 1.2.1 Users
+
+Each user is distinguished from other users by a unique nickname having a maximum length of nine (9) characters. See the protocol grammar rules (section 2.3.1) for what may and may not be used in a nickname.
+
+While the maximum length is limited to nine characters, clients SHOULD accept longer strings as they may become used in future evolutions of the protocol.
+
+##### 1.2.1.1 Operators
+
+To allow a reasonable amount of order to be kept within the IRC network, a special class of users (operators) is allowed to perform general maintenance functions on the network. Although the powers granted to an operator can be considered as 'dangerous', they are nonetheless often necessary. Operators SHOULD be able to perform basic network tasks such as disconnecting and reconnecting servers as needed. In recognition of this need, the protocol discussed herein provides for operators only to be able to perform such functions. See sections 3.1.8 (SQUIT) and 3.4.7 (CONNECT).
+
+A more controversial power of operators is the ability to remove a user from the connected network by 'force', i.e., operators are able to close the connection between any client and server. The justification for this is very delicate since its abuse is both destructive and annoying, and its benefits close to inexistent. For further details on this type of action, see section 3.7.1 (KILL).
+
+#### 1.2.2 Services
+
+Each service is distinguished from other services by a service name composed of a nickname and a server name. As for users, the nickname has a maximum length of nine (9) characters. See the protocol grammar rules (section 2.3.1) for what may and may not be used in a nickname.
+
+### 1.3 Channels
+
+Channels names are strings (beginning with a '&', '#', '+' or '!' character) of length up to fifty (50) characters. Apart from the requirement that the first character is either '&', '#', '+' or '!', the only restriction on a channel name is that it SHALL NOT contain any spaces (' '), a control G (^G or ASCII 7), a comma (','). Space is used as parameter separator and command is used as a list item separator by the protocol). A colon (':') can also be used as a delimiter for the channel mask. Channel names are case insensitive.
+
+See the protocol grammar rules (section 2.3.1) for the exact syntax of a channel name.
+
+Each prefix characterizes a different channel type. The definition of the channel types is not relevant to the client-server protocol and thus it is beyond the scope of this document. More details can be found in "Internet Relay Chat: Channel Management" [IRC-CHAN].
+
+## 2. The IRC Client Specification
+
+### 2.1 Overview
+
+The protocol as described herein is for use only with client to server connections when the client registers as a user.
+
+### 2.2 Character codes
+
+No specific character set is specified. The protocol is based on a set of codes which are composed of eight (8) bits, making up an octet. Each message may be composed of any number of these octets; however, some octet values are used for control codes, which act as message delimiters.
+
+Regardless of being an 8-bit protocol, the delimiters and keywords are such that protocol is mostly usable from US-ASCII terminal and a telnet connection.
+
+Because of IRC's Scandinavian origin, the characters `{}|^` are considered to be the lower case equivalents of the characters `[]\~`, respectively. This is a critical issue when determining the equivalence of two nicknames or channel names.
+
+### 2.3 Messages
+
+Servers and clients send each other messages, which may or may not generate a reply. If the message contains a valid command, as described in later sections, the client should expect a reply as specified but it is not advised to wait forever for the reply; client to server and server to server communication is essentially asynchronous by nature.
+
+Each IRC message may consist of up to three main parts: the prefix (OPTIONAL), the command, and the command parameters (maximum of fifteen (15)). The prefix, command, and all parameters are separated by one ASCII space character (0x20) each.
+
+The presence of a prefix is indicated with a single leading ASCII colon character (':', 0x3b), which MUST be the first character of the message itself. There MUST be NO gap (whitespace) between the colon and the prefix. The prefix is used by servers to indicate the true origin of the message. If the prefix is missing from the message, it is assumed to have originated from the connection from which it was received from. Clients SHOULD NOT use a prefix when sending a message; if they use one, the only valid prefix is the registered nickname associated with the client.
+
+The command MUST either be a valid IRC command or a three (3) digit number represented in ASCII text.
+
+IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and these messages SHALL NOT exceed 512 characters in length, counting all characters including the trailing CR-LF. Thus, there are 510 characters maximum allowed for the command and its parameters. There is no provision for continuation of message lines. See section 6 for more details about current implementations.
+
+#### 2.3.1 Message format in Augmented BNF
+
+The protocol messages must be extracted from the contiguous stream of octets. The current solution is to designate two characters, CR and LF, as message separators. Empty messages are silently ignored, which permits use of the sequence CR-LF between messages without extra problems.
+
+The extracted message is parsed into the components <prefix>, <command> and list of parameters (<params>).
+
+The Augmented BNF representation for this is:
+
+```
+message    =  [ ":" prefix SPACE ] command [ params ] crlf
+prefix     =  servername / ( nickname [ [ "!" user ] "@" host ] )
+command    =  1*letter / 3digit
+params     =  *14( SPACE middle ) [ SPACE ":" trailing ]
+           =/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]
+
+nospcrlfcl =  %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF
+                ; any octet except NUL, CR, LF, " " and ":"
+middle     =  nospcrlfcl *( ":" / nospcrlfcl )
+trailing   =  *( ":" / " " / nospcrlfcl )
+
+SPACE      =  %x20        ; space character
+crlf       =  %x0D %x0A   ; "carriage return" "linefeed"
+```
+
+**NOTES:**
+
+1. After extracting the parameter list, all parameters are equal whether matched by <middle> or <trailing>. <trailing> is just a syntactic trick to allow SPACE within the parameter.
+
+2. The NUL (%x00) character is not special in message framing, and basically could end up inside a parameter, but it would cause extra complexities in normal C string handling. Therefore, NUL is not allowed within messages.
+
+Most protocol messages specify additional semantics and syntax for the extracted parameter strings dictated by their position in the list. For example, many server commands will assume that the first parameter after the command is the list of targets, which can be described with:
+
+```
+target     =  nickname / server
+msgtarget  =  msgto *( "," msgto )
+msgto      =  channel / ( user [ "%" host ] "@" servername )
+msgto      =/ ( user "%" host ) / targetmask
+msgto      =/ nickname / ( nickname "!" user "@" host )
+channel    =  ( "#" / "+" / ( "!" channelid ) / "&" ) chanstring
+              [ ":" chanstring ]
+servername =  hostname
+host       =  hostname / hostaddr
+hostname   =  shortname *( "." shortname )
+shortname  =  ( letter / digit ) *( letter / digit / "-" )
+              *( letter / digit )
+                ; as specified in RFC 1123 [HNAME]
+hostaddr   =  ip4addr / ip6addr
+ip4addr    =  1*3digit "." 1*3digit "." 1*3digit "." 1*3digit
+ip6addr    =  1*hexdigit 7( ":" 1*hexdigit )
+ip6addr    =/ "0:0:0:0:0:" ( "0" / "FFFF" ) ":" ip4addr
+nickname   =  ( letter / special ) *8( letter / digit / special / "-" )
+targetmask =  ( "$" / "#" ) mask
+                ; see details on allowed masks in section 3.3.1
+chanstring =  %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B
+chanstring =/ %x2D-39 / %x3B-FF
+                ; any octet except NUL, BELL, CR, LF, " ", "," and ":"
+channelid  = 5( %x41-5A / digit )   ; 5( A-Z / 0-9 )
+```
+
+Other parameter syntaxes are:
+
+```
+user       =  1*( %x01-09 / %x0B-0C / %x0E-1F / %x21-3F / %x41-FF )
+                ; any octet except NUL, CR, LF, " " and "@"
+key        =  1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F )
+                ; any 7-bit US_ASCII character,
+                ; except NUL, CR, LF, FF, h/v TABs, and " "
+letter     =  %x41-5A / %x61-7A       ; A-Z / a-z
+digit      =  %x30-39                 ; 0-9
+hexdigit   =  digit / "A" / "B" / "C" / "D" / "E" / "F"
+special    =  %x5B-60 / %x7B-7D
+                 ; "[", "]", "\", "`", "_", "^", "{", "|", "}"
+```
+
+**NOTES:**
+
+1. The <hostaddr> syntax is given here for the sole purpose of indicating the format to follow for IP addresses. This reflects the fact that the only available implementations of this protocol uses TCP/IP as underlying network protocol but is not meant to prevent other protocols to be used.
+
+2. <hostname> has a maximum length of 63 characters. This is a limitation of the protocol as internet hostnames (in particular) can be longer. Such restriction is necessary because IRC messages are limited to 512 characters in length. Clients connecting from a host which name is longer than 63 characters are registered using the host (numeric) address instead of the host name.
+
+3. Some parameters used in the following sections of this documents are not defined here as there is nothing specific about them besides the name that is used for convenience. These parameters follow the general syntax defined for <params>.
+
+### 2.4 Numeric replies
+
+Most of the messages sent to the server generate a reply of some sort. The most common reply is the numeric reply, used for both errors and normal replies. The numeric reply MUST be sent as one message consisting of the sender prefix, the three-digit numeric, and the target of the reply. A numeric reply is not allowed to originate from a client. In all other respects, a numeric reply is just like a normal message, except that the keyword is made up of 3 numeric digits rather than a string of letters. A list of different replies is supplied in section 5 (Replies).
+
+### 2.5 Wildcard expressions
+
+When wildcards are allowed in a string, it is referred as a "mask".
+
+For string matching purposes, the protocol allows the use of two special characters: '?' (%x3F) to match one and only one character, and '*' (%x2A) to match any number of any characters. These two characters can be escaped using the character '\' (%x5C).
+
+The Augmented BNF syntax for this is:
+
+```
+mask       =  *( nowild / noesc wildone / noesc wildmany )
+wildone    =  %x3F
+wildmany   =  %x2A
+nowild     =  %x01-29 / %x2B-3E / %x40-FF
+                ; any octet except NUL, "*", "?"
+noesc      =  %x01-5B / %x5D-FF
+                ; any octet except NUL and "\"
+matchone   =  %x01-FF
+                ; matches wildone
+matchmany  =  *matchone
+                ; matches wildmany
+```
+
+Examples:
+
+- `a?c` - Matches any string of 3 characters in length starting with "a" and ending with "c"
+- `a*c` - Matches any string of at least 2 characters in length starting with "a" and ending with "c"
+
+
+## 3. Message Details
+
+On the following pages there are descriptions of each message recognized by the IRC server and client. All commands described in this section MUST be implemented by any server for this protocol.
+
+Where the reply ERR_NOSUCHSERVER is returned, it means that the target of the message could not be found. The server MUST NOT send any other replies after this error for that command.
+
+The server to which a client is connected is required to parse the complete message, and return any appropriate errors.
+
+If multiple parameters is presented, then each MUST be checked for validity and appropriate responses MUST be sent back to the client. In the case of incorrect messages which use parameter lists with comma as an item separator, a reply MUST be sent for each item.
+
+### 3.1 Connection Registration
+
+The commands described here are used to register a connection with an IRC server as a user as well as to correctly disconnect.
+
+A "PASS" command is not required for a client connection to be registered, but it MUST precede the latter of the NICK/USER combination (for a user connection) or the SERVICE command (for a service connection). The RECOMMENDED order for a client to register is as follows:
+
+1. Pass message
+2. Nick message / Service message
+3. User message
+
+Upon success, the client will receive an RPL_WELCOME (for users) or RPL_YOURESERVICE (for services) message indicating that the connection is now registered and known the to the entire IRC network. The reply message MUST contain the full client identifier upon which it was registered.
+
+#### 3.1.1 Password message
+
+**Command:** PASS  
+**Parameters:** <password>
+
+The PASS command is used to set a 'connection password'. The optional password can and MUST be set before any attempt to register the connection is made. Currently this requires that user send a PASS command before sending the NICK/USER combination.
+
+**Numeric Replies:**
+- ERR_NEEDMOREPARAMS
+- ERR_ALREADYREGISTRED
+
+**Example:**
+
+```
+PASS secretpasswordhere
+```
+
+#### 3.1.2 Nick message
+
+**Command:** NICK  
+**Parameters:** <nickname>
+
+NICK command is used to give user a nickname or change the existing one.
+
+**Numeric Replies:**
+- ERR_NONICKNAMEGIVEN
+- ERR_ERRONEUSNICKNAME
+- ERR_NICKNAMEINUSE
+- ERR_NICKCOLLISION
+- ERR_UNAVAILRESOURCE
+- ERR_RESTRICTED
+
+**Examples:**
+
+```
+NICK Wiz                ; Introducing new nick "Wiz" if session is
+                        still unregistered, or user changing his
+                        nickname to "Wiz"
+
+:WiZ!jto@tolsun.oulu.fi NICK Kilroy
+                        ; Server telling that WiZ changed his
+                        nickname to Kilroy.
+```
+
+#### 3.1.3 User message
+
+**Command:** USER  
+**Parameters:** <user> <mode> <unused> <realname>
+
+The USER command is used at the beginning of connection to specify the username, hostname and realname of a new user.
+
+The <mode> parameter should be a numeric, and can be used to automatically set user modes when registering with the server. This parameter is a bitmask, with only 2 bits having any signification: if the bit 2 is set, the user mode 'w' will be set and if the bit 3 is set, the user mode 'i' will be set. (See Section 3.1.5 "User Modes").
+
+The <realname> may contain space characters.
+
+**Numeric Replies:**
+- ERR_NEEDMOREPARAMS
+- ERR_ALREADYREGISTRED
+
+**Example:**
+
+```
+USER guest 0 * :Ronnie Reagan   ; User registering themselves with a
+                                username of "guest" and real name
+                                "Ronnie Reagan".
+
+USER guest 8 * :Ronnie Reagan   ; User registering themselves with a
+                                username of "guest" and real name
+                                "Ronnie Reagan", and asking to be set
+                                invisible.
+```
+
+#### 3.1.4 Oper message
+
+**Command:** OPER  
+**Parameters:** <name> <password>
+
+A normal user uses the OPER command to obtain operator privileges. The combination of <name> and <password> are REQUIRED to gain Operator privileges. Upon success, the user will receive a MODE message (see section 3.1.5) indicating the new user modes.
+
+**Numeric Replies:**
+- ERR_NEEDMOREPARAMS
+- RPL_YOUREOPER
+- ERR_NOOPERHOST
+- ERR_PASSWDMISMATCH
+
+**Example:**
+
+```
+OPER foo bar                    ; Attempt to register as an operator
+                                using a username of "foo" and "bar"
+                                as the password.
+```
+
+#### 3.1.5 User mode message
+
+**Command:** MODE  
+**Parameters:** <nickname> *( ( "+" / "-" ) *( "i" / "w" / "o" / "O" / "r" ) )
+
+The user MODE's are typically changes which affect either how the client is seen by others or what 'extra' messages the client is sent.
+
+A user MODE command MUST only be accepted if both the sender of the message and the nickname given as a parameter are both the same. If no other parameter is given, then the server will return the current settings for the nick.
+
+The available modes are as follows:
+
+- **a** - user is flagged as away;
+- **i** - marks a users as invisible;
+- **w** - user receives wallops;
+- **r** - restricted user connection;
+- **o** - operator flag;
+- **O** - local operator flag;
+- **s** - marks a user for receipt of server notices.
+
+Additional modes may be available later on.
+
+The flag 'a' SHALL NOT be toggled by the user using the MODE command, instead use of the AWAY command is REQUIRED.
+
+If a user attempts to make themselves an operator using the "+o" or "+O" flag, the attempt SHOULD be ignored as users could bypass the authentication mechanisms of the OPER command. There is no restriction, however, on anyone `deopping' themselves (using "-o" or "-O").
+
+On the other hand, if a user attempts to make themselves unrestricted using the "-r" flag, the attempt SHOULD be ignored. There is no restriction, however, on anyone `deopping' themselves (using "+r"). This flag is typically set by the server upon connection for administrative reasons. While the restrictions imposed are left up to the implementation, it is typical that a restricted user not be allowed to change nicknames, nor make use of the channel operator status on channels.
+
+The flag 's' is obsolete but MAY still be used.
+
+**Numeric Replies:**
+- ERR_NEEDMOREPARAMS
+- ERR_USERSDONTMATCH
+- ERR_UMODEUNKNOWNFLAG
+- RPL_UMODEIS
+
+**Examples:**
+
+```
+MODE WiZ -w                     ; Command by WiZ to turn off
+                                reception of WALLOPS messages.
+
+MODE Angel +i                   ; Command from Angel to make herself
+                                invisible.
+
+MODE WiZ -o                     ; WiZ 'deopping' (removing operator
+                                status).
+```
+
+#### 3.1.6 Service message
+
+**Command:** SERVICE  
+**Parameters:** <nickname> <reserved> <distribution> <type> <reserved> <info>
+
+The SERVICE command to register a new service. Command parameters specify the service nickname, distribution, type and info of a new service.
+
+The <distribution> parameter is used to specify the visibility of a service. The service may only be known to servers which have a name matching the distribution. For a matching server to have knowledge of the service, the network path between that server and the server on which the service is connected MUST be composed of servers which names all match the mask.
+
+The <type> parameter is currently reserved for future usage.
+
+**Numeric Replies:**
+- ERR_ALREADYREGISTRED
+- ERR_NEEDMOREPARAMS
+- ERR_ERRONEUSNICKNAME
+- RPL_YOURESERVICE
+- RPL_YOURHOST
+- RPL_MYINFO
+
+**Example:**
+
+```
+SERVICE dict * *.fr 0 0 :French Dictionary ; Service registering
+                                itself with a name of "dict".  This
+                                service will only be available on
+                                servers which name matches "*.fr".
+```
+
+#### 3.1.7 Quit
+
+**Command:** QUIT  
+**Parameters:** [ <Quit Message> ]
+
+A client session is terminated with a quit message. The server acknowledges this by sending an ERROR message to the client.
+
+**Numeric Replies:** None.
+
+**Example:**
+
+```
+QUIT :Gone to have lunch        ; Preferred message format.
+
+:syrk!kalt@millennium.stealth.net QUIT :Gone to have lunch ; User
+                                syrk has quit IRC to have lunch.
+```
+
+#### 3.1.8 Squit
+
+**Command:** SQUIT  
+**Parameters:** <server> <comment>
+
+The SQUIT command is available only to operators. It is used to disconnect server links. Also servers can generate SQUIT messages on error conditions. A SQUIT message may also target a remote server connection. In this case, the SQUIT message will simply be sent to the remote server without affecting the servers in between the operator and the remote server.
+
+The <comment> SHOULD be supplied by all operators who execute a SQUIT for a remote server. The server ordered to disconnect its peer generates a WALLOPS message with <comment> included, so that other users may be aware of the reason of this action.
+
+**Numeric replies:**
+- ERR_NOPRIVILEGES
+- ERR_NOSUCHSERVER
+- ERR_NEEDMOREPARAMS
+
+**Examples:**
+
+```
+SQUIT tolsun.oulu.fi :Bad Link ?  ; Command to uplink of the server
+                                tolson.oulu.fi to terminate its
+                                connection with comment "Bad Link".
+
+:Trillian SQUIT cm22.eng.umd.edu :Server out of control ; Command
+                                from Trillian from to disconnect
+                                "cm22.eng.umd.edu" from the net with
+                                comment "Server out of control".
+```
+
+
+### 3.2 Channel operations
+
+This group of messages is concerned with manipulating channels, their properties (channel modes), and their contents (typically users). For this reason, these messages SHALL NOT be made available to services.
+
+All of these messages are requests which will or will not be granted by the server. The server MUST send a reply informing the user whether the request was granted, denied or generated an error. When the server grants the request, the message is typically sent back (eventually reformatted) to the user with the prefix set to the user itself.
+
+The rules governing how channels are managed are enforced by the servers. These rules are beyond the scope of this document. More details are found in "Internet Relay Chat: Channel Management" [IRC-CHAN].
+
+#### 3.2.1 Join message
+
+**Command:** JOIN  
+**Parameters:** ( <channel> *( "," <channel> ) [ <key> *( "," <key> ) ] ) / "0"
+
+The JOIN command is used by a user to request to start listening to the specific channel. Servers MUST be able to parse arguments in the form of a list of target, but SHOULD NOT use lists when sending JOIN messages to clients.
+
+Once a user has joined a channel, he receives information about all commands his server receives affecting the channel. This includes JOIN, MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. This allows channel members to keep track of the other channel members, as well as channel modes.
+
+If a JOIN is successful, the user receives a JOIN message as confirmation and is then sent the channel's topic (using RPL_TOPIC) and the list of users who are on the channel (using RPL_NAMREPLY), which MUST include the user joining.
+
+Note that this message accepts a special argument ("0"), which is a special request to leave all channels the user is currently a member of. The server will process this message as if the user had sent a PART command (See Section 3.2.2) for each channel he is a member of.
+
+**Numeric Replies:**
+- ERR_NEEDMOREPARAMS
+- ERR_BANNEDFROMCHAN
+- ERR_INVITEONLYCHAN
+- ERR_BADCHANNELKEY
+- ERR_CHANNELISFULL
+- ERR_BADCHANMASK
+- ERR_NOSUCHCHANNEL
+- ERR_TOOMANYCHANNELS
+- ERR_TOOMANYTARGETS
+- ERR_UNAVAILRESOURCE
+- RPL_TOPIC
+
+**Examples:**
+
+```
+JOIN #foobar                    ; Command to join channel #foobar.
+
+JOIN &foo fubar                 ; Command to join channel &foo using
+                                key "fubar".
+
+JOIN #foo,&bar fubar            ; Command to join channel #foo using
+                                key "fubar" and &bar using no key.
+
+JOIN #foo,#bar fubar,foobar     ; Command to join channel #foo using
+                                key "fubar", and channel #bar using
+                                key "foobar".
+
+JOIN #foo,#bar                  ; Command to join channels #foo and
+                                #bar.
+
+JOIN 0                          ; Leave all currently joined
+                                channels.
+
+:WiZ!jto@tolsun.oulu.fi JOIN #Twilight_zone ; JOIN message from WiZ
+                                on channel #Twilight_zone
+```
+
+#### 3.2.2 Part message
+
+**Command:** PART  
+**Parameters:** <channel> *( "," <channel> ) [ <Part Message> ]
+
+The PART command causes the user sending the message to be removed from the list of active members for all given channels listed in the parameter string. If a "Part Message" is given, this will be sent instead of the default message, the nickname. This request is always granted by the server.
+
+Servers MUST be able to parse arguments in the form of a list of target, but SHOULD NOT use lists when sending PART messages to clients.
+
+**Numeric Replies:**
+- ERR_NEEDMOREPARAMS
+- ERR_NOSUCHCHANNEL
+- ERR_NOTONCHANNEL
+
+**Examples:**
+
+```
+PART #twilight_zone             ; Command to leave channel
+                                "#twilight_zone"
+
+PART #oz-ops,&group5            ; Command to leave both channels
+                                "&group5" and "#oz-ops".
+
+:WiZ!jto@tolsun.oulu.fi PART #playzone :I lost
+                                ; User WiZ leaving channel
+                                "#playzone" with the message "I
+                                lost".
+```
+
+#### 3.2.3 Channel mode message
+
+**Command:** MODE  
+**Parameters:** <channel> *( ( "-" / "+" ) *<modes> *<modeparams> )
+
+The MODE command is provided so that users may query and change the characteristics of a channel. For more details on available modes and their uses, see "Internet Relay Chat: Channel Management" [IRC-CHAN]. Note that there is a maximum limit of three (3) changes per command for modes that take a parameter.
+
+**Numeric Replies:**
+- ERR_NEEDMOREPARAMS
+- ERR_KEYSET
+- ERR_NOCHANMODES
+- ERR_CHANOPRIVSNEEDED
+- ERR_USERNOTINCHANNEL
+- ERR_UNKNOWNMODE
+- RPL_CHANNELMODEIS
+- RPL_BANLIST
+- RPL_ENDOFBANLIST
+- RPL_EXCEPTLIST
+- RPL_ENDOFEXCEPTLIST
+- RPL_INVITELIST
+- RPL_ENDOFINVITELIST
+- RPL_UNIQOPIS
+
+The following examples are given to help understanding the syntax of the MODE command, but refer to modes defined in "Internet Relay Chat: Channel Management" [IRC-CHAN].
+
+**Examples:**
+
+```
+MODE #Finnish +imI *!*@*.fi     ; Command to make #Finnish channel
+                                moderated and 'invite-only' with user
+                                with a hostname matching *.fi
+                                automatically invited.
+
+MODE #Finnish +o Kilroy         ; Command to give 'chanop' privileges
+                                to Kilroy on channel #Finnish.
+
+MODE #Finnish +v Wiz            ; Command to allow WiZ to speak on
+                                #Finnish.
+
+MODE #Fins -s                   ; Command to remove 'secret' flag
+                                from channel #Fins.
+
+MODE #42 +k oulu                ; Command to set the channel key to
+                                "oulu".
+
+MODE #42 -k oulu                ; Command to remove the "oulu"
+                                channel key on channel "#42".
+
+MODE #eu-opers +l 10            ; Command to set the limit for the
+                                number of users on channel
+                                "#eu-opers" to 10.
+
+:WiZ!jto@tolsun.oulu.fi MODE #eu-opers -l
+                                ; User "WiZ" removing the limit for
+                                the number of users on channel "#eu-
+                                opers".
+
+MODE &oulu +b                   ; Command to list ban masks set for
+                                the channel "&oulu".
+
+MODE &oulu +b *!*@*             ; Command to prevent all users from
+                                joining.
+
+MODE &oulu +b *!*@*.edu +e *!*@*.bu.edu
+                                ; Command to prevent any user from a
+                                hostname matching *.edu from joining,
+                                except if matching *.bu.edu
+
+MODE #bu +be *!*@*.edu *!*@*.bu.edu
+                                ; Comment to prevent any user from a
+                                hostname matching *.edu from joining,
+                                except if matching *.bu.edu
+
+MODE #meditation e              ; Command to list exception masks set
+                                for the channel "#meditation".
+
+MODE #meditation I              ; Command to list invitations masks
+                                set for the channel "#meditation".
+
+MODE !12345ircd O               ; Command to ask who the channel
+                                creator for "!12345ircd" is
+```
+
+#### 3.2.4 Topic message
+
+**Command:** TOPIC  
+**Parameters:** <channel> [ <topic> ]
+
+The TOPIC command is used to change or view the topic of a channel. The topic for channel <channel> is returned if there is no <topic> given. If the <topic> parameter is present, the topic for that channel will be changed, if this action is allowed for the user requesting it. If the <topic> parameter is an empty string, the topic for that channel will be removed.
+
+**Numeric Replies:**
+- ERR_NEEDMOREPARAMS
+- ERR_NOTONCHANNEL
+- RPL_NOTOPIC
+- RPL_TOPIC
+- ERR_CHANOPRIVSNEEDED
+- ERR_NOCHANMODES
+
+**Examples:**
+
+```
+:WiZ!jto@tolsun.oulu.fi TOPIC #test :New topic ; User Wiz setting the
+                                topic.
+
+TOPIC #test :another topic      ; Command to set the topic on #test
+                                to "another topic".
+
+TOPIC #test :                   ; Command to clear the topic on
+                                #test.
+
+TOPIC #test                     ; Command to check the topic for
+                                #test.
+```
+
+#### 3.2.5 Names message
+
+**Command:** NAMES  
+**Parameters:** [ <channel> *( "," <channel> ) [ <target> ] ]
+
+By using the NAMES command, a user can list all nicknames that are visible to him. For more details on what is visible and what is not, see "Internet Relay Chat: Channel Management" [IRC-CHAN]. The <channel> parameter specifies which channel(s) to return information about. There is no error reply for bad channel names.
+
+If no <channel> parameter is given, a list of all channels and their occupants is returned. At the end of this list, a list of users who are visible but either not on any channel or not on a visible channel are listed as being on `channel' "*".
+
+If the <target> parameter is specified, the request is forwarded to that server which will generate the reply.
+
+Wildcards are allowed in the <target> parameter.
+
+**Numerics:**
+- ERR_TOOMANYMATCHES
+- ERR_NOSUCHSERVER
+- RPL_NAMREPLY
+- RPL_ENDOFNAMES
+
+**Examples:**
+
+```
+NAMES #twilight_zone,#42        ; Command to list visible users on
+                                #twilight_zone and #42
+
+NAMES                           ; Command to list all visible
+                                channels and users
+```
+
+#### 3.2.6 List message
+
+**Command:** LIST  
+**Parameters:** [ <channel> *( "," <channel> ) [ <target> ] ]
+
+The list command is used to list channels and their topics. If the <channel> parameter is used, only the status of that channel is displayed.
+
+If the <target> parameter is specified, the request is forwarded to that server which will generate the reply.
+
+Wildcards are allowed in the <target> parameter.
+
+**Numeric Replies:**
+- ERR_TOOMANYMATCHES
+- ERR_NOSUCHSERVER
+- RPL_LIST
+- RPL_LISTEND
+
+**Examples:**
+
+```
+LIST                            ; Command to list all channels.
+
+LIST #twilight_zone,#42         ; Command to list channels
+                                #twilight_zone and #42
+```
+
+#### 3.2.7 Invite message
+
+**Command:** INVITE  
+**Parameters:** <nickname> <channel>
+
+The INVITE command is used to invite a user to a channel. The parameter <nickname> is the nickname of the person to be invited to the target channel <channel>. There is no requirement that the channel the target user is being invited to must exist or be a valid channel. However, if the channel exists, only members of the channel are allowed to invite other users. When the channel has invite-only flag set, only channel operators may issue INVITE command.
+
+Only the user inviting and the user being invited will receive notification of the invitation. Other channel members are not notified. (This is unlike the MODE changes, and is occasionally the source of trouble for users.)
+
+**Numeric Replies:**
+- ERR_NEEDMOREPARAMS
+- ERR_NOSUCHNICK
+- ERR_NOTONCHANNEL
+- ERR_USERONCHANNEL
+- ERR_CHANOPRIVSNEEDED
+- RPL_INVITING
+- RPL_AWAY
+
+**Examples:**
+
+```
+:Angel!wings@irc.org INVITE Wiz #Dust
+
+                                ; Message to WiZ when he has been
+                                invited by user Angel to channel
+                                #Dust
+
+INVITE Wiz #Twilight_Zone       ; Command to invite WiZ to
+                                #Twilight_zone
+```
+
+#### 3.2.8 Kick command
+
+**Command:** KICK  
+**Parameters:** <channel> *( "," <channel> ) <user> *( "," <user> ) [<comment>]
+
+The KICK command can be used to request the forced removal of a user from a channel. It causes the <user> to PART from the <channel> by force. For the message to be syntactically correct, there MUST be either one channel parameter and multiple user parameter, or as many channel parameters as there are user parameters. If a "comment" is given, this will be sent instead of the default message, the nickname of the user issuing the KICK.
+
+The server MUST NOT send KICK messages with multiple channels or users to clients. This is necessarily to maintain backward compatibility with old client software.
+
+**Numeric Replies:**
+- ERR_NEEDMOREPARAMS
+- ERR_NOSUCHCHANNEL
+- ERR_BADCHANMASK
+- ERR_CHANOPRIVSNEEDED
+- ERR_USERNOTINCHANNEL
+- ERR_NOTONCHANNEL
+
+**Examples:**
+
+```
+KICK &Melbourne Matthew         ; Command to kick Matthew from
+                                &Melbourne
+
+KICK #Finnish John :Speaking English
+                                ; Command to kick John from #Finnish
+                                using "Speaking English" as the
+                                reason (comment).
+
+:WiZ!jto@tolsun.oulu.fi KICK #Finnish John
+                                ; KICK message on channel #Finnish
+                                from WiZ to remove John from channel
+```
+
+
+### 3.3 Sending messages
+
+The main purpose of the IRC protocol is to provide a base for clients to communicate with each other. PRIVMSG, NOTICE and SQUERY (described in Section 3.5 on Service Query and Commands) are the only messages available which actually perform delivery of a text message from one client to another - the rest just make it possible and try to ensure it happens in a reliable and structured manner.
+
+#### 3.3.1 Private messages
+
+**Command:** PRIVMSG  
+**Parameters:** <msgtarget> <text to be sent>
+
+PRIVMSG is used to send private messages between users, as well as to send messages to channels. <msgtarget> is usually the nickname of the recipient of the message, or a channel name.
+
+The <msgtarget> parameter may also be a host mask (#<mask>) or server mask ($<mask>). In both cases the server will only send the PRIVMSG to those who have a server or host matching the mask. The mask MUST have at least 1 (one) "." in it and no wildcards following the last ".". This requirement exists to prevent people sending messages to "#*" or "$*", which would broadcast to all users. Wildcards are the '*' and '?' characters. This extension to the PRIVMSG command is only available to operators.
+
+**Numeric Replies:**
+- ERR_NORECIPIENT
+- ERR_NOTEXTTOSEND
+- ERR_CANNOTSENDTOCHAN
+- ERR_NOTOPLEVEL
+- ERR_WILDTOPLEVEL
+- ERR_TOOMANYTARGETS
+- ERR_NOSUCHNICK
+- RPL_AWAY
+
+**Examples:**
+
+```
+:Angel!wings@irc.org PRIVMSG Wiz :Are you receiving this message ?
+                                ; Message from Angel to Wiz.
+
+PRIVMSG Angel :yes I'm receiving it !
+                                ; Command to send a message to Angel.
+
+PRIVMSG jto@tolsun.oulu.fi :Hello !
+                                ; Command to send a message to a user
+                                on server tolsun.oulu.fi with
+                                username of "jto".
+
+PRIVMSG kalt%millennium.stealth.net@irc.stealth.net :Are you a frog?
+                                ; Message to a user on server
+                                irc.stealth.net with username of
+                                "kalt", and connected from the host
+                                millennium.stealth.net.
+
+PRIVMSG kalt%millennium.stealth.net :Do you like cheese?
+                                ; Message to a user on the local
+                                server with username of "kalt", and
+                                connected from the host
+                                millennium.stealth.net.
+
+PRIVMSG Wiz!jto@tolsun.oulu.fi :Hello !
+                                ; Message to the user with nickname
+                                Wiz who is connected from the host
+                                tolsun.oulu.fi and has the username
+                                "jto".
+
+PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.
+                                ; Message to everyone on a server
+                                which has a name matching *.fi.
+
+PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions
+                                ; Message to all users who come from
+                                a host which has a name matching
+                                *.edu.
+```
+
+#### 3.3.2 Notice
+
+**Command:** NOTICE  
+**Parameters:** <msgtarget> <text>
+
+The NOTICE command is used similarly to PRIVMSG. The difference between NOTICE and PRIVMSG is that automatic replies MUST NEVER be sent in response to a NOTICE message. This rule applies to servers too - they MUST NOT send any error reply back to the client on receipt of a notice. The object of this rule is to avoid loops between clients automatically sending something in response to something it received.
+
+This command is available to services as well as users.
+
+This is typically used by services, and automatons (clients with either an AI or other interactive program controlling their actions).
+
+See PRIVMSG for more details on replies and examples.
+
+### 3.4 Server queries and commands
+
+The server query group of commands has been designed to return information about any server which is connected to the network.
+
+In these queries, where a parameter appears as <target>, wildcard masks are usually valid. For each parameter, however, only one query and set of replies is to be generated. In most cases, if a nickname is given, it will mean the server to which the user is connected.
+
+These messages typically have little value for services, it is therefore RECOMMENDED to forbid services from using them.
+
+#### 3.4.1 Motd message
+
+**Command:** MOTD  
+**Parameters:** [ <target> ]
+
+The MOTD command is used to get the "Message Of The Day" of the given server, or current server if <target> is omitted.
+
+Wildcards are allowed in the <target> parameter.
+
+**Numeric Replies:**
+- RPL_MOTDSTART
+- RPL_MOTD
+- RPL_ENDOFMOTD
+- ERR_NOMOTD
+
+#### 3.4.2 Lusers message
+
+**Command:** LUSERS  
+**Parameters:** [ <mask> [ <target> ] ]
+
+The LUSERS command is used to get statistics about the size of the IRC network. If no parameter is given, the reply will be about the whole net. If a <mask> is specified, then the reply will only concern the part of the network formed by the servers matching the mask. Finally, if the <target> parameter is specified, the request is forwarded to that server which will generate the reply.
+
+Wildcards are allowed in the <target> parameter.
+
+**Numeric Replies:**
+- RPL_LUSERCLIENT
+- RPL_LUSEROP
+- RPL_LUSERUNKOWN
+- RPL_LUSERCHANNELS
+- RPL_LUSERME
+- ERR_NOSUCHSERVER
+
+#### 3.4.3 Version message
+
+**Command:** VERSION  
+**Parameters:** [ <target> ]
+
+The VERSION command is used to query the version of the server program. An optional parameter <target> is used to query the version of the server program which a client is not directly connected to.
+
+Wildcards are allowed in the <target> parameter.
+
+**Numeric Replies:**
+- ERR_NOSUCHSERVER
+- RPL_VERSION
+
+**Examples:**
+
+```
+VERSION tolsun.oulu.fi          ; Command to check the version of
+                                server "tolsun.oulu.fi".
+```
+
+#### 3.4.4 Stats message
+
+**Command:** STATS  
+**Parameters:** [ <query> [ <target> ] ]
+
+The stats command is used to query statistics of certain server. If <query> parameter is omitted, only the end of stats reply is sent back.
+
+A query may be given for any single letter which is only checked by the destination server and is otherwise passed on by intermediate servers, ignored and unaltered.
+
+Wildcards are allowed in the <target> parameter.
+
+Except for the ones below, the list of valid queries is implementation dependent. The standard queries below SHOULD be supported by the server:
+
+- **l** - returns a list of the server's connections, showing how long each connection has been established and the traffic over that connection in Kbytes and messages for each direction;
+- **m** - returns the usage count for each of commands supported by the server; commands for which the usage count is zero MAY be omitted;
+- **o** - returns a list of configured privileged users, operators;
+- **u** - returns a string showing how long the server has been up.
+
+It is also RECOMMENDED that client and server access configuration be published this way.
+
+**Numeric Replies:**
+- ERR_NOSUCHSERVER
+- RPL_STATSLINKINFO
+- RPL_STATSUPTIME
+- RPL_STATSCOMMANDS
+- RPL_STATSOLINE
+- RPL_ENDOFSTATS
+
+**Examples:**
+
+```
+STATS m                         ; Command to check the command usage
+                                for the server you are connected to
+```
+
+#### 3.4.5 Links message
+
+**Command:** LINKS  
+**Parameters:** [ [ <remote server> ] <server mask> ]
+
+With LINKS, a user can list all servernames, which are known by the server answering the query. The returned list of servers MUST match the mask, or if no mask is given, the full list is returned.
+
+If <remote server> is given in addition to <server mask>, the LINKS command is forwarded to the first server found that matches that name (if any), and that server is then required to answer the query.
+
+**Numeric Replies:**
+- ERR_NOSUCHSERVER
+- RPL_LINKS
+- RPL_ENDOFLINKS
+
+**Examples:**
+
+```
+LINKS *.au                      ; Command to list all servers which
+                                have a name that matches *.au;
+
+LINKS *.edu *.bu.edu            ; Command to list servers matching
+                                *.bu.edu as seen by the first server
+                                matching *.edu.
+```
+
+#### 3.4.6 Time message
+
+**Command:** TIME  
+**Parameters:** [ <target> ]
+
+The time command is used to query local time from the specified server. If the <target> parameter is not given, the server receiving the command must reply to the query.
+
+Wildcards are allowed in the <target> parameter.
+
+**Numeric Replies:**
+- ERR_NOSUCHSERVER
+- RPL_TIME
+
+**Examples:**
+
+```
+TIME tolsun.oulu.fi             ; check the time on the server
+                                "tolson.oulu.fi"
+```
+
+#### 3.4.7 Connect message
+
+**Command:** CONNECT  
+**Parameters:** <target server> <port> [ <remote server> ]
+
+The CONNECT command can be used to request a server to try to establish a new connection to another server immediately. CONNECT is a privileged command and SHOULD be available only to IRC Operators. If a <remote server> is given and its mask doesn't match name of the parsing server, the CONNECT attempt is sent to the first match of remote server. Otherwise the CONNECT attempt is made by the server processing the request.
+
+The server receiving a remote CONNECT command SHOULD generate a WALLOPS message describing the source and target of the request.
+
+**Numeric Replies:**
+- ERR_NOSUCHSERVER
+- ERR_NOPRIVILEGES
+- ERR_NEEDMOREPARAMS
+
+**Examples:**
+
+```
+CONNECT tolsun.oulu.fi 6667     ; Command to attempt to connect local
+                                server to tolsun.oulu.fi on port 6667
+```
+
+#### 3.4.8 Trace message
+
+**Command:** TRACE  
+**Parameters:** [ <target> ]
+
+TRACE command is used to find the route to specific server and information about its peers. Each server that processes this command MUST report to the sender about it. The replies from pass-through links form a chain, which shows route to destination. After sending this reply back, the query MUST be sent to the next server until given <target> server is reached.
+
+TRACE command is used to find the route to specific server. Each server that processes this message MUST tell the sender about it by sending a reply indicating it is a pass-through link, forming a chain of replies. After sending this reply back, it MUST then send the TRACE message to the next server until given server is reached. If the <target> parameter is omitted, it is RECOMMENDED that TRACE command sends a message to the sender telling which servers the local server has direct connection to.
+
+If the destination given by <target> is an actual server, the destination server is REQUIRED to report all servers, services and operators which are connected to it; if the command was issued by an operator, the server MAY also report all users which are connected to it. If the destination given by <target> is a nickname, then only a reply for that nickname is given. If the <target> parameter is omitted, it is RECOMMENDED that the TRACE command is parsed as targeted to the processing server.
+
+Wildcards are allowed in the <target> parameter.
+
+**Numeric Replies:**
+- ERR_NOSUCHSERVER
+
+If the TRACE message is destined for another server, all intermediate servers must return a RPL_TRACELINK reply to indicate that the TRACE passed through it and where it is going next.
+
+- RPL_TRACELINK
+
+A TRACE reply may be composed of any number of the following numeric replies.
+
+- RPL_TRACECONNECTING
+- RPL_TRACEHANDSHAKE
+- RPL_TRACEUNKNOWN
+- RPL_TRACEOPERATOR
+- RPL_TRACEUSER
+- RPL_TRACESERVER
+- RPL_TRACESERVICE
+- RPL_TRACENEWTYPE
+- RPL_TRACECLASS
+- RPL_TRACELOG
+- RPL_TRACEEND
+
+**Examples:**
+
+```
+TRACE *.oulu.fi                 ; TRACE to a server matching
+                                *.oulu.fi
+```
+
+#### 3.4.9 Admin command
+
+**Command:** ADMIN  
+**Parameters:** [ <target> ]
+
+The admin command is used to find information about the administrator of the given server, or current server if <target> parameter is omitted. Each server MUST have the ability to forward ADMIN messages to other servers.
+
+Wildcards are allowed in the <target> parameter.
+
+**Numeric Replies:**
+- ERR_NOSUCHSERVER
+- RPL_ADMINME
+- RPL_ADMINLOC1
+- RPL_ADMINLOC2
+- RPL_ADMINEMAIL
+
+**Examples:**
+
+```
+ADMIN tolsun.oulu.fi            ; request an ADMIN reply from
+                                tolsun.oulu.fi
+
+ADMIN syrk                      ; ADMIN request for the server to
+                                which the user syrk is connected
+```
+
+#### 3.4.10 Info command
+
+**Command:** INFO  
+**Parameters:** [ <target> ]
+
+The INFO command is REQUIRED to return information describing the server: its version, when it was compiled, the patchlevel, when it was started, and any other miscellaneous information which may be considered to be relevant.
+
+Wildcards are allowed in the <target> parameter.
+
+**Numeric Replies:**
+- ERR_NOSUCHSERVER
+- RPL_INFO
+- RPL_ENDOFINFO
+
+**Examples:**
+
+```
+INFO csd.bu.edu                 ; request an INFO reply from
+                                csd.bu.edu
+
+INFO Angel                      ; request info from the server that
+                                Angel is connected to.
+```
+
+
+### 3.5 Service Query and Commands
+
+The service query group of commands has been designed to return information about any service which is connected to the network.
+
+#### 3.5.1 Servlist message
+
+**Command:** SERVLIST  
+**Parameters:** [ <mask> [ <type> ] ]
+
+The SERVLIST command is used to list services currently connected to the network and visible to the user issuing the command. The optional parameters may be used to restrict the result of the query (to matching services names, and services type).
+
+**Numeric Replies:**
+- RPL_SERVLIST
+- RPL_SERVLISTEND
+
+#### 3.5.2 Squery
+
+**Command:** SQUERY  
+**Parameters:** <servicename> <text>
+
+The SQUERY command is used similarly to PRIVMSG. The only difference is that the recipient MUST be a service. This is the only way for a text message to be delivered to a service.
+
+See PRIVMSG for more details on replies and example.
+
+**Examples:**
+
+```
+SQUERY irchelp :HELP privmsg
+                                ; Message to the service with
+                                nickname irchelp.
+
+SQUERY dict@irc.fr :fr2en blaireau
+                                ; Message to the service with name
+                                dict@irc.fr.
+```
+
+### 3.6 User based queries
+
+User queries are a group of commands which are primarily concerned with finding details on a particular user or group users. When using wildcards with any of these commands, if they match, they will only return information on users who are 'visible' to you. The visibility of a user is determined as a combination of the user's mode and the common set of channels you are both on.
+
+Although services SHOULD NOT be using this class of message, they are allowed to.
+
+#### 3.6.1 Who query
+
+**Command:** WHO  
+**Parameters:** [ <mask> [ "o" ] ]
+
+The WHO command is used by a client to generate a query which returns a list of information which 'matches' the <mask> parameter given by the client. In the absence of the <mask> parameter, all visible (users who aren't invisible (user mode +i) and who don't have a common channel with the requesting client) are listed. The same result can be achieved by using a <mask> of "0" or any wildcard which will end up matching every visible user.
+
+The <mask> passed to WHO is matched against users' host, server, real name and nickname if the channel <mask> cannot be found.
+
+If the "o" parameter is passed only operators are returned according to the <mask> supplied.
+
+**Numeric Replies:**
+- ERR_NOSUCHSERVER
+- RPL_WHOREPLY
+- RPL_ENDOFWHO
+
+**Examples:**
+
+```
+WHO *.fi                        ; Command to list all users who match
+                                against "*.fi".
+
+WHO jto* o                      ; Command to list all users with a
+                                match against "jto*" if they are an
+                                operator.
+```
+
+#### 3.6.2 Whois query
+
+**Command:** WHOIS  
+**Parameters:** [ <target> ] <mask> *( "," <mask> )
+
+This command is used to query information about particular user. The server will answer this command with several numeric messages indicating different statuses of each user which matches the mask (if you are entitled to see them). If no wildcard is present in the <mask>, any information about that nick which you are allowed to see is presented.
+
+If the <target> parameter is specified, it sends the query to a specific server. It is useful if you want to know how long the user in question has been idle as only local server (i.e., the server the user is directly connected to) knows that information, while everything else is globally known.
+
+Wildcards are allowed in the <target> parameter.
+
+**Numeric Replies:**
+- ERR_NOSUCHSERVER
+- ERR_NONICKNAMEGIVEN
+- RPL_WHOISUSER
+- RPL_WHOISCHANNELS
+- RPL_WHOISSERVER
+- RPL_AWAY
+- RPL_WHOISOPERATOR
+- RPL_WHOISIDLE
+- ERR_NOSUCHNICK
+- RPL_ENDOFWHOIS
+
+**Examples:**
+
+```
+WHOIS wiz                       ; return available user information
+                                about nick WiZ
+
+WHOIS eff.org trillian          ; ask server eff.org for user
+                                information  about trillian
+```
+
+#### 3.6.3 Whowas
+
+**Command:** WHOWAS  
+**Parameters:** <nickname> *( "," <nickname> ) [ <count> [ <target> ] ]
+
+Whowas asks for information about a nickname which no longer exists. This may either be due to a nickname change or the user leaving IRC. In response to this query, the server searches through its nickname history, looking for any nicks which are lexically the same (no wild card matching here). The history is searched backward, returning the most recent entry first. If there are multiple entries, up to <count> replies will be returned (or all of them if no <count> parameter is given). If a non-positive number is passed as being <count>, then a full search is done.
+
+Wildcards are allowed in the <target> parameter.
+
+**Numeric Replies:**
+- ERR_NONICKNAMEGIVEN
+- ERR_WASNOSUCHNICK
+- RPL_WHOWASUSER
+- RPL_WHOISSERVER
+- RPL_ENDOFWHOWAS
+
+**Examples:**
+
+```
+WHOWAS Wiz                      ; return all information in the nick
+                                history about nick "WiZ";
+
+WHOWAS Mermaid 9                ; return at most, the 9 most recent
+                                entries in the nick history for
+                                "Mermaid";
+
+WHOWAS Trillian 1 *.edu         ; return the most recent history for
+                                "Trillian" from the first server
+                                found to match "*.edu".
+```
+
+### 3.7 Miscellaneous messages
+
+Messages in this category do not fit into any of the above categories but are nonetheless still a part of and REQUIRED by the protocol.
+
+#### 3.7.1 Kill message
+
+**Command:** KILL  
+**Parameters:** <nickname> <comment>
+
+The KILL command is used to cause a client-server connection to be closed by the server which has the actual connection. Servers generate KILL messages on nickname collisions. It MAY also be available available to users who have the operator status.
+
+Clients which have automatic reconnect algorithms effectively make this command useless since the disconnection is only brief. It does however break the flow of data and can be used to stop large amounts of 'flooding' from abusive users or accidents. Abusive users usually don't care as they will reconnect promptly and resume their abusive behaviour. To prevent this command from being abused, any user may elect to receive KILL messages generated for others to keep an 'eye' on would be trouble spots.
+
+In an arena where nicknames are REQUIRED to be globally unique at all times, KILL messages are sent whenever 'duplicates' are detected (that is an attempt to register two users with the same nickname) in the hope that both of them will disappear and only 1 reappear.
+
+When a client is removed as the result of a KILL message, the server SHOULD add the nickname to the list of unavailable nicknames in an attempt to avoid clients to reuse this name immediately which is usually the pattern of abusive behaviour often leading to useless "KILL loops". See the "IRC Server Protocol" document [IRC-SERVER] for more information on this procedure.
+
+The comment given MUST reflect the actual reason for the KILL. For server-generated KILLs it usually is made up of details concerning the origins of the two conflicting nicknames. For users it is left up to them to provide an adequate reason to satisfy others who see it. To prevent/discourage fake KILLs from being generated to hide the identify of the KILLer, the comment also shows a 'kill-path' which is updated by each server it passes through, each prepending its name to the path.
+
+**Numeric Replies:**
+- ERR_NOPRIVILEGES
+- ERR_NEEDMOREPARAMS
+- ERR_NOSUCHNICK
+- ERR_CANTKILLSERVER
+
+**NOTE:** It is RECOMMENDED that only Operators be allowed to kill other users with KILL command. This command has been the subject of many controversies over the years, and along with the above recommendation, it is also widely recognized that not even operators should be allowed to kill users on remote servers.
+
+#### 3.7.2 Ping message
+
+**Command:** PING  
+**Parameters:** <server1> [ <server2> ]
+
+The PING command is used to test the presence of an active client or server at the other end of the connection. Servers send a PING message at regular intervals if no other activity detected coming from a connection. If a connection fails to respond to a PING message within a set amount of time, that connection is closed. A PING message MAY be sent even if the connection is active.
+
+When a PING message is received, the appropriate PONG message MUST be sent as reply to <server1> (server which sent the PING message out) as soon as possible. If the <server2> parameter is specified, it represents the target of the ping, and the message gets forwarded there.
+
+**Numeric Replies:**
+- ERR_NOORIGIN
+- ERR_NOSUCHSERVER
+
+**Examples:**
+
+```
+PING tolsun.oulu.fi             ; Command to send a PING message to
+                                server
+
+PING WiZ tolsun.oulu.fi         ; Command from WiZ to send a PING
+                                message to server "tolsun.oulu.fi"
+
+PING :irc.funet.fi              ; Ping message sent by server
+                                "irc.funet.fi"
+```
+
+#### 3.7.3 Pong message
+
+**Command:** PONG  
+**Parameters:** <server> [ <server2> ]
+
+PONG message is a reply to ping message. If parameter <server2> is given, this message MUST be forwarded to given target. The <server> parameter is the name of the entity who has responded to PING message and generated this message.
+
+**Numeric Replies:**
+- ERR_NOORIGIN
+- ERR_NOSUCHSERVER
+
+**Example:**
+
+```
+PONG csd.bu.edu tolsun.oulu.fi  ; PONG message from csd.bu.edu to
+                                tolsun.oulu.fi
+```
+
+#### 3.7.4 Error
+
+**Command:** ERROR  
+**Parameters:** <error message>
+
+The ERROR command is for use by servers when reporting a serious or fatal error to its peers. It may also be sent from one server to another but MUST NOT be accepted from any normal unknown clients.
+
+Only an ERROR message SHOULD be used for reporting errors which occur with a server-to-server link. An ERROR message is sent to the server at the other end (which reports it to appropriate local users and logs) and to appropriate local users and logs. It is not to be passed onto any other servers by a server if it is received from a server.
+
+The ERROR message is also used before terminating a client connection.
+
+When a server sends a received ERROR message to its operators, the message SHOULD be encapsulated inside a NOTICE message, indicating that the client was not responsible for the error.
+
+**Numerics:** None.
+
+**Examples:**
+
+```
+ERROR :Server *.fi already exists ; ERROR message to the other server
+                                which caused this error.
+
+NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
+                                ; Same ERROR message as above but
+                                sent to user WiZ on the other server.
+```
+
+
+## 4. Optional features
+
+This section describes OPTIONAL messages. They are not required in a working server implementation of the protocol described herein. In the absence of the feature, an error reply message MUST be generated or an unknown command error. If the message is destined for another server to answer then it MUST be passed on (elementary parsing REQUIRED) The allocated numerics for this are listed with the messages below.
+
+From this section, only the USERHOST and ISON messages are available to services.
+
+### 4.1 Away
+
+**Command:** AWAY  
+**Parameters:** [ <text> ]
+
+With the AWAY command, clients can set an automatic reply string for any PRIVMSG commands directed at them (not to a channel they are on). The server sends an automatic reply to the client sending the PRIVMSG command. The only replying server is the one to which the sending client is connected to.
+
+The AWAY command is used either with one parameter, to set an AWAY message, or with no parameters, to remove the AWAY message.
+
+Because of its high cost (memory and bandwidth wise), the AWAY message SHOULD only be used for client-server communication. A server MAY choose to silently ignore AWAY messages received from other servers. To update the away status of a client across servers, the user mode 'a' SHOULD be used instead. (See Section 3.1.5)
+
+**Numeric Replies:**
+- RPL_UNAWAY
+- RPL_NOWAWAY
+
+**Example:**
+
+```
+AWAY :Gone to lunch.  Back in 5 ; Command to set away message to
+                                "Gone to lunch.  Back in 5".
+```
+
+### 4.2 Rehash message
+
+**Command:** REHASH  
+**Parameters:** None
+
+The rehash command is an administrative command which can be used by an operator to force the server to re-read and process its configuration file.
+
+**Numeric Replies:**
+- RPL_REHASHING
+- ERR_NOPRIVILEGES
+
+**Example:**
+
+```
+REHASH                          ; message from user with operator
+                                status to server asking it to reread
+                                its configuration file.
+```
+
+### 4.3 Die message
+
+**Command:** DIE  
+**Parameters:** None
+
+An operator can use the DIE command to shutdown the server. This message is optional since it may be viewed as a risk to allow arbitrary people to connect to a server as an operator and execute this command.
+
+The DIE command MUST always be fully processed by the server to which the sending client is connected and MUST NOT be passed onto other connected servers.
+
+**Numeric Replies:**
+- ERR_NOPRIVILEGES
+
+**Example:**
+
+```
+DIE                             ; no parameters required.
+```
+
+### 4.4 Restart message
+
+**Command:** RESTART  
+**Parameters:** None
+
+An operator can use the restart command to force the server to restart itself. This message is optional since it may be viewed as a risk to allow arbitrary people to connect to a server as an operator and execute this command, causing (at least) a disruption to service.
+
+The RESTART command MUST always be fully processed by the server to which the sending client is connected and MUST NOT be passed onto other connected servers.
+
+**Numeric Replies:**
+- ERR_NOPRIVILEGES
+
+**Example:**
+
+```
+RESTART                         ; no parameters required.
+```
+
+### 4.5 Summon message
+
+**Command:** SUMMON  
+**Parameters:** <user> [ <target> [ <channel> ] ]
+
+The SUMMON command can be used to give users who are on a host running an IRC server a message asking them to please join IRC. This message is only sent if the target server (a) has SUMMON enabled, (b) the user is logged in and (c) the server process can write to the user's tty (or similar).
+
+If no <server> parameter is given it tries to summon <user> from the server the client is connected to is assumed as the target.
+
+If summon is not enabled in a server, it MUST return the ERR_SUMMONDISABLED numeric.
+
+**Numeric Replies:**
+- ERR_NORECIPIENT
+- ERR_FILEERROR
+- ERR_NOLOGIN
+- ERR_NOSUCHSERVER
+- ERR_SUMMONDISABLED
+- RPL_SUMMONING
+
+**Examples:**
+
+```
+SUMMON jto                      ; summon user jto on the server's
+                                host
+
+SUMMON jto tolsun.oulu.fi       ; summon user jto on the host which a
+                                server named "tolsun.oulu.fi" is
+                                running.
+```
+
+### 4.6 Users
+
+**Command:** USERS  
+**Parameters:** [ <target> ]
+
+The USERS command returns a list of users logged into the server in a format similar to the UNIX commands who(1), rusers(1) and finger(1). If disabled, the correct numeric MUST be returned to indicate this.
+
+Because of the security implications of such a command, it SHOULD be disabled by default in server implementations. Enabling it SHOULD require recompiling the server or some equivalent change rather than simply toggling an option and restarting the server. The procedure to enable this command SHOULD also include suitable large comments.
+
+**Numeric Replies:**
+- ERR_NOSUCHSERVER
+- ERR_FILEERROR
+- RPL_USERSSTART
+- RPL_USERS
+- RPL_NOUSERS
+- RPL_ENDOFUSERS
+- ERR_USERSDISABLED
+
+**Disabled Reply:**
+- ERR_USERSDISABLED
+
+**Example:**
+
+```
+USERS eff.org                   ; request a list of users logged in
+                                on server eff.org
+```
+
+### 4.7 Operwall message
+
+**Command:** WALLOPS  
+**Parameters:** <Text to be sent>
+
+The WALLOPS command is used to send a message to all currently connected users who have set the 'w' user mode for themselves. (See Section 3.1.5 "User modes").
+
+After implementing WALLOPS as a user command it was found that it was often and commonly abused as a means of sending a message to a lot of people. Due to this, it is RECOMMENDED that the implementation of WALLOPS allows and recognizes only servers as the originators of WALLOPS.
+
+**Numeric Replies:**
+- ERR_NEEDMOREPARAMS
+
+**Example:**
+
+```
+:csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua ; WALLOPS
+                                message from csd.bu.edu announcing a
+                                CONNECT message it received from
+                                Joshua and acted upon.
+```
+
+### 4.8 Userhost message
+
+**Command:** USERHOST  
+**Parameters:** <nickname> *( SPACE <nickname> )
+
+The USERHOST command takes a list of up to 5 nicknames, each separated by a space character and returns a list of information about each nickname that it found. The returned list has each reply separated by a space.
+
+**Numeric Replies:**
+- RPL_USERHOST
+- ERR_NEEDMOREPARAMS
+
+**Example:**
+
+```
+USERHOST Wiz Michael syrk       ; USERHOST request for information on
+                                nicks "Wiz", "Michael", and "syrk"
+
+:ircd.stealth.net 302 yournick :syrk=+syrk@millennium.stealth.net
+                                ; Reply for user syrk
+```
+
+### 4.9 Ison message
+
+**Command:** ISON  
+**Parameters:** <nickname> *( SPACE <nickname> )
+
+The ISON command was implemented to provide a quick and efficient means to get a response about whether a given nickname was currently on IRC. ISON only takes one (1) type of parameter: a space-separated list of nicks. For each nickname in the list that is present, the server adds that to its reply string. Thus the reply string may return empty (none of the given nicks are present), an exact copy of the parameter string (all of them present) or any other subset of the set of nicks given in the parameter. The only limit on the number of nicks that may be checked is that the combined length MUST NOT be too large as to cause the server to chop it off so it fits in 512 characters.
+
+ISON is only processed by the server local to the client sending the command and thus not passed onto other servers for further processing.
+
+**Numeric Replies:**
+- RPL_ISON
+- ERR_NEEDMOREPARAMS
+
+**Example:**
+
+```
+ISON phone trillian WiZ jarlek Avalon Angel Monstah syrk
+                                ; Sample ISON request for 7 nicks.
+```
+
+
+## 5. Replies
+
+The following is a list of numeric replies which are generated in response to the commands given above. Each numeric is given with its number, name and reply string.
+
+### 5.1 Command responses
+
+Numerics in the range from 001 to 099 are used for client-server connections only and should never travel between servers. Replies generated in the response to commands are found in the range from 200 to 399.
+
+**001 RPL_WELCOME**
+```
+"Welcome to the Internet Relay Network <nick>!<user>@<host>"
+```
+
+**002 RPL_YOURHOST**
+```
+"Your host is <servername>, running version <ver>"
+```
+
+**003 RPL_CREATED**
+```
+"This server was created <date>"
+```
+
+**004 RPL_MYINFO**
+```
+"<servername> <version> <available user modes> <available channel modes>"
+```
+
+- The server sends Replies 001 to 004 to a user upon successful registration.
+
+**005 RPL_BOUNCE**
+```
+"Try server <server name>, port <port number>"
+```
+
+- Sent by the server to a user to suggest an alternative server. This is often used when the connection is refused because the server is already full.
+
+**302 RPL_USERHOST**
+```
+":*1<reply> *( " " <reply> )"
+```
+
+- Reply format used by USERHOST to list replies to the query list. The reply string is composed as follows:
+  - `reply = nickname [ "*" ] "=" ( "+" / "-" ) hostname`
+  - The '*' indicates whether the client has registered as an Operator. The '-' or '+' characters represent whether the client has set an AWAY message or not respectively.
+
+**303 RPL_ISON**
+```
+":*1<nick> *( " " <nick> )"
+```
+
+- Reply format used by ISON to list replies to the query list.
+
+**301 RPL_AWAY**
+```
+"<nick> :<away message>"
+```
+
+**305 RPL_UNAWAY**
+```
+":You are no longer marked as being away"
+```
+
+**306 RPL_NOWAWAY**
+```
+":You have been marked as being away"
+```
+
+- These replies are used with the AWAY command (if allowed). RPL_AWAY is sent to any client sending a PRIVMSG to a client which is away. RPL_AWAY is only sent by the server to which the client is connected. Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the client removes and sets an AWAY message.
+
+**311 RPL_WHOISUSER**
+```
+"<nick> <user> <host> * :<real name>"
+```
+
+**312 RPL_WHOISSERVER**
+```
+"<nick> <server> :<server info>"
+```
+
+**313 RPL_WHOISOPERATOR**
+```
+"<nick> :is an IRC operator"
+```
+
+**317 RPL_WHOISIDLE**
+```
+"<nick> <integer> :seconds idle"
+```
+
+**318 RPL_ENDOFWHOIS**
+```
+"<nick> :End of WHOIS list"
+```
+
+**319 RPL_WHOISCHANNELS**
+```
+"<nick> :*( ( "@" / "+" ) <channel> " " )"
+```
+
+- Replies 311 - 313, 317 - 319 are all replies generated in response to a WHOIS message. Given that there are enough parameters present, the answering server MUST either formulate a reply out of the above numerics (if the query nick is found) or return an error reply. The '*' in RPL_WHOISUSER is there as the literal character and not as a wild card. For each reply set, only RPL_WHOISCHANNELS may appear more than once (for long lists of channel names). The '@' and '+' characters next to the channel name indicate whether a client is a channel operator or has been granted permission to speak on a moderated channel. The RPL_ENDOFWHOIS reply is used to mark the end of processing a WHOIS message.
+
+**314 RPL_WHOWASUSER**
+```
+"<nick> <user> <host> * :<real name>"
+```
+
+**369 RPL_ENDOFWHOWAS**
+```
+"<nick> :End of WHOWAS"
+```
+
+- When replying to a WHOWAS message, a server MUST use the replies RPL_WHOWASUSER, RPL_WHOISSERVER or ERR_WASNOSUCHNICK for each nickname in the presented list. At the end of all reply batches, there MUST be RPL_ENDOFWHOWAS (even if there was only one reply and it was an error).
+
+**321 RPL_LISTSTART**
+```
+Obsolete. Not used.
+```
+
+**322 RPL_LIST**
+```
+"<channel> <# visible> :<topic>"
+```
+
+**323 RPL_LISTEND**
+```
+":End of LIST"
+```
+
+- Replies RPL_LIST, RPL_LISTEND mark the actual replies with data and end of the server's response to a LIST command. If there are no channels available to return, only the end reply MUST be sent.
+
+**325 RPL_UNIQOPIS**
+```
+"<channel> <nickname>"
+```
+
+**324 RPL_CHANNELMODEIS**
+```
+"<channel> <mode> <mode params>"
+```
+
+**331 RPL_NOTOPIC**
+```
+"<channel> :No topic is set"
+```
+
+**332 RPL_TOPIC**
+```
+"<channel> :<topic>"
+```
+
+- When sending a TOPIC message to determine the channel topic, one of two replies is sent. If the topic is set, RPL_TOPIC is sent back else RPL_NOTOPIC.
+
+**341 RPL_INVITING**
+```
+"<channel> <nick>"
+```
+
+- Returned by the server to indicate that the attempted INVITE message was successful and is being passed onto the end client.
+
+**342 RPL_SUMMONING**
+```
+"<user> :Summoning user to IRC"
+```
+
+- Returned by a server answering a SUMMON message to indicate that it is summoning that user.
+
+**346 RPL_INVITELIST**
+```
+"<channel> <invitemask>"
+```
+
+**347 RPL_ENDOFINVITELIST**
+```
+"<channel> :End of channel invite list"
+```
+
+- When listing the 'invitations masks' for a given channel, a server is required to send the list back using the RPL_INVITELIST and RPL_ENDOFINVITELIST messages. A separate RPL_INVITELIST is sent for each active mask. After the masks have been listed (or if none present) a RPL_ENDOFINVITELIST MUST be sent.
+
+**348 RPL_EXCEPTLIST**
+```
+"<channel> <exceptionmask>"
+```
+
+**349 RPL_ENDOFEXCEPTLIST**
+```
+"<channel> :End of channel exception list"
+```
+
+- When listing the 'exception masks' for a given channel, a server is required to send the list back using the RPL_EXCEPTLIST and RPL_ENDOFEXCEPTLIST messages. A separate RPL_EXCEPTLIST is sent for each active mask. After the masks have been listed (or if none present) a RPL_ENDOFEXCEPTLIST MUST be sent.
+
+**351 RPL_VERSION**
+```
+"<version>.<debuglevel> <server> :<comments>"
+```
+
+- Reply by the server showing its version details. The <version> is the version of the software being used (including any patchlevel revisions) and the <debuglevel> is used to indicate if the server is running in "debug mode". The "comments" field may contain any comments about the version or further version details.
+
+**352 RPL_WHOREPLY**
+```
+"<channel> <user> <host> <server> <nick> ( "H" / "G" > ["*"] [ ( "@" / "+" ) ]
+:<hopcount> <real name>"
+```
+
+**315 RPL_ENDOFWHO**
+```
+"<name> :End of WHO list"
+```
+
+- The RPL_WHOREPLY and RPL_ENDOFWHO pair are used to answer a WHO message. The RPL_WHOREPLY is only sent if there is an appropriate match to the WHO query. If there is a list of parameters supplied with a WHO message, a RPL_ENDOFWHO MUST be sent after processing each list item with <name> being the item.
+
+**353 RPL_NAMREPLY**
+```
+"( "=" / "*" / "@" ) <channel>
+ :[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )
+```
+
+- "@" is used for secret channels, "*" for private channels, and "=" for others (public channels).
+
+**366 RPL_ENDOFNAMES**
+```
+"<channel> :End of NAMES list"
+```
+
+- To reply to a NAMES message, a reply pair consisting of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the server back to the client. If there is no channel found as in the query, then only RPL_ENDOFNAMES is returned. The exception to this is when a NAMES message is sent with no parameters and all visible channels and contents are sent back in a series of RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark the end.
+
+**364 RPL_LINKS**
+```
+"<mask> <server> :<hopcount> <server info>"
+```
+
+**365 RPL_ENDOFLINKS**
+```
+"<mask> :End of LINKS list"
+```
+
+- In replying to the LINKS message, a server MUST send replies back using the RPL_LINKS numeric and mark the end of the list using an RPL_ENDOFLINKS reply.
+
+**367 RPL_BANLIST**
+```
+"<channel> <banmask>"
+```
+
+**368 RPL_ENDOFBANLIST**
+```
+"<channel> :End of channel ban list"
+```
+
+- When listing the active 'bans' for a given channel, a server is required to send the list back using the RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate RPL_BANLIST is sent for each active banmask. After the banmasks have been listed (or if none present) a RPL_ENDOFBANLIST MUST be sent.
+
+**371 RPL_INFO**
+```
+":<string>"
+```
+
+**374 RPL_ENDOFINFO**
+```
+":End of INFO list"
+```
+
+- A server responding to an INFO message is required to send all its 'info' in a series of RPL_INFO messages with a RPL_ENDOFINFO reply to indicate the end of the replies.
+
+**375 RPL_MOTDSTART**
+```
+":- <server> Message of the day - "
+```
+
+**372 RPL_MOTD**
+```
+":- <text>"
+```
+
+**376 RPL_ENDOFMOTD**
+```
+":End of MOTD command"
+```
+
+- When responding to the MOTD message and the MOTD file is found, the file is displayed line by line, with each line no longer than 80 characters, using RPL_MOTD format replies. These MUST be surrounded by a RPL_MOTDSTART (before the RPL_MOTDs) and an RPL_ENDOFMOTD (after).
+
+**381 RPL_YOUREOPER**
+```
+":You are now an IRC operator"
+```
+
+- RPL_YOUREOPER is sent back to a client which has just successfully issued an OPER message and gained operator status.
+
+**382 RPL_REHASHING**
+```
+"<config file> :Rehashing"
+```
+
+- If the REHASH option is used and an operator sends a REHASH message, an RPL_REHASHING is sent back to the operator.
+
+**383 RPL_YOURESERVICE**
+```
+"You are service <servicename>"
+```
+
+- Sent by the server to a service upon successful registration.
+
+**391 RPL_TIME**
+```
+"<server> :<string showing server's local time>"
+```
+
+- When replying to the TIME message, a server MUST send the reply using the RPL_TIME format above. The string showing the time need only contain the correct day and time there. There is no further requirement for the time string.
+
+**392 RPL_USERSSTART**
+```
+":UserID   Terminal  Host"
+```
+
+**393 RPL_USERS**
+```
+":<username> <ttyline> <hostname>"
+```
+
+**394 RPL_ENDOFUSERS**
+```
+":End of users"
+```
+
+**395 RPL_NOUSERS**
+```
+":Nobody logged in"
+```
+
+- If the USERS message is handled by a server, the replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and RPL_NOUSERS are used. RPL_USERSSTART MUST be sent first, following by either a sequence of RPL_USERS or a single RPL_NOUSER. Following this is RPL_ENDOFUSERS.
+
+
+**200 RPL_TRACELINK** through **262 RPL_TRACEEND**
+
+The RPL_TRACE* numerics are all returned by the server in response to the TRACE message. How many are returned is dependent on the TRACE message and whether it was sent by an operator or not. There is no predefined order for which occurs first. Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and RPL_TRACEHANDSHAKE are all used for connections which have not been fully established and are either unknown, still attempting to connect or in the process of completing the 'server handshake'. RPL_TRACELINK is sent by any server which handles a TRACE message and has to pass it on to another server. The list of RPL_TRACELINKs sent in response to a TRACE command traversing the IRC network should reflect the actual connectivity of the servers themselves along that path.
+
+**211 RPL_STATSLINKINFO** through **219 RPL_ENDOFSTATS**
+
+Reports statistics on a connection and command usage.
+
+**221 RPL_UMODEIS**
+```
+"<user mode string>"
+```
+
+- To answer a query about a client's own mode, RPL_UMODEIS is sent back.
+
+**234 RPL_SERVLIST** / **235 RPL_SERVLISTEND**
+
+When listing services in reply to a SERVLIST message, a server is required to send the list back using the RPL_SERVLIST and RPL_SERVLISTEND messages.
+
+**251-255 RPL_LUSERCLIENT** through **RPL_LUSERME**
+
+In processing an LUSERS message, the server sends a set of replies from RPL_LUSERCLIENT, RPL_LUSEROP, RPL_USERUNKNOWN, RPL_LUSERCHANNELS and RPL_LUSERME. When replying, a server MUST send back RPL_LUSERCLIENT and RPL_LUSERME. The other replies are only sent back if a non-zero count is found for them.
+
+**256-259 RPL_ADMINME** through **RPL_ADMINEMAIL**
+
+When replying to an ADMIN message, a server is expected to use replies RPL_ADMINME through to RPL_ADMINEMAIL and provide a text message with each. For RPL_ADMINLOC1 a description of what city, state and country the server is in is expected, followed by details of the institution (RPL_ADMINLOC2) and finally the administrative contact for the server (an email address here is REQUIRED) in RPL_ADMINEMAIL.
+
+**263 RPL_TRYAGAIN**
+```
+"<command> :Please wait a while and try again."
+```
+
+- When a server drops a command without processing it, it MUST use the reply RPL_TRYAGAIN to inform the originating client.
+
+### 5.2 Error Replies
+
+Error replies are found in the range from 400 to 599.
+
+**401 ERR_NOSUCHNICK**
+```
+"<nickname> :No such nick/channel"
+```
+
+- Used to indicate the nickname parameter supplied to a command is currently unused.
+
+**402 ERR_NOSUCHSERVER**
+```
+"<server name> :No such server"
+```
+
+- Used to indicate the server name given currently does not exist.
+
+**403 ERR_NOSUCHCHANNEL**
+```
+"<channel name> :No such channel"
+```
+
+- Used to indicate the given channel name is invalid.
+
+**404 ERR_CANNOTSENDTOCHAN**
+```
+"<channel name> :Cannot send to channel"
+```
+
+- Sent to a user who is either (a) not on a channel which is mode +n or (b) not a chanop (or mode +v) on a channel which has mode +m set or where the user is banned and is trying to send a PRIVMSG message to that channel.
+
+**405 ERR_TOOMANYCHANNELS**
+```
+"<channel name> :You have joined too many channels"
+```
+
+- Sent to a user when they have joined the maximum number of allowed channels and they try to join another channel.
+
+**406 ERR_WASNOSUCHNICK**
+```
+"<nickname> :There was no such nickname"
+```
+
+- Returned by WHOWAS to indicate there is no history information for that nickname.
+
+**407 ERR_TOOMANYTARGETS**
+```
+"<target> :<error code> recipients. <abort message>"
+```
+
+- Returned to a client which is attempting to send a PRIVMSG/NOTICE using the user@host destination format and for a user@host which has several occurrences.
+- Returned to a client which trying to send a PRIVMSG/NOTICE to too many recipients.
+- Returned to a client which is attempting to JOIN a safe channel using the shortname when there are more than one such channel.
+
+**408 ERR_NOSUCHSERVICE**
+```
+"<service name> :No such service"
+```
+
+- Returned to a client which is attempting to send a SQUERY to a service which does not exist.
+
+**409 ERR_NOORIGIN**
+```
+":No origin specified"
+```
+
+- PING or PONG message missing the originator parameter.
+
+**411 ERR_NORECIPIENT**
+```
+":No recipient given (<command>)"
+```
+
+**412 ERR_NOTEXTTOSEND**
+```
+":No text to send"
+```
+
+**413 ERR_NOTOPLEVEL**
+```
+"<mask> :No toplevel domain specified"
+```
+
+**414 ERR_WILDTOPLEVEL**
+```
+"<mask> :Wildcard in toplevel domain"
+```
+
+**415 ERR_BADMASK**
+```
+"<mask> :Bad Server/host mask"
+```
+
+- 412 - 415 are returned by PRIVMSG to indicate that the message wasn't delivered for some reason. ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that are returned when an invalid use of "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
+
+**421 ERR_UNKNOWNCOMMAND**
+```
+"<command> :Unknown command"
+```
+
+- Returned to a registered client to indicate that the command sent is unknown by the server.
+
+**422 ERR_NOMOTD**
+```
+":MOTD File is missing"
+```
+
+- Server's MOTD file could not be opened by the server.
+
+**423 ERR_NOADMININFO**
+```
+"<server> :No administrative info available"
+```
+
+- Returned by a server in response to an ADMIN message when there is an error in finding the appropriate information.
+
+**424 ERR_FILEERROR**
+```
+":File error doing <file op> on <file>"
+```
+
+- Generic error message used to report a failed file operation during the processing of a message.
+
+**431 ERR_NONICKNAMEGIVEN**
+```
+":No nickname given"
+```
+
+- Returned when a nickname parameter expected for a command and isn't found.
+
+**432 ERR_ERRONEUSNICKNAME**
+```
+"<nick> :Erroneous nickname"
+```
+
+- Returned after receiving a NICK message which contains characters which do not fall in the defined set. See section 2.3.1 for details on valid nicknames.
+
+**433 ERR_NICKNAMEINUSE**
+```
+"<nick> :Nickname is already in use"
+```
+
+- Returned when a NICK message is processed that results in an attempt to change to a currently existing nickname.
+
+**436 ERR_NICKCOLLISION**
+```
+"<nick> :Nickname collision KILL from <user>@<host>"
+```
+
+- Returned by a server to a client when it detects a nickname collision (registered of a NICK that already exists by another server).
+
+**437 ERR_UNAVAILRESOURCE**
+```
+"<nick/channel> :Nick/channel is temporarily unavailable"
+```
+
+- Returned by a server to a user trying to join a channel currently blocked by the channel delay mechanism.
+- Returned by a server to a user trying to change nickname when the desired nickname is blocked by the nick delay mechanism.
+
+**441 ERR_USERNOTINCHANNEL**
+```
+"<nick> <channel> :They aren't on that channel"
+```
+
+- Returned by the server to indicate that the target user of the command is not on the given channel.
+
+**442 ERR_NOTONCHANNEL**
+```
+"<channel> :You're not on that channel"
+```
+
+- Returned by the server whenever a client tries to perform a channel affecting command for which the client isn't a member.
+
+**443 ERR_USERONCHANNEL**
+```
+"<user> <channel> :is already on channel"
+```
+
+- Returned when a client tries to invite a user to a channel they are already on.
+
+**444 ERR_NOLOGIN**
+```
+"<user> :User not logged in"
+```
+
+- Returned by the summon after a SUMMON command for a user was unable to be performed since they were not logged in.
+
+**445 ERR_SUMMONDISABLED**
+```
+":SUMMON has been disabled"
+```
+
+- Returned as a response to the SUMMON command. MUST be returned by any server which doesn't implement it.
+
+**446 ERR_USERSDISABLED**
+```
+":USERS has been disabled"
+```
+
+- Returned as a response to the USERS command. MUST be returned by any server which does not implement it.
+
+**451 ERR_NOTREGISTERED**
+```
+":You have not registered"
+```
+
+- Returned by the server to indicate that the client MUST be registered before the server will allow it to be parsed in detail.
+
+**461 ERR_NEEDMOREPARAMS**
+```
+"<command> :Not enough parameters"
+```
+
+- Returned by the server by numerous commands to indicate to the client that it didn't supply enough parameters.
+
+**462 ERR_ALREADYREGISTRED**
+```
+":Unauthorized command (already registered)"
+```
+
+- Returned by the server to any link which tries to change part of the registered details (such as password or user details from second USER message).
+
+**463 ERR_NOPERMFORHOST**
+```
+":Your host isn't among the privileged"
+```
+
+- Returned to a client which attempts to register with a server which does not been setup to allow connections from the host the attempted connection is tried.
+
+**464 ERR_PASSWDMISMATCH**
+```
+":Password incorrect"
+```
+
+- Returned to indicate a failed attempt at registering a connection for which a password was required and was either not given or incorrect.
+
+**465 ERR_YOUREBANNEDCREEP**
+```
+":You are banned from this server"
+```
+
+- Returned after an attempt to connect and register yourself with a server which has been setup to explicitly deny connections to you.
+
+**466 ERR_YOUWILLBEBANNED**
+
+- Sent by a server to a user to inform that access to the server will soon be denied.
+
+**467 ERR_KEYSET**
+```
+"<channel> :Channel key already set"
+```
+
+**471 ERR_CHANNELISFULL**
+```
+"<channel> :Cannot join channel (+l)"
+```
+
+**472 ERR_UNKNOWNMODE**
+```
+"<char> :is unknown mode char to me for <channel>"
+```
+
+**473 ERR_INVITEONLYCHAN**
+```
+"<channel> :Cannot join channel (+i)"
+```
+
+**474 ERR_BANNEDFROMCHAN**
+```
+"<channel> :Cannot join channel (+b)"
+```
+
+**475 ERR_BADCHANNELKEY**
+```
+"<channel> :Cannot join channel (+k)"
+```
+
+**476 ERR_BADCHANMASK**
+```
+"<channel> :Bad Channel Mask"
+```
+
+**477 ERR_NOCHANMODES**
+```
+"<channel> :Channel doesn't support modes"
+```
+
+**478 ERR_BANLISTFULL**
+```
+"<channel> <char> :Channel list is full"
+```
+
+**481 ERR_NOPRIVILEGES**
+```
+":Permission Denied- You're not an IRC operator"
+```
+
+- Any command requiring operator privileges to operate MUST return this error to indicate the attempt was unsuccessful.
+
+**482 ERR_CHANOPRIVSNEEDED**
+```
+"<channel> :You're not channel operator"
+```
+
+- Any command requiring 'chanop' privileges (such as MODE messages) MUST return this error if the client making the attempt is not a chanop on the specified channel.
+
+**483 ERR_CANTKILLSERVER**
+```
+":You can't kill a server!"
+```
+
+- Any attempts to use the KILL command on a server are to be refused and this error returned directly to the client.
+
+**484 ERR_RESTRICTED**
+```
+":Your connection is restricted!"
+```
+
+- Sent by the server to a user upon connection to indicate the restricted nature of the connection (user mode "+r").
+
+**485 ERR_UNIQOPPRIVSNEEDED**
+```
+":You're not the original channel operator"
+```
+
+- Any MODE requiring "channel creator" privileges MUST return this error if the client making the attempt is not a chanop on the specified channel.
+
+**491 ERR_NOOPERHOST**
+```
+":No O-lines for your host"
+```
+
+- If a client sends an OPER message and the server has not been configured to allow connections from the client's host as an operator, this error MUST be returned.
+
+**501 ERR_UMODEUNKNOWNFLAG**
+```
+":Unknown MODE flag"
+```
+
+- Returned by the server to indicate that a MODE message was sent with a nickname parameter and that the a mode flag sent was not recognized.
+
+**502 ERR_USERSDONTMATCH**
+```
+":Cannot change mode for other users"
+```
+
+- Error sent to any user trying to view or change the user mode for a user other than themselves.
+
+### 5.3 Reserved numerics
+
+These numerics are not described above since they fall into one of the following categories:
+
+1. no longer in use;
+2. reserved for future planned use;
+3. in current use but are part of a non-generic 'feature' of the current IRC server.
+
+```
+231    RPL_SERVICEINFO     232  RPL_ENDOFSERVICES
+233    RPL_SERVICE
+300    RPL_NONE            316  RPL_WHOISCHANOP
+361    RPL_KILLDONE        362  RPL_CLOSING
+363    RPL_CLOSEEND        373  RPL_INFOSTART
+384    RPL_MYPORTIS
+
+213    RPL_STATSCLINE      214  RPL_STATSNLINE
+215    RPL_STATSILINE      216  RPL_STATSKLINE
+217    RPL_STATSQLINE      218  RPL_STATSYLINE
+240    RPL_STATSVLINE      241  RPL_STATSLLINE
+244    RPL_STATSHLINE      244  RPL_STATSSLINE
+246    RPL_STATSPING       247  RPL_STATSBLINE
+250    RPL_STATSDLINE
+
+492    ERR_NOSERVICEHOST
+```
+
+
+## 6. Current implementations
+
+The IRC software, version 2.10 is the only complete implementation of the IRC protocol (client and server). Because of the small amount of changes in the client protocol since the publication of RFC 1459 [IRC], implementations that follow it are likely to be compliant with this protocol or to require a small amount of changes to reach compliance.
+
+## 7. Current problems
+
+There are a number of recognized problems with the IRC Client Protocol, and more generally with the IRC Server Protocol. In order to preserve backward compatibility with old clients, this protocol has almost not evolved since the publication of RFC 1459 [IRC].
+
+### 7.1 Nicknames
+
+The idea of the nickname on IRC is very convenient for users to use when talking to each other outside of a channel, but there is only a finite nickname space and being what they are, it's not uncommon for several people to want to use the same nick. If a nickname is chosen by two people using this protocol, either one will not succeed or both will removed by use of a server KILL (See Section 3.7.1).
+
+### 7.2 Limitation of wildcards
+
+There is no way to escape the escape character "\\" (%x5C). While this isn't usually a problem, it makes it impossible to form a mask with a backslash character ("\\") preceding a wildcard.
+
+### 7.3 Security considerations
+
+Security issues related to this protocol are discussed in the "IRC Server Protocol" [IRC-SERVER] as they are mostly an issue for the server side of the connection.
+
+## 8. Current support and availability
+
+**Mailing lists for IRC related discussion:**
+- General discussion: ircd-users@irc.org
+- Protocol development: ircd-dev@irc.org
+
+**Software implementations:**
+- ftp://ftp.irc.org/irc/server
+- ftp://ftp.funet.fi/pub/unix/irc
+- ftp://ftp.irc.org/irc/clients
+
+**Newsgroup:** alt.irc
+
+## 9. Acknowledgements
+
+Parts of this document were copied from the RFC 1459 [IRC] which first formally documented the IRC Protocol. It has also benefited from many rounds of review and comments. In particular, the following people have made significant contributions to this document:
+
+Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
+
+## 10. References
+
+**[KEYWORDS]** Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+**[ABNF]** Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
+
+**[HNAME]** Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
+
+**[IRC]** Oikarinen, J. & D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
+
+**[IRC-ARCH]** Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
+
+**[IRC-CHAN]** Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
+
+**[IRC-SERVER]** Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
+
+## 11. Author's Address
+
+Christophe Kalt  
+99 Teaneck Rd, Apt #117  
+Ridgefield Park, NJ 07660  
+USA
+
+EMail: kalt@stealth.net
+
+## 12. Full Copyright Statement
+
+Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+### Acknowledgement
+
+Funding for the RFC Editor function is currently provided by the Internet Society.
diff --git a/wiki/RFC2813.md b/wiki/RFC2813.md
new file mode 100644
index 0000000..b490149
--- /dev/null
+++ b/wiki/RFC2813.md
@@ -0,0 +1,627 @@
+# RFC 2813 - Internet Relay Chat: Server Protocol
+
+**Network Working Group:** C. Kalt  
+**Request for Comments:** 2813  
+**Updates:** 1459  
+**Category:** Informational  
+**Date:** April 2000
+
+## Status of this Memo
+
+This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
+
+## Copyright Notice
+
+Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+## Abstract
+
+While based on the client-server model, the IRC (Internet Relay Chat) protocol allows servers to connect to each other effectively forming a network.
+
+This document defines the protocol used by servers to talk to each other. It was originally a superset of the client protocol but has evolved differently.
+
+First formally documented in May 1993 as part of RFC 1459 [IRC], most of the changes brought since then can be found in this document as development was focused on making the protocol scale better. Better scalability has allowed existing world-wide networks to keep growing and reach sizes which defy the old specification.
+
+## Table of Contents
+
+- [1. Introduction](#1-introduction)
+- [2. Global database](#2-global-database)
+  - [2.1 Servers](#21-servers)
+  - [2.2 Clients](#22-clients)
+    - [2.2.1 Users](#221-users)
+    - [2.2.2 Services](#222-services)
+  - [2.3 Channels](#23-channels)
+- [3. The IRC Server Specification](#3-the-irc-server-specification)
+  - [3.1 Overview](#31-overview)
+  - [3.2 Character codes](#32-character-codes)
+  - [3.3 Messages](#33-messages)
+    - [3.3.1 Message format in Augmented BNF](#331-message-format-in-augmented-bnf)
+  - [3.4 Numeric replies](#34-numeric-replies)
+- [4. Message Details](#4-message-details)
+  - [4.1 Connection Registration](#41-connection-registration)
+    - [4.1.1 Password message](#411-password-message)
+    - [4.1.2 Server message](#412-server-message)
+    - [4.1.3 Nick](#413-nick)
+    - [4.1.4 Service message](#414-service-message)
+    - [4.1.5 Quit](#415-quit)
+    - [4.1.6 Server quit message](#416-server-quit-message)
+  - [4.2 Channel operations](#42-channel-operations)
+    - [4.2.1 Join message](#421-join-message)
+    - [4.2.2 Njoin message](#422-njoin-message)
+    - [4.2.3 Mode message](#423-mode-message)
+- [5. Implementation details](#5-implementation-details)
+  - [5.1 Connection 'Liveness'](#51-connection-liveness)
+  - [5.2 Accepting a client to server connection](#52-accepting-a-client-to-server-connection)
+    - [5.2.1 Users](#521-users)
+    - [5.2.2 Services](#522-services)
+  - [5.3 Establishing a server-server connection](#53-establishing-a-server-server-connection)
+    - [5.3.1 Link options](#531-link-options)
+      - [5.3.1.1 Compressed server to server links](#5311-compressed-server-to-server-links)
+      - [5.3.1.2 Anti abuse protections](#5312-anti-abuse-protections)
+    - [5.3.2 State information exchange when connecting](#532-state-information-exchange-when-connecting)
+  - [5.4 Terminating server-client connections](#54-terminating-server-client-connections)
+  - [5.5 Terminating server-server connections](#55-terminating-server-server-connections)
+  - [5.6 Tracking nickname changes](#56-tracking-nickname-changes)
+  - [5.7 Tracking recently used nicknames](#57-tracking-recently-used-nicknames)
+  - [5.8 Flood control of clients](#58-flood-control-of-clients)
+  - [5.9 Non blocking lookups](#59-non-blocking-lookups)
+    - [5.9.1 Hostname (DNS) lookups](#591-hostname-dns-lookups)
+    - [5.9.2 Username (Ident) lookups](#592-username-ident-lookups)
+  - [5.10 Configuration File](#510-configuration-file)
+  - [5.11 Channel Membership](#511-channel-membership)
+- [6. Current problems](#6-current-problems)
+  - [6.1 Scalability](#61-scalability)
+  - [6.2 Labels](#62-labels)
+    - [6.2.1 Nicknames](#621-nicknames)
+    - [6.2.2 Channels](#622-channels)
+    - [6.2.3 Servers](#623-servers)
+  - [6.3 Algorithms](#63-algorithms)
+- [7. Security Considerations](#7-security-considerations)
+  - [7.1 Authentication](#71-authentication)
+  - [7.2 Connection Hijacking](#72-connection-hijacking)
+  - [7.3 Denial of Service](#73-denial-of-service)
+  - [7.4 Channel Takeover](#74-channel-takeover)
+- [8. Current support and availability](#8-current-support-and-availability)
+- [9. Acknowledgements](#9-acknowledgements)
+- [10. References](#10-references)
+- [11. Author's Address](#11-authors-address)
+- [12. Full Copyright Statement](#12-full-copyright-statement)
+
+
+## 1. Introduction
+
+The IRC protocol was developed since 1989. Although it has remained mostly compatible with the 2.10 implementation, some issues had to be addressed in order to let the protocol scale properly. This document aims at providing a reference for the server to server protocol of the current implementation. Changes to the client to server protocol are minor.
+
+This document is mainly intended for server implementors.
+
+The IRC (Internet Relay Chat) protocol has been designed over a number of years, with multitudinous implementations and increasing complexity. While based on a client-server model, there are a vast number of design decisions and implementation choices that determine the overall behavior and scalability of any given IRC network.
+
+RFC 1459 [IRC] has been the sole formal specification of IRC protocol for many years. As implementations evolved, it was shown that the protocol described in RFC 1459 has serious weaknesses and deficiencies. This document attempts to provide documentation for the working protocol used by the majority of IRC servers connected to what is sometimes referred to as the "IRC network".
+
+## 2. Global database
+
+IRC servers SHALL maintain the following database about the state of the whole network:
+- a list of all servers;
+- a list of all users;
+- a list of all channels.
+
+Each server MUST keep the database synchronized with the rest of the network. It is important to note here that the messages used to maintain the database synchronized are ONLY passed server-to-server.
+
+### 2.1 Servers
+
+Each server MUST know about all other servers on the network.  Each server is identified by its name which has a maximum length of sixty three (63) characters. It is RECOMMENDED that the server name be chosen as the DNS name of the host on which the server runs.
+
+### 2.2 Clients
+
+For each client, servers MUST keep the following information:
+- a nickname (See "IRC Client Protocol" [IRC-CLIENT]);
+- a username (as provided by the USER command) (See [IRC-CLIENT]);
+- a hostname (as determined by the server);
+- a servername (which server the client is connected to);
+- the realname or "GECOS" (as provided by USER command) (See [IRC-CLIENT]);
+- any user modes (defined in [IRC-CLIENT]).
+
+#### 2.2.1 Users
+
+Users are clients which have registered with the server. They are distinguished from other connections which have not successfully registered (such as clients still performing authentication).
+
+#### 2.2.2 Services
+
+Services are special kind of clients. They are introduced to the network and can send messages. However, they MUST NOT be the target of commands sent by users (such as MODE, KICK, etc.).
+
+### 2.3 Channels
+
+Channels are groups of one or more clients. Messages sent to a channel are received by all clients which are members of that channel.
+
+Details on channels are covered in "Internet Relay Chat: Channel Management" [IRC-CHAN].
+
+For each channel, the server MUST keep the following information:
+- the channel name;
+- the current members;
+- the channel modes.
+
+It is to be noted here that various servers MAY store additional (local) state information for each channel, such as local bans, local exceptions, etc.
+
+## 3. The IRC Server Specification
+
+### 3.1 Overview
+
+The protocol as described herein is for use with server to server connections.
+
+### 3.2 Character codes
+
+No specific character set is specified. The protocol is based on a set of codes which are composed of eight (8) bits, making up an octet. Each message may be composed of any number of these octets; however, some octet values are used for control codes, which act as message delimiters.
+
+Regardless of being an 8-bit protocol, the delimiters and keywords are such that protocol is mostly usable from US-ASCII terminal and a telnet connection.
+
+Because of IRC's Scandinavian origin, the characters `{}|^` are considered to be the lower case equivalents of the characters `[]\~`, respectively. This is a critical issue when determining the equivalence of two nicknames or channel names.
+
+### 3.3 Messages
+
+Servers and clients send each other messages, which may or may not generate a reply. If the message contains a valid command, as described in later sections, the client should expect a reply as specified but it is not advised to wait forever for the reply; client to server and server to server communication is essentially asynchronous by nature.
+
+Each IRC message may consist of up to three main parts: the prefix (OPTIONAL), the command, and the command parameters (maximum of fifteen (15)). The prefix, command, and all parameters are separated by one ASCII space character (0x20) each.
+
+The presence of a prefix is indicated with a single leading ASCII colon character (':', 0x3b), which MUST be the first character of the message itself. There MUST be NO gap (whitespace) between the colon and the prefix. The prefix is used by servers to indicate the true origin of the message.
+
+The command MUST either be a valid IRC command or a three (3) digit number represented in ASCII text.
+
+IRC messages are always lines of characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and these messages SHALL NOT exceed 512 characters in length, counting all characters including the trailing CR-LF. Thus, there are 510 characters maximum allowed for the command and its parameters. There is no provision for continuation of message lines.
+
+#### 3.3.1 Message format in Augmented BNF
+
+The protocol messages must be extracted from the contiguous stream of octets. The current solution is to designate two characters, CR and LF, as message separators. Empty messages are silently ignored, which permits use of the sequence CR-LF between messages without extra problems.
+
+The extracted message is parsed into the components <prefix>, <command> and list of parameters (<params>).
+
+The Augmented BNF representation for this is found in [IRC-CLIENT]. In addition to the client to server messages, the following messages are available for server to server communication.
+
+### 3.4 Numeric replies
+
+Most of the messages sent to the server generate a reply of some sort. The most common reply is the numeric reply, used for both errors and normal replies. Refer to [IRC-CLIENT] for more information on numeric replies.
+
+## 4. Message Details
+
+On the following pages are descriptions of each server to server message recognized by the IRC server. Server to client messages are described in [IRC-CLIENT].
+
+Where the reply ERR_NOSUCHSERVER is returned, it means that the target of the message could not be found. The server MUST NOT send any other replies after this error for that command.
+
+### 4.1 Connection Registration
+
+The commands described here are used to register a connection with another IRC server.
+
+#### 4.1.1 Password message
+
+**Command:** PASS  
+**Parameters:** <password> <version> <flags> [<options>]
+
+The PASS command is used to set a 'connection password'. The password supplied MUST match the one contained in the C/N lines (for servers) or I lines (for clients). It is possible to send multiple PASS commands before registering but only the last one sent is used for verification and it may not be changed once registered.
+
+The <version> parameter consists of two substrings separated by one (1) dot ('.'), the leftmost being the generation and the rightmost being the server version number.
+
+The optional <flags> parameter is a string of characters representing server flags (see below).
+
+The optional <options> parameter is a list of space separated string options.
+
+**Numeric Replies:** ERR_NEEDMOREPARAMS, ERR_ALREADYREGISTRED
+
+**Example:**
+
+```
+PASS secretpasswordhere 0210 IRC|aBgH
+```
+
+#### 4.1.2 Server message
+
+**Command:** SERVER  
+**Parameters:** <servername> <hopcount> <info>
+
+The SERVER message is used to tell a server that the other end of a new connection is a server. This message is also used to pass server data over whole net.
+
+When a new server connection is established, each side sends SERVER and PASS messages to the other side. The SERVER message carries information about the sending server. If the information is acceptable, the other side responds with its own SERVER and PASS messages otherwise it should close the connection.
+
+When the SERVER command is received, a server SHOULD check that it is authenticated. This can be done various ways, the most common being:
+- the hostname of the server matches the server's host configuration;
+- the password provided by the server with the PASS command matches the expected password.
+
+The <hopcount> parameter is used by servers to indicate how far away the introduced server is. When sending SERVER, servers MUST set the <hopcount> to 1. When relaying SERVER, servers MUST increment the <hopcount> by 1.
+
+The <info> parameter contains information about the server, and is displayed by various commands. It may include network name, city, owner, etc.
+
+**Numeric Replies:**
+- ERR_ALREADYREGISTRED
+
+**Example:**
+
+```
+SERVER tolsun.oulu.fi 1 :Experimental server
+
+:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
+```
+
+#### 4.1.3 Nick
+
+**Command:** NICK  
+**Parameters:** <nickname> <hopcount> <username> <host> <servertoken> <umode> <realname>
+
+The NICK message is used by servers to inform other servers about new users. This is also how servers transmit nickname changes.
+
+The NICK message MUST be sent to all servers that need to know about the user. Each parameter has the same meaning as in the USER and MODE commands (See [IRC-CLIENT]).
+
+For newly introduced clients, the <hopcount> SHALL be set to 1. When propagating NICK to other servers, <hopcount> MUST be incremented by 1 for each hop.
+
+**Numeric Replies:** None for servers
+
+**Example:**
+
+```
+:csd.bu.edu NICK WiZ 7 ~john csd.bu.edu 1 +i :John Doe
+
+NICK syrk 1 kalt millennium.stealth.net tolsun.oulu.fi 0 :Christophe Kalt
+```
+
+#### 4.1.4 Service message
+
+**Command:** SERVICE  
+**Parameters:** <servicename> <servertoken> <distribution> <type> <hopcount> <info>
+
+The SERVICE command is used by servers to introduce a service to the rest of the network. The meaning of the parameters is the same as in the SERVICE client command (See [IRC-CLIENT]).
+
+**Numeric Replies:** None for servers
+
+**Example:**
+
+```
+SERVICE dict * *.fr 0 0 :French Dictionary
+```
+
+#### 4.1.5 Quit
+
+**Command:** QUIT  
+**Parameters:** <comment>
+
+A client session is ended with a quit message. The server MUST send the quit message to all servers to which it is directly connected, which then MUST broadcast it to all clients which have common channels with the quitting client.
+
+When a server connection is closed, a QUIT message is generated for each client connected only to that server.
+
+**Numeric Replies:** None
+
+**Example:**
+
+```
+:WiZ QUIT :Gone to have lunch
+
+:tolsun.oulu.fi QUIT :Bad link
+```
+
+#### 4.1.6 Server quit message
+
+**Command:** SQUIT  
+**Parameters:** <server> <comment>
+
+The SQUIT message is needed to tell about quitting or dead servers. If a server wishes to break the connection to another server it MUST send a SQUIT message to the other server, using the name of the other server as the server parameter.
+
+When a server link is closed, a SQUIT message is broadcast to the network. Each server that receives it removes from its database all servers and users that were connected through the server that was removed from the network.
+
+**Numeric Replies:** None for servers
+
+**Example:**
+
+```
+SQUIT tolsun.oulu.fi :Bad Link
+
+:csd.bu.edu SQUIT bar.foo.com :Link inactive
+```
+
+### 4.2 Channel operations
+
+These messages are used by servers to distribute channel information.
+
+#### 4.2.1 Join message
+
+**Command:** JOIN  
+**Parameters:** <channel>
+
+The JOIN command is used by servers to tell other servers that a user is now a member of a particular channel. When a user joins a channel, the server generates a JOIN message for that channel and sends it to all servers.
+
+**Numeric Replies:** None for servers
+
+**Example:**
+
+```
+:WiZ JOIN #Twilight_zone
+```
+
+#### 4.2.2 Njoin message
+
+**Command:** NJOIN  
+**Parameters:** <channel> <nicknames>
+
+The NJOIN message is used between servers only. It is used to efficiently distribute a whole list of users that have joined a channel (for example, after a netjoin) instead of a series of JOIN messages.
+
+The <nicknames> parameter is a list of nicknames, with their channel status indicated by a prefix character. The characters are:
+- `@` indicates channel operator status;
+- `+` indicates voice privilege;
+- No prefix indicates normal channel member.
+
+**Numeric Replies:** None for servers
+
+**Example:**
+
+```
+:services.fr NJOIN #welcome :@WiZ,+guest,user1,user2
+
+NJOIN #test :@Alice,+Bob,Charlie
+```
+
+#### 4.2.3 Mode message
+
+**Command:** MODE  
+**Parameters:** <channel/nick> <mode> [<mode parameters>]
+
+The MODE command is a dual-purpose command in IRC. It allows both channel modes and user modes to be changed. When used with a channel name, it changes channel modes; when used with a nickname, it changes user modes.
+
+MODE messages between servers are used to distribute channel and user mode changes throughout the network.
+
+**Numeric Replies:** None for servers
+
+**Example:**
+
+```
+:WiZ MODE #Fins +o Kilroy
+
+:csd.bu.edu MODE WiZ +iw
+
+:WiZ MODE #eu-opers +l 10
+```
+
+## 5. Implementation details
+
+This section deals with the various implementation problems and choices for IRC servers.
+
+### 5.1 Connection 'Liveness'
+
+It is important for servers to be able to check if the other end of the connection is alive. For this purpose, the server SHALL send PING messages at regular intervals (typical value is 90 seconds) to all of its neighbors. Every connection which has not shown any activity (i.e., neither sending nor receiving any data) for 2*ping_frequency MUST be dropped.
+
+When a server receives a PING message, it MUST reply with an appropriate PONG message.
+
+### 5.2 Accepting a client to server connection
+
+When a new client connects to a server, the server SHALL begin the authentication process to verify whether the connection is from a legitimate user or from another server.
+
+#### 5.2.1 Users
+
+For a connection to be accepted as a user connection, it MUST provide a password (if required) and complete the registration sequence with USER and NICK commands. The server SHOULD also perform hostname and ident lookups.
+
+#### 5.2.2 Services
+
+Services are a special type of client. They are introduced to the network and can send messages. They have limited interaction with normal users and channels. The SERVICE command is used to register a service.
+
+### 5.3 Establishing a server-server connection
+
+When two servers connect, they MUST exchange PASS and SERVER messages. A server SHOULD NOT send any other information until this is done.
+
+#### 5.3.1 Link options
+
+##### 5.3.1.1 Compressed server to server links
+
+To reduce the amount of bandwidth used by server to server links, servers MAY compress the data stream. This is typically implemented using the zlib compression library.
+
+##### 5.3.1.2 Anti abuse protections
+
+Servers MAY implement various anti-abuse protections to limit the impact of abusive servers on the network. This can include rate limiting, filtering, etc.
+
+#### 5.3.2 State information exchange when connecting
+
+When a new server-to-server connection is established, each side must inform the other about the state of the network as it sees it. This is done by sending:
+- SERVER messages for all known servers;
+- NICK messages for all known users;
+- SERVICE messages for all known services;
+- Information about channel states.
+
+### 5.4 Terminating server-client connections
+
+When terminating a server-client connection, the server MUST send a QUIT message for that client to all servers, which will in turn propagate it to their clients that shared channels with the quitting client.
+
+### 5.5 Terminating server-server connections
+
+When a server connection is terminated, the server MUST send a SQUIT message for the removed server to all its neighbors. Those servers will then remove from their database all servers and clients that were connected through the broken link.
+
+### 5.6 Tracking nickname changes
+
+When a client changes nickname, the server MUST send a NICK message to all other servers. This ensures that the nickname change is propagated throughout the network and that all servers update their database.
+
+### 5.7 Tracking recently used nicknames
+
+To prevent nickname collisions and abuse, servers SHOULD keep track of recently used nicknames and make them unavailable for a short period after they are released. This is particularly important after a netspli
+
+t where multiple users might try to grab the same nickname.
+
+### 5.8 Flood control of clients
+
+Servers SHOULD implement flood protection to prevent clients from sending too many commands too quickly. This helps protect the server and network from abuse.
+
+Typical implementations use a "token bucket" algorithm or similar approach to rate-limit commands from clients.
+
+### 5.9 Non blocking lookups
+
+To avoid blocking the server while performing hostname and ident lookups, these lookups SHOULD be performed asynchronously.
+
+#### 5.9.1 Hostname (DNS) lookups
+
+When a client connects, the server SHOULD perform a DNS lookup on the client's IP address to determine the hostname. This lookup SHOULD be done asynchronously to avoid blocking the server.
+
+#### 5.9.2 Username (Ident) lookups
+
+In addition to DNS lookups, servers MAY perform ident lookups (RFC 1413) to verify the username of connecting clients. Like DNS lookups, these SHOULD be done asynchronously.
+
+### 5.10 Configuration File
+
+Servers typically use configuration files to determine:
+- What servers they are allowed to connect to;
+- What clients are allowed to connect;
+- Operator passwords;
+- Connection classes and limits;
+- Channel and user modes available;
+- etc.
+
+The exact format and options of configuration files are implementation-specific.
+
+### 5.11 Channel Membership
+
+Servers MUST track which clients are members of which channels. This information is essential for:
+- Distributing channel messages to the correct recipients;
+- Enforcing channel modes;
+- Handling channel operations like kicks and bans.
+
+
+## 6. Current problems
+
+There are a number of recognized problems with the IRC Server Protocol, this section addresses the problems related to the architecture of the protocol.
+
+### 6.1 Scalability
+
+It is widely recognized that this protocol does not scale sufficiently well when used in a large arena. The main problem comes from the requirement that all servers know about all other servers, clients and channels and that information regarding them be updated as soon as it changes.
+
+While this issue is also present in the architecture (See [IRC-ARCH]), it is compounded by the protocol itself which doesn't provide for more sophisticated routing. Servers need to broadcast most messages to all other servers.
+
+### 6.2 Labels
+
+#### 6.2.1 Nicknames
+
+The issue of nicknames is discussed in [IRC-CLIENT].
+
+With the current protocol, it is possible for two clients to pick the same nickname at the same time on different servers (nick collision). The protocol provides a way to detect and solve such conflicts but it remains a problem.
+
+While the protocol allows for collision detection and resolution through KILL messages, this mechanism has serious weaknesses and deficiencies.
+
+#### 6.2.2 Channels
+
+Channel names suffer from the same issue as nicknames. When two channels with the same name are created on different servers (channel collision), the protocol has to deal with merging them.
+
+The current protocol handles channel collisions as inclusive events: all users from both channels become members of the resulting channel. This can lead to various problems, especially with channel modes and privileges.
+
+#### 6.2.3 Servers
+
+Server names are currently required to be unique across the entire network. While this is generally not a problem (as server names typically use DNS hostnames), it can become an issue when servers need to be renamed or when experimental servers are connected.
+
+The protocol does not provide any mechanism to handle server name collisions; a server is expected to disconnect if it detects a name collision.
+
+### 6.3 Algorithms
+
+The core routing algorithm is simple: most messages are broadcast to all servers. While this ensures that all servers receive all updates, it has severe scalability limitations.
+
+More sophisticated routing algorithms would be required to scale to larger networks, but implementing such algorithms while maintaining backward compatibility is extremely difficult.
+
+## 7. Security Considerations
+
+### 7.1 Authentication
+
+Server to server connections rely on a simple password authentication mechanism. This is vulnerable to various attacks:
+- Passwords are often transmitted in clear text;
+- There is no protection against replay attacks;
+- Compromised passwords grant full access to the network.
+
+More sophisticated authentication mechanisms (such as public key cryptography) would provide better security.
+
+### 7.2 Connection Hijacking
+
+The protocol does not provide any protection against connection hijacking. If an attacker can inject or modify packets in a server-to-server connection, they can:
+- Introduce fake servers, clients, or services;
+- Modify channel modes and privileges;
+- Send messages on behalf of other users.
+
+Using encrypted connections (such as TLS/SSL) would help mitigate this risk.
+
+### 7.3 Denial of Service
+
+The IRC protocol is vulnerable to various denial of service attacks:
+
+**Message Flooding:** An attacker can flood a server with messages, consuming bandwidth and CPU resources.
+
+**Split Attacks:** By causing network splits (disconnecting servers), an attacker can:
+- Create nickname collisions;
+- Take over channels;
+- Disrupt service.
+
+**Resource Exhaustion:** Attackers can attempt to exhaust server resources by:
+- Creating many channels;
+- Joining many channels;
+- Setting many channel modes;
+- etc.
+
+Servers SHOULD implement various protections against these attacks, such as:
+- Rate limiting;
+- Connection limits;
+- Flood protection;
+- Resource limits.
+
+### 7.4 Channel Takeover
+
+Because channel collisions are treated as inclusive events (all users from both channels are merged), it is possible for malicious users to "take over" channels by:
+- Causing a network split;
+- Creating a channel with the same name on the split network;
+- Gaining operator privileges;
+- Waiting for the network to rejoin.
+
+When the networks rejoin, the malicious users will become part of the original channel, potentially with operator privileges. Various mechanisms have been proposed to address this issue:
+- Channel delay (See [IRC-CHAN]);
+- "Safe" channels (See [IRC-CHAN]);
+- Channel timestamps;
+- etc.
+
+However, each mechanism has its own limitations and none completely solve the problem.
+
+## 8. Current support and availability
+
+**Mailing lists for IRC related discussion:**
+- General discussion: ircd-users@irc.org
+- Protocol development: ircd-dev@irc.org
+
+**Software implementations:**
+- ftp://ftp.irc.org/irc/server
+- ftp://ftp.funet.fi/pub/unix/irc
+- ftp://coombs.anu.edu.au/pub/irc
+
+**Newsgroup:** alt.irc
+
+## 9. Acknowledgements
+
+Parts of this document were copied from the RFC 1459 [IRC] which first formally documented the IRC Protocol. It has also benefited from many rounds of review and comments. In particular, the following people have made significant contributions to this document:
+
+Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
+
+## 10. References
+
+**[KEYWORDS]** Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+**[IRC]** Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
+
+**[IRC-ARCH]** Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
+
+**[IRC-CLIENT]** Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.
+
+**[IRC-CHAN]** Kalt, C., "Internet Relay Chat: Channel Management", RFC 2811, April 2000.
+
+## 11. Author's Address
+
+Christophe Kalt  
+99 Teaneck Rd, Apt #117  
+Ridgefield Park, NJ 07660  
+USA
+
+EMail: kalt@stealth.net
+
+## 12. Full Copyright Statement
+
+Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+### Acknowledgement
+
+Funding for the RFC Editor function is currently provided by the Internet Society.
diff --git a/wiki/SNOMASKS.md b/wiki/SNOMASKS.md
new file mode 100644
index 0000000..9232cf8
--- /dev/null
+++ b/wiki/SNOMASKS.md
@@ -0,0 +1,38 @@
+# SNOMASKS
+
+#### Usage:
+
+```
+/mode YourNick +s [+|-]<SNOMASK>
+```
+
+#### Examples:
+
+```
+/mode acidvegas +s +cCfoS
+/mode acidvegas +s -k
+```
+
+---
+
+| Mode  | Description                                               |
+|-------|-----------------------------------------------------------|
+| **b** | Server bans                                               |
+| **B** | DNSBL hits                                                |
+| **c** | Local connections                                         |
+| **C** | Remote connections                                        |
+| **d** | Rejected `/DCC`                                           |
+| **D** | Debugging *(noisy)*                                       |
+| **f** | Flood blocks                                              |
+| **j** | `/JOIN`, `/PART`, & `/KICK`                               |
+| **k** | `/KILL`                                                   |
+| **n** | Local `/NICK`                                             |
+| **N** | Remote `/NICK`                                            |
+| **o** | IRCOp overriding channels                                 |
+| **O** | `/CHGNAME`, `/CHGIDENT`, `/CHGHOST`, `/SAJOIN`, `/SAPART` |
+| **q** | `/QLINE` rejections                                       |
+| **r** | SPAMREPORT and Spamreport block usage notices             |
+| **R** | JSON-RPC                                                  |
+| **s** | Server notices                                            |
+| **S** | `/SPAMFILTER` hits                                        |
+| **v** | `/VHOST` usage                                            |
\ No newline at end of file
diff --git a/wiki/USER-MODES.md b/wiki/USER-MODES.md
new file mode 100644
index 0000000..2a068c1
--- /dev/null
+++ b/wiki/USER-MODES.md
@@ -0,0 +1,42 @@
+# USER MODES
+
+#### Usage:
+
+```
+/mode YourNick [+|-]<MODE>
+```
+
+#### Examples:
+
+```
+/mode acidvegas -x
+/mode acidvegas +Z
+```
+
+---
+
+#### Key
+
+`✅ = Set by default ` `🔒 = Can not be turned off`
+
+|    | Mode  | Name       | Description                                                                   | Restriction |
+|----|-------|------------|-------------------------------------------------------------------------------|-------------|
+|    | **B** | Bot        | Marked as a bot in `/WHOIS`                                                   |             |
+|    | **d** | Deaf       | Can only see messages prefixed with `!@$.` *(used by bots to reduce traffic)* |             |
+|    | **D** | Privdeaf   | Block private messages from everyone                                          |             |
+|    | **G** | Censor     | Enable word filters                                                           |             |
+| ✅ | **H** | Hidden     | Hide operator status in `/WHOIS`                                              | *Oper*      |
+| 🔒 | **i** | Invisible  | Hidden in `/WHO` & `/NAMES` from outsiders                                    |             |
+| ✅ | **I** | Idle       | Hide idle time in `/WHOIS`                                                    |             |
+|    | **o** | Operator   | Marked as an operator                                                         | *Server*    |
+| 🔒 | **p** | Privacy    | Hide channels in `/WHOIS`                                                     |             |
+| ✅ | **q** | Unkickable | Unkickable                                                                    | *Oper*      |
+|    | **r** | Registered | Marked as a registered user                                                   | *Services*  |
+|    | **R** | Regonly    | Block private messages from unregistered users                                |             |
+|    | **s** | Snomask    | Server notices                                                                | *Oper*      |
+|    | **S** | Servicebot | Marked as a services bot                                                      | *Services*  |
+|    | **t** | Vhost      | Marked as using a `/VHOST`                                                    | *Server*    |
+| ✅ | **T** | NoCTCP     | Prevent CTCP                                                                  |             |
+| ✅ | **x** | Cloak      | Hide your hostmask                                                            |             |
+|    | **z** | SSL        | Marked as connected via SSL/TLS                                               | *Server*    |
+|    | **Z** | Secureonly | Block private message from anyone not using TLS                               |             |
\ No newline at end of file
diff --git a/wiki/USERS.md b/wiki/USERS.md
new file mode 100644
index 0000000..fe4d5d3
--- /dev/null
+++ b/wiki/USERS.md
@@ -0,0 +1 @@
+Coming soon
\ No newline at end of file
diff --git a/wiki/_Footer.md b/wiki/_Footer.md
new file mode 100644
index 0000000..a2f1d8c
--- /dev/null
+++ b/wiki/_Footer.md
@@ -0,0 +1 @@
+© SuperNETs 2026
\ No newline at end of file
diff --git a/wiki/_Sidebar.md b/wiki/_Sidebar.md
new file mode 100644
index 0000000..142f130
--- /dev/null
+++ b/wiki/_Sidebar.md
@@ -0,0 +1,14 @@
+###### IRC
+- [ASCII/ANSI Art](ASCII)
+- [Ban Policy](./BAN-POLICY)
+- [Bots](./BOTS)
+- [Channels](./CHANNELS)
+- [Clients](./CLIENTS)
+- [Commands](./COMMANDS)
+- [Modes](./MODES)
+- [RFC](./RFC)
+- [SASL](./SASL)
+- [Services](./SERVICES)
+
+###### Lore
+- [Users](./USERS)
\ No newline at end of file