mirror of
https://github.com/osmarks/ngircd.git
synced 2024-12-12 01:40:27 +00:00
13122bc97d
- Fix syntax of LINKS amd LIST commands. - Whitespace and spelling fixes. - Add some more information about IRCv3 support.
993 lines
31 KiB
Plaintext
993 lines
31 KiB
Plaintext
|
|
ngIRCd - Next Generation IRC Server
|
|
http://ngircd.barton.de/
|
|
|
|
(c)2001-2019 Alexander Barton and Contributors.
|
|
ngIRCd is free software and published under the
|
|
terms of the GNU General Public License.
|
|
|
|
-- Commands.txt --
|
|
|
|
|
|
This file lists all commands available on ngIRCd. It is written in a format
|
|
that is human readable as well as machine parseable and therefore can be used
|
|
as "help text file" of the daemon.
|
|
|
|
In short, the daemon reads this file on startup and parses it as following
|
|
when an user issues a "HELP <cmd>" command:
|
|
|
|
1. Search the file for a line "- <cmd>",
|
|
2. Output all subsequent lines that start with a TAB (ASCII 9) character
|
|
to the client using NOTICE commands, treat lines containing a single "."
|
|
after the TAB as empty lines.
|
|
3. Break at the first line not starting with a TAB character.
|
|
|
|
This format allows to have information to each command stored in this file
|
|
which will not be sent to an IRC user requesting help which enables us to
|
|
have additional annotations stored here which further describe the origin,
|
|
implementation details, or limits of the specific command which are not
|
|
relevant to an end-user but administrators and developers.
|
|
|
|
A special "Intro" block is returned to the user when the HELP command is
|
|
used without a command name:
|
|
|
|
|
|
- Intro
|
|
This is ngIRCd, a server software for Internet Relay Chat (IRC)
|
|
networks. You can find more information about ngIRCd on its homepage:
|
|
<http://ngircd.barton.de>
|
|
.
|
|
Use "HELP COMMANDS" to get a list of all available commands and
|
|
"HELP <command-name>" to get help for a specific IRC command, for
|
|
example "HELP quit" or "HELP privmsg".
|
|
|
|
|
|
Connection Handling Commands
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
- CAP
|
|
CAP LS
|
|
CAP LIST
|
|
CAP REQ <capabilities>
|
|
CAP ACK <capabilities>
|
|
CAP NAK <capabilities>
|
|
CAP CLEAR
|
|
CAP END
|
|
.
|
|
List, request, and clear "IRC Capabilities".
|
|
.
|
|
Using this command, an IRC client can request additional "IRC
|
|
capabilities" during login or later on, which influences the
|
|
communication between server and client. Normally, these commands
|
|
aren't directly used by humans, but automatically by their client
|
|
software. And please note that issuing such commands manually can
|
|
irritate the client software used, because of the "non-standard"
|
|
behavior of the server!
|
|
.
|
|
- CAP LS: list all available capabilities.
|
|
- CAP LIST: list active capabilities of this connection.
|
|
- CAP REQ: Request particular capabilities.
|
|
- CAP ACK: Acknowledge a set of capabilities to be enabled/disabled.
|
|
- CAP NAK: Reject a set of capabilities.
|
|
- CAP CLEAR: Clear all set capabilities.
|
|
- CAP END: Indicate end of capability negotiation during login,
|
|
ignored in an fully registered session.
|
|
|
|
Please note that the <capabilities> must be given in a single
|
|
parameter but whitespace separated, therefore a command could look
|
|
like this: "CAP REQ :capability1 capability2 capability3" for example.
|
|
|
|
References:
|
|
- <http://ircv3.net/specs/core/capability-negotiation-3.1.html>
|
|
- <http://ngircd.barton.de/doc/Capabilities.txt>
|
|
- doc/Capabilities.txt
|
|
|
|
- CHARCONV
|
|
CHARCONV <client-charset>
|
|
.
|
|
Set client character set encoding to <client-charset>.
|
|
.
|
|
After receiving such a command, the server translates all message
|
|
data received from the client using the set <client-charset> to the
|
|
server encoding (UTF-8), and all message data which is to be sent to
|
|
the client from the server encoding (UTF-8) to <client-charset>.
|
|
.
|
|
This enables older clients and clients using "strange" character sets
|
|
to transparently participate in channels and direct messages to
|
|
clients using UTF-8, which should be the default today.
|
|
|
|
References:
|
|
- IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
|
|
- IRC+, doc/Protocol.txt
|
|
|
|
- NICK
|
|
NICK <nickname>
|
|
NICK <nickname> [<hops>]
|
|
NICK <nickname> <hops> <username> <host> <servertoken> <usermodes> <realname>
|
|
.
|
|
Set or change the <nickname> of a client (first form) and register
|
|
remote clients (second and third form; servers only).
|
|
|
|
References:
|
|
- RFC 1459, 4.1.2 "Nick message" (old client and server protocol)
|
|
- RFC 2812, 3.1.2 "Nick message" (client protocol)
|
|
- RFC 2813, 4.1.3 "Nick" (server protocol)
|
|
|
|
- PASS
|
|
PASS <password>
|
|
PASS <password> <version> <flags> [<options>]
|
|
.
|
|
Set a connection <password>. This command must be the first command
|
|
sent to the server, even before the NICK/USER or SERVER commands.
|
|
.
|
|
The first form is used by user sessions or (old) RFC 1459 servers,
|
|
the second form is used by RFC 2812 or IRC+ compliant servers and
|
|
enables the server to indicate its version and supported protocol
|
|
features.
|
|
|
|
References:
|
|
- RFC 1459, 4.1.1 "Password message" (old client and server protocol)
|
|
- RFC 2812, 3.1.1 "Password message" (client protocol)
|
|
- RFC 2813, 4.1.1 "Password message" (server protocol)
|
|
- IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
|
|
- IRC+, doc/Protocol.txt
|
|
|
|
- PING
|
|
PING <token> [<target>]
|
|
.
|
|
Tests the presence of a connection to a client or server.
|
|
.
|
|
If no <target> has been given, the local server is used. User clients
|
|
can only use other servers as <target>, no user clients.
|
|
.
|
|
A PING message results in a PONG reply containing the <token>, which
|
|
can be arbitrary text.
|
|
|
|
Please note:
|
|
The RFCs state that the <token> parameter is used to specify the
|
|
origin of the PING command when forwarded in the network, but this
|
|
is not the case: the sender is specified using the prefix as usual,
|
|
and the parameter is used to identify the PONG reply in practice.
|
|
|
|
References:
|
|
- RFC 2812, 3.7.2 "Ping message"
|
|
|
|
- PONG
|
|
PONG <target> [<token>]
|
|
.
|
|
Reply to a "PING" command, indicate that the connection is alive.
|
|
.
|
|
The <token> is the arbitrary text received in the "PING" command and
|
|
can be used to identify the correct PONG sent as answer.
|
|
.
|
|
When the "PONG" command is received from a user session, the <target>
|
|
parameter is ignored; otherwise the PONG is forwarded to this client.
|
|
|
|
References:
|
|
- RFC 2812, 3.7.3 "Pong message"
|
|
|
|
- QUIT
|
|
QUIT [<quit-message>]
|
|
.
|
|
Terminate a user session.
|
|
.
|
|
When received from a user, the server acknowledges this by sending
|
|
an "ERROR" message back to the client and terminates the connection.
|
|
.
|
|
When a <quit-message> has been given, it is sent to all the channels
|
|
that the client is a member of when leaving.
|
|
|
|
References:
|
|
- RFC 2812, 3.1.7 "Quit"
|
|
- RFC 2813, 4.1.5 "Quit"
|
|
|
|
- USER
|
|
USER <username> <hostname> <unused> <realname>
|
|
.
|
|
Register (and authenticate) a new user session with a short <username>
|
|
and a human-readable <realname>.
|
|
.
|
|
The parameter <hostname> is only used when received by an other server
|
|
and ignored otherwise; and the parameter <unused> is always ignored.
|
|
But both parameters are required on each invocation by the protocol
|
|
and can be set to arbitrary characters/text when not used.
|
|
.
|
|
If <username> contains an "@" character, the full <username> is used
|
|
for authentication, but only the first part up to this character is
|
|
set as "user name" for this session.
|
|
|
|
References:
|
|
- RFC 2812, 3.1.3 "User message"
|
|
|
|
- WEBIRC
|
|
WEBIRC <password> <username> <hostname> <ip-address>
|
|
.
|
|
Allow Web-to-IRC gateway software (for example) to set the correct
|
|
user name and host name of users instead of their own.
|
|
.
|
|
It must be the very first command sent to the server, even before
|
|
USER and NICK commands!
|
|
.
|
|
The <password> must be set in the server configuration file to prevent
|
|
unauthorized clients to fake their identity; it is an arbitrary string.
|
|
|
|
References:
|
|
- IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
|
|
- IRC+, doc/Protocol.txt
|
|
|
|
|
|
General Commands
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
- AWAY
|
|
AWAY [<message>]
|
|
.
|
|
Provides the server with a message to automatically send in reply to a
|
|
PRIVMSG directed at the user, but not to a channel they are on.
|
|
.
|
|
If <message> is omitted, the away status is removed.
|
|
|
|
References:
|
|
- RFC 2812, 4.1 "Away"
|
|
|
|
- HELP
|
|
HELP [<command>]
|
|
.
|
|
Show help information for a specific IRC <command>. The <command> name
|
|
is case-insensitive.
|
|
.
|
|
Use the command "HELP Commands" to get a list of all available commands.
|
|
|
|
The HELP command isn't specified by any RFC but implemented by most
|
|
daemons. If no help text could be read in, ngIRCd outputs a list of all
|
|
implemented commands when receiving a plain "HELP" command as well as
|
|
on "HELP Commands".
|
|
|
|
ngIRCd replies using "NOTICE" commands like ircd 2.10/2.11; other
|
|
implementations are using numerics 704, 705, and 706.
|
|
|
|
- MODE
|
|
MODE <nickname> [{+|-}<mode>[<mode>] [{+|-}<mode>[<mode>] [...]]]
|
|
MODE <channel> [{+|-}<mode>[<mode>] [<arg> [<arg> [...]]] [{+|-}<mode>[<mode>] [<arg> [<arg> [...]]] [...]]]
|
|
.
|
|
Set and get user and channel modes.
|
|
.
|
|
When no mode parameters are given, the currently set user or channel
|
|
modes are returned. Otherwise the modes are adjusted accordingly
|
|
and the changes will be reported back to the client.
|
|
.
|
|
All user and channel "modes" are indicated by single case-sensitive
|
|
characters.
|
|
.
|
|
Please note that a user can only get and set his own modes, and not
|
|
all user "levels" are allowed to change all channel modes ...
|
|
.
|
|
The mode parameters can become quite complex, especially when dealing
|
|
with channel modes that require additional arguments:
|
|
.
|
|
{+|-}<mode(s}> -- set or unset one or more modes.
|
|
+<mode(s)> -<mode(s)> -- set some modes and unset others.
|
|
+<modes> <arg1> <arg2> -- set (at least) two modes with arguments.
|
|
.
|
|
Some examples:
|
|
.
|
|
MODE nick +i -- set user to "invisible".
|
|
MODE #chan +tn -- set "topic lock" and "no external messages".
|
|
MODE #chan -t +l 50 -- remove "topic lock", set "user limit" to 50.
|
|
MODE #chan +ov nick1 nick2 -- set "channel op" and "voice" mode
|
|
to nick1 and nick2 in channel #chan.
|
|
.
|
|
A complete list of all modes supported by ngIRCd can be found online
|
|
here: <http://ngircd.barton.de/doc/Modes.txt>.
|
|
|
|
References:
|
|
- RFC 2811, 4. "Channel Modes"
|
|
- RFC 2812, 3.1.5 "User mode message"
|
|
- RFC 2812, 3.2.3 "Channel mode message"
|
|
- <http://ngircd.barton.de/doc/Modes.txt>
|
|
- doc/Modes.txt
|
|
|
|
- NOTICE
|
|
NOTICE <target>[,<target>[,...]] <message>
|
|
.
|
|
Send a <message> to a given <target>, which can be a user or a
|
|
channel, but DON'T report any error.
|
|
.
|
|
The "NOTICE" command exactly behaves like the "PRIVMSG" command, but
|
|
doesn't report any errors it encounters (like an unknown <target>).
|
|
Please see the help text of the "PRIVMSG" command for a detailed
|
|
description of the parameters!
|
|
|
|
References:
|
|
- RFC 2812, 2.3.1 "Message format in Augmented BNF"
|
|
- RFC 2812, 3.3 "Sending messages"
|
|
- RFC 2812, 3.3.2 "Notice"
|
|
|
|
- PRIVMSG
|
|
PRIVMSG <target>[,<target>[,...]] <message>
|
|
.
|
|
Send a <message> to a given <target>, which can be a user or a
|
|
channel, and report all errors.
|
|
.
|
|
The <target> must follow one of these syntax variants:
|
|
.
|
|
- <nickname>
|
|
- <channel>
|
|
- <user>[%<host>]@<server>
|
|
- <user>%<host>
|
|
- <nickname>!<user>@<host>
|
|
.
|
|
If the <target> is a user, a private message is sent directly to this
|
|
user; if it resolves to a channel name, a public message is sent
|
|
to all the members of that channel.
|
|
.
|
|
In addition, IRC Ops can use these two forms to specify the <target>:
|
|
.
|
|
- #<hostmask>
|
|
- $<servermask>
|
|
.
|
|
The <mask> can contain the wildcard characters "*" and "?", but must
|
|
contain at least one dot (".") and no wildcard after the last one.
|
|
Then, the <message> is sent to all users matching this <mask>.
|
|
.
|
|
All warnings and errors are reported back to the initiator using
|
|
numeric status codes, which is the only difference to the "NOTICE"
|
|
command, which doesn't report back any errors or warnings at all.
|
|
.
|
|
Please note that clients often use "MSG" as an alias to PRIVMSG, and
|
|
a command "QUERY <nick> [<message>]" to initiate private chats. Both
|
|
are command extensions of the client and never sent to the server.
|
|
|
|
References:
|
|
- RFC 2812, 2.3.1 "Message format in Augmented BNF"
|
|
- RFC 2812, 3.3 "Sending messages"
|
|
- RFC 2812, 3.3.1 "Private messages"
|
|
|
|
Status and Informational Commands
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
- ADMIN
|
|
ADMIN [<target>]
|
|
.
|
|
Show administrative information about an IRC server in the network.
|
|
.
|
|
<target> can be a server name, the nickname of a client connected to
|
|
a specific server, or a mask matching a server name in the network.
|
|
The server of the current connection is used when <target> is omitted.
|
|
|
|
References:
|
|
- RFC 2812, 3.4.9 "Admin command"
|
|
|
|
- INFO
|
|
INFO [<target>]
|
|
.
|
|
Show the version, birth & online time of an IRC server in the network.
|
|
.
|
|
<target> can be a server name, the nickname of a client connected to
|
|
a specific server, or a mask matching a server name in the network.
|
|
The server of the current connection is used when <target> is omitted.
|
|
|
|
References:
|
|
- RFC 2812, 3.4.10 "Info command"
|
|
|
|
- ISON
|
|
ISON <nickname> [<nickname> [...]]
|
|
.
|
|
Query online status of a list of nicknames. The server replies with
|
|
a list only containing nicknames actually connected to a server in
|
|
the network. If no nicknames of the given list are online, an empty
|
|
list is returned to the client requesting the information.
|
|
|
|
Please note that "all" IRC daemons even parse separate nicknames in
|
|
a single parameter (like ":nick1 nick2"), and therefore ngIRCd
|
|
implements this behavior, too.
|
|
|
|
References:
|
|
- RFC 2812, 4.9 "Ison message"
|
|
|
|
- LINKS
|
|
LINKS [[<target>] <mask>]
|
|
.
|
|
List all servers currently registered in the network matching <mask>,
|
|
or all servers if <mask> has been omitted, as seen by the server
|
|
specified by <target> or the local server when <target> is omitted.
|
|
.
|
|
<target> can be a server name, the nickname of a client connected to
|
|
a specific server, or a mask matching a server name in the network.
|
|
|
|
References:
|
|
- RFC 2812, 3.4.5 "Links message"
|
|
|
|
- LUSERS
|
|
LUSERS [<mask> [<target>]]
|
|
.
|
|
Return statistics about the number of clients (users, servers,
|
|
services, ...) in the network as seen by the server <target>.
|
|
.
|
|
<target> can be a server name, the nickname of a client connected to
|
|
a specific server, or a mask matching a server name in the network.
|
|
The server of the current connection is used when <target> is omitted.
|
|
|
|
Please note that ngIRCd ignores the <mask> parameter entirely: it
|
|
is not possible to get information for a part of the network only.
|
|
|
|
References:
|
|
- RFC 2812, 3.4.2 "Lusers message"
|
|
|
|
- MOTD
|
|
MOTD [<target>]
|
|
.
|
|
Show the "Message of the Day" (MOTD) of an IRC server in the network.
|
|
.
|
|
<target> can be a server name, the nickname of a client connected to
|
|
a specific server, or a mask matching a server name in the network.
|
|
The server of the current connection is used when <target> is omitted.
|
|
|
|
References:
|
|
- RFC 2812, 3.4.1 "Motd message"
|
|
|
|
- NAMES
|
|
NAMES [<channel>[,<channel>[,...]] [<target>]]
|
|
.
|
|
Show the list of users that are members of a particular <channel>
|
|
(and that are visible for the client requesting this information) as
|
|
seen by the server <target>. More than one <channel> can be given
|
|
separated by "," (but not whitespaces!).
|
|
.
|
|
If <channel> has been omitted, all visible users are shown, grouped
|
|
by channel name, and all visible users not being members of at least
|
|
one channel are shown as members of the pseudo channel "*".
|
|
.
|
|
<target> can be a server name, the nickname of a client connected to
|
|
a specific server, or a mask matching a server name in the network.
|
|
The server of the current connection is used when <target> is omitted.
|
|
|
|
References:
|
|
- RFC 2812, 3.2.5 "Names message"
|
|
|
|
- STATS
|
|
STATS [<query> [<target>]]
|
|
.
|
|
Show statistics and other information of type <query> of a particular
|
|
IRC server in the network.
|
|
.
|
|
The following <query> types are supported (case-insensitive where
|
|
applicable):
|
|
.
|
|
- g Network-wide bans ("G-Lines").
|
|
- k Server-local bans ("K-Lines").
|
|
- L Link status (servers and user links).
|
|
- l Link status (servers and own link).
|
|
- m Command usage count.
|
|
- u Server uptime.
|
|
.
|
|
<target> can be a server name, the nickname of a client connected to
|
|
a specific server, or a mask matching a server name in the network.
|
|
The server of the current connection is used when <target> is omitted.
|
|
.
|
|
To use "STATS L" the user must be an IRC Operator.
|
|
|
|
References:
|
|
- RFC 2812, 3.4.4 "Stats message"
|
|
|
|
- TIME
|
|
TIME [<target>]
|
|
.
|
|
Show the local time of an IRC server in the network.
|
|
.
|
|
<target> can be a server name, the nickname of a client connected to
|
|
a specific server, or a mask matching a server name in the network.
|
|
The server of the current connection is used when <target> is omitted.
|
|
|
|
References
|
|
- RFC 2812, 3.4.6 "Time message"
|
|
|
|
- TRACE
|
|
TRACE [<target>]
|
|
.
|
|
Find the route to a specific server and send information about its
|
|
peers. Each server that processes this command reports back to the
|
|
sender about it: the replies from pass-through servers form a chain
|
|
which shows the route to the destination.
|
|
.
|
|
<target> can be a server name, the nickname of a client connected to
|
|
a specific server, or a mask matching a server name in the network.
|
|
The server of the current connection is used when <target> is omitted.
|
|
|
|
References:
|
|
- RFC 2812, 3.4.8 "Trace message"
|
|
|
|
- USERHOST
|
|
USERHOST <nickname> [<nickname> [...]]
|
|
.
|
|
Show flags and the hostmasks (<user>@<host>) of the <nickname>s,
|
|
separated by spaces. The following flags are used:
|
|
.
|
|
- "-" The client is "away" (the mode "+a" is set on this client).
|
|
- "+" Client seems to be available, at least it isn't marked "away".
|
|
- "*" The client is an IRC operator (the mode "+o" is set).
|
|
|
|
References:
|
|
- RFC 2812, 4.8 "Userhost message"
|
|
|
|
- VERSION
|
|
VERSION [<target>]
|
|
.
|
|
Show version information about a particular IRC server in the network.
|
|
.
|
|
<target> can be a server name, the nickname of a client connected to
|
|
a specific server, or a mask matching a server name in the network.
|
|
The server of the current connection is used when <target> is omitted.
|
|
.
|
|
Please note: in normal operation, the version number ends in a dot
|
|
(".", for example "ngIRCd-20.1."). If it ends in ".1" (for example
|
|
"ngIRCd-20.1.1", same version than before!), the server is running in
|
|
debug-mode; and if it ends in ".2", the "network sniffer" is active!
|
|
Keep your privacy in mind ...
|
|
|
|
References:
|
|
- RFC 2812, 3.4.3 "Version message"
|
|
|
|
- WHO
|
|
WHO [<mask> ["o"]]
|
|
.
|
|
Show a list of users who match the <mask>, or all visible users when
|
|
the <mask> has been omitted. (Special case: the <mask> "0" is
|
|
equivalent to "*")
|
|
.
|
|
If the flag "o" is given, the server will only return information about
|
|
IRC Operators.
|
|
|
|
References:
|
|
- RFC 2812, 3.6.1 "Who query"
|
|
|
|
- WHOIS
|
|
WHOIS [<target>] <mask>[,<mask>[,...]]
|
|
.
|
|
Query information about users matching the <mask> parameter(s) as seen
|
|
by the server <target>; up to 3 <masks> are supported.
|
|
.
|
|
<target> can be a server name, the nickname of a client connected to a
|
|
specific server, or a mask matching a server name in the network. The
|
|
server of the current connection is used when <target> is omitted.
|
|
|
|
References:
|
|
- RFC 2812, 3.6.2 "Whois query"
|
|
|
|
- WHOWAS
|
|
WHOWAS <nickname>[,<nickname>[,...]] [<count> [<target>]]
|
|
.
|
|
Query information about nicknames no longer in use in the network,
|
|
either because of nickname changes or disconnects. The history is
|
|
searched backwards, returning the most recent entry first. If there
|
|
are multiple entries, up to <count> entries will be shown (or all of
|
|
them, if no <count> has been given).
|
|
.
|
|
<target> can be a server name, the nickname of a client connected to a
|
|
specific server, or a mask matching a server name in the network. The
|
|
server of the current connection is used when <target> is omitted.
|
|
|
|
References:
|
|
- RFC 2812, 3.6.3 "Whowas"
|
|
|
|
|
|
Channel Commands
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
- INVITE
|
|
INVITE <nickname> <channel>
|
|
.
|
|
Invite <nickname> to join channel <channel>.
|
|
.
|
|
<channel> does not have to exist, but if it does, only members of the
|
|
channel are allowed to invite other users. If the channel mode "+i"
|
|
is set, only channel "half-ops" (and above) may invite other clients,
|
|
and if channel mode "+V" is set, nobody can invite other users.
|
|
|
|
References:
|
|
- RFC 2812, 3.2.7 "Invite message"
|
|
|
|
- JOIN
|
|
JOIN {<channel>[,<channel>[,...]] [<key>[,<key>[,...]]] | 0}
|
|
.
|
|
Makes the client join the <channel> (comma-separated list), specifying
|
|
the channel keys ("passwords"). A <channel-key> is only needed if the
|
|
<channel> has the mode "+k" set.
|
|
.
|
|
If the channel(s) do not exist, then they will be created.
|
|
.
|
|
Using "JOIN 0" parts all channels at once.
|
|
|
|
References:
|
|
- RFC 2812, 3.2.1 "Join message" (client protocol)
|
|
- RFC 2813, 4.2.1 "Join message" (server protocol)
|
|
|
|
- KICK
|
|
KICK <channel>[,<channel>[,...]] <nickname>[,<nickname>[,...]] [<reason>]
|
|
.
|
|
Remove users(s) with <nickname>(s) from <channel>(s).
|
|
.
|
|
There must be either exactly one <channel> parameter and multiple
|
|
<nickname> parameters, or as many <channel> parameters as there are
|
|
<nickname> parameters. The <reason> is shown to the users being
|
|
kicked, and the nickname of the current user is used when <reason>
|
|
is omitted.
|
|
|
|
References:
|
|
- RFC 2812, 3.2.8 "Kick command"
|
|
|
|
- LIST
|
|
LIST [<mask>[,<mask>[,...]] [<server>]]
|
|
.
|
|
List all visible channels matching the <mask> (comma-separated list),
|
|
or all channels when no <mask> was specified.
|
|
.
|
|
If <server> is given, the command will be forwarded to <server> for
|
|
evaluation.
|
|
|
|
References:
|
|
- RFC 2812, 3.2.6 "List message"
|
|
|
|
- PART
|
|
PART <channel>[,<channel>[,...]] [<part-message>]
|
|
.
|
|
Leave <channel> (comma-separated list), optionally with sending a
|
|
<part-message> to all the other channel members.
|
|
|
|
References:
|
|
- RFC 2812, 3.2.2 "Part message"
|
|
|
|
- TOPIC
|
|
TOPIC <channel> [<topic>]
|
|
.
|
|
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.
|
|
|
|
References:
|
|
- RFC 2812, 3.2.4 "Topic message"
|
|
|
|
|
|
Administrative Commands
|
|
~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
- CONNECT
|
|
CONNECT <server> [<port> [<remote-server> [<my-pwd> <peer-pwd>]]]
|
|
.
|
|
Instructs the current server, or <remote-server> if specified,
|
|
to connect to the server named <server>, which must be configured
|
|
in the server configuration file.
|
|
.
|
|
To use this command, the user must be an IRC Operator. To establish
|
|
a connection on a <remote-server>, you must have remote IRC operator
|
|
privileges.
|
|
.
|
|
If <port>, <my-pwd> and <peer-pwd> are given, these values override
|
|
the ones specified in the server configuration file.
|
|
|
|
References:
|
|
- RFC 2812, 3.4.7 "Connect message"
|
|
|
|
- DIE
|
|
DIE [<message>]
|
|
.
|
|
Instructs the server to shut down.
|
|
.
|
|
The optional (and non-standard) <message> text is sent to each client
|
|
connected to this server before all connections are closed.
|
|
.
|
|
To use this command, the user must be an IRC Operator.
|
|
|
|
References:
|
|
- RFC 2812, 4.3 "Die message"
|
|
|
|
- DISCONNECT
|
|
DISCONNECT <server>
|
|
.
|
|
Disconnect and disable a locally linked server.
|
|
.
|
|
To use this command, the user must be an IRC Operator.
|
|
|
|
References:
|
|
- This command is not specified in the IRC RFCs, it is an extension
|
|
of ngIRCd.
|
|
|
|
- GLINE
|
|
GLINE <nick!user@hostmask> [<timeout> :<reason>]
|
|
.
|
|
This command provides timed G-Lines (network-wide bans).
|
|
.
|
|
If a client matches a G-Line, it cannot connect to any server on
|
|
the IRC network for <timeout> seconds. When <timeout> is 0, it make
|
|
the G-Line permanent.
|
|
.
|
|
If no <timeout> and no <reason> is given, the G-Line is removed.
|
|
.
|
|
To use this command, the user must be an IRC Operator.
|
|
.
|
|
"STATS g" can be used to list all currently active G-Lines.
|
|
|
|
References:
|
|
- This command is not specified in the IRC RFCs, it is an extension
|
|
of ngIRCd.
|
|
|
|
- KILL
|
|
KILL <nickname> <reason>
|
|
.
|
|
Forcibly remove all users with a given <nickname> from the IRC
|
|
network and display the given <reason> to them.
|
|
.
|
|
This command is used internally between servers, too, for example
|
|
to disconnect duplicate <nickname>'s after a "net split".
|
|
.
|
|
To use this command, the user must be an IRC Operator.
|
|
|
|
References:
|
|
- RFC 2812, 3.7.1 "Kill message"
|
|
|
|
- KLINE
|
|
KLINE <nick!user@hostmask> [<timeout> :<reason>]
|
|
.
|
|
This command provides timed K-Lines (server-local bans).
|
|
.
|
|
If a client matches a K-Line, it cannot connect to this server for
|
|
<timeout> seconds. When <timeout> is 0, it makes the K-Line permanent.
|
|
.
|
|
If no <timeout> and no <reason> is given, the K-Line is removed.
|
|
.
|
|
To use this command, the user must be an IRC Operator.
|
|
.
|
|
"STATS k" can be used to list all currently active K-Lines.
|
|
|
|
References:
|
|
- This command is not specified in the IRC RFCs, it is an extension
|
|
of ngIRCd.
|
|
|
|
- OPER
|
|
OPER <name> <password>
|
|
.
|
|
Authenticates a user named <name> as an IRC operator on the current
|
|
server/network.
|
|
.
|
|
This operator <name> must be configured in the server configuration.
|
|
.
|
|
Please note that <name> is NOT related to a nickname at all!
|
|
|
|
References:
|
|
- RFC 2812, 3.1.4 "Oper message"
|
|
|
|
- REHASH
|
|
REHASH
|
|
.
|
|
Causes the server to re-read and re-process its configuration file(s).
|
|
.
|
|
While rehashing, no new connections are accepted, but all already
|
|
established connections stay connected.
|
|
.
|
|
To use this command, the user must be an IRC Operator.
|
|
|
|
References:
|
|
- RFC 2812, 4.2 "Rehash message"
|
|
|
|
- RESTART
|
|
RESTART
|
|
.
|
|
Restart the server.
|
|
.
|
|
While restarting, all connections are reset and no new connections
|
|
are accepted.
|
|
.
|
|
To use this command, the user must be an IRC Operator.
|
|
|
|
References:
|
|
- RFC 2812, 4.4 "Restart message"
|
|
|
|
- WALLOPS
|
|
WALLOPS <message>
|
|
.
|
|
Sends <message> to all users with user mode "+w".
|
|
.
|
|
To use this command, the user must be an IRC Operator.
|
|
|
|
References:
|
|
- RFC 2812, 4.7 "Operwall message"
|
|
|
|
IRC Service Commands
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
|
|
- SERVICE
|
|
SERVICE <name> <reserved1> <distribution> <type> <reserved2> <info>
|
|
SERVICE <name> <servertoken> <distribution> {<type>|+<modes>} <hops> <info>
|
|
.
|
|
Register a new service in the network.
|
|
.
|
|
The first form is used by directly linked services and isn't supported
|
|
by ngIRCd at the moment. The second form announces services connected
|
|
to remote "pseudo-servers" ("services hubs").
|
|
.
|
|
The <distribution> and <type> parameters are ignored by ngIRCd.
|
|
|
|
References:
|
|
- RFC 2812, 3.1.6 "Service message"
|
|
- RFC 2813, 4.1.4 "Service message"
|
|
|
|
- SERVLIST
|
|
SERVLIST [<mask> [<type>]]
|
|
.
|
|
List all IRC services currently registered in the network.
|
|
.
|
|
The optional <mask> and <type> parameters can be used to limit the
|
|
listing to services matching the <mask> and that are of type <type>.
|
|
.
|
|
Please note that ngIRCd doesn't use any service types at the moment
|
|
and therefore all services are of type "0".
|
|
|
|
References:
|
|
- RFC 2812, 3.5.1 "Servlist message"
|
|
|
|
- SQUERY
|
|
SQUERY <target>[,<target>[,...]] <message>
|
|
.
|
|
Send a <message> to a given <target> IRC service, and report all
|
|
errors.
|
|
.
|
|
The "SQUERY" command exactly behaves like the "PRIVMSG" command, but
|
|
enforces that the <target> of the <message> is an IRC service.
|
|
Please see the help text of the "PRIVMSG" command for a detailed
|
|
description of the parameters!
|
|
.
|
|
If a user wants to interact with IRC services, he should use "SQUERY"
|
|
instead of "PRIVMSG" or "NOTICE": only "SQUERY makes sure that no
|
|
regular user, which uses the nickname of an IRC service, receives
|
|
the command in error, for example during a "net split"!
|
|
|
|
References:
|
|
- RFC 2812, 2.3.1 "Message format in Augmented BNF"
|
|
- RFC 2812, 3.3 "Sending messages"
|
|
- RFC 2812, 3.3.2 "Notice"
|
|
|
|
- SVSNICK
|
|
SVSNICK <oldnick> <newnick>
|
|
.
|
|
Forcefully change foreign user nicknames. This command is allowed
|
|
for servers only.
|
|
.
|
|
The "SVSNICK" command is forwarded to the server to which the user
|
|
with nickname <oldnick> is connected to, which in turn generates a
|
|
regular "NICK" command that then is sent to the client, so no special
|
|
support in the client software is required.
|
|
|
|
References:
|
|
- ngIRCd GIT commit e3f300d3231f
|
|
|
|
|
|
Server Protocol Commands
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
- CHANINFO
|
|
CHANINFO <channel> +<modes> [[<key> <limit>] <topic>]
|
|
.
|
|
CHANINFO is used by servers to inform each other about a channel:
|
|
its modes, channel key, user limits and its topic.
|
|
.
|
|
The CHANINFO command is allowed on server-links only.
|
|
|
|
References:
|
|
- IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
|
|
- IRC+, doc/Protocol.txt
|
|
|
|
- ERROR
|
|
ERROR [<message> [<> [...]]]
|
|
.
|
|
Inform a client or a server about an error condition. The first
|
|
parameter, if given, is logged by the server receiving the message,
|
|
all other parameters are silently ignored.
|
|
.
|
|
This command is silently ignored on non-server and non-service links
|
|
and shouldn't be used by regular IRC clients.
|
|
.
|
|
The ERROR message is also sent before terminating a regular client
|
|
connection.
|
|
|
|
References:
|
|
- RFC 2812, 3.7.4 "Error message"
|
|
|
|
- METADATA
|
|
METADATA <target> <key> <value>
|
|
.
|
|
The METADATA command is used on server-links to update "metadata"
|
|
information of clients, like the hostname, the info text ("real name"),
|
|
or the user name.
|
|
.
|
|
The METADATA command is allowed on server-links only.
|
|
|
|
References:
|
|
- IRC+, <http://ngircd.barton.de/doc/Protocol.txt>
|
|
- IRC+, doc/Protocol.txt
|
|
|
|
- NJOIN
|
|
NJOIN <channel> [<mode>]<nick>[,[<mode>]<nick>[,...]]
|
|
.
|
|
The NJOIN command is used on server-links to add users with <nick>
|
|
and <mode> to a <channel> while peering.
|
|
.
|
|
The NJOIN command is allowed on server-links only.
|
|
|
|
References:
|
|
- RFC 2813, 4.2.2 "Njoin message"
|
|
|
|
- SERVER
|
|
SERVER <servername> <info>
|
|
SERVER <servername> <hopcount> <info>
|
|
SERVER <servername> <hopcount> <token> <info>
|
|
.
|
|
The first form registers the local connection as a new server in the
|
|
network, the second (RFC 1459) and third (RFC 2812) form announce a
|
|
new remote server in the network.
|
|
.
|
|
The SERVER command is allowed on unregistered or server-links only.
|
|
|
|
References:
|
|
- RFC 1459, 4.1.4 "Server message"
|
|
- RFC 2813, 4.1.2 "Server message"
|
|
|
|
- SQUIT
|
|
SQUIT <server> <comment>
|
|
.
|
|
Disconnects an IRC Server from the network.
|
|
.
|
|
This command is used on server-links, but can be used by IRC Operators
|
|
to forcefully disconnect servers from the network, too.
|
|
|
|
References:
|
|
- RFC 2812, 3.1.8 "Squit"
|
|
- RFC 2813, 4.1.6 "Server quit message"
|
|
|
|
Dummy Commands
|
|
~~~~~~~~~~~~~~
|
|
|
|
- SUMMON
|
|
SUMMON <user> [<target> [<channel>]]
|
|
.
|
|
This command was intended to call people into IRC who are directly
|
|
connected to the terminal console of the IRC server -- but is
|
|
deprecated today. Therefore ngIRCd doesn't really implement this
|
|
command and always returns an error message, regardless of the
|
|
parameters given.
|
|
|
|
References:
|
|
- RFC 2812, 4.5 "Summon message"
|
|
|
|
- USERS
|
|
USERS [<target>]
|
|
.
|
|
This command was intended to list users directly logged in into the
|
|
console of the IRC server -- but is deprecated today. Therefore ngIRCd
|
|
doesn't really implement this command and always returns an error
|
|
message, regardless of the parameters given.
|
|
|
|
References:
|
|
- RFC 2812, 4.6 "Users"
|
|
|
|
- GET
|
|
GET [...]
|
|
.
|
|
Fake HTTP GET command. When received, the connection is shut down
|
|
immediately again to protect against crazy web browsers ...
|
|
|
|
References:
|
|
- ngIRCd GIT commit 33e8c2480649
|
|
|
|
- POST
|
|
POST [...]
|
|
.
|
|
Fake HTTP POST command. When received, the connection is shut down
|
|
immediately again to protect against crazy web browsers ...
|
|
|
|
References:
|
|
- ngIRCd GIT commit 33e8c2480649
|