2009-01-25 20:11:28 +00:00
|
|
|
TS6 protocol description
|
|
|
|
Written by Jilles Tjoelker
|
2016-03-06 04:37:42 +00:00
|
|
|
Edits by Elizabeth Myers to add TS rules described by Lee Harvey.
|
2009-01-25 20:11:28 +00:00
|
|
|
|
|
|
|
General format: much like rfc1459
|
|
|
|
Maximum parameters for a command: 15 (this does not include the prefix
|
|
|
|
and command name)
|
|
|
|
|
|
|
|
SID: a server's unique ID. It is configured in each server and consists of
|
|
|
|
a digit and two alphanumerics. Sending SIDs with lowercase letters is
|
|
|
|
questionable.
|
|
|
|
|
|
|
|
UID: a client's unique ID. It consists of the server's SID and six
|
|
|
|
alphanumerics (so it is nine characters long). The first of the alphanumerics
|
|
|
|
should be a letter, numbers are legal but reserved for future use.
|
|
|
|
|
|
|
|
hunted: a parameter type used for various remote requests. From local users,
|
|
|
|
nicknames and server names are accepted, possibly with wildcards; from servers,
|
|
|
|
UIDs/SIDs (sending names or even wildcards is deprecated). This is done with
|
|
|
|
the function hunt_server(). Any rate limiting should be done locally.
|
|
|
|
|
2016-03-06 04:37:42 +00:00
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
duration: a parameter type used for ban durations. It is a duration in seconds.
|
|
|
|
A value of 0 means a permanent ban.
|
|
|
|
|
2012-03-13 21:41:39 +00:00
|
|
|
IP addresses: IP addresses are converted to text in the usual way, including
|
|
|
|
'::' shortening in IPv6, with the exception that a zero is prepended to any
|
|
|
|
IP address that starts with a colon.
|
|
|
|
|
2009-02-05 19:10:34 +00:00
|
|
|
propagation: to which other servers the command is sent
|
|
|
|
|
|
|
|
For all commands with a hunted parameter, the propagation is determined by
|
|
|
|
that, and not otherwise specified.
|
|
|
|
|
|
|
|
For all commands with a target server mask parameter, the propagation is
|
|
|
|
determined by that, and not otherwise specified. The command is sent to all
|
|
|
|
servers with names matching the given mask (for example '*', '*.example.com',
|
|
|
|
'irc.example.com'). Those servers do not have to be directly connected.
|
|
|
|
Targets cannot be SIDs.
|
|
|
|
|
|
|
|
Propagation broadcast means the command is sent to all servers.
|
|
|
|
|
|
|
|
Propagation one-to-one means the command is only sent to the target or the
|
|
|
|
server the target is on.
|
|
|
|
|
|
|
|
Propagation none means the command is never sent to another server if it is
|
|
|
|
received.
|
|
|
|
|
|
|
|
For some other commands, the propagation depends on the parameters and is
|
|
|
|
described in text.
|
2009-01-25 20:11:28 +00:00
|
|
|
|
|
|
|
services server: server mentioned in a service{} block. There are no services
|
|
|
|
servers on EFnet.
|
|
|
|
|
|
|
|
service: client with umode +S. This implies that it is on a services server.
|
|
|
|
|
2009-01-30 16:08:59 +00:00
|
|
|
connection setup:
|
|
|
|
The initiator sends the PASS, CAPAB and SERVER messages. Upon receiving the
|
|
|
|
SERVER, the listener will check the information, and if it is valid, it will
|
|
|
|
send its own PASS, CAPAB and SERVER messages, followed by SVINFO and the burst.
|
|
|
|
Upon receiving the SERVER, the initiator will send SVINFO and the burst. If
|
|
|
|
ziplinks are used, SVINFO is the first compressed message.
|
|
|
|
|
2010-03-07 13:06:28 +00:00
|
|
|
The burst consists of SID and SERVER messages for all known servers, BAN
|
|
|
|
messages for all propagated bans, UID or EUID messages for all known users
|
|
|
|
(possibly followed by ENCAP REALHOST, ENCAP LOGIN and/or AWAY) and SJOIN
|
|
|
|
messages for all known channels (possibly followed by BMASK and/or TB).
|
2009-01-30 16:08:59 +00:00
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
user modes:
|
|
|
|
(all)
|
|
|
|
+D (deaf: does not receive channel messages)
|
|
|
|
+S (network service) (only settable on burst from a services server)
|
|
|
|
+a (appears as server administrator)
|
|
|
|
+i (invisible, see rfc1459)
|
|
|
|
+o (IRC operator, see rfc1459)
|
|
|
|
+w (wallops, see rfc1459) (always propagated for historical reasons)
|
|
|
|
(charybdis TS6)
|
|
|
|
+Q/+R/+g/+l/+s/+z (only locally effective)
|
|
|
|
+Z (ssl user) (only settable on burst)
|
|
|
|
possibly more added by modules
|
|
|
|
|
|
|
|
channel modes:
|
|
|
|
(all)
|
|
|
|
statuses
|
|
|
|
+o (prefix @) (ops)
|
|
|
|
+v (prefix +) (voice)
|
|
|
|
type A
|
|
|
|
+b (ban)
|
2009-12-25 23:25:52 +00:00
|
|
|
+e (ban exception) (capab: EX)
|
|
|
|
+I (invite exception) (capab: IE)
|
2009-01-25 20:11:28 +00:00
|
|
|
type B
|
|
|
|
+k (key: password required to join, <= 23 ascii chars, no : or , or whitespace)
|
|
|
|
type C
|
|
|
|
+l (limit: maximum number of members before further joins are disallowed)
|
|
|
|
type D
|
|
|
|
+m (moderated)
|
|
|
|
+n (no external messages)
|
|
|
|
+p (private: does not appear in /whois to non-members, no /knock allowed)
|
2009-12-25 23:25:52 +00:00
|
|
|
+r (only registered users may join) (only if a services server exists) (capab: SERVICES)
|
2009-01-25 20:11:28 +00:00
|
|
|
+s (secret)
|
|
|
|
+t (only chanops may change topic)
|
|
|
|
(charybdis TS6)
|
|
|
|
type A
|
|
|
|
+q (quiet)
|
|
|
|
type C
|
|
|
|
+f (forward: channel name <= 30 chars)
|
|
|
|
+j (join throttle: N:T with integer N and T)
|
|
|
|
type D
|
|
|
|
+F (free target for +f)
|
|
|
|
+L (large ban list)
|
|
|
|
+P (permanent: does not disappear when empty)
|
|
|
|
+Q (ignore forwards to this)
|
|
|
|
+c (strip colours)
|
|
|
|
+g (allow any member to /invite)
|
|
|
|
+z (send messages blocked by +m to chanops)
|
|
|
|
|
2016-03-06 04:37:42 +00:00
|
|
|
Nick TS rules:
|
|
|
|
A server receiving a command that requires nick TS rules must check for a
|
|
|
|
collision between an existing user, and the nick in the received message.
|
|
|
|
(the "new user"). The collisions must obey the rules specified in Nick TS
|
|
|
|
collisions.
|
|
|
|
|
|
|
|
If the TS received is lower than the TS of the existing user the server will
|
|
|
|
collide the existing user if the clients user@host are different, if the
|
|
|
|
clients user@hosts are identical it will collide the new user.
|
|
|
|
|
|
|
|
If the TS received is equal to the TS of the existing user both clients are
|
|
|
|
collided.
|
|
|
|
|
|
|
|
If the TS received is higher than the TS of the existing user, the server
|
|
|
|
will collide the existing user if the user@hosts are identical, if the
|
|
|
|
clients user@host are different it will collide the new user and drop the
|
|
|
|
message.
|
|
|
|
|
|
|
|
Nick TS collisions:
|
|
|
|
If both users are to be collided, we must issue a KILL for the existing
|
|
|
|
user to all servers. If the new user has a UID then we must also issue a
|
|
|
|
KILL for that UID back to the server sending us data causing the collision.
|
|
|
|
|
|
|
|
If only the existing user is being collided, we must issue a KILL for the
|
|
|
|
existing user to all servers except the server sending us data. If the
|
|
|
|
existing user has a UID and the server sending us data supports TS6 then
|
|
|
|
we must also issue a KILL for the existing users UID to the server sending
|
|
|
|
us data.
|
|
|
|
|
|
|
|
If only the new user is being collided, we must issue a KILL for the new user
|
|
|
|
back to the server sending us data if the new user has a UID.
|
|
|
|
|
|
|
|
Channel TS rules:
|
|
|
|
A server receiving a command that requires normal channel TS rules must
|
|
|
|
apply the following rules to the command.
|
|
|
|
|
|
|
|
If the TS received is lower than our TS of the channel a TS6 server must
|
|
|
|
remove status modes (+ov etc) and channel modes (+nt etc). If the
|
|
|
|
originating server is TS6 capable (ie, it has a SID), the server must
|
|
|
|
also remove any ban modes (+b etc). The new modes and statuses are then
|
|
|
|
accepted.
|
|
|
|
|
|
|
|
If any bans are removed, the server must send to non-TS6, directly connected
|
|
|
|
servers mode changes removing the bans after the command is propagated.
|
|
|
|
This prevents desync with banlists, and has to be sent after as clients are
|
|
|
|
still able to send mode changes before the triggering command arrives.
|
|
|
|
|
|
|
|
If the TS received is equal to our TS of the channel the server should keep
|
|
|
|
its current modes and accept the received modes and statuses.
|
|
|
|
|
|
|
|
If the TS received is higher than our TS of the channel the server should keep
|
|
|
|
its current modes and ignore the received modes and statuses. Any statuses
|
|
|
|
given in the received message will be removed. A server must mark clients
|
|
|
|
losing their op (+o) status who do not have a UID as 'deopped'. A server must
|
|
|
|
ignore any "MODE" commands from a user marked as 'deopped'.
|
|
|
|
|
|
|
|
Simple channel TS rules:
|
|
|
|
|
|
|
|
A server receiving a command that requires simple channel TS rules must
|
|
|
|
apply the following rules to the command.
|
|
|
|
|
|
|
|
If the TS received is lower, or equal to our TS of the channel the modes are
|
|
|
|
accepted. If the TS received is higher than our TS of the channel the modes
|
|
|
|
are ignored and dropped.
|
|
|
|
|
|
|
|
Simple channel TS rules do not affect current modes in the channel except
|
|
|
|
for the modes we are accepting.
|
|
|
|
|
|
|
|
|
2009-02-08 14:39:12 +00:00
|
|
|
<numeric>
|
|
|
|
source: server
|
|
|
|
parameters: target, any...
|
|
|
|
|
|
|
|
The command name should be three decimal ASCII digits.
|
|
|
|
|
|
|
|
Propagates a "numeric" command reply, such as from a remote WHOIS request.
|
|
|
|
|
|
|
|
If the first digit is 0 (indicating a reply about the local connection), it
|
|
|
|
should be changed to 1 before propagation or sending to a user.
|
|
|
|
|
|
|
|
Numerics to the local server may be sent to opers.
|
|
|
|
|
|
|
|
To avoid infinite loops, servers should not send any replies to numerics.
|
|
|
|
|
|
|
|
The target can be:
|
|
|
|
- a client
|
|
|
|
propagation: one-to-one
|
|
|
|
- a channel name
|
|
|
|
propagation: all servers with -D users on the channel
|
|
|
|
|
|
|
|
Numerics to channels are broken in some older servers.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
ADMIN
|
|
|
|
source: user
|
|
|
|
parameters: hunted
|
|
|
|
|
|
|
|
Remote ADMIN request.
|
|
|
|
|
|
|
|
AWAY
|
|
|
|
source: user
|
|
|
|
propagation: broadcast
|
|
|
|
parameters: opt. away reason
|
|
|
|
|
|
|
|
If the away reason is empty or not present, mark the user as not away.
|
|
|
|
Otherwise, mark the user as away.
|
|
|
|
|
|
|
|
Changing away reason from one non-empty string to another non-empty string
|
|
|
|
may not be propagated.
|
|
|
|
|
2010-03-07 13:06:28 +00:00
|
|
|
BAN
|
|
|
|
charybdis TS6
|
|
|
|
capab: BAN
|
|
|
|
source: any
|
|
|
|
propagation: broadcast (restricted)
|
|
|
|
parameters: type, user mask, host mask, creation TS, duration, lifetime, oper, reason
|
|
|
|
|
|
|
|
Propagates a network wide ban.
|
|
|
|
|
2010-04-28 22:26:49 +00:00
|
|
|
The type is K for K:lines, R for resvs and X for X:lines; other types are
|
|
|
|
reserved. The user mask field is only used for K:lines; for resvs and X:lines
|
|
|
|
the field is ignored in input and sent as an asterisk.
|
2010-03-07 13:06:28 +00:00
|
|
|
|
|
|
|
The creation TS indicates when this ban was last modified. An incoming ban MUST
|
|
|
|
be ignored and not propagated if the creation TS is older than the creation TS
|
|
|
|
of the current ban. If the ban is identical, it SHOULD NOT be propagated to
|
|
|
|
avoid unnecessary network traffic. (Two changes to bans that set the TS to the
|
|
|
|
same value may cause desynchronization.)
|
|
|
|
|
|
|
|
The duration is 0 for an unban and relative to the creation TS for a ban.
|
|
|
|
When the duration has passed, the ban is no longer active but it may still
|
|
|
|
be necessary to remember it.
|
|
|
|
|
|
|
|
The lifetime is relative to the creation TS and indicates for how long this
|
|
|
|
ban needs to be remembered and propagated. This MUST be at least the duration.
|
|
|
|
Initially, it is usually set the same as the duration but when the ban is
|
|
|
|
modified later, it SHOULD be set such that the modified ban is remembered at
|
|
|
|
least as long as the original ban. This ensures that the original ban does not
|
|
|
|
revive via split servers. This requirement is only a SHOULD to allow for
|
|
|
|
implementations that only inject bans and do not remember any; implementations
|
|
|
|
that remember and propagate bans MUST set the lifetime appropriately.
|
|
|
|
|
|
|
|
The oper field indicates the oper that originally set the ban. If this message
|
|
|
|
is the initial propagation of a change, it SHOULD be sent as * (an asterisk).
|
|
|
|
|
|
|
|
The reason field indicates the reason for the ban. Any part after a | (vertical
|
|
|
|
bar) MUST NOT be shown to normal users. The rest of the field and the creation
|
|
|
|
TS and duration MAY be shown to normal users.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
BMASK
|
|
|
|
source: server
|
|
|
|
propagation: broadcast
|
|
|
|
parameters: channelTS, channel, type, space separated masks
|
|
|
|
|
|
|
|
If the channelTS in the message is greater (newer) than the current TS of
|
|
|
|
the channel, drop the message and do not propagate it.
|
|
|
|
|
|
|
|
Type is the mode letter of a ban-like mode. In efnet TS6 this is 'b', 'e' or
|
|
|
|
'I'. In charybdis TS6 additionally 'q' is possible.
|
|
|
|
|
|
|
|
Add all the masks to the given list of the channel.
|
|
|
|
|
|
|
|
All ban-like modes must be bursted using this command, not using MODE or TMODE.
|
|
|
|
|
|
|
|
CAPAB
|
|
|
|
source: unregistered server
|
|
|
|
propagation: none
|
|
|
|
parameters: space separated capability list
|
|
|
|
|
2014-05-29 14:13:39 +00:00
|
|
|
Sends capabilities of the server. This must include QS and ENCAP, and for
|
|
|
|
charybdis TS6 also EX and IE. It is also strongly recommended to include EX,
|
|
|
|
CHW, IE and KNOCK, and for charybdis TS6 also SAVE and EUID. For use with
|
|
|
|
services, SERVICES and RSFNC are strongly recommended.
|
2009-01-30 16:08:59 +00:00
|
|
|
|
|
|
|
The capabilities may depend on the configuration for the server they are sent
|
|
|
|
to.
|
2009-01-25 20:11:28 +00:00
|
|
|
|
|
|
|
CHGHOST
|
|
|
|
charybdis TS6
|
|
|
|
source: any
|
|
|
|
propagation: broadcast
|
|
|
|
parameters: client, new hostname
|
|
|
|
|
|
|
|
Changes the visible hostname of a client.
|
|
|
|
|
|
|
|
Opers are notified unless the source is a server or a service.
|
|
|
|
|
|
|
|
CONNECT
|
|
|
|
source: any
|
|
|
|
parameters: server to connect to, port, hunted
|
|
|
|
|
|
|
|
Remote connect request. A server WALLOPS should be sent by the receiving
|
|
|
|
server.
|
|
|
|
|
|
|
|
The port can be 0 for the default port.
|
|
|
|
|
|
|
|
DLINE
|
|
|
|
charybdis TS6
|
|
|
|
encap only
|
|
|
|
source: user
|
|
|
|
parameters: duration, mask, reason
|
|
|
|
|
|
|
|
Sets a D:line (IP ban checked directly after accepting connection).
|
|
|
|
|
|
|
|
The mask must be an IP address or CIDR mask.
|
|
|
|
|
2022-08-20 00:35:54 +00:00
|
|
|
EBMASK
|
|
|
|
source: server
|
|
|
|
propagation: broadcast
|
|
|
|
parameters: channelTS, channel, type, space separated "masks ts hostmask" chunks
|
|
|
|
|
|
|
|
If the channelTS in the message is greater (newer) than the current TS of
|
|
|
|
the channel, drop the message and do not propagate it.
|
|
|
|
|
|
|
|
Type is the mode letter of a ban-like mode. In efnet TS6 this is 'b', 'e' or
|
|
|
|
'I'. In charybdis TS6 additionally 'q' is possible.
|
|
|
|
|
|
|
|
Add all the masks and their set at/by to the given list of the channel.
|
|
|
|
|
|
|
|
All ban-like modes must be bursted using this command, not using MODE or TMODE.
|
|
|
|
|
2020-11-06 17:48:15 +00:00
|
|
|
ECHO
|
|
|
|
source: user
|
|
|
|
parameters: "P"/"N", target, text
|
|
|
|
|
|
|
|
As PRIVMSG, but delivers an echo-message echo to the target; they will see
|
|
|
|
a PRIVMSG or NOTICE from themselves to the source.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
ENCAP
|
|
|
|
source: any
|
|
|
|
parameters: target server mask, subcommand, opt. parameters...
|
|
|
|
|
2009-02-05 19:10:34 +00:00
|
|
|
Sends a command to matching servers. Propagation is independent of
|
|
|
|
understanding the subcommand.
|
2009-01-25 20:11:28 +00:00
|
|
|
|
2009-02-05 19:10:34 +00:00
|
|
|
Subcommands are listed elsewhere with "encap only".
|
2009-01-25 20:11:28 +00:00
|
|
|
|
|
|
|
ERROR
|
|
|
|
source: server or unregistered server
|
|
|
|
propagation: none
|
|
|
|
parameters: error message
|
|
|
|
|
|
|
|
Reports a (usually fatal) error with the connection.
|
|
|
|
|
|
|
|
Error messages may contain IP addresses and have a negative effect on server
|
|
|
|
IP hiding.
|
|
|
|
|
2014-02-22 16:43:57 +00:00
|
|
|
ETB
|
|
|
|
capab: EOPMOD
|
|
|
|
source: any
|
|
|
|
propagation: broadcast
|
|
|
|
parameters: channelTS, channel, topicTS, topic setter, opt. extensions, topic
|
|
|
|
|
|
|
|
Propagates a channel topic change or propagates a channel topic as part of a
|
|
|
|
burst.
|
|
|
|
|
|
|
|
If the channel had no topic yet, the channelTS in the message is lower (older)
|
|
|
|
than the current TS of the channel, or the channelTSes are equal and the
|
|
|
|
topicTS in the message is newer than the topicTS of the current topic on the
|
|
|
|
channel, set the topic with topicTS and topic setter, and propagate the
|
|
|
|
message. Otherwise ignore the message and do not propagate it.
|
|
|
|
|
|
|
|
Unlike a TB message, an ETB message can change the topicTS without changing
|
|
|
|
the topic text. In this case, the message should be propagated to servers but
|
|
|
|
local users should not be notified.
|
|
|
|
|
|
|
|
Services can send a channelTS of 0 to force restoring an older topic (unless
|
|
|
|
the channel's TS is 0). Therefore, the channelTS should be propagated as given
|
|
|
|
and should not be replaced by the current TS of the channel.
|
|
|
|
|
|
|
|
An ETB message with a newer channelTS can still set a topic on a channel
|
|
|
|
without topic. This corresponds to SJOIN not clearing the topic when lowering
|
|
|
|
TS on a channel.
|
|
|
|
|
|
|
|
If ETB comes from a user, it can be propagated to non-EOPMOD servers using
|
|
|
|
TOPIC, TB or a combination of TOPIC to clear the topic and TB to set a new
|
|
|
|
topic with topicTS. However, this can be somewhat noisy. On the other hand, if
|
|
|
|
ETB comes from a server, there is no way to force setting a newer topicTS. It
|
|
|
|
is possible to set the topic text but the incorrect topicTS may lead to desync
|
|
|
|
later on.
|
|
|
|
|
|
|
|
This document does not document the optional extensions between topic setter
|
|
|
|
and topic.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
ETRACE
|
|
|
|
encap only
|
|
|
|
encap target: single server
|
|
|
|
source: oper
|
|
|
|
parameters: client
|
|
|
|
|
|
|
|
Remote ETRACE information request.
|
|
|
|
|
|
|
|
EUID
|
|
|
|
charybdis TS6
|
|
|
|
capab: EUID
|
|
|
|
source: server
|
|
|
|
parameters: nickname, hopcount, nickTS, umodes, username, visible hostname, IP address, UID, real hostname, account name, gecos
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
Introduces a client. The client is on the source server of this command.
|
|
|
|
|
2012-03-13 21:41:39 +00:00
|
|
|
The IP address MUST be '0' (a zero) if the true address is not sent such as
|
|
|
|
because of a spoof. Otherwise, and if there is no dynamic spoof (i.e. the
|
|
|
|
visible and real hostname are equal), the IP address MAY be shown to normal
|
|
|
|
users.
|
|
|
|
|
2012-04-30 16:32:04 +00:00
|
|
|
The account name is '*' if the user is not logged in with services.
|
2009-01-25 20:11:28 +00:00
|
|
|
|
|
|
|
Nick TS rules apply.
|
|
|
|
|
|
|
|
EUID is similar to UID but includes the ENCAP REALHOST and ENCAP LOGIN
|
|
|
|
information.
|
|
|
|
|
|
|
|
GCAP
|
|
|
|
encap only
|
|
|
|
encap target: *
|
|
|
|
source: server
|
|
|
|
parameters: space separated capability list
|
|
|
|
|
|
|
|
Capability list of remote server.
|
|
|
|
|
2009-03-01 00:03:58 +00:00
|
|
|
GLINE
|
|
|
|
efnet TS6
|
|
|
|
capab: GLN
|
|
|
|
source: user
|
|
|
|
parameters: user mask, host mask, reason
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
Propagates a G:line vote. Once votes from three different opers (based on
|
|
|
|
user@host mask) on three different servers have arrived, trigger the G:line.
|
|
|
|
Pending G:lines expire after some time, usually ten minutes. Triggered G:lines
|
|
|
|
expire after a configured time which may differ across servers.
|
|
|
|
|
|
|
|
Requests from server connections must be propagated, unless they are found to
|
|
|
|
be syntactically invalid (e.g. '!' in user mask). Therefore, disabling glines
|
|
|
|
must not affect propagation, and too wide glines, double votes and glines that
|
|
|
|
already exist locally must still be propagated.
|
|
|
|
|
|
|
|
Of course, servers are free to reject gline requests from their own operators.
|
|
|
|
|
2009-03-24 23:34:12 +00:00
|
|
|
GUNGLINE
|
|
|
|
efnet TS6
|
|
|
|
encap only
|
|
|
|
encap target: *
|
|
|
|
source: user
|
|
|
|
parameters: user mask, host mask, reason
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
Propagates a G:line removal vote. Once three votes have arrived (as with
|
|
|
|
G:lines), remove the G:line. Pending G:lines removals expire after some time,
|
|
|
|
usually ten minutes.
|
|
|
|
|
|
|
|
Pending G:line removals do not interact with pending G:lines. Triggering a
|
|
|
|
G:line does not affect a pending G:line removal. Triggering a G:line removal
|
|
|
|
does not affect a pending G:line.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
INFO
|
|
|
|
source: user
|
|
|
|
parameters: hunted
|
|
|
|
|
|
|
|
Remote INFO request.
|
|
|
|
|
|
|
|
INVITE
|
|
|
|
source: user
|
|
|
|
parameters: target user, channel, opt. channelTS
|
|
|
|
propagation: one-to-one
|
|
|
|
|
|
|
|
Invites a user to a channel.
|
|
|
|
|
|
|
|
If the channelTS is greater (newer) than the current TS of the channel, drop
|
|
|
|
the message.
|
|
|
|
|
|
|
|
Not sending the channelTS parameter is deprecated.
|
|
|
|
|
|
|
|
JOIN
|
|
|
|
1.
|
|
|
|
source: user
|
|
|
|
parameters: '0' (one ASCII zero)
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
Parts the source user from all channels.
|
|
|
|
|
|
|
|
2.
|
|
|
|
source: user
|
|
|
|
parameters: channelTS, channel, '+' (a plus sign)
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
Joins the source user to the given channel. If the channel does not exist yet,
|
|
|
|
it is created with the given channelTS and no modes. If the channel already
|
|
|
|
exists and has a greater (newer) TS, wipe all simple modes and statuses and
|
|
|
|
change the TS, notifying local users of this but not servers (note that
|
|
|
|
ban-like modes remain intact; invites may or may not be cleared).
|
|
|
|
|
2009-02-06 14:58:02 +00:00
|
|
|
A JOIN is propagated with the new TS of the channel.
|
|
|
|
|
2010-10-28 18:24:22 +00:00
|
|
|
JUPE
|
|
|
|
capab: JUPE
|
|
|
|
source: any
|
|
|
|
propagation: broadcast (restricted)
|
|
|
|
parameters: target server mask, add or delete, server name, oper, reason
|
|
|
|
|
|
|
|
Adds or removes a jupe for a server. If the server is presently connected,
|
|
|
|
it MUST be SQUIT by the server's uplink when the jupe is applied.
|
|
|
|
|
|
|
|
The oper field indicates the oper that originally set the jupe. If this message
|
|
|
|
is the initial propagation of a removal, it SHOULD be sent as * (an asterisk).
|
|
|
|
|
|
|
|
The reason field indicates the reason for the jupe. It SHOULD be displayed
|
|
|
|
as the linking error message to the juped server if it tries to reconnect.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
KICK
|
|
|
|
source: any
|
|
|
|
parameters: channel, target user, opt. reason
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
Kicks the target user from the given channel.
|
|
|
|
|
|
|
|
Unless the channel's TS is 0, no check is done whether the source user has ops.
|
|
|
|
|
|
|
|
Not sending the reason parameter is questionable.
|
|
|
|
|
|
|
|
KILL
|
|
|
|
source: any
|
|
|
|
parameters: target user, path
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
Removes the user from the network.
|
|
|
|
|
|
|
|
The format of the path parameter is some sort of description of the source of
|
|
|
|
the kill followed by a space and a parenthesized reason. To avoid overflow,
|
|
|
|
it is recommended not to add anything to the path.
|
|
|
|
|
|
|
|
KLINE
|
|
|
|
1.
|
|
|
|
encap only
|
|
|
|
source: user
|
|
|
|
parameters: duration, user mask, host mask, reason
|
|
|
|
|
|
|
|
Sets a K:line (ban on user@host).
|
|
|
|
|
|
|
|
2.
|
|
|
|
capab: KLN
|
|
|
|
source: user
|
|
|
|
parameters: target server mask, duration, user mask, host mask, reason
|
|
|
|
|
|
|
|
As form 1, deprecated.
|
|
|
|
|
|
|
|
KNOCK
|
2009-12-25 23:25:52 +00:00
|
|
|
capab: KNOCK
|
2009-01-25 20:11:28 +00:00
|
|
|
source: user
|
|
|
|
parameters: channel
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
Requests an invite to a channel that is locked somehow (+ikl). Notifies all
|
|
|
|
operators of the channel. (In charybdis, on +g channels all members are
|
|
|
|
notified.)
|
|
|
|
|
|
|
|
This is broadcast so that each server can store when KNOCK was used last on
|
|
|
|
a channel.
|
|
|
|
|
|
|
|
LINKS
|
|
|
|
source: user
|
|
|
|
parameters: hunted, server mask
|
|
|
|
|
|
|
|
Remote LINKS request. The server mask limits which servers are listed.
|
|
|
|
|
2009-02-05 18:57:51 +00:00
|
|
|
LOCOPS
|
|
|
|
1.
|
|
|
|
encap only
|
|
|
|
source: user
|
|
|
|
parameters: text
|
|
|
|
|
|
|
|
Sends a message to operators (with umode +l set). This is intended to be
|
|
|
|
used for strict subsets of the network.
|
|
|
|
|
|
|
|
2.
|
|
|
|
capab: CLUSTER
|
|
|
|
source: user
|
|
|
|
parameters: target server mask, text
|
|
|
|
|
|
|
|
As form 1, deprecated.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
LOGIN
|
|
|
|
encap only
|
|
|
|
source: user
|
|
|
|
parameters: account name
|
|
|
|
|
|
|
|
In a burst, states that the source user is logged in as the account.
|
|
|
|
|
|
|
|
LUSERS
|
|
|
|
source: user
|
|
|
|
parameters: server mask, hunted
|
|
|
|
|
|
|
|
Remote LUSERS request. Most servers ignore the server mask, treating it as '*'.
|
|
|
|
|
2010-03-08 03:51:41 +00:00
|
|
|
MLOCK
|
|
|
|
charybdis TS6
|
|
|
|
source: services server
|
2010-05-02 21:18:13 +00:00
|
|
|
parameters: channelTS, channel, mode letters
|
2010-03-08 03:51:41 +00:00
|
|
|
propagation: broadcast (restricted)
|
|
|
|
|
2010-05-02 21:18:13 +00:00
|
|
|
Propagates a channel mode lock change.
|
2010-03-08 03:51:41 +00:00
|
|
|
|
|
|
|
If the channelTS is greater (newer) than the current TS of the channel, drop
|
|
|
|
the message.
|
|
|
|
|
2010-05-02 21:18:13 +00:00
|
|
|
The final parameter is a list of mode letters that may not be changed by local
|
|
|
|
users. This applies to setting or unsetting simple modes, and changing or
|
|
|
|
removing mode parameters.
|
2010-03-08 03:51:41 +00:00
|
|
|
|
|
|
|
An MLOCK message with no modes disables the MLOCK, therefore the MLOCK message
|
|
|
|
always contains the literal MLOCK for simplicity.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
MODE
|
|
|
|
1.
|
|
|
|
source: user
|
|
|
|
parameters: client, umode changes
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
Propagates a user mode change. The client parameter must refer to the same user
|
|
|
|
as the source.
|
|
|
|
|
|
|
|
Not all umodes are propagated to other servers.
|
|
|
|
|
|
|
|
2.
|
|
|
|
source: any
|
|
|
|
parameters: channel, cmode changes, opt. cmode parameters...
|
|
|
|
|
|
|
|
Propagates a channel mode change.
|
|
|
|
|
|
|
|
This is deprecated because the channelTS is not included. If it is received,
|
|
|
|
it should be propagated as TMODE.
|
|
|
|
|
|
|
|
MOTD
|
|
|
|
source: user
|
|
|
|
parameters: hunted
|
|
|
|
|
|
|
|
Remote MOTD request.
|
|
|
|
|
|
|
|
NICK
|
|
|
|
1.
|
|
|
|
source: user
|
|
|
|
parameters: new nickname, new nickTS
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
Propagates a nick change.
|
|
|
|
|
|
|
|
2.
|
|
|
|
source: server
|
|
|
|
parameters: nickname, hopcount, nickTS, umodes, username, hostname, server, gecos
|
|
|
|
|
|
|
|
Historic TS5 user introduction. The user is on the server indicated by the
|
|
|
|
server parameter; the source server is meaningless (local link).
|
|
|
|
|
|
|
|
NICKDELAY
|
|
|
|
charybdis TS6
|
|
|
|
encap only
|
|
|
|
encap target: *
|
|
|
|
source: services server
|
|
|
|
parameters: duration, nickname
|
|
|
|
|
|
|
|
If duration is greater than 0, makes the given nickname unavailable for that
|
|
|
|
time.
|
|
|
|
|
|
|
|
If duration is 0, removes a nick delay entry for the given nickname.
|
|
|
|
|
|
|
|
There may or may not be a client with the given nickname; this does not affect
|
|
|
|
the operation.
|
|
|
|
|
|
|
|
NOTICE
|
|
|
|
source: any
|
|
|
|
parameters: msgtarget, message
|
|
|
|
|
|
|
|
As PRIVMSG, except NOTICE messages are sent out, server sources are permitted
|
|
|
|
and most error messages are suppressed.
|
|
|
|
|
2009-02-08 14:48:04 +00:00
|
|
|
Servers may not send '$$', '$#' and opers@server notices. Older servers may
|
|
|
|
not allow servers to send to specific statuses on a channel.
|
|
|
|
|
2019-07-07 01:36:58 +00:00
|
|
|
OPER
|
|
|
|
source: user
|
|
|
|
parameters: opername, privset
|
|
|
|
|
|
|
|
Sets the source user's oper name and privset. Sent after the +o mode change, or
|
|
|
|
during burst, to inform other servers of an oper's privileges.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
OPERSPY
|
|
|
|
encap only
|
|
|
|
encap target: *
|
|
|
|
source: user
|
|
|
|
parameters: command name, parameters
|
|
|
|
|
|
|
|
Reports operspy usage.
|
|
|
|
|
|
|
|
OPERWALL
|
|
|
|
source: user
|
|
|
|
parameters: message
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
Sends a message to operators (with umode +z set).
|
|
|
|
|
|
|
|
PART
|
|
|
|
source: user
|
|
|
|
parameters: comma separated channel list, message
|
|
|
|
|
|
|
|
Parts the source user from the given channels.
|
|
|
|
|
|
|
|
PASS
|
|
|
|
source: unregistered server
|
|
|
|
parameters: password, 'TS', TS version, SID
|
|
|
|
|
|
|
|
Sends the server link password, TS version and SID.
|
|
|
|
|
|
|
|
PING
|
|
|
|
source: any
|
2009-01-30 16:08:59 +00:00
|
|
|
parameters: origin, opt. destination server
|
2009-01-25 20:11:28 +00:00
|
|
|
|
2009-01-30 16:08:59 +00:00
|
|
|
Sends a PING to the destination server, which will reply with a PONG. If the
|
|
|
|
destination server parameter is not present, the server receiving the message
|
|
|
|
must reply.
|
2009-01-25 20:11:28 +00:00
|
|
|
|
2009-01-30 16:08:59 +00:00
|
|
|
The origin field is not used in the server protocol. It is sent as the name
|
|
|
|
(not UID/SID) of the source.
|
2009-01-25 20:11:28 +00:00
|
|
|
|
|
|
|
Remote PINGs are used for end-of-burst detection, therefore all servers must
|
|
|
|
implement them.
|
|
|
|
|
|
|
|
PONG
|
|
|
|
source: server
|
|
|
|
parameters: origin, destination
|
|
|
|
|
|
|
|
Routes a PONG back to the destination that originally sent the PING.
|
|
|
|
|
|
|
|
PRIVMSG
|
|
|
|
source: user
|
|
|
|
parameters: msgtarget, message
|
|
|
|
|
|
|
|
Sends a normal message (PRIVMSG) to the given target.
|
|
|
|
|
|
|
|
The target can be:
|
|
|
|
- a client
|
|
|
|
propagation: one-to-one
|
|
|
|
- a channel name
|
|
|
|
propagation: all servers with -D users on the channel
|
|
|
|
(cmode +m/+n should be checked everywhere, bans should not be checked
|
|
|
|
remotely)
|
|
|
|
- a status character ('@'/'+') followed by a channel name, to send to users
|
|
|
|
with that status or higher only.
|
2009-03-29 13:04:17 +00:00
|
|
|
capab: CHW
|
2009-01-25 20:11:28 +00:00
|
|
|
propagation: all servers with -D users with appropriate status
|
2009-03-29 13:48:07 +00:00
|
|
|
- '=' followed by a channel name, to send to chanops only, for cmode +z.
|
|
|
|
capab: CHW and EOPMOD
|
|
|
|
propagation: all servers with -D chanops
|
2009-01-25 20:11:28 +00:00
|
|
|
- a user@server message, to send to users on a specific server. The exact
|
|
|
|
meaning of the part before the '@' is not prescribed, except that "opers"
|
|
|
|
allows IRC operators to send to all IRC operators on the server in an
|
|
|
|
unspecified format.
|
|
|
|
propagation: one-to-one
|
|
|
|
- a message to all users on server names matching a mask ('$$' followed by mask)
|
|
|
|
propagation: broadcast
|
2009-02-08 14:48:04 +00:00
|
|
|
Only allowed to IRC operators.
|
2009-01-25 20:11:28 +00:00
|
|
|
- a message to all users with hostnames matching a mask ('$#' followed by mask).
|
|
|
|
Note that this is often implemented poorly.
|
|
|
|
propagation: broadcast
|
2009-02-08 14:48:04 +00:00
|
|
|
Only allowed to IRC operators.
|
|
|
|
|
|
|
|
In charybdis TS6, services may send to any channel and to statuses on any
|
|
|
|
channel.
|
2009-01-25 20:11:28 +00:00
|
|
|
|
|
|
|
PRIVS
|
|
|
|
charybdis TS6
|
|
|
|
encap only
|
|
|
|
encap target: single server
|
|
|
|
source: oper
|
|
|
|
parameters: client
|
|
|
|
|
|
|
|
Remote PRIVS information request.
|
|
|
|
|
|
|
|
QUIT
|
|
|
|
source: user
|
|
|
|
parameters: comment
|
|
|
|
|
|
|
|
Propagates quitting of a client. No QUIT should be sent for a client that
|
|
|
|
has been removed as result of a KILL message.
|
|
|
|
|
|
|
|
REALHOST
|
|
|
|
charybdis TS6
|
|
|
|
encap only
|
|
|
|
encap target: *
|
|
|
|
source: user
|
|
|
|
parameters: real hostname
|
|
|
|
|
|
|
|
In a burst, propagates the real host of a dynamically-spoofed user.
|
|
|
|
|
|
|
|
REHASH
|
|
|
|
charybdis TS6
|
|
|
|
encap only
|
|
|
|
source: user
|
|
|
|
parameters: opt. rehash type
|
|
|
|
|
|
|
|
Remote REHASH request. If the rehash type is omitted, it is equivalent to
|
|
|
|
a regular /rehash, otherwise it is equivalent to /rehash <rehash type>.
|
|
|
|
|
|
|
|
RESV
|
|
|
|
1.
|
|
|
|
encap only
|
|
|
|
source: user
|
|
|
|
parameters: duration, mask, reason
|
|
|
|
|
|
|
|
Sets a RESV, making a nickname mask or exact channel unavailable.
|
|
|
|
|
|
|
|
2.
|
|
|
|
capab: CLUSTER
|
|
|
|
source: user
|
|
|
|
parameters: target server mask, duration, mask, reason
|
|
|
|
|
|
|
|
As form 1, deprecated.
|
|
|
|
|
|
|
|
RSFNC
|
|
|
|
encap only
|
|
|
|
capab: RSFNC
|
|
|
|
encap target: single server
|
|
|
|
source: services server
|
2012-03-06 23:39:03 +00:00
|
|
|
parameters: target user, new nickname, new nickTS, old nickTS
|
2009-01-25 20:11:28 +00:00
|
|
|
|
|
|
|
Forces a nickname change and propagates it.
|
|
|
|
|
|
|
|
The command is ignored if the nick TS of the user is not equal to the old
|
|
|
|
nickTS parameter. If the new nickname already exists (and is not the target
|
|
|
|
user), it is killed first.
|
|
|
|
|
|
|
|
SASL
|
|
|
|
charybdis TS6
|
|
|
|
encap only
|
|
|
|
1.
|
|
|
|
encap target: *
|
|
|
|
source: server
|
|
|
|
parameters: source uid, '*', 'S', sasl mechanism name
|
|
|
|
|
|
|
|
Requests that a SASL agent (a service) initiate the authentication process.
|
|
|
|
The source uid is that of an unregistered client. This is why it is not sent
|
|
|
|
as the prefix.
|
|
|
|
|
|
|
|
2.
|
|
|
|
encap target: single server
|
|
|
|
source: server
|
|
|
|
parameters: source uid, target uid, mode, data
|
|
|
|
|
|
|
|
Part of a SASL authentication exchange. The mode is 'C' to send some data
|
2014-01-12 19:17:34 +00:00
|
|
|
(base64 encoded), or 'D' to end the exchange (data indicates type of
|
2009-01-25 20:11:28 +00:00
|
|
|
termination: 'A' for abort, 'F' for authentication failure, 'S' for
|
|
|
|
authentication success).
|
|
|
|
|
2017-08-09 21:04:11 +00:00
|
|
|
3.
|
|
|
|
encap target: *
|
|
|
|
source: server
|
|
|
|
parameters: source uid, '*', 'H', hostname, ip, tls
|
|
|
|
|
|
|
|
Provides information on a client. The "tls" data is either 'P' for a
|
|
|
|
plaintext connection or any other string for a TLS connection.
|
|
|
|
The source uid is that of an unregistered client. This is why it is not sent
|
|
|
|
as the prefix.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
SAVE
|
|
|
|
capab: SAVE
|
|
|
|
source: server
|
|
|
|
propagation: broadcast
|
|
|
|
parameters: target uid, TS
|
|
|
|
|
|
|
|
Resolve a nick collision by changing a nickname to the UID.
|
|
|
|
|
|
|
|
The server should verify that the UID belongs to a registered user, the user
|
|
|
|
does not already have their UID as their nick and the TS matches the user's
|
|
|
|
nickTS. If not, drop the message.
|
|
|
|
|
|
|
|
SAVE should be propagated as a regular NICK change to links without SAVE capab.
|
|
|
|
present.
|
|
|
|
|
|
|
|
SERVER
|
|
|
|
1.
|
|
|
|
source: unregistered server
|
|
|
|
parameters: server name, hopcount, server description
|
|
|
|
|
|
|
|
Registers the connection as a server. PASS and CAPAB must have been sent
|
|
|
|
before, SVINFO should be sent afterwards.
|
|
|
|
|
|
|
|
If there is no such server configured or authentication failed, the connection
|
|
|
|
should be dropped.
|
|
|
|
|
|
|
|
This is propagated as a SID message.
|
|
|
|
|
|
|
|
2.
|
|
|
|
source: server
|
|
|
|
propagation: broadcast
|
|
|
|
parameters: server name, hopcount, server description
|
|
|
|
|
|
|
|
Introduces a new TS5 server, directly connected to the source of this command.
|
|
|
|
This is only used for jupes as TS5 servers may do little else than existing.
|
|
|
|
|
|
|
|
SID
|
|
|
|
source: server
|
|
|
|
propagation: broadcast
|
|
|
|
parameters: server name, hopcount, sid, server description
|
|
|
|
|
|
|
|
Introduces a new server, directly connected to the source of this command.
|
|
|
|
|
|
|
|
SIGNON
|
|
|
|
source: user
|
|
|
|
propagation: broadcast
|
|
|
|
parameters: new nickname, new username, new visible hostname, new nickTS, new login name
|
|
|
|
|
|
|
|
Broadcasts a change of several user parameters at once.
|
|
|
|
|
|
|
|
Currently only sent after an SVSLOGIN.
|
|
|
|
|
|
|
|
SJOIN
|
|
|
|
source: server
|
|
|
|
propagation: broadcast
|
2013-05-15 07:27:40 +00:00
|
|
|
parameters: channelTS, channel, simple modes, opt. mode parameters..., nicklist
|
2009-01-25 20:11:28 +00:00
|
|
|
|
|
|
|
Broadcasts a channel creation or bursts a channel.
|
|
|
|
|
|
|
|
The nicklist consists of users joining the channel, with status prefixes for
|
|
|
|
their status ('@+', '@', '+' or ''), for example:
|
|
|
|
'@+1JJAAAAAB +2JJAAAA4C 1JJAAAADS'. All users must be behind the source server
|
|
|
|
so it is not possible to use this message to force users to join a channel.
|
|
|
|
|
|
|
|
The interpretation depends on the channelTS and the current TS of the channel.
|
|
|
|
If either is 0, set the channel's TS to 0 and accept all modes. Otherwise, if
|
|
|
|
the incoming channelTS is greater (newer), ignore the incoming simple modes
|
|
|
|
and statuses and join and propagate just the users. If the incoming channelTS
|
|
|
|
is lower (older), wipe all modes and change the TS, notifying local users of
|
|
|
|
this but not servers (invites may be cleared). In the latter case, kick on
|
|
|
|
split riding may happen: if the key (+k) differs or the incoming simple modes
|
|
|
|
include +i, kick all local users, sending KICK messages to servers.
|
|
|
|
|
2009-02-06 14:58:02 +00:00
|
|
|
An SJOIN is propagated with the new TS and modes of the channel. The statuses
|
|
|
|
are propagated if and only if they were accepted.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
SJOIN must be used to propagate channel creation and in netbursts. For regular
|
|
|
|
users joining channels, JOIN must be used. Pseudoservers may use SJOIN to join
|
|
|
|
a user with ops.
|
|
|
|
|
|
|
|
SNOTE
|
|
|
|
charybdis TS6
|
|
|
|
encap only
|
|
|
|
source: server
|
|
|
|
parameters: snomask letter, text
|
|
|
|
|
|
|
|
Sends the text as a server notice from the source server to opers with the
|
|
|
|
given snomask set.
|
|
|
|
|
|
|
|
SQUIT
|
|
|
|
parameters: target server, comment
|
|
|
|
|
|
|
|
Removes the target server and all servers and users behind it from the network.
|
|
|
|
|
|
|
|
If the target server is the receiving server or the local link this came from,
|
|
|
|
this is an announcement that the link is being closed.
|
|
|
|
|
|
|
|
Otherwise, if the target server is locally connected, the server should send
|
|
|
|
a WALLOPS announcing the SQUIT.
|
|
|
|
|
|
|
|
STATS
|
|
|
|
source: user
|
|
|
|
parameters: stats letter, hunted
|
|
|
|
|
|
|
|
Remote STATS request. Privileges are checked on the server executing the
|
|
|
|
actual request.
|
|
|
|
|
|
|
|
SU
|
|
|
|
encap only
|
|
|
|
encap target: *
|
|
|
|
source: services server
|
|
|
|
parameters: target user, new login name (optional)
|
|
|
|
|
|
|
|
If the new login name is not present or empty, mark the target user as not
|
|
|
|
logged in, otherwise mark the target user as logged in as the given account.
|
|
|
|
|
|
|
|
SVINFO
|
|
|
|
source: server
|
|
|
|
propagation: none
|
|
|
|
parameters: current TS version, minimum TS version, '0', current time
|
|
|
|
|
|
|
|
Verifies TS protocol compatibility and clock. If anything is not in order,
|
|
|
|
the link is dropped.
|
|
|
|
|
|
|
|
The current TS version is the highest version supported by the source server
|
|
|
|
and the minimum TS version is the lowest version supported.
|
|
|
|
|
|
|
|
The current time is sent as a TS in the usual way.
|
|
|
|
|
|
|
|
SVSLOGIN
|
|
|
|
charybdis TS6
|
|
|
|
encap only
|
|
|
|
encap target: single server
|
|
|
|
source: services server
|
|
|
|
parameters: target, new nick, new username, new visible hostname, new login name
|
|
|
|
|
|
|
|
Sent after successful SASL authentication.
|
|
|
|
|
|
|
|
The target is a UID, typically an unregistered one.
|
|
|
|
|
|
|
|
Any of the "new" parameters can be '*' to leave the corresponding field
|
|
|
|
unchanged. The new login name can be '0' to log the user out.
|
|
|
|
|
|
|
|
If the UID is registered on the network, a SIGNON with the changes will be
|
|
|
|
broadcast, otherwise the changes will be stored, to be used when registration
|
|
|
|
completes.
|
|
|
|
|
|
|
|
TB
|
2009-03-29 20:05:59 +00:00
|
|
|
capab: TB
|
2009-01-25 20:11:28 +00:00
|
|
|
source: server
|
|
|
|
propagation: broadcast
|
2009-03-29 20:05:59 +00:00
|
|
|
parameters: channel, topicTS, opt. topic setter, topic
|
|
|
|
|
|
|
|
Propagates a channel topic as part of a burst.
|
|
|
|
|
|
|
|
If the channel had no topic yet or the topicTS in the message is older than
|
|
|
|
the topicTS of the current topic on the channel and the topics differ, set
|
|
|
|
the topic with topicTS and topic setter, and propagate the message. Otherwise
|
|
|
|
ignore the message and do not propagate it.
|
|
|
|
|
|
|
|
If the topic setter is not present, use a server name instead.
|
2009-01-25 20:11:28 +00:00
|
|
|
|
|
|
|
TIME
|
|
|
|
source: user
|
|
|
|
parameters: hunted
|
|
|
|
|
|
|
|
Remote TIME request.
|
|
|
|
|
|
|
|
TMODE
|
|
|
|
source: any
|
|
|
|
parameters: channelTS, channel, cmode changes, opt. cmode parameters...
|
|
|
|
|
|
|
|
Propagates a channel mode change.
|
|
|
|
|
|
|
|
If the channelTS is greater (newer) than the current TS of the channel, drop
|
|
|
|
the message.
|
|
|
|
|
|
|
|
On input, only the limit on parameters per line restricts how many cmode
|
|
|
|
parameters can be present. Apart from this, arbitrary modes shall be
|
|
|
|
processed. Redundant modes may be dropped. For example, +n-n may be applied and
|
|
|
|
propagated as +n-n, -n or (if the channel was already -n) nothing, but not as
|
|
|
|
+n.
|
|
|
|
|
|
|
|
The parameter for mode -k (removing a key) shall be ignored.
|
|
|
|
|
|
|
|
On output, at most ten cmode parameters should be sent; if there are more,
|
|
|
|
multiple TMODE messages should be sent.
|
|
|
|
|
|
|
|
TOPIC
|
|
|
|
source: user
|
|
|
|
propagation: broadcast
|
2009-03-29 20:05:59 +00:00
|
|
|
parameters: channel, topic
|
2009-01-25 20:11:28 +00:00
|
|
|
|
|
|
|
Propagates a channel topic change. The server may verify that the source has
|
|
|
|
ops in the channel.
|
|
|
|
|
2009-03-29 20:05:59 +00:00
|
|
|
The topicTS shall be set to the current time and the topic setter shall be
|
|
|
|
set indicating the source user. Note that this means that the topicTS of a
|
|
|
|
topic set with TOPIC is not necessarily consistent across the network.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
TRACE
|
|
|
|
source: user
|
|
|
|
1.
|
|
|
|
parameters: hunted
|
|
|
|
|
|
|
|
Performs a trace to the target, sending 200 numerics from each server passing
|
|
|
|
the message on. The target server sends a description of the target followed
|
|
|
|
by a 262 numeric.
|
|
|
|
|
|
|
|
TRACE, STATS l and STATS L are the only commands using hunt_server that use the
|
|
|
|
hunted parameter for more than just determining which server the command
|
|
|
|
should be executed on.
|
|
|
|
|
|
|
|
2.
|
|
|
|
parameters: target name, hunted
|
|
|
|
|
|
|
|
Executes a trace command on the target server. No 200 numerics are sent.
|
|
|
|
The target name is a name, not a UID, and should be on the target server.
|
|
|
|
|
|
|
|
UID
|
|
|
|
source: server
|
|
|
|
propagation: broadcast
|
|
|
|
parameters: nickname, hopcount, nickTS, umodes, username, visible hostname, IP address, UID, gecos
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
Introduces a client. The client is on the source server of this command.
|
|
|
|
|
2012-03-13 21:41:39 +00:00
|
|
|
The IP address MUST be '0' (a zero) if the true address is not sent such as
|
|
|
|
because of a spoof. Otherwise, and if there is no dynamic spoof (ENCAP
|
|
|
|
REALHOST, charybdis TS6 only), the IP address MAY be shown to normal users.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
Nick TS rules apply.
|
|
|
|
|
|
|
|
UNDLINE
|
|
|
|
charybdis TS6
|
|
|
|
encap only
|
|
|
|
source: user
|
|
|
|
parameters: mask
|
|
|
|
|
|
|
|
Removes a D:line (IP ban checked directly after accepting connection).
|
|
|
|
|
|
|
|
The mask must be an IP address or CIDR mask.
|
|
|
|
|
|
|
|
UNKLINE
|
|
|
|
1.
|
|
|
|
encap only
|
|
|
|
source: user
|
|
|
|
parameters: user mask, host mask
|
|
|
|
|
|
|
|
Removes a K:line (ban on user@host).
|
|
|
|
|
|
|
|
2.
|
|
|
|
capab: UNKLN
|
|
|
|
source: user
|
|
|
|
parameters: target server mask, user mask, host mask
|
|
|
|
|
|
|
|
As form 1, deprecated.
|
|
|
|
|
|
|
|
UNRESV
|
|
|
|
1.
|
|
|
|
encap only
|
|
|
|
source: user
|
|
|
|
parameters: mask
|
|
|
|
|
|
|
|
Removes a RESV.
|
|
|
|
|
|
|
|
2.
|
|
|
|
capab: CLUSTER
|
|
|
|
source: user
|
|
|
|
parameters: target server mask, mask
|
|
|
|
|
|
|
|
As form 1, deprecated.
|
|
|
|
|
|
|
|
UNXLINE
|
|
|
|
1.
|
|
|
|
encap only
|
|
|
|
source: user
|
|
|
|
parameters: mask
|
|
|
|
|
|
|
|
Removes an X:line (ban on realname).
|
|
|
|
|
|
|
|
2.
|
|
|
|
capab: CLUSTER
|
|
|
|
source: user
|
|
|
|
parameters: target server mask, mask
|
|
|
|
|
|
|
|
As form 1, deprecated.
|
|
|
|
|
|
|
|
USERS
|
|
|
|
source: user
|
|
|
|
parameters: hunted
|
|
|
|
|
|
|
|
Remote USERS request.
|
|
|
|
|
|
|
|
VERSION
|
|
|
|
source: any
|
|
|
|
parameters: hunted
|
|
|
|
|
|
|
|
Remote VERSION request.
|
|
|
|
|
|
|
|
WALLOPS
|
|
|
|
1.
|
|
|
|
source: user
|
|
|
|
parameters: message
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
In efnet TS6, sends a message to operators (with umode +z set). This is a
|
|
|
|
deprecated equivalent to OPERWALL.
|
|
|
|
|
|
|
|
In charybdis TS6, sends a message to local users with umode +w set (or possibly
|
|
|
|
another indication that WALLOPS messages should be sent), including non-opers.
|
|
|
|
|
|
|
|
2.
|
|
|
|
source: server
|
|
|
|
parameters: message
|
|
|
|
propagation: broadcast
|
|
|
|
|
|
|
|
Sends a message to local users with umode +w set (or possibly another
|
|
|
|
indication that WALLOPS messages should be sent).
|
|
|
|
|
|
|
|
In efnet TS6 this may include non-opers, in charybdis TS6 this may only be
|
|
|
|
sent to opers.
|
|
|
|
|
|
|
|
WHOIS
|
|
|
|
source: user
|
|
|
|
parameters: hunted, target nick
|
|
|
|
|
|
|
|
Remote WHOIS request.
|
|
|
|
|
2013-09-13 20:29:26 +00:00
|
|
|
WHOWAS
|
|
|
|
source: user
|
|
|
|
parameters: nickname, limit, hunted
|
|
|
|
|
|
|
|
Remote WHOWAS request. Not implemented in all servers.
|
|
|
|
|
|
|
|
Different from a local WHOWAS request, the limit is mandatory and servers should
|
|
|
|
apply a maximum to it.
|
|
|
|
|
2009-01-25 20:11:28 +00:00
|
|
|
XLINE
|
|
|
|
1.
|
|
|
|
encap only
|
|
|
|
source: user
|
|
|
|
parameters: duration, mask, reason
|
|
|
|
|
|
|
|
Sets an X:line (ban on realname).
|
|
|
|
|
|
|
|
2.
|
|
|
|
capab: CLUSTER
|
|
|
|
source: user
|
|
|
|
parameters: target server mask, duration, mask, reason
|
|
|
|
|
|
|
|
As form 1, deprecated.
|
|
|
|
|
|
|
|
Local only commands (charybdis 3.1):
|
|
|
|
|
|
|
|
ACCEPT
|
|
|
|
AUTHENTICATE
|
|
|
|
CAP
|
|
|
|
CHALLENGE
|
|
|
|
CHANTRACE
|
|
|
|
CLOSE
|
|
|
|
DIE
|
|
|
|
GET
|
|
|
|
HELP
|
|
|
|
ISON
|
|
|
|
LIST
|
|
|
|
MAP
|
|
|
|
MASKTRACE
|
|
|
|
MODLIST
|
|
|
|
MODLOAD
|
|
|
|
MODRELOAD
|
|
|
|
MODRESTART
|
|
|
|
MODUNLOAD
|
|
|
|
MONITOR
|
|
|
|
NAMES
|
|
|
|
POST
|
|
|
|
PUT
|
|
|
|
RESTART
|
|
|
|
SCAN
|
|
|
|
SET
|
|
|
|
TESTGECOS
|
|
|
|
TESTLINE
|
|
|
|
TESTMASK
|
|
|
|
UHELP
|
|
|
|
UNREJECT
|
|
|
|
USER
|
|
|
|
USERHOST
|
|
|
|
WEBIRC
|
|
|
|
WHO
|
|
|
|
WHOWAS
|