doc/technical/ts6.txt

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