]>
Commit | Line | Data |
---|---|---|
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 |