doc/technical/ts6.txt

   1 $Id: ts6.txt 3211 2007-02-20 00:34:28Z jilles $
   2
   3 TS6 Proposal (v8)
   4 Written by Lee H <lee@leeh.co.uk>
   5 Ideas borrowed heavily from ircnet (Beeth, jv, Q)
   6
   7 - Changes between v7 and v8 -
   8 -----------------------------
   9
  10 In the v7 specification, the JOIN command included the channel modes of a
  11 channel, and acted on them following TS rules.  In the v8 specification,
  12 JOIN will never send modes.
  13
  14 Desyncs can occur both when they are sent and when they are not.  If they
  15 are sent, then you can have a situation where a user on one side of the
  16 network issues "MODE #channel -l", and a user on another side of the network
  17 issues "JOIN #channel" whilst the +l still exists.  As the JOIN string sent
  18 server<->server includes the full modes at the time of the user joining,
  19 this will propagate the +l, but there is a -l crossing in the other
  20 direction.  Desync will occur beyond where they intersect.
  21
  22 If the modes are not sent, then a lower TS JOIN command, or a JOIN command
  23 that creates a channel will cause a desync.
  24
  25 It is judged that the desync with sending the modes is worse than the desync
  26 by not sending them, as such the v8 specification dictates modes are not
  27 sent with a JOIN command server<->server.
  28
  29 The v8 specification also clarifies that servers may issue TMODE.
  30
  31 - Introduction -
  32 ----------------
  33
  34 This document aims to fix some of the flaws that are still present in the
  35 current TS system.
  36
  37 Whilst only one person may use a nickname at any one time, they are not
  38 a reliable method of directing commands between servers.  Clients can change
  39 their nicknames, which can create desyncs.  A reliable method of directing
  40 messages between servers is required so that a message will always reach the
  41 intended destination, even if the client changes nicks in between.
  42
  43 UID solves this problem by ensuring that a client has a unique ID for the
  44 duration of his connection.
  45
  46 This document also aims to solve the lack of TS rules to channel 'bans' on
  47 a netburst.  Bans from both sides of a TS war (losing/winning) are kept.
  48 Bursting the bans with a TS solves this problem.
  49
  50 There is also a race condition in the current TS system, where a user can
  51 issue a mode during a netburst and the mode will be set on the server
  52 we are bursting to.
  53
  54
  55 - Definitions -
  56 ---------------
  57
  58 Throughout this document, the following terms are used:
  59
  60 SID     - A servers unique ID.  This is three characters long and must be in
  61           the form [0-9][A-Z0-9][A-Z0-9]
  62 ID      - A clients unique ID.  This is six characters long and must be in
  63           the form [A-Z][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9][A-Z0-9].  The
  64           numbers [0-9] at the beginning of an ID are legal characters, but
  65           reserved for future use.
  66 UID     - An ID concateneted to a SID.  This forms the clients UID.
  67 TS6     - The TS version 6.
  68
  69
  70 - Support -
  71 -----------
  72
  73 Support for this document is given by the TS version 6.
  74
  75 Wherever a destination parameter or source parameter is used, it must use
  76 the SID or UID if the server/client has one.  A TS6 capable server must
  77 translate any SIDs/UIDs back into the server/clients name when communicating
  78 with a server that does not support TS6.
  79
  80 A TS6 server must also support the QS (quitstorm) system, and the encap
  81 specification found here:
  82 http://www.leeh.co.uk/ircd/encap.txt
  83
  84 The TS6 protocol does not supports masked entities.
  85
  86
  87 - Nick TS rules -
  88 -----------------
  89
  90 A server receiving a command that requires nick TS rules must check for a
  91 collision between an existing user, and the nick in the received message.
  92 (the "new user").  The collisions must obey the rules specified in Nick TS
  93 collisions.
  94
  95 If the TS received is lower than the TS of the existing user the server will
  96 collide the existing user if the clients user@host are different, if the
  97 clients user@hosts are identical it will collide the new user.
  98
  99 If the TS received is equal to the TS of the existing user both clients are
 100 collided.
 101
 102 If the TS received is higher than the TS of the existing user, the server
 103 will collide the existing user if the user@hosts are identical, if the
 104 clients user@host are different it will collide the new user and drop the
 105 message.
 106
 107
 108 - Nick TS collisions -
 109 ----------------------
 110
 111 If both users are to be collided, we must issue a KILL for the existing
 112 user to all servers.  If the new user has a UID then we must also issue a
 113 KILL for that UID back to the server sending us data causing the collision.
 114
 115 If only the existing user is being collided, we must issue a KILL for the
 116 existing user to all servers except the server sending us data.  If the
 117 existing user has a UID and the server sending us data supports TS6 then
 118 we must also issue a KILL for the existing users UID to the server sending
 119 us data.
 120
 121 If only the new user is being collided, we must issue a KILL for the new user
 122 back to the server sending us data if the new user has a UID.
 123
 124
 125 - Channel TS rules -
 126 --------------------
 127
 128 A server receiving a command that requires normal channel TS rules must
 129 apply the following rules to the command.
 130
 131 If the TS received is lower than our TS of the channel a TS6 server must
 132 remove status modes (+ov etc) and channel modes (+nt etc).  If the
 133 originating server is TS6 capable (ie, it has a SID), the server must
 134 also remove any ban modes (+b etc).  The new modes and statuses are then
 135 accepted.
 136
 137 If any bans are removed, the server must send to non-TS6, directly connected
 138 servers mode changes removing the bans after the command is propagated.
 139 This prevents desync with banlists, and has to be sent after as clients are
 140 still able to send mode changes before the triggering command arrives.
 141
 142 If the TS received is equal to our TS of the channel the server should keep
 143 its current modes and accept the received modes and statuses.
 144
 145 If the TS received is higher than our TS of the channel the server should keep
 146 its current modes and ignore the received modes and statuses.  Any statuses
 147 given in the received message will be removed.  A server must mark clients
 148 losing their op (+o) status who do not have a UID as 'deopped'.  A server must
 149 ignore any "MODE" commands from a user marked as 'deopped'.
 150
 151
 152 - Simple channel TS rules -
 153 ---------------------------
 154
 155 A server receiving a command that requires simple channel TS rules must
 156 apply the following rules to the command.
 157
 158 If the TS received is lower, or equal to our TS of the channel the modes are
 159 accepted.  If the TS received is higher than our TS of the channel the modes
 160 are ignored and dropped.
 161
 162 Simple channel TS rules do not affect current modes in the channel except
 163 for the modes we are accepting.
 164
 165
 166 - The following commands are defined here as the TS6 protocol -
 167 ---------------------------------------------------------------
 168
 169 - PASS -
 170         PASS <PASSWORD> TS <TS_CURRENT> :<SID>
 171
 172 This command is used for password verification with the server we are
 173 connecting to.
 174
 175 Due to the burst being sent on verification of the "SERVER" command, and
 176 "SVINFO" being sent after "SERVER", we need to be aware of the TS version
 177 earlier to decide whether to send a TS6 burst or not.
 178
 179 The <PASSWORD> field is the password we have stored for this server,
 180 <TS_CURRENT> is our current TS version.  If this field is not present then
 181 the server does not support TS6.  <SID> is the SID of the server.
 182
 183 - UID -
 184         :<SID> UID <NICK> <HOPS> <TS> +<UMODE> <USERNAME> <HOSTNAME> <IP> <UID> :<GECOS>
 185
 186 This command is used for introducing clients to the network.
 187
 188 The <SID> field is the SID of the server the client is connected to.
 189 The <NICK> field is the nick of the client being introduced.  The <HOPS>
 190 field is the amount of server hops between the server being burst to and
 191 the server the client is on.  The <TS> field is the TS of the client, either
 192 the time they connected or the time they last changed nick.  The <UMODE>
 193 field contains the clients usermodes that need to be transmitted between
 194 servers.  The <USERNAME> field contains the clients username/ident.  The
 195 <HOSTNAME> field contains the clients host.
 196
 197 The <IP> field contains the clients IP.  If the IP is not to be sent
 198 (due to a spoof etc), the field must be sent as "0".  The <UID> field is the
 199 clients UID.  The <GECOS> field is the clients gecos.
 200
 201 A server receiving a UID command must apply nick TS rules to the nick.
 202
 203 - SID -
 204         :<SID> SID <SERVERNAME> <HOPS> <SID> :<GECOS>
 205
 206 This command is used for introducing servers to the network.
 207
 208 The first <SID> field is the SID of the new servers uplink.  The
 209 <SERVERNAME> field is the new servers name.  The <HOPS> field is the hops
 210 between the server being introduced nd the server being burst to.
 211
 212 The second <SID> field is the SID of the new server.  The <GECOS> field i
 213 is the new servers gecos.
 214
 215 Upon receiving the SID command servers must check for a SID collision.
 216 Two servers must not be allowed to link to the network with the same SID.
 217 If a server detects a SID collision it must drop the link to the directly
 218 connected server through which the command was received.
 219
 220 Client and servers which do not have a UID/SID must be introduced by old
 221 methods.
 222
 223 - SJOIN -
 224         :<SID> SJOIN <TS> <CHANNAME> +<CHANMODES> :<UIDS>
 225
 226 This command is used for introducing users to channels.
 227
 228 The <SID> field is the SID of the server introducing users to the channel.
 229 The <TS> field is the channels current TS, <CHANNAME> is the channels
 230 current name, <CHANMODES> are the channels current modes.  <UIDS> is a
 231 space delimited list of clients UIDs to join to the channel.  Each clients
 232 UID is prefixed with their status on the channel, ie "@UID" for an opped
 233 user.  Multiple prefixes are allowed, "peons" (clients without a status) are
 234 not prefixed.
 235
 236 A server receiving an SJOIN must apply normal channel TS rules to the SJOIN.
 237
 238 A TS6 server must not use the SJOIN command outside of a netburst
 239 to introduce a single user to an existing channel.  It must instead
 240 use the "JOIN" command defined in this specification.  A TS6 server must
 241 still use SJOIN for creating channels.
 242
 243 - JOIN -
 244         :<UID> JOIN <TS> <CHANNAME> +
 245
 246 This command is used for introducing one user unopped to an existing channel.
 247
 248 The <UID> field is the UID of the client joining the channel.  The
 249 <TS> field is the channels current TS, <CHANNAME> is the channels
 250 current name.
 251
 252 A server receiving a JOIN must apply normal channel TS rules to the JOIN.
 253
 254 No channel modes are sent with the JOIN command.  In previous versions of
 255 this specification, the "+" parameter contained the channels current modes.
 256 A server following this version of the specification must not interpret this
 257 argument and must not propagate any value other than "+" for this parameter.
 258
 259 It should be noted that whilst JOIN would not normally create a
 260 channel or lower the timestamp, during specific conditions it can.  This
 261 can create a desync that this specification does not rectify.
 262
 263 - BMASK -
 264         :<SID> BMASK <TS> <CHANNAME> <TYPE> :<MASKS>
 265
 266 This command is used for bursting channel bans to a network.
 267
 268 The <SID> field is the SID of the server bursting the bans.  The
 269 <TS> field is the channels current TS, <CHANNAME> is the channels
 270 name.  <TYPE> is a single character identifying the mode type (ie,
 271 for a ban 'b').  <MASKS> is a space delimited list of masks of the
 272 given mode,limited only in length to the size of the buffer as defined
 273 by RFC1459.
 274
 275 A server receiving a BMASK must apply simple channel TS rules to the BMASK.
 276
 277 A TS6 server must translate BMASKs into raw modes for non-TS6
 278 capable servers.  This command must be used only after SJOIN has
 279 been sent for the given channel.
 280
 281 It should be noted however, that a BMASK with a lower TS should
 282 not be possible without a desync, due to it being sent after
 283 SJOIN.
 284
 285 - TMODE -
 286         :<SID|UID> TMODE <TS> <CHANNAME> <MODESTRING>
 287
 288 This command is used for clients issuing modes on a channel.
 289
 290 <SID|UID> is either the UID of the client setting the mode, or the SID of
 291 the server setting the mode.  <TS> is the current TS of the channel,
 292 <CHANNAME> is the channels name. <MODESTRING> is the raw mode the client is
 293 setting.
 294
 295 A server receiving a TMODE must apply simple channel TS rules to the TMODE.
 296
 297 A TS6 server must translate MODEs issued by a local client, or received from
 298 a server into TMODE to send to other TS6 capable servers.
 299