$Id: ts6.txt 3211 2007-02-20 00:34:28Z jilles $ TS6 Proposal (v8) Written by Lee H Ideas borrowed heavily from ircnet (Beeth, jv, Q) - Changes between v7 and v8 - ----------------------------- In the v7 specification, the JOIN command included the channel modes of a channel, and acted on them following TS rules. In the v8 specification, JOIN will never send modes. Desyncs can occur both when they are sent and when they are not. If they are sent, then you can have a situation where a user on one side of the network issues "MODE #channel -l", and a user on another side of the network issues "JOIN #channel" whilst the +l still exists. As the JOIN string sent server<->server includes the full modes at the time of the user joining, this will propagate the +l, but there is a -l crossing in the other direction. Desync will occur beyond where they intersect. If the modes are not sent, then a lower TS JOIN command, or a JOIN command that creates a channel will cause a desync. It is judged that the desync with sending the modes is worse than the desync by not sending them, as such the v8 specification dictates modes are not sent with a JOIN command server<->server. The v8 specification also clarifies that servers may issue TMODE. - Introduction - ---------------- This document aims to fix some of the flaws that are still present in the current TS system. Whilst only one person may use a nickname at any one time, they are not a reliable method of directing commands between servers. Clients can change their nicknames, which can create desyncs. A reliable method of directing messages between servers is required so that a message will always reach the intended destination, even if the client changes nicks in between. UID solves this problem by ensuring that a client has a unique ID for the duration of his connection. This document also aims to solve the lack of TS rules to channel 'bans' on a netburst. Bans from both sides of a TS war (losing/winning) are kept. Bursting the bans with a TS solves this problem. There is also a race condition in the current TS system, where a user can issue a mode during a netburst and the mode will be set on the server we are bursting to. - Definitions - --------------- Throughout this document, the following terms are used: SID - A servers unique ID. This is three characters long and must be in the form [0-9][A-Z0-9][A-Z0-9] ID - A clients unique ID. This is six characters long and must be in the form [A-Z][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9]. The numbers [0-9] at the beginning of an ID are legal characters, but reserved for future use. UID - An ID concateneted to a SID. This forms the clients UID. TS6 - The TS version 6. - Support - ----------- Support for this document is given by the TS version 6. Wherever a destination parameter or source parameter is used, it must use the SID or UID if the server/client has one. A TS6 capable server must translate any SIDs/UIDs back into the server/clients name when communicating with a server that does not support TS6. A TS6 server must also support the QS (quitstorm) system, and the encap specification found here: http://www.leeh.co.uk/ircd/encap.txt The TS6 protocol does not supports masked entities. - 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. - The following commands are defined here as the TS6 protocol - --------------------------------------------------------------- - PASS - PASS TS : This command is used for password verification with the server we are connecting to. Due to the burst being sent on verification of the "SERVER" command, and "SVINFO" being sent after "SERVER", we need to be aware of the TS version earlier to decide whether to send a TS6 burst or not. The field is the password we have stored for this server, is our current TS version. If this field is not present then the server does not support TS6. is the SID of the server. - UID - : UID + : This command is used for introducing clients to the network. The field is the SID of the server the client is connected to. The field is the nick of the client being introduced. The field is the amount of server hops between the server being burst to and the server the client is on. The field is the TS of the client, either the time they connected or the time they last changed nick. The field contains the clients usermodes that need to be transmitted between servers. The field contains the clients username/ident. The field contains the clients host. The field contains the clients IP. If the IP is not to be sent (due to a spoof etc), the field must be sent as "0". The field is the clients UID. The field is the clients gecos. A server receiving a UID command must apply nick TS rules to the nick. - SID - : SID : This command is used for introducing servers to the network. The first field is the SID of the new servers uplink. The field is the new servers name. The field is the hops between the server being introduced nd the server being burst to. The second field is the SID of the new server. The field i is the new servers gecos. Upon receiving the SID command servers must check for a SID collision. Two servers must not be allowed to link to the network with the same SID. If a server detects a SID collision it must drop the link to the directly connected server through which the command was received. Client and servers which do not have a UID/SID must be introduced by old methods. - SJOIN - : SJOIN + : This command is used for introducing users to channels. The field is the SID of the server introducing users to the channel. The field is the channels current TS, is the channels current name, are the channels current modes. is a space delimited list of clients UIDs to join to the channel. Each clients UID is prefixed with their status on the channel, ie "@UID" for an opped user. Multiple prefixes are allowed, "peons" (clients without a status) are not prefixed. A server receiving an SJOIN must apply normal channel TS rules to the SJOIN. A TS6 server must not use the SJOIN command outside of a netburst to introduce a single user to an existing channel. It must instead use the "JOIN" command defined in this specification. A TS6 server must still use SJOIN for creating channels. - JOIN - : JOIN + This command is used for introducing one user unopped to an existing channel. The field is the UID of the client joining the channel. The field is the channels current TS, is the channels current name. A server receiving a JOIN must apply normal channel TS rules to the JOIN. No channel modes are sent with the JOIN command. In previous versions of this specification, the "+" parameter contained the channels current modes. A server following this version of the specification must not interpret this argument and must not propagate any value other than "+" for this parameter. It should be noted that whilst JOIN would not normally create a channel or lower the timestamp, during specific conditions it can. This can create a desync that this specification does not rectify. - BMASK - : BMASK : This command is used for bursting channel bans to a network. The field is the SID of the server bursting the bans. The field is the channels current TS, is the channels name. is a single character identifying the mode type (ie, for a ban 'b'). is a space delimited list of masks of the given mode,limited only in length to the size of the buffer as defined by RFC1459. A server receiving a BMASK must apply simple channel TS rules to the BMASK. A TS6 server must translate BMASKs into raw modes for non-TS6 capable servers. This command must be used only after SJOIN has been sent for the given channel. It should be noted however, that a BMASK with a lower TS should not be possible without a desync, due to it being sent after SJOIN. - TMODE - : TMODE This command is used for clients issuing modes on a channel. is either the UID of the client setting the mode, or the SID of the server setting the mode. is the current TS of the channel, is the channels name. is the raw mode the client is setting. A server receiving a TMODE must apply simple channel TS rules to the TMODE. A TS6 server must translate MODEs issued by a local client, or received from a server into TMODE to send to other TS6 capable servers.