doc/Commands.txt

   1
   2                      ngIRCd - Next Generation IRC Server
   3                            http://ngircd.barton.de/
   4
   5                (c)2001-2019 Alexander Barton and Contributors.
   6                ngIRCd is free software and published under the
   7                    terms of the GNU General Public License.
   8
   9                               -- Commands.txt --
  10
  11
  12 This file lists all commands available on ngIRCd. It is written in a format
  13 that is human readable as well as machine parseable and therefore can be used
  14 as "help text file" of the daemon.
  15
  16 In short, the daemon reads this file on startup and parses it as following
  17 when an user issues a "HELP <cmd>" command:
  18
  19  1. Search the file for a line "- <cmd>",
  20  2. Output all subsequent lines that start with a TAB (ASCII 9) character
  21     to the client using NOTICE commands, treat lines containing a single "."
  22     after the TAB as empty lines.
  23  3. Break at the first line not starting with a TAB character.
  24
  25 This format allows to have information to each command stored in this file
  26 which will not be sent to an IRC user requesting help which enables us to
  27 have additional annotations stored here which further describe the origin,
  28 implementation details, or limits of the specific command which are not
  29 relevant to an end-user but administrators and developers.
  30
  31 A special "Intro" block is returned to the user when the HELP command is
  32 used without a command name:
  33
  34
  35 - Intro
  36         This is ngIRCd, a server software for Internet Relay Chat (IRC)
  37         networks. You can find more information about ngIRCd on its homepage:
  38                 <http://ngircd.barton.de>
  39         .
  40         Use "HELP COMMANDS" to get a list of all available commands and
  41         "HELP <command-name>" to get help for a specific IRC command, for
  42         example "HELP quit" or "HELP privmsg".
  43
  44
  45 Connection Handling Commands
  46 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  47
  48 - CAP
  49         CAP LS
  50         CAP LIST
  51         CAP REQ <capabilities>
  52         CAP ACK <capabilities>
  53         CAP NAK <capabilities>
  54         CAP CLEAR
  55         CAP END
  56         .
  57         List, request, and clear "IRC Capabilities".
  58         .
  59         Using this command, an IRC client can request additional "IRC
  60         capabilities" during login or later on, which influences the
  61         communication between server and client. Normally, these commands
  62         aren't directly used by humans, but automatically by their client
  63         software. And please note that issuing such commands manually can
  64         irritate the client software used, because of the "non-standard"
  65         behavior of the server!
  66         .
  67         - CAP LS: list all available capabilities.
  68         - CAP LIST: list active capabilities of this connection.
  69         - CAP REQ: Request particular capabilities.
  70         - CAP ACK: Acknowledge a set of capabilities to be enabled/disabled.
  71         - CAP NAK: Reject a set of capabilities.
  72         - CAP CLEAR: Clear all set capabilities.
  73         - CAP END: Indicate end of capability negotiation during login,
  74           ignored in an fully registered session.
  75
  76         Please note that the <capabilities> must be given in a single
  77         parameter but whitespace separated, therefore a command could look
  78         like this: "CAP REQ :capability1 capability2 capability3" for example.
  79
  80         References:
  81          - <http://ircv3.net/specs/core/capability-negotiation-3.1.html>
  82          - <http://ngircd.barton.de/doc/Capabilities.txt>
  83          - doc/Capabilities.txt
  84
  85 - CHARCONV
  86         CHARCONV <client-charset>
  87         .
  88         Set client character set encoding to <client-charset>.
  89         .
  90         After receiving such a command, the server translates all message
  91         data received from the client using the set <client-charset> to the
  92         server encoding (UTF-8), and all message data which is to be sent to
  93         the client from the server encoding (UTF-8) to <client-charset>.
  94         .
  95         This enables older clients and clients using "strange" character sets
  96         to transparently participate in channels and direct messages to
  97         clients using UTF-8, which should be the default today.
  98
  99         References:
 100          - IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
 101          - IRC+, doc/Protocol.txt
 102
 103 - NICK
 104         NICK <nickname>
 105         NICK <nickname> [<hops>]
 106         NICK <nickname> <hops> <username> <host> <servertoken> <usermodes> <realname>
 107         .
 108         Set or change the <nickname> of a client (first form) and register
 109         remote clients (second and third form; servers only).
 110
 111         References:
 112          - RFC 1459, 4.1.2 "Nick message" (old client and server protocol)
 113          - RFC 2812, 3.1.2 "Nick message" (client protocol)
 114          - RFC 2813, 4.1.3 "Nick" (server protocol)
 115
 116 - PASS
 117         PASS <password>
 118         PASS <password> <version> <flags> [<options>]
 119         .
 120         Set a connection <password>. This command must be the first command
 121         sent to the server, even before the NICK/USER or SERVER commands.
 122         .
 123         The first form is used by user sessions or (old) RFC 1459 servers,
 124         the second form is used by RFC 2812 or IRC+ compliant servers and
 125         enables the server to indicate its version and supported protocol
 126         features.
 127
 128         References:
 129          - RFC 1459, 4.1.1 "Password message" (old client and server protocol)
 130          - RFC 2812, 3.1.1 "Password message" (client protocol)
 131          - RFC 2813, 4.1.1 "Password message" (server protocol)
 132          - IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
 133          - IRC+, doc/Protocol.txt
 134
 135 - PING
 136         PING <token> [<target>]
 137         .
 138         Tests the presence of a connection to a client or server.
 139         .
 140         If no <target> has been given, the local server is used. User clients
 141         can only use other servers as <target>, no user clients.
 142         .
 143         A PING message results in a PONG reply containing the <token>, which
 144         can be arbitrary text.
 145
 146         Please note:
 147         The RFCs state that the <token> parameter is used to specify the
 148         origin of the PING command when forwarded in the network, but this
 149         is not the case: the sender is specified using the prefix as usual,
 150         and the parameter is used to identify the PONG reply in practice.
 151
 152         References:
 153          - RFC 2812, 3.7.2 "Ping message"
 154
 155 - PONG
 156         PONG <target> [<token>]
 157         .
 158         Reply to a "PING" command, indicate that the connection is alive.
 159         .
 160         The <token> is the arbitrary text received in the "PING" command and
 161         can be used to identify the correct PONG sent as answer.
 162         .
 163         When the "PONG" command is received from a user session, the <target>
 164         parameter is ignored; otherwise the PONG is forwarded to this client.
 165
 166         References:
 167          - RFC 2812, 3.7.3 "Pong message"
 168
 169 - QUIT
 170         QUIT [<quit-message>]
 171         .
 172         Terminate a user session.
 173         .
 174         When received from a user, the server acknowledges this by sending
 175         an "ERROR" message back to the client and terminates the connection.
 176         .
 177         When a <quit-message> has been given, it is sent to all the channels
 178         that the client is a member of when leaving.
 179
 180         References:
 181          - RFC 2812, 3.1.7 "Quit"
 182          - RFC 2813, 4.1.5 "Quit"
 183
 184 - USER
 185         USER <username> <hostname> <unused> <realname>
 186         .
 187         Register (and authenticate) a new user session with a short <username>
 188         and a human-readable <realname>.
 189         .
 190         The parameter <hostname> is only used when received by an other server
 191         and ignored otherwise; and the parameter <unused> is always ignored.
 192         But both parameters are required on each invocation by the protocol
 193         and can be set to arbitrary characters/text when not used.
 194         .
 195         If <username> contains an "@" character, the full <username> is used
 196         for authentication, but only the first part up to this character is
 197         set as "user name" for this session.
 198
 199         References:
 200          - RFC 2812, 3.1.3 "User message"
 201
 202 - WEBIRC
 203         WEBIRC <password> <username> <hostname> <ip-address>
 204         .
 205         Allow Web-to-IRC gateway software (for example) to set the correct
 206         user name and host name of users instead of their own.
 207         .
 208         It must be the very first command sent to the server, even before
 209         USER and NICK commands!
 210         .
 211         The <password> must be set in the server configuration file to prevent
 212         unauthorized clients to fake their identity; it is an arbitrary string.
 213
 214         References:
 215          - IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
 216          - IRC+, doc/Protocol.txt
 217
 218
 219 General Commands
 220 ~~~~~~~~~~~~~~~~
 221
 222 - AWAY
 223         AWAY [<message>]
 224         .
 225         Provides the server with a message to automatically send in reply to a
 226         PRIVMSG directed at the user, but not to a channel they are on.
 227         .
 228         If <message> is omitted, the away status is removed.
 229
 230         References:
 231          - RFC 2812, 4.1 "Away"
 232
 233 - HELP
 234         HELP [<command>]
 235         .
 236         Show help information for a specific IRC <command>. The <command> name
 237         is case-insensitive.
 238         .
 239         Use the command "HELP Commands" to get a list of all available commands.
 240
 241         The HELP command isn't specified by any RFC but implemented by most
 242         daemons. If no help text could be read in, ngIRCd outputs a list of all
 243         implemented commands when receiving a plain "HELP" command as well as
 244         on "HELP Commands".
 245
 246         ngIRCd replies using "NOTICE" commands like ircd 2.10/2.11; other
 247         implementations are using numerics 704, 705, and 706.
 248
 249 - MODE
 250         MODE <nickname> [{+|-}<mode>[<mode>] [{+|-}<mode>[<mode>] [...]]]
 251         MODE <channel> [{+|-}<mode>[<mode>] [<arg> [<arg> [...]]] [{+|-}<mode>[<mode>] [<arg> [<arg> [...]]] [...]]]
 252         .
 253         Set and get user and channel modes.
 254         .
 255         When no mode parameters are given, the currently set user or channel
 256         modes are returned. Otherwise the modes are adjusted accordingly
 257         and the changes will be reported back to the client.
 258         .
 259         All user and channel "modes" are indicated by single case-sensitive
 260         characters.
 261         .
 262         Please note that a user can only get and set his own modes, and not
 263         all user "levels" are allowed to change all channel modes ...
 264         .
 265         The mode parameters can become quite complex, especially when dealing
 266         with channel modes that require additional arguments:
 267         .
 268           {+|-}<mode(s}>  -- set or unset one or more modes.
 269           +<mode(s)> -<mode(s)>  -- set some modes and unset others.
 270           +<modes> <arg1> <arg2>  -- set (at least) two modes with arguments.
 271         .
 272         Some examples:
 273         .
 274           MODE nick +i  -- set user to "invisible".
 275           MODE #chan +tn  -- set "topic lock" and "no external messages".
 276           MODE #chan -t +l 50  -- remove "topic lock", set "user limit" to 50.
 277           MODE #chan +ov nick1 nick2  -- set "channel op" and "voice" mode
 278                                          to nick1 and nick2 in channel #chan.
 279         .
 280         A complete list of all modes supported by ngIRCd can be found online
 281         here: <http://ngircd.barton.de/doc/Modes.txt>.
 282
 283         References:
 284          - RFC 2811, 4. "Channel Modes"
 285          - RFC 2812, 3.1.5 "User mode message"
 286          - RFC 2812, 3.2.3 "Channel mode message"
 287          - <http://ngircd.barton.de/doc/Modes.txt>
 288          - doc/Modes.txt
 289
 290 - NOTICE
 291         NOTICE <target>[,<target>[,...]] <message>
 292         .
 293         Send a <message> to a given <target>, which can be a user or a
 294         channel, but DON'T report any error.
 295         .
 296         The "NOTICE" command exactly behaves like the "PRIVMSG" command, but
 297         doesn't report any errors it encounters (like an unknown <target>).
 298         Please see the help text of the "PRIVMSG" command for a detailed
 299         description of the parameters!
 300
 301         References:
 302          - RFC 2812, 2.3.1 "Message format in Augmented BNF"
 303          - RFC 2812, 3.3 "Sending messages"
 304          - RFC 2812, 3.3.2 "Notice"
 305
 306 - PRIVMSG
 307         PRIVMSG <target>[,<target>[,...]] <message>
 308         .
 309         Send a <message> to a given <target>, which can be a user or a
 310         channel, and report all errors.
 311         .
 312         The <target> must follow one of these syntax variants:
 313         .
 314          - <nickname>
 315          - <channel>
 316          - <user>[%<host>]@<server>
 317          - <user>%<host>
 318          - <nickname>!<user>@<host>
 319         .
 320         If the <target> is a user, a private message is sent directly to this
 321         user; if it resolves to a channel name, a public message is sent
 322         to all the members of that channel.
 323         .
 324         In addition, IRC Ops can use these two forms to specify the <target>:
 325         .
 326          - #<hostmask>
 327          - $<servermask>
 328         .
 329         The <mask> can contain the wildcard characters "*" and "?", but must
 330         contain at least one dot (".") and no wildcard after the last one.
 331         Then, the <message> is sent to all users matching this <mask>.
 332         .
 333         All warnings and errors are reported back to the initiator using
 334         numeric status codes, which is the only difference to the "NOTICE"
 335         command, which doesn't report back any errors or warnings at all.
 336         .
 337         Please note that clients often use "MSG" as an alias to PRIVMSG, and
 338         a command "QUERY <nick> [<message>]" to initiate private chats. Both
 339         are command extensions of the client and never sent to the server.
 340
 341         References:
 342          - RFC 2812, 2.3.1 "Message format in Augmented BNF"
 343          - RFC 2812, 3.3 "Sending messages"
 344          - RFC 2812, 3.3.1 "Private messages"
 345
 346 Status and Informational Commands
 347 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 348
 349 - ADMIN
 350         ADMIN [<target>]
 351         .
 352         Show administrative information about an IRC server in the network.
 353         .
 354         <target> can be a server name, the nickname of a client connected to
 355         a specific server, or a mask matching a server name in the network.
 356         The server of the current connection is used when <target> is omitted.
 357
 358         References:
 359          - RFC 2812, 3.4.9 "Admin command"
 360
 361 - INFO
 362         INFO [<target>]
 363         .
 364         Show the version, birth & online time of an IRC server in the network.
 365         .
 366         <target> can be a server name, the nickname of a client connected to
 367         a specific server, or a mask matching a server name in the network.
 368         The server of the current connection is used when <target> is omitted.
 369
 370         References:
 371          - RFC 2812, 3.4.10 "Info command"
 372
 373 - ISON
 374         ISON <nickname> [<nickname> [...]]
 375         .
 376         Query online status of a list of nicknames. The server replies with
 377         a list only containing nicknames actually connected to a server in
 378         the network. If no nicknames of the given list are online, an empty
 379         list is returned to the client requesting the information.
 380
 381         Please note that "all" IRC daemons even parse separate nicknames in
 382         a single parameter (like ":nick1 nick2"), and therefore ngIRCd
 383         implements this behavior, too.
 384
 385         References:
 386          - RFC 2812, 4.9 "Ison message"
 387
 388 - LINKS
 389         LINKS [[<target>] <mask>]
 390         .
 391         List all servers currently registered in the network matching <mask>,
 392         or all servers if <mask> has been omitted, as seen by the server
 393         specified by <target> or the local server when <target> is omitted.
 394         .
 395         <target> can be a server name, the nickname of a client connected to
 396         a specific server, or a mask matching a server name in the network.
 397
 398         References:
 399          - RFC 2812, 3.4.5 "Links message"
 400
 401 - LUSERS
 402         LUSERS [<mask> [<target>]]
 403         .
 404         Return statistics about the number of clients (users, servers,
 405         services, ...) in the network as seen by the server <target>.
 406         .
 407         <target> can be a server name, the nickname of a client connected to
 408         a specific server, or a mask matching a server name in the network.
 409         The server of the current connection is used when <target> is omitted.
 410
 411         Please note that ngIRCd ignores the <mask> parameter entirely: it
 412         is not possible to get information for a part of the network only.
 413
 414         References:
 415          - RFC 2812, 3.4.2 "Lusers message"
 416
 417 - MOTD
 418         MOTD [<target>]
 419         .
 420         Show the "Message of the Day" (MOTD) of an IRC server in the network.
 421         .
 422         <target> can be a server name, the nickname of a client connected to
 423         a specific server, or a mask matching a server name in the network.
 424         The server of the current connection is used when <target> is omitted.
 425
 426         References:
 427          - RFC 2812, 3.4.1 "Motd message"
 428
 429 - NAMES
 430         NAMES [<channel>[,<channel>[,...]] [<target>]]
 431         .
 432         Show the list of users that are members of a particular <channel>
 433         (and that are visible for the client requesting this information) as
 434         seen by the server <target>. More than one <channel> can be given
 435         separated by "," (but not whitespaces!).
 436         .
 437         If <channel> has been omitted, all visible users are shown, grouped
 438         by channel name, and all visible users not being members of at least
 439         one channel are shown as members of the pseudo channel "*".
 440         .
 441         <target> can be a server name, the nickname of a client connected to
 442         a specific server, or a mask matching a server name in the network.
 443         The server of the current connection is used when <target> is omitted.
 444
 445         References:
 446          - RFC 2812, 3.2.5 "Names message"
 447
 448 - STATS
 449         STATS [<query> [<target>]]
 450         .
 451         Show statistics and other information of type <query> of a particular
 452         IRC server in the network.
 453         .
 454         The following <query> types are supported (case-insensitive where
 455         applicable):
 456         .
 457          - g  Network-wide bans ("G-Lines").
 458          - k  Server-local bans ("K-Lines").
 459          - L  Link status (servers and user links).
 460          - l  Link status (servers and own link).
 461          - m  Command usage count.
 462          - u  Server uptime.
 463         .
 464         <target> can be a server name, the nickname of a client connected to
 465         a specific server, or a mask matching a server name in the network.
 466         The server of the current connection is used when <target> is omitted.
 467         .
 468         To use "STATS L" the user must be an IRC Operator.
 469
 470         References:
 471          - RFC 2812, 3.4.4 "Stats message"
 472
 473 - TIME
 474         TIME [<target>]
 475         .
 476         Show the local time of an IRC server in the network.
 477         .
 478         <target> can be a server name, the nickname of a client connected to
 479         a specific server, or a mask matching a server name in the network.
 480         The server of the current connection is used when <target> is omitted.
 481
 482         References
 483          - RFC 2812, 3.4.6 "Time message"
 484
 485 - TRACE
 486         TRACE [<target>]
 487         .
 488         Find the route to a specific server and send information about its
 489         peers. Each server that processes this command reports back to the
 490         sender about it: the replies from pass-through servers form a chain
 491         which shows the route to the destination.
 492         .
 493         <target> can be a server name, the nickname of a client connected to
 494         a specific server, or a mask matching a server name in the network.
 495         The server of the current connection is used when <target> is omitted.
 496
 497         References:
 498          - RFC 2812, 3.4.8 "Trace message"
 499
 500 - USERHOST
 501         USERHOST <nickname> [<nickname> [...]]
 502         .
 503         Show flags and the hostmasks (<user>@<host>) of the <nickname>s,
 504         separated by spaces. The following flags are used:
 505         .
 506          - "-"  The client is "away" (the mode "+a" is set on this client).
 507          - "+"  Client seems to be available, at least it isn't marked "away".
 508          - "*"  The client is an IRC operator (the mode "+o" is set).
 509
 510         References:
 511          - RFC 2812, 4.8 "Userhost message"
 512
 513 - VERSION
 514         VERSION [<target>]
 515         .
 516         Show version information about a particular IRC server in the network.
 517         .
 518         <target> can be a server name, the nickname of a client connected to
 519         a specific server, or a mask matching a server name in the network.
 520         The server of the current connection is used when <target> is omitted.
 521         .
 522         Please note: in normal operation, the version number ends in a dot
 523         (".", for example "ngIRCd-20.1."). If it ends in ".1" (for example
 524         "ngIRCd-20.1.1", same version than before!), the server is running in
 525         debug-mode; and if it ends in ".2", the "network sniffer" is active!
 526         Keep your privacy in mind ...
 527
 528         References:
 529          - RFC 2812, 3.4.3 "Version message"
 530
 531 - WHO
 532         WHO [<mask> ["o"]]
 533         .
 534         Show a list of users who match the <mask>, or all visible users when
 535         the <mask> has been omitted. (Special case: the <mask> "0" is
 536         equivalent to "*")
 537         .
 538         If the flag "o" is given, the server will only return information about
 539         IRC Operators.
 540
 541         References:
 542          - RFC 2812, 3.6.1 "Who query"
 543
 544 - WHOIS
 545         WHOIS [<target>] <mask>[,<mask>[,...]]
 546         .
 547         Query information about users matching the <mask> parameter(s) as seen
 548         by the server <target>; up to 3 <masks> are supported.
 549         .
 550         <target> can be a server name, the nickname of a client connected to a
 551         specific server, or a mask matching a server name in the network. The
 552         server of the current connection is used when <target> is omitted.
 553
 554         References:
 555          - RFC 2812, 3.6.2 "Whois query"
 556
 557 - WHOWAS
 558         WHOWAS <nickname>[,<nickname>[,...]] [<count> [<target>]]
 559         .
 560         Query information about nicknames no longer in use in the network,
 561         either because of nickname changes or disconnects. The history is
 562         searched backwards, returning the most recent entry first. If there
 563         are multiple entries, up to <count> entries will be shown (or all of
 564         them, if no <count> has been given).
 565         .
 566         <target> can be a server name, the nickname of a client connected to a
 567         specific server, or a mask matching a server name in the network. The
 568         server of the current connection is used when <target> is omitted.
 569
 570         References:
 571          - RFC 2812, 3.6.3 "Whowas"
 572
 573
 574 Channel Commands
 575 ~~~~~~~~~~~~~~~~
 576
 577 - INVITE
 578         INVITE <nickname> <channel>
 579         .
 580         Invite <nickname> to join channel <channel>.
 581         .
 582         <channel> does not have to exist, but if it does, only members of the
 583         channel are allowed to invite other users. If the channel mode "+i"
 584         is set, only channel "half-ops" (and above) may invite other clients,
 585         and if channel mode "+V" is set, nobody can invite other users.
 586
 587         References:
 588          - RFC 2812, 3.2.7 "Invite message"
 589
 590 - JOIN
 591         JOIN {<channel>[,<channel>[,...]] [<key>[,<key>[,...]]] | 0}
 592         .
 593         Makes the client join the <channel> (comma-separated list), specifying
 594         the channel keys ("passwords"). A <channel-key> is only needed if the
 595         <channel> has the mode "+k" set.
 596         .
 597         If the channel(s) do not exist, then they will be created.
 598         .
 599         Using "JOIN 0" parts all channels at once.
 600
 601         References:
 602          - RFC 2812, 3.2.1 "Join message" (client protocol)
 603          - RFC 2813, 4.2.1 "Join message" (server protocol)
 604
 605 - KICK
 606         KICK <channel>[,<channel>[,...]] <nickname>[,<nickname>[,...]] [<reason>]
 607         .
 608         Remove users(s) with <nickname>(s) from <channel>(s).
 609         .
 610         There must be either exactly one <channel> parameter and multiple
 611         <nickname> parameters, or as many <channel> parameters as there are
 612         <nickname> parameters. The <reason> is shown to the users being
 613         kicked, and the nickname of the current user is used when <reason>
 614         is omitted.
 615
 616         References:
 617          - RFC 2812, 3.2.8 "Kick command"
 618
 619 - LIST
 620         LIST [<mask>[,<mask>[,...]] [<server>]]
 621         .
 622         List all visible channels matching the <mask> (comma-separated list),
 623         or all channels when no <mask> was specified.
 624         .
 625         If <server> is given, the command will be forwarded to <server> for
 626         evaluation.
 627
 628         References:
 629          - RFC 2812, 3.2.6 "List message"
 630
 631 - PART
 632         PART <channel>[,<channel>[,...]] [<part-message>]
 633         .
 634         Leave <channel> (comma-separated list), optionally with sending a
 635         <part-message> to all the other channel members.
 636
 637         References:
 638          - RFC 2812, 3.2.2 "Part message"
 639
 640 - TOPIC
 641         TOPIC <channel> [<topic>]
 642         .
 643         Change or view the topic of a channel.
 644         .
 645         The topic for channel <channel> is returned if there is no <topic>
 646         given. If the <topic> parameter is present, the topic for that
 647         channel will be changed, if this action is allowed for the user
 648         requesting it. If the <topic> parameter is an empty string, the
 649         topic for that channel will be removed.
 650
 651         References:
 652          - RFC 2812, 3.2.4 "Topic message"
 653
 654
 655 Administrative Commands
 656 ~~~~~~~~~~~~~~~~~~~~~~~
 657
 658 - CONNECT
 659         CONNECT <server> [<port> [<remote-server> [<my-pwd> <peer-pwd>]]]
 660         .
 661         Instructs the current server, or <remote-server> if specified,
 662         to connect to the server named <server>, which must be configured
 663         in the server configuration file.
 664         .
 665         To use this command, the user must be an IRC Operator. To establish
 666         a connection on a <remote-server>, you must have remote IRC operator
 667         privileges.
 668         .
 669         If <port>, <my-pwd> and <peer-pwd> are given, these values override
 670         the ones specified in the server configuration file.
 671
 672         References:
 673          - RFC 2812, 3.4.7 "Connect message"
 674
 675 - DIE
 676         DIE [<message>]
 677         .
 678         Instructs the server to shut down.
 679         .
 680         The optional (and non-standard) <message> text is sent to each client
 681         connected to this server before all connections are closed.
 682         .
 683         To use this command, the user must be an IRC Operator.
 684
 685         References:
 686          - RFC 2812, 4.3 "Die message"
 687
 688 - DISCONNECT
 689         DISCONNECT <server>
 690         .
 691         Disconnect and disable a locally linked server.
 692         .
 693         To use this command, the user must be an IRC Operator.
 694
 695         References:
 696          - This command is not specified in the IRC RFCs, it is an extension
 697            of ngIRCd.
 698
 699 - GLINE
 700         GLINE <nick!user@hostmask> [<timeout> :<reason>]
 701         .
 702         This command provides timed G-Lines (network-wide bans).
 703         .
 704         If a client matches a G-Line, it cannot connect to any server on
 705         the IRC network for <timeout> seconds. When <timeout> is 0, it make
 706         the G-Line permanent.
 707         .
 708         If no <timeout> and no <reason> is given, the G-Line is removed.
 709         .
 710         To use this command, the user must be an IRC Operator.
 711         .
 712         "STATS g" can be used to list all currently active G-Lines.
 713
 714         References:
 715          - This command is not specified in the IRC RFCs, it is an extension
 716            of ngIRCd.
 717
 718 - KILL
 719         KILL <nickname> <reason>
 720         .
 721         Forcibly remove all users with a given <nickname> from the IRC
 722         network and display the given <reason> to them.
 723         .
 724         This command is used internally between servers, too, for example
 725         to disconnect duplicate <nickname>'s after a "net split".
 726         .
 727         To use this command, the user must be an IRC Operator.
 728
 729         References:
 730          - RFC 2812, 3.7.1 "Kill message"
 731
 732 - KLINE
 733         KLINE <nick!user@hostmask> [<timeout> :<reason>]
 734         .
 735         This command provides timed K-Lines (server-local bans).
 736         .
 737         If a client matches a K-Line, it cannot connect to this server for
 738         <timeout> seconds. When <timeout> is 0, it makes the K-Line permanent.
 739         .
 740         If no <timeout> and no <reason> is given, the K-Line is removed.
 741         .
 742         To use this command, the user must be an IRC Operator.
 743         .
 744         "STATS k" can be used to list all currently active K-Lines.
 745
 746         References:
 747          - This command is not specified in the IRC RFCs, it is an extension
 748            of ngIRCd.
 749
 750 - OPER
 751         OPER <name> <password>
 752         .
 753         Authenticates a user named <name> as an IRC operator on the current
 754         server/network.
 755         .
 756         This operator <name> must be configured in the server configuration.
 757         .
 758         Please note that <name> is NOT related to a nickname at all!
 759
 760         References:
 761          - RFC 2812, 3.1.4 "Oper message"
 762
 763 - REHASH
 764         REHASH
 765         .
 766         Causes the server to re-read and re-process its configuration file(s).
 767         .
 768         While rehashing, no new connections are accepted, but all already
 769         established connections stay connected.
 770         .
 771         To use this command, the user must be an IRC Operator.
 772
 773         References:
 774          - RFC 2812, 4.2 "Rehash message"
 775
 776 - RESTART
 777         RESTART
 778         .
 779         Restart the server.
 780         .
 781         While restarting, all connections are reset and no new connections
 782         are accepted.
 783         .
 784         To use this command, the user must be an IRC Operator.
 785
 786         References:
 787          - RFC 2812, 4.4 "Restart message"
 788
 789 - WALLOPS
 790         WALLOPS <message>
 791         .
 792         Sends <message> to all users with user mode "+w".
 793         .
 794         To use this command, the user must be an IRC Operator.
 795
 796         References:
 797          - RFC 2812, 4.7 "Operwall message"
 798
 799 IRC Service Commands
 800 ~~~~~~~~~~~~~~~~~~~~
 801
 802 - SERVICE
 803         SERVICE <name> <reserved1> <distribution> <type> <reserved2> <info>
 804         SERVICE <name> <servertoken> <distribution> {<type>|+<modes>} <hops> <info>
 805         .
 806         Register a new service in the network.
 807         .
 808         The first form is used by directly linked services and isn't supported
 809         by ngIRCd at the moment. The second form announces services connected
 810         to remote "pseudo-servers" ("services hubs").
 811         .
 812         The <distribution> and <type> parameters are ignored by ngIRCd.
 813
 814         References:
 815          - RFC 2812, 3.1.6 "Service message"
 816          - RFC 2813, 4.1.4 "Service message"
 817
 818 - SERVLIST
 819         SERVLIST [<mask> [<type>]]
 820         .
 821         List all IRC services currently registered in the network.
 822         .
 823         The optional <mask> and <type> parameters can be used to limit the
 824         listing to services matching the <mask> and that are of type <type>.
 825         .
 826         Please note that ngIRCd doesn't use any service types at the moment
 827         and therefore all services are of type "0".
 828
 829         References:
 830          - RFC 2812, 3.5.1 "Servlist message"
 831
 832 - SQUERY
 833         SQUERY <target>[,<target>[,...]] <message>
 834         .
 835         Send a <message> to a given <target> IRC service, and report all
 836         errors.
 837         .
 838         The "SQUERY" command exactly behaves like the "PRIVMSG" command, but
 839         enforces that the <target> of the <message> is an IRC service.
 840         Please see the help text of the "PRIVMSG" command for a detailed
 841         description of the parameters!
 842         .
 843         If a user wants to interact with IRC services, he should use "SQUERY"
 844         instead of "PRIVMSG" or "NOTICE": only "SQUERY makes sure that no
 845         regular user, which uses the nickname of an IRC service, receives
 846         the command in error, for example during a "net split"!
 847
 848         References:
 849          - RFC 2812, 2.3.1 "Message format in Augmented BNF"
 850          - RFC 2812, 3.3 "Sending messages"
 851          - RFC 2812, 3.3.2 "Notice"
 852
 853 - SVSNICK
 854         SVSNICK <oldnick> <newnick>
 855         .
 856         Forcefully change foreign user nicknames. This command is allowed
 857         for servers only.
 858         .
 859         The "SVSNICK" command is forwarded to the server to which the user
 860         with nickname <oldnick> is connected to, which in turn generates a
 861         regular "NICK" command that then is sent to the client, so no special
 862         support in the client software is required.
 863
 864         References:
 865          - ngIRCd GIT commit e3f300d3231f
 866
 867
 868 Server Protocol Commands
 869 ~~~~~~~~~~~~~~~~~~~~~~~~
 870
 871 - CHANINFO
 872         CHANINFO <channel> +<modes> [[<key> <limit>] <topic>]
 873         .
 874         CHANINFO is used by servers to inform each other about a channel:
 875         its modes, channel key, user limits and its topic.
 876         .
 877         The CHANINFO command is allowed on server-links only.
 878
 879         References:
 880          - IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
 881          - IRC+, doc/Protocol.txt
 882
 883 - ERROR
 884         ERROR [<message> [<> [...]]]
 885         .
 886         Inform a client or a server about an error condition. The first
 887         parameter, if given, is logged by the server receiving the message,
 888         all other parameters are silently ignored.
 889         .
 890         This command is silently ignored on non-server and non-service links
 891         and shouldn't be used by regular IRC clients.
 892         .
 893         The ERROR message is also sent before terminating a regular client
 894         connection.
 895
 896         References:
 897          - RFC 2812, 3.7.4 "Error message"
 898
 899 - METADATA
 900         METADATA <target> <key> <value>
 901         .
 902         The METADATA command is used on server-links to update "metadata"
 903         information of clients, like the hostname, the info text ("real name"),
 904         or the user name.
 905         .
 906         The METADATA command is allowed on server-links only.
 907
 908         References:
 909          - IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
 910          - IRC+, doc/Protocol.txt
 911
 912 - NJOIN
 913         NJOIN <channel> [<mode>]<nick>[,[<mode>]<nick>[,...]]
 914         .
 915         The NJOIN command is used on server-links to add users with <nick>
 916         and <mode> to a <channel> while peering.
 917         .
 918         The NJOIN command is allowed on server-links only.
 919
 920         References:
 921          - RFC 2813, 4.2.2 "Njoin message"
 922
 923 - SERVER
 924         SERVER <servername> <info>
 925         SERVER <servername> <hopcount> <info>
 926         SERVER <servername> <hopcount> <token> <info>
 927         .
 928         The first form registers the local connection as a new server in the
 929         network, the second (RFC 1459) and third (RFC 2812) form announce a
 930         new remote server in the network.
 931         .
 932         The SERVER command is allowed on unregistered or server-links only.
 933
 934         References:
 935          - RFC 1459, 4.1.4 "Server message"
 936          - RFC 2813, 4.1.2 "Server message"
 937
 938 - SQUIT
 939         SQUIT <server> <comment>
 940         .
 941         Disconnects an IRC Server from the network.
 942         .
 943         This command is used on server-links, but can be used by IRC Operators
 944         to forcefully disconnect servers from the network, too.
 945
 946         References:
 947          - RFC 2812, 3.1.8 "Squit"
 948          - RFC 2813, 4.1.6 "Server quit message"
 949
 950 Dummy Commands
 951 ~~~~~~~~~~~~~~
 952
 953 - SUMMON
 954         SUMMON <user> [<target> [<channel>]]
 955         .
 956         This command was intended to call people into IRC who are directly
 957         connected to the terminal console of the IRC server -- but is
 958         deprecated today. Therefore ngIRCd doesn't really implement this
 959         command and always returns an error message, regardless of the
 960         parameters given.
 961
 962         References:
 963          - RFC 2812, 4.5 "Summon message"
 964
 965 - USERS
 966         USERS [<target>]
 967         .
 968         This command was intended to list users directly logged in into the
 969         console of the IRC server -- but is deprecated today. Therefore ngIRCd
 970         doesn't really implement this command and always returns an error
 971         message, regardless of the parameters given.
 972
 973         References:
 974          - RFC 2812, 4.6 "Users"
 975
 976 - GET
 977         GET [...]
 978         .
 979         Fake HTTP GET command. When received, the connection is shut down
 980         immediately again to protect against crazy web browsers ...
 981
 982         References:
 983          - ngIRCd GIT commit 33e8c2480649
 984
 985 - POST
 986         POST [...]
 987         .
 988         Fake HTTP POST command. When received, the connection is shut down
 989         immediately again to protect against crazy web browsers ...
 990
 991         References:
 992          - ngIRCd GIT commit 33e8c2480649