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
+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...
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
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.
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