]>
Commit | Line | Data |
---|---|---|
bee3b671 | 1 | $Id: ts6.txt 3211 2007-02-20 00:34:28Z jilles $ |
212380e3 | 2 | |
bee3b671 | 3 | TS6 Proposal (v8) |
212380e3 AC |
4 | Written by Lee H <lee@leeh.co.uk> |
5 | Ideas borrowed heavily from ircnet (Beeth, jv, Q) | |
6 | ||
bee3b671 JT |
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 | ---------------- | |
212380e3 AC |
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 | ||
bee3b671 JT |
55 | - Definitions - |
56 | --------------- | |
212380e3 AC |
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 | ||
bee3b671 JT |
70 | - Support - |
71 | ----------- | |
212380e3 AC |
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 | ||
bee3b671 JT |
87 | - Nick TS rules - |
88 | ----------------- | |
212380e3 AC |
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 | ||
bee3b671 JT |
108 | - Nick TS collisions - |
109 | ---------------------- | |
212380e3 AC |
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 | ||
bee3b671 JT |
125 | - Channel TS rules - |
126 | -------------------- | |
212380e3 AC |
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 | ||
bee3b671 JT |
152 | - Simple channel TS rules - |
153 | --------------------------- | |
212380e3 AC |
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 | ||
bee3b671 JT |
166 | - The following commands are defined here as the TS6 protocol - |
167 | --------------------------------------------------------------- | |
212380e3 | 168 | |
bee3b671 JT |
169 | - PASS - |
170 | PASS <PASSWORD> TS <TS_CURRENT> :<SID> | |
212380e3 AC |
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 | ||
bee3b671 JT |
183 | - UID - |
184 | :<SID> UID <NICK> <HOPS> <TS> +<UMODE> <USERNAME> <HOSTNAME> <IP> <UID> :<GECOS> | |
212380e3 AC |
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 | ||
bee3b671 JT |
203 | - SID - |
204 | :<SID> SID <SERVERNAME> <HOPS> <SID> :<GECOS> | |
212380e3 AC |
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 | ||
bee3b671 JT |
223 | - SJOIN - |
224 | :<SID> SJOIN <TS> <CHANNAME> +<CHANMODES> :<UIDS> | |
212380e3 AC |
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 | ||
bee3b671 JT |
243 | - JOIN - |
244 | :<UID> JOIN <TS> <CHANNAME> + | |
212380e3 AC |
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 | |
bee3b671 | 250 | current name. |
212380e3 AC |
251 | |
252 | A server receiving a JOIN must apply normal channel TS rules to the JOIN. | |
253 | ||
bee3b671 JT |
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 | ||
212380e3 | 259 | It should be noted that whilst JOIN would not normally create a |
bee3b671 JT |
260 | channel or lower the timestamp, during specific conditions it can. This |
261 | can create a desync that this specification does not rectify. | |
212380e3 | 262 | |
bee3b671 JT |
263 | - BMASK - |
264 | :<SID> BMASK <TS> <CHANNAME> <TYPE> :<MASKS> | |
212380e3 AC |
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 | ||
bee3b671 JT |
285 | - TMODE - |
286 | :<SID|UID> TMODE <TS> <CHANNAME> <MODESTRING> | |
212380e3 AC |
287 | |
288 | This command is used for clients issuing modes on a channel. | |
289 | ||
bee3b671 JT |
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. | |
212380e3 AC |
294 | |
295 | A server receiving a TMODE must apply simple channel TS rules to the TMODE. | |
296 | ||
bee3b671 JT |
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. | |
212380e3 | 299 |