TS6 protocol description
Written by Jilles Tjoelker
+Edits by Elizabeth Myers to add TS rules described by Lee Harvey.
General format: much like rfc1459
Maximum parameters for a command: 15 (this does not include the prefix
UIDs/SIDs (sending names or even wildcards is deprecated). This is done with
the function hunt_server(). Any rate limiting should be done locally.
+
duration: a parameter type used for ban durations. It is a duration in seconds.
A value of 0 means a permanent ban.
+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.
+
propagation: to which other servers the command is sent
For all commands with a hunted parameter, the propagation is determined by
Upon receiving the SERVER, the initiator will send SVINFO and the burst. If
ziplinks are used, SVINFO is the first compressed message.
-The burst consists of SID and SERVER messages for all known servers, 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).
+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).
user modes:
(all)
+v (prefix +) (voice)
type A
+b (ban)
-+e (ban exception)
-+I (invite exception)
++e (ban exception) (capab: EX)
++I (invite exception) (capab: IE)
type B
+k (key: password required to join, <= 23 ascii chars, no : or , or whitespace)
type C
+m (moderated)
+n (no external messages)
+p (private: does not appear in /whois to non-members, no /knock allowed)
-+r (only registered users may join) (only if a services server exists)
++r (only registered users may join) (only if a services server exists) (capab: SERVICES)
+s (secret)
+t (only chanops may change topic)
(charybdis TS6)
+g (allow any member to /invite)
+z (send messages blocked by +m to chanops)
+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.
+
+
<numeric>
source: server
parameters: target, any...
Changing away reason from one non-empty string to another non-empty string
may not be propagated.
+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.
+
+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.
+
+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.
+
BMASK
source: server
propagation: broadcast
propagation: none
parameters: space separated capability list
-Sends capabilities of the server. This must include QS and ENCAP. 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.
+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.
The capabilities may depend on the configuration for the server they are sent
to.
Error messages may contain IP addresses and have a negative effect on server
IP hiding.
+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.
+
ETRACE
encap only
encap target: single server
Introduces a client. The client is on the source server of this command.
-The account name is '0' if the user is not logged in with services.
+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.
+
+The account name is '*' if the user is not logged in with services.
Nick TS rules apply.
A JOIN is propagated with the new TS of the channel.
+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.
+
KICK
source: any
parameters: channel, target user, opt. reason
As form 1, deprecated.
KNOCK
+capab: KNOCK
source: user
parameters: channel
propagation: broadcast
Remote LUSERS request. Most servers ignore the server mask, treating it as '*'.
+MLOCK
+charybdis TS6
+source: services server
+parameters: channelTS, channel, mode letters
+propagation: broadcast (restricted)
+
+Propagates a channel mode lock change.
+
+If the channelTS is greater (newer) than the current TS of the channel, drop
+the message.
+
+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.
+
+An MLOCK message with no modes disables the MLOCK, therefore the MLOCK message
+always contains the literal MLOCK for simplicity.
+
MODE
1.
source: user
capab: RSFNC
encap target: single server
source: services server
-parameters: target user, new nickname, old nickTS, new nickTS
+parameters: target user, new nickname, new nickTS, old nickTS
Forces a nickname change and propagates it.
parameters: source uid, target uid, mode, data
Part of a SASL authentication exchange. The mode is 'C' to send some data
-(base64 encoded), or 'S' to end the exchange (data indicates type of
+(base64 encoded), or 'D' to end the exchange (data indicates type of
termination: 'A' for abort, 'F' for authentication failure, 'S' for
authentication success).
SJOIN
source: server
propagation: broadcast
-parameters: channelTS, simple modes, opt. mode parameters..., nicklist
+parameters: channelTS, channel, simple modes, opt. mode parameters..., nicklist
Broadcasts a channel creation or bursts a channel.
completes.
TB
+capab: TB
source: server
propagation: broadcast
-parameters:
+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.
TIME
source: user
TOPIC
source: user
propagation: broadcast
+parameters: channel, topic
Propagates a channel topic change. The server may verify that the source has
ops in the channel.
+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.
+
TRACE
source: user
1.
Introduces a client. The client is on the source server of this command.
+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.
+
Nick TS rules apply.
UNDLINE
Remote WHOIS request.
+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.
+
XLINE
1.
encap only
projects / solanum.git / blobdiff