doc/Commands.txt

   1
   2                      ngIRCd - Next Generation IRC Server
   3                            http://ngircd.barton.de/
   4
   5                (c)2001-2013 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 behaviour, 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 [<channel>[,<channel>[,...]] [<server>]]
 621         .
 622         List all visible <channels> (comma-separated list).
 623         .
 624         If <server> is given, the command will be forwarded to <server> for
 625         evaluation.
 626
 627         References:
 628          - RFC 2812, 3.2.6 "List message"
 629
 630 - PART
 631         PART <channel>[,<channel>[,...]] [<part-message>]
 632         .
 633         Leave <channel> (comma-separated list), optionally with sending a
 634         <part-message> to all the other channel members.
 635
 636         References:
 637          - RFC 2812, 3.2.2 "Part message"
 638
 639 - TOPIC
 640         TOPIC <channel> [<topic>]
 641         .
 642         Change or view the topic of a channel.
 643         .
 644         The topic for channel <channel> is returned if there is no <topic>
 645         given. If the <topic> parameter is present, the topic for that
 646         channel will be changed, if this action is allowed for the user
 647         requesting it. If the <topic> parameter is an empty string, the
 648         topic for that channel will be removed.
 649
 650         References:
 651          - RFC 2812, 3.2.4 "Topic message"
 652
 653
 654 Administrative Commands
 655 ~~~~~~~~~~~~~~~~~~~~~~~
 656
 657 - CONNECT
 658         CONNECT <server> [<port> [<remote-server> [<my-pwd> <peer-pwd>]]]
 659         .
 660         Instructs the current server, or <remote-server> if specified,
 661         to connect to the server named <server>, which must be configured
 662         in the server configuration file.
 663         .
 664         To use this command, the user must be an IRC Operator. To establish
 665         a connection on a <remote-server>, you must have remote IRC operator
 666         privileges.
 667         .
 668         If <port>, <my-pwd> and <peer-pwd> are given, these values override
 669         the ones specified in the server configuration file.
 670
 671         References:
 672          - RFC 2812, 3.4.7 "Connect message"
 673
 674 - DIE
 675         DIE [<message>]
 676         .
 677         Instructs the server to shut down.
 678         .
 679         The optional (and non-standard) <message> text is sent to each client
 680         connected to this server before all connections are closed.
 681         .
 682         To use this command, the user must be an IRC Operator.
 683
 684         References:
 685          - RFC 2812, 4.3 "Die message"
 686
 687 - DISCONNECT
 688         DISCONNECT <server>
 689         .
 690         Disconnect and disable a locally linked server.
 691         .
 692         To use this command, the user must be an IRC Operator.
 693
 694         References:
 695          - This command is not specified in the IRC RFCs, it is an extension
 696            of ngIRCd.
 697
 698 - GLINE
 699         GLINE <nick!user@hostmask> [<timeout> :<reason>]
 700         .
 701         This command provides timed G-Lines (network-wide bans).
 702         .
 703         If a client matches a G-Line, it cannot connect to any server on
 704         the IRC network for <timeout> seconds. When <timeout> is 0, it make
 705         the G-Line permanent.
 706         .
 707         If no <timeout> and no <reason> is given, the G-Line is removed.
 708         .
 709         To use this command, the user must be an IRC Operator.
 710         .
 711         "STATS g" can be used to list all currently active G-Lines.
 712
 713         References:
 714          - This command is not specified in the IRC RFCs, it is an extension
 715            of ngIRCd.
 716
 717 - KILL
 718         KILL <nickname> <reason>
 719         .
 720         Forcibly remove all users with a given <nickname> from the IRC
 721         network and display the given <reason> to them.
 722         .
 723         This command is used internally between servers, too, for example
 724         to disconnect duplicate <nickname>'s after a "net split".
 725         .
 726         To use this command, the user must be an IRC Operator.
 727
 728         References:
 729          - RFC 2812, 3.7.1 "Kill message"
 730
 731 - KLINE
 732         KLINE <nick!user@hostmask> [<timeout> :<reason>]
 733         .
 734         This command provides timed K-Lines (server-local bans).
 735         .
 736         If a client matches a K-Line, it cannot connect to this server for
 737         <timeout> seconds. When <timeout> is 0, it makes the K-Line permanent.
 738         .
 739         If no <timeout> and no <reason> is given, the K-Line is removed.
 740         .
 741         To use this command, the user must be an IRC Operator.
 742         .
 743         "STATS k" can be used to list all currently active K-Lines.
 744
 745         References:
 746          - This command is not specified in the IRC RFCs, it is an extension
 747            of ngIRCd.
 748
 749 - OPER
 750         OPER <name> <password>
 751         .
 752         Authenticates a user named <name> as an IRC operator on the current
 753         server/network.
 754         .
 755         This operator <name> must be configured in the server configuration.
 756         .
 757         Please note that <name> is NOT related to a nickname at all!
 758
 759         References:
 760          - RFC 2812, 3.1.4 "Oper message"
 761
 762 - REHASH
 763         REHASH
 764         .
 765         Causes the server to re-read and re-process its configuration file(s).
 766         .
 767         While rehashing, no new connections are accepted, but all already
 768         established connections stay connected.
 769         .
 770         To use this command, the user must be an IRC Operator.
 771
 772         References:
 773          - RFC 2812, 4.2 "Rehash message"
 774
 775 - RESTART
 776         RESTART
 777         .
 778         Restart the server.
 779         .
 780         While restarting, all connections are reset and no new connections
 781         are accepted.
 782         .
 783         To use this command, the user must be an IRC Operator.
 784
 785         References:
 786          - RFC 2812, 4.4 "Restart message"
 787
 788 - WALLOPS
 789         WALLOPS <message>
 790         .
 791         Sends <message> to all users with user mode "+w".
 792         .
 793         To use this command, the user must be an IRC Operator.
 794
 795         References:
 796          - RFC 2812, 4.7 "Operwall message"
 797
 798 IRC Service Commands
 799 ~~~~~~~~~~~~~~~~~~~~
 800
 801 - SERVICE
 802         SERVICE <name> <reserved1> <distribution> <type> <reserved2> <info>
 803         SERVICE <name> <servertoken> <distribution> {<type>|+<modes>} <hops> <info>
 804         .
 805         Register a new service in the network.
 806         .
 807         The first form is used by directly linked services and isn't supported
 808         by ngIRCd at the moment. The second form announces services connected
 809         to remote "pseudo-servers" ("services hubs").
 810         .
 811         The <distribution> and <type> parameters are ignored by ngIRCd.
 812
 813         References:
 814          - RFC 2812, 3.1.6 "Service message"
 815          - RFC 2813, 4.1.4 "Service message"
 816
 817 - SERVLIST
 818         SERVLIST [<mask> [<type>]]
 819         .
 820         List all IRC services currently registered in the network.
 821         .
 822         The optional <mask> and <type> parameters can be used to limit the
 823         listing to services matching the <mask> and that are of type <type>.
 824         .
 825         Please note that ngIRCd doesn't use any service types at the moment
 826         and therefore all services are of type "0".
 827
 828         References:
 829          - RFC 2812, 3.5.1 "Servlist message"
 830
 831 - SQUERY
 832         SQUERY <target>[,<target>[,...]] <message>
 833         .
 834         Send a <message> to a given <target> IRC service, and report all
 835         errors.
 836         .
 837         The "SQUERY" command exactly behaves like the "PRIVMSG" command, but
 838         enforces that the <target> of the <message> is an IRC service.
 839         Please see the help text of the "PRIVMSG" command for a detailed
 840         description of the parameters!
 841         .
 842         If a user wants to interact with IRC services, he should use "SQUERY"
 843         instead of "PRIVMSG" or "NOTICE": only "SQUERY makes sure that no
 844         regular user, which uses the nickname of an IRC service, receives
 845         the command in error, for example during a "net split"!
 846
 847         References:
 848          - RFC 2812, 2.3.1 "Message format in Augmented BNF"
 849          - RFC 2812, 3.3 "Sending messages"
 850          - RFC 2812, 3.3.2 "Notice"
 851
 852 - SVSNICK
 853         SVSNICK <oldnick> <newnick>
 854         .
 855         Forcefully change foreign user nicknames. This command is allowed
 856         for servers only.
 857         .
 858         The "SVSNICK" command is forwarded to the server to which the user
 859         with nickname <oldnick> is connected to, which in turn generates a
 860         regular "NICK" command that then is sent to the client, so no special
 861         support in the client software is required.
 862
 863         References:
 864          - ngIRCd GIT commit e3f300d3231f
 865
 866
 867 Server Protocol Commands
 868 ~~~~~~~~~~~~~~~~~~~~~~~~
 869
 870 - CHANINFO
 871         CHANINFO <channel> +<modes> [[<key> <limit>] <topic>]
 872         .
 873         CHANINFO is used by servers to inform each other about a channel:
 874         its modes, channel key, user limits and its topic.
 875         .
 876         The CHANINFO command is allowed on server-links only.
 877
 878         References:
 879          - IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
 880          - IRC+, doc/Protocol.txt
 881
 882 - ERROR
 883         ERROR [<message> [<> [...]]]
 884         .
 885         Inform a client or a server about an error condition. The first
 886         parameter, if given, is logged by the server receiving the message,
 887         all other parameters are silently ignored.
 888         .
 889         This command is silently ignored on non-server and non-service links
 890         and shouldn't be used by regular IRC clients.
 891         .
 892         The ERROR message is also sent before terminating a regular client
 893         connection.
 894
 895         References:
 896          - RFC 2812, 3.7.4 "Error message"
 897
 898 - METADATA
 899         METADATA <target> <key> <value>
 900         .
 901         The METADATA command is used on server-links to update "metadata"
 902         information of clients, like the hostname, the info text ("real name"),
 903         or the user name.
 904         .
 905         The METADATA command is allowed on server-links only.
 906
 907         References:
 908          - IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
 909          - IRC+, doc/Protocol.txt
 910
 911 - NJOIN
 912         NJOIN <channel> [<mode>]<nick>[,[<mode>]<nick>[,...]]
 913         .
 914         The NJOIN command is used on server-links to add users with <nick>
 915         and <mode> to a <channel> while peering.
 916         .
 917         The NJOIN command is allowed on server-links only.
 918
 919         References:
 920          - RFC 2813, 4.2.2 "Njoin message"
 921
 922 - SERVER
 923         SERVER <servername> <info>
 924         SERVER <servername> <hopcount> <info>
 925         SERVER <servername> <hopcount> <token> <info>
 926         .
 927         The first form registers the local connection as a new server in the
 928         network, the second (RFC 1459) and third (RFC 2812) form announce a
 929         new remote server in the network.
 930         .
 931         The SERVER command is allowed on unregistered or server-links only.
 932
 933         References:
 934          - RFC 1459, 4.1.4 "Server message"
 935          - RFC 2813, 4.1.2 "Server message"
 936
 937 - SQUIT
 938         SQUIT <server> <comment>
 939         .
 940         Disconnects an IRC Server from the network.
 941         .
 942         This command is used on server-links, but can be used by IRC Operators
 943         to forcefully disconnect servers from the network, too.
 944
 945         References:
 946          - RFC 2812, 3.1.8 "Squit"
 947          - RFC 2813, 4.1.6 "Server quit message"
 948
 949 Dummy Commands
 950 ~~~~~~~~~~~~~~
 951
 952 - SUMMON
 953         SUMMON <user> [<target> [<channel>]]
 954         .
 955         This command was intended to call people into IRC who are directly
 956         connected to the terminal console of the IRC server -- but is
 957         deprecated today. Therefore ngIRCd doesn't really implement this
 958         command and always returns an error message, regardless of the
 959         parameters given.
 960
 961         References:
 962          - RFC 2812, 4.5 "Summon message"
 963
 964 - USERS
 965         USERS [<target>]
 966         .
 967         This command was intended to list users directly logged in into the
 968         console of the IRC server -- but is deprecated today. Therefore ngIRCd
 969         doesn't really implement this command and always returns an error
 970         message, regardless of the parameters given.
 971
 972         References:
 973          - RFC 2812, 4.6 "Users"
 974
 975 - GET
 976         GET [...]
 977         .
 978         Fake HTTP GET command. When received, the connection is shut down
 979         immediately again to protect against crazy web browsers ...
 980
 981         References:
 982          - ngIRCd GIT commit 33e8c2480649
 983
 984 - POST
 985         POST [...]
 986         .
 987         Fake HTTP POST command. When received, the connection is shut down
 988         immediately again to protect against crazy web browsers ...
 989
 990         References:
 991          - ngIRCd GIT commit 33e8c2480649