1 TS6 protocol description
2 Written by Jilles Tjoelker
3 Edits by Elizabeth Myers to add TS rules described by Lee Harvey.
5 General format: much like rfc1459
6 Maximum parameters for a command: 15 (this does not include the prefix
9 SID: a server's unique ID. It is configured in each server and consists of
10 a digit and two alphanumerics. Sending SIDs with lowercase letters is
13 UID: a client's unique ID. It consists of the server's SID and six
14 alphanumerics (so it is nine characters long). The first of the alphanumerics
15 should be a letter, numbers are legal but reserved for future use.
17 hunted: a parameter type used for various remote requests. From local users,
18 nicknames and server names are accepted, possibly with wildcards; from servers,
19 UIDs/SIDs (sending names or even wildcards is deprecated). This is done with
20 the function hunt_server(). Any rate limiting should be done locally.
23 duration: a parameter type used for ban durations. It is a duration in seconds.
24 A value of 0 means a permanent ban.
26 IP addresses: IP addresses are converted to text in the usual way, including
27 '::' shortening in IPv6, with the exception that a zero is prepended to any
28 IP address that starts with a colon.
30 propagation: to which other servers the command is sent
32 For all commands with a hunted parameter, the propagation is determined by
33 that, and not otherwise specified.
35 For all commands with a target server mask parameter, the propagation is
36 determined by that, and not otherwise specified. The command is sent to all
37 servers with names matching the given mask (for example '*', '*.example.com',
38 'irc.example.com'). Those servers do not have to be directly connected.
39 Targets cannot be SIDs.
41 Propagation broadcast means the command is sent to all servers.
43 Propagation one-to-one means the command is only sent to the target or the
44 server the target is on.
46 Propagation none means the command is never sent to another server if it is
49 For some other commands, the propagation depends on the parameters and is
52 services server: server mentioned in a service{} block. There are no services
55 service: client with umode +S. This implies that it is on a services server.
58 The initiator sends the PASS, CAPAB and SERVER messages. Upon receiving the
59 SERVER, the listener will check the information, and if it is valid, it will
60 send its own PASS, CAPAB and SERVER messages, followed by SVINFO and the burst.
61 Upon receiving the SERVER, the initiator will send SVINFO and the burst. If
62 ziplinks are used, SVINFO is the first compressed message.
64 The burst consists of SID and SERVER messages for all known servers, BAN
65 messages for all propagated bans, UID or EUID messages for all known users
66 (possibly followed by ENCAP REALHOST, ENCAP LOGIN and/or AWAY) and SJOIN
67 messages for all known channels (possibly followed by BMASK and/or TB).
71 +D (deaf: does not receive channel messages)
72 +S (network service) (only settable on burst from a services server)
73 +a (appears as server administrator)
74 +i (invisible, see rfc1459)
75 +o (IRC operator, see rfc1459)
76 +w (wallops, see rfc1459) (always propagated for historical reasons)
78 +Q/+R/+g/+l/+s/+z (only locally effective)
79 +Z (ssl user) (only settable on burst)
80 possibly more added by modules
89 +e (ban exception) (capab: EX)
90 +I (invite exception) (capab: IE)
92 +k (key: password required to join, <= 23 ascii chars, no : or , or whitespace)
94 +l (limit: maximum number of members before further joins are disallowed)
97 +n (no external messages)
98 +p (private: does not appear in /whois to non-members, no /knock allowed)
99 +r (only registered users may join) (only if a services server exists) (capab: SERVICES)
101 +t (only chanops may change topic)
106 +f (forward: channel name <= 30 chars)
107 +j (join throttle: N:T with integer N and T)
109 +F (free target for +f)
111 +P (permanent: does not disappear when empty)
112 +Q (ignore forwards to this)
114 +g (allow any member to /invite)
115 +z (send messages blocked by +m to chanops)
118 A server receiving a command that requires nick TS rules must check for a
119 collision between an existing user, and the nick in the received message.
120 (the "new user"). The collisions must obey the rules specified in Nick TS
123 If the TS received is lower than the TS of the existing user the server will
124 collide the existing user if the clients user@host are different, if the
125 clients user@hosts are identical it will collide the new user.
127 If the TS received is equal to the TS of the existing user both clients are
130 If the TS received is higher than the TS of the existing user, the server
131 will collide the existing user if the user@hosts are identical, if the
132 clients user@host are different it will collide the new user and drop the
136 If both users are to be collided, we must issue a KILL for the existing
137 user to all servers. If the new user has a UID then we must also issue a
138 KILL for that UID back to the server sending us data causing the collision.
140 If only the existing user is being collided, we must issue a KILL for the
141 existing user to all servers except the server sending us data. If the
142 existing user has a UID and the server sending us data supports TS6 then
143 we must also issue a KILL for the existing users UID to the server sending
146 If only the new user is being collided, we must issue a KILL for the new user
147 back to the server sending us data if the new user has a UID.
150 A server receiving a command that requires normal channel TS rules must
151 apply the following rules to the command.
153 If the TS received is lower than our TS of the channel a TS6 server must
154 remove status modes (+ov etc) and channel modes (+nt etc). If the
155 originating server is TS6 capable (ie, it has a SID), the server must
156 also remove any ban modes (+b etc). The new modes and statuses are then
159 If any bans are removed, the server must send to non-TS6, directly connected
160 servers mode changes removing the bans after the command is propagated.
161 This prevents desync with banlists, and has to be sent after as clients are
162 still able to send mode changes before the triggering command arrives.
164 If the TS received is equal to our TS of the channel the server should keep
165 its current modes and accept the received modes and statuses.
167 If the TS received is higher than our TS of the channel the server should keep
168 its current modes and ignore the received modes and statuses. Any statuses
169 given in the received message will be removed. A server must mark clients
170 losing their op (+o) status who do not have a UID as 'deopped'. A server must
171 ignore any "MODE" commands from a user marked as 'deopped'.
173 Simple channel TS rules:
175 A server receiving a command that requires simple channel TS rules must
176 apply the following rules to the command.
178 If the TS received is lower, or equal to our TS of the channel the modes are
179 accepted. If the TS received is higher than our TS of the channel the modes
180 are ignored and dropped.
182 Simple channel TS rules do not affect current modes in the channel except
183 for the modes we are accepting.
188 parameters: target, any...
190 The command name should be three decimal ASCII digits.
192 Propagates a "numeric" command reply, such as from a remote WHOIS request.
194 If the first digit is 0 (indicating a reply about the local connection), it
195 should be changed to 1 before propagation or sending to a user.
197 Numerics to the local server may be sent to opers.
199 To avoid infinite loops, servers should not send any replies to numerics.
203 propagation: one-to-one
205 propagation: all servers with -D users on the channel
207 Numerics to channels are broken in some older servers.
213 Remote ADMIN request.
217 propagation: broadcast
218 parameters: opt. away reason
220 If the away reason is empty or not present, mark the user as not away.
221 Otherwise, mark the user as away.
223 Changing away reason from one non-empty string to another non-empty string
224 may not be propagated.
230 propagation: broadcast (restricted)
231 parameters: type, user mask, host mask, creation TS, duration, lifetime, oper, reason
233 Propagates a network wide ban.
235 The type is K for K:lines, R for resvs and X for X:lines; other types are
236 reserved. The user mask field is only used for K:lines; for resvs and X:lines
237 the field is ignored in input and sent as an asterisk.
239 The creation TS indicates when this ban was last modified. An incoming ban MUST
240 be ignored and not propagated if the creation TS is older than the creation TS
241 of the current ban. If the ban is identical, it SHOULD NOT be propagated to
242 avoid unnecessary network traffic. (Two changes to bans that set the TS to the
243 same value may cause desynchronization.)
245 The duration is 0 for an unban and relative to the creation TS for a ban.
246 When the duration has passed, the ban is no longer active but it may still
247 be necessary to remember it.
249 The lifetime is relative to the creation TS and indicates for how long this
250 ban needs to be remembered and propagated. This MUST be at least the duration.
251 Initially, it is usually set the same as the duration but when the ban is
252 modified later, it SHOULD be set such that the modified ban is remembered at
253 least as long as the original ban. This ensures that the original ban does not
254 revive via split servers. This requirement is only a SHOULD to allow for
255 implementations that only inject bans and do not remember any; implementations
256 that remember and propagate bans MUST set the lifetime appropriately.
258 The oper field indicates the oper that originally set the ban. If this message
259 is the initial propagation of a change, it SHOULD be sent as * (an asterisk).
261 The reason field indicates the reason for the ban. Any part after a | (vertical
262 bar) MUST NOT be shown to normal users. The rest of the field and the creation
263 TS and duration MAY be shown to normal users.
267 propagation: broadcast
268 parameters: channelTS, channel, type, space separated masks
270 If the channelTS in the message is greater (newer) than the current TS of
271 the channel, drop the message and do not propagate it.
273 Type is the mode letter of a ban-like mode. In efnet TS6 this is 'b', 'e' or
274 'I'. In charybdis TS6 additionally 'q' is possible.
276 Add all the masks to the given list of the channel.
278 All ban-like modes must be bursted using this command, not using MODE or TMODE.
281 source: unregistered server
283 parameters: space separated capability list
285 Sends capabilities of the server. This must include QS and ENCAP, and for
286 charybdis TS6 also EX and IE. It is also strongly recommended to include EX,
287 CHW, IE and KNOCK, and for charybdis TS6 also SAVE and EUID. For use with
288 services, SERVICES and RSFNC are strongly recommended.
290 The capabilities may depend on the configuration for the server they are sent
296 propagation: broadcast
297 parameters: client, new hostname
299 Changes the visible hostname of a client.
301 Opers are notified unless the source is a server or a service.
305 parameters: server to connect to, port, hunted
307 Remote connect request. A server WALLOPS should be sent by the receiving
310 The port can be 0 for the default port.
316 parameters: duration, mask, reason
318 Sets a D:line (IP ban checked directly after accepting connection).
320 The mask must be an IP address or CIDR mask.
324 parameters: "P"/"N", target, text
326 As PRIVMSG, but delivers an echo-message echo to the target; they will see
327 a PRIVMSG or NOTICE from themselves to the source.
331 parameters: target server mask, subcommand, opt. parameters...
333 Sends a command to matching servers. Propagation is independent of
334 understanding the subcommand.
336 Subcommands are listed elsewhere with "encap only".
339 source: server or unregistered server
341 parameters: error message
343 Reports a (usually fatal) error with the connection.
345 Error messages may contain IP addresses and have a negative effect on server
351 propagation: broadcast
352 parameters: channelTS, channel, topicTS, topic setter, opt. extensions, topic
354 Propagates a channel topic change or propagates a channel topic as part of a
357 If the channel had no topic yet, the channelTS in the message is lower (older)
358 than the current TS of the channel, or the channelTSes are equal and the
359 topicTS in the message is newer than the topicTS of the current topic on the
360 channel, set the topic with topicTS and topic setter, and propagate the
361 message. Otherwise ignore the message and do not propagate it.
363 Unlike a TB message, an ETB message can change the topicTS without changing
364 the topic text. In this case, the message should be propagated to servers but
365 local users should not be notified.
367 Services can send a channelTS of 0 to force restoring an older topic (unless
368 the channel's TS is 0). Therefore, the channelTS should be propagated as given
369 and should not be replaced by the current TS of the channel.
371 An ETB message with a newer channelTS can still set a topic on a channel
372 without topic. This corresponds to SJOIN not clearing the topic when lowering
375 If ETB comes from a user, it can be propagated to non-EOPMOD servers using
376 TOPIC, TB or a combination of TOPIC to clear the topic and TB to set a new
377 topic with topicTS. However, this can be somewhat noisy. On the other hand, if
378 ETB comes from a server, there is no way to force setting a newer topicTS. It
379 is possible to set the topic text but the incorrect topicTS may lead to desync
382 This document does not document the optional extensions between topic setter
387 encap target: single server
391 Remote ETRACE information request.
397 parameters: nickname, hopcount, nickTS, umodes, username, visible hostname, IP address, UID, real hostname, account name, gecos
398 propagation: broadcast
400 Introduces a client. The client is on the source server of this command.
402 The IP address MUST be '0' (a zero) if the true address is not sent such as
403 because of a spoof. Otherwise, and if there is no dynamic spoof (i.e. the
404 visible and real hostname are equal), the IP address MAY be shown to normal
407 The account name is '*' if the user is not logged in with services.
411 EUID is similar to UID but includes the ENCAP REALHOST and ENCAP LOGIN
418 parameters: space separated capability list
420 Capability list of remote server.
426 parameters: user mask, host mask, reason
427 propagation: broadcast
429 Propagates a G:line vote. Once votes from three different opers (based on
430 user@host mask) on three different servers have arrived, trigger the G:line.
431 Pending G:lines expire after some time, usually ten minutes. Triggered G:lines
432 expire after a configured time which may differ across servers.
434 Requests from server connections must be propagated, unless they are found to
435 be syntactically invalid (e.g. '!' in user mask). Therefore, disabling glines
436 must not affect propagation, and too wide glines, double votes and glines that
437 already exist locally must still be propagated.
439 Of course, servers are free to reject gline requests from their own operators.
446 parameters: user mask, host mask, reason
447 propagation: broadcast
449 Propagates a G:line removal vote. Once three votes have arrived (as with
450 G:lines), remove the G:line. Pending G:lines removals expire after some time,
453 Pending G:line removals do not interact with pending G:lines. Triggering a
454 G:line does not affect a pending G:line removal. Triggering a G:line removal
455 does not affect a pending G:line.
465 parameters: target user, channel, opt. channelTS
466 propagation: one-to-one
468 Invites a user to a channel.
470 If the channelTS is greater (newer) than the current TS of the channel, drop
473 Not sending the channelTS parameter is deprecated.
478 parameters: '0' (one ASCII zero)
479 propagation: broadcast
481 Parts the source user from all channels.
485 parameters: channelTS, channel, '+' (a plus sign)
486 propagation: broadcast
488 Joins the source user to the given channel. If the channel does not exist yet,
489 it is created with the given channelTS and no modes. If the channel already
490 exists and has a greater (newer) TS, wipe all simple modes and statuses and
491 change the TS, notifying local users of this but not servers (note that
492 ban-like modes remain intact; invites may or may not be cleared).
494 A JOIN is propagated with the new TS of the channel.
499 propagation: broadcast (restricted)
500 parameters: target server mask, add or delete, server name, oper, reason
502 Adds or removes a jupe for a server. If the server is presently connected,
503 it MUST be SQUIT by the server's uplink when the jupe is applied.
505 The oper field indicates the oper that originally set the jupe. If this message
506 is the initial propagation of a removal, it SHOULD be sent as * (an asterisk).
508 The reason field indicates the reason for the jupe. It SHOULD be displayed
509 as the linking error message to the juped server if it tries to reconnect.
513 parameters: channel, target user, opt. reason
514 propagation: broadcast
516 Kicks the target user from the given channel.
518 Unless the channel's TS is 0, no check is done whether the source user has ops.
520 Not sending the reason parameter is questionable.
524 parameters: target user, path
525 propagation: broadcast
527 Removes the user from the network.
529 The format of the path parameter is some sort of description of the source of
530 the kill followed by a space and a parenthesized reason. To avoid overflow,
531 it is recommended not to add anything to the path.
537 parameters: duration, user mask, host mask, reason
539 Sets a K:line (ban on user@host).
544 parameters: target server mask, duration, user mask, host mask, reason
546 As form 1, deprecated.
552 propagation: broadcast
554 Requests an invite to a channel that is locked somehow (+ikl). Notifies all
555 operators of the channel. (In charybdis, on +g channels all members are
558 This is broadcast so that each server can store when KNOCK was used last on
563 parameters: hunted, server mask
565 Remote LINKS request. The server mask limits which servers are listed.
573 Sends a message to operators (with umode +l set). This is intended to be
574 used for strict subsets of the network.
579 parameters: target server mask, text
581 As form 1, deprecated.
586 parameters: account name
588 In a burst, states that the source user is logged in as the account.
592 parameters: server mask, hunted
594 Remote LUSERS request. Most servers ignore the server mask, treating it as '*'.
598 source: services server
599 parameters: channelTS, channel, mode letters
600 propagation: broadcast (restricted)
602 Propagates a channel mode lock change.
604 If the channelTS is greater (newer) than the current TS of the channel, drop
607 The final parameter is a list of mode letters that may not be changed by local
608 users. This applies to setting or unsetting simple modes, and changing or
609 removing mode parameters.
611 An MLOCK message with no modes disables the MLOCK, therefore the MLOCK message
612 always contains the literal MLOCK for simplicity.
617 parameters: client, umode changes
618 propagation: broadcast
620 Propagates a user mode change. The client parameter must refer to the same user
623 Not all umodes are propagated to other servers.
627 parameters: channel, cmode changes, opt. cmode parameters...
629 Propagates a channel mode change.
631 This is deprecated because the channelTS is not included. If it is received,
632 it should be propagated as TMODE.
643 parameters: new nickname, new nickTS
644 propagation: broadcast
646 Propagates a nick change.
650 parameters: nickname, hopcount, nickTS, umodes, username, hostname, server, gecos
652 Historic TS5 user introduction. The user is on the server indicated by the
653 server parameter; the source server is meaningless (local link).
659 source: services server
660 parameters: duration, nickname
662 If duration is greater than 0, makes the given nickname unavailable for that
665 If duration is 0, removes a nick delay entry for the given nickname.
667 There may or may not be a client with the given nickname; this does not affect
672 parameters: msgtarget, message
674 As PRIVMSG, except NOTICE messages are sent out, server sources are permitted
675 and most error messages are suppressed.
677 Servers may not send '$$', '$#' and opers@server notices. Older servers may
678 not allow servers to send to specific statuses on a channel.
682 parameters: opername, privset
684 Sets the source user's oper name and privset. Sent after the +o mode change, or
685 during burst, to inform other servers of an oper's privileges.
691 parameters: command name, parameters
693 Reports operspy usage.
698 propagation: broadcast
700 Sends a message to operators (with umode +z set).
704 parameters: comma separated channel list, message
706 Parts the source user from the given channels.
709 source: unregistered server
710 parameters: password, 'TS', TS version, SID
712 Sends the server link password, TS version and SID.
716 parameters: origin, opt. destination server
718 Sends a PING to the destination server, which will reply with a PONG. If the
719 destination server parameter is not present, the server receiving the message
722 The origin field is not used in the server protocol. It is sent as the name
723 (not UID/SID) of the source.
725 Remote PINGs are used for end-of-burst detection, therefore all servers must
730 parameters: origin, destination
732 Routes a PONG back to the destination that originally sent the PING.
736 parameters: msgtarget, message
738 Sends a normal message (PRIVMSG) to the given target.
742 propagation: one-to-one
744 propagation: all servers with -D users on the channel
745 (cmode +m/+n should be checked everywhere, bans should not be checked
747 - a status character ('@'/'+') followed by a channel name, to send to users
748 with that status or higher only.
750 propagation: all servers with -D users with appropriate status
751 - '=' followed by a channel name, to send to chanops only, for cmode +z.
752 capab: CHW and EOPMOD
753 propagation: all servers with -D chanops
754 - a user@server message, to send to users on a specific server. The exact
755 meaning of the part before the '@' is not prescribed, except that "opers"
756 allows IRC operators to send to all IRC operators on the server in an
758 propagation: one-to-one
759 - a message to all users on server names matching a mask ('$$' followed by mask)
760 propagation: broadcast
761 Only allowed to IRC operators.
762 - a message to all users with hostnames matching a mask ('$#' followed by mask).
763 Note that this is often implemented poorly.
764 propagation: broadcast
765 Only allowed to IRC operators.
767 In charybdis TS6, services may send to any channel and to statuses on any
773 encap target: single server
777 Remote PRIVS information request.
783 Propagates quitting of a client. No QUIT should be sent for a client that
784 has been removed as result of a KILL message.
791 parameters: real hostname
793 In a burst, propagates the real host of a dynamically-spoofed user.
799 parameters: opt. rehash type
801 Remote REHASH request. If the rehash type is omitted, it is equivalent to
802 a regular /rehash, otherwise it is equivalent to /rehash <rehash type>.
808 parameters: duration, mask, reason
810 Sets a RESV, making a nickname mask or exact channel unavailable.
815 parameters: target server mask, duration, mask, reason
817 As form 1, deprecated.
822 encap target: single server
823 source: services server
824 parameters: target user, new nickname, new nickTS, old nickTS
826 Forces a nickname change and propagates it.
828 The command is ignored if the nick TS of the user is not equal to the old
829 nickTS parameter. If the new nickname already exists (and is not the target
830 user), it is killed first.
838 parameters: source uid, '*', 'S', sasl mechanism name
840 Requests that a SASL agent (a service) initiate the authentication process.
841 The source uid is that of an unregistered client. This is why it is not sent
845 encap target: single server
847 parameters: source uid, target uid, mode, data
849 Part of a SASL authentication exchange. The mode is 'C' to send some data
850 (base64 encoded), or 'D' to end the exchange (data indicates type of
851 termination: 'A' for abort, 'F' for authentication failure, 'S' for
852 authentication success).
857 parameters: source uid, '*', 'H', hostname, ip, tls
859 Provides information on a client. The "tls" data is either 'P' for a
860 plaintext connection or any other string for a TLS connection.
861 The source uid is that of an unregistered client. This is why it is not sent
867 propagation: broadcast
868 parameters: target uid, TS
870 Resolve a nick collision by changing a nickname to the UID.
872 The server should verify that the UID belongs to a registered user, the user
873 does not already have their UID as their nick and the TS matches the user's
874 nickTS. If not, drop the message.
876 SAVE should be propagated as a regular NICK change to links without SAVE capab.
881 source: unregistered server
882 parameters: server name, hopcount, server description
884 Registers the connection as a server. PASS and CAPAB must have been sent
885 before, SVINFO should be sent afterwards.
887 If there is no such server configured or authentication failed, the connection
890 This is propagated as a SID message.
894 propagation: broadcast
895 parameters: server name, hopcount, server description
897 Introduces a new TS5 server, directly connected to the source of this command.
898 This is only used for jupes as TS5 servers may do little else than existing.
902 propagation: broadcast
903 parameters: server name, hopcount, sid, server description
905 Introduces a new server, directly connected to the source of this command.
909 propagation: broadcast
910 parameters: new nickname, new username, new visible hostname, new nickTS, new login name
912 Broadcasts a change of several user parameters at once.
914 Currently only sent after an SVSLOGIN.
918 propagation: broadcast
919 parameters: channelTS, channel, simple modes, opt. mode parameters..., nicklist
921 Broadcasts a channel creation or bursts a channel.
923 The nicklist consists of users joining the channel, with status prefixes for
924 their status ('@+', '@', '+' or ''), for example:
925 '@+1JJAAAAAB +2JJAAAA4C 1JJAAAADS'. All users must be behind the source server
926 so it is not possible to use this message to force users to join a channel.
928 The interpretation depends on the channelTS and the current TS of the channel.
929 If either is 0, set the channel's TS to 0 and accept all modes. Otherwise, if
930 the incoming channelTS is greater (newer), ignore the incoming simple modes
931 and statuses and join and propagate just the users. If the incoming channelTS
932 is lower (older), wipe all modes and change the TS, notifying local users of
933 this but not servers (invites may be cleared). In the latter case, kick on
934 split riding may happen: if the key (+k) differs or the incoming simple modes
935 include +i, kick all local users, sending KICK messages to servers.
937 An SJOIN is propagated with the new TS and modes of the channel. The statuses
938 are propagated if and only if they were accepted.
940 SJOIN must be used to propagate channel creation and in netbursts. For regular
941 users joining channels, JOIN must be used. Pseudoservers may use SJOIN to join
948 parameters: snomask letter, text
950 Sends the text as a server notice from the source server to opers with the
954 parameters: target server, comment
956 Removes the target server and all servers and users behind it from the network.
958 If the target server is the receiving server or the local link this came from,
959 this is an announcement that the link is being closed.
961 Otherwise, if the target server is locally connected, the server should send
962 a WALLOPS announcing the SQUIT.
966 parameters: stats letter, hunted
968 Remote STATS request. Privileges are checked on the server executing the
974 source: services server
975 parameters: target user, new login name (optional)
977 If the new login name is not present or empty, mark the target user as not
978 logged in, otherwise mark the target user as logged in as the given account.
983 parameters: current TS version, minimum TS version, '0', current time
985 Verifies TS protocol compatibility and clock. If anything is not in order,
988 The current TS version is the highest version supported by the source server
989 and the minimum TS version is the lowest version supported.
991 The current time is sent as a TS in the usual way.
996 encap target: single server
997 source: services server
998 parameters: target, new nick, new username, new visible hostname, new login name
1000 Sent after successful SASL authentication.
1002 The target is a UID, typically an unregistered one.
1004 Any of the "new" parameters can be '*' to leave the corresponding field
1005 unchanged. The new login name can be '0' to log the user out.
1007 If the UID is registered on the network, a SIGNON with the changes will be
1008 broadcast, otherwise the changes will be stored, to be used when registration
1014 propagation: broadcast
1015 parameters: channel, topicTS, opt. topic setter, topic
1017 Propagates a channel topic as part of a burst.
1019 If the channel had no topic yet or the topicTS in the message is older than
1020 the topicTS of the current topic on the channel and the topics differ, set
1021 the topic with topicTS and topic setter, and propagate the message. Otherwise
1022 ignore the message and do not propagate it.
1024 If the topic setter is not present, use a server name instead.
1030 Remote TIME request.
1034 parameters: channelTS, channel, cmode changes, opt. cmode parameters...
1036 Propagates a channel mode change.
1038 If the channelTS is greater (newer) than the current TS of the channel, drop
1041 On input, only the limit on parameters per line restricts how many cmode
1042 parameters can be present. Apart from this, arbitrary modes shall be
1043 processed. Redundant modes may be dropped. For example, +n-n may be applied and
1044 propagated as +n-n, -n or (if the channel was already -n) nothing, but not as
1047 The parameter for mode -k (removing a key) shall be ignored.
1049 On output, at most ten cmode parameters should be sent; if there are more,
1050 multiple TMODE messages should be sent.
1054 propagation: broadcast
1055 parameters: channel, topic
1057 Propagates a channel topic change. The server may verify that the source has
1060 The topicTS shall be set to the current time and the topic setter shall be
1061 set indicating the source user. Note that this means that the topicTS of a
1062 topic set with TOPIC is not necessarily consistent across the network.
1069 Performs a trace to the target, sending 200 numerics from each server passing
1070 the message on. The target server sends a description of the target followed
1073 TRACE, STATS l and STATS L are the only commands using hunt_server that use the
1074 hunted parameter for more than just determining which server the command
1075 should be executed on.
1078 parameters: target name, hunted
1080 Executes a trace command on the target server. No 200 numerics are sent.
1081 The target name is a name, not a UID, and should be on the target server.
1085 propagation: broadcast
1086 parameters: nickname, hopcount, nickTS, umodes, username, visible hostname, IP address, UID, gecos
1087 propagation: broadcast
1089 Introduces a client. The client is on the source server of this command.
1091 The IP address MUST be '0' (a zero) if the true address is not sent such as
1092 because of a spoof. Otherwise, and if there is no dynamic spoof (ENCAP
1093 REALHOST, charybdis TS6 only), the IP address MAY be shown to normal users.
1095 Nick TS rules apply.
1103 Removes a D:line (IP ban checked directly after accepting connection).
1105 The mask must be an IP address or CIDR mask.
1111 parameters: user mask, host mask
1113 Removes a K:line (ban on user@host).
1118 parameters: target server mask, user mask, host mask
1120 As form 1, deprecated.
1133 parameters: target server mask, mask
1135 As form 1, deprecated.
1143 Removes an X:line (ban on realname).
1148 parameters: target server mask, mask
1150 As form 1, deprecated.
1156 Remote USERS request.
1162 Remote VERSION request.
1168 propagation: broadcast
1170 In efnet TS6, sends a message to operators (with umode +z set). This is a
1171 deprecated equivalent to OPERWALL.
1173 In charybdis TS6, sends a message to local users with umode +w set (or possibly
1174 another indication that WALLOPS messages should be sent), including non-opers.
1179 propagation: broadcast
1181 Sends a message to local users with umode +w set (or possibly another
1182 indication that WALLOPS messages should be sent).
1184 In efnet TS6 this may include non-opers, in charybdis TS6 this may only be
1189 parameters: hunted, target nick
1191 Remote WHOIS request.
1195 parameters: nickname, limit, hunted
1197 Remote WHOWAS request. Not implemented in all servers.
1199 Different from a local WHOWAS request, the limit is mandatory and servers should
1200 apply a maximum to it.
1206 parameters: duration, mask, reason
1208 Sets an X:line (ban on realname).
1213 parameters: target server mask, duration, mask, reason
1215 As form 1, deprecated.
1217 Local only commands (charybdis 3.1):