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