TS6 protocol description
Written by Jilles Tjoelker
+Edits by Elizabeth Myers to add TS rules described by Lee Harvey.
General format: much like rfc1459
Maximum parameters for a command: 15 (this does not include the prefix
UIDs/SIDs (sending names or even wildcards is deprecated). This is done with
the function hunt_server(). Any rate limiting should be done locally.
+
duration: a parameter type used for ban durations. It is a duration in seconds.
A value of 0 means a permanent ban.
+g (allow any member to /invite)
+z (send messages blocked by +m to chanops)
+Nick TS rules:
+A server receiving a command that requires nick TS rules must check for a
+collision between an existing user, and the nick in the received message.
+(the "new user"). The collisions must obey the rules specified in Nick TS
+collisions.
+
+If the TS received is lower than the TS of the existing user the server will
+collide the existing user if the clients user@host are different, if the
+clients user@hosts are identical it will collide the new user.
+
+If the TS received is equal to the TS of the existing user both clients are
+collided.
+
+If the TS received is higher than the TS of the existing user, the server
+will collide the existing user if the user@hosts are identical, if the
+clients user@host are different it will collide the new user and drop the
+message.
+
+Nick TS collisions:
+If both users are to be collided, we must issue a KILL for the existing
+user to all servers. If the new user has a UID then we must also issue a
+KILL for that UID back to the server sending us data causing the collision.
+
+If only the existing user is being collided, we must issue a KILL for the
+existing user to all servers except the server sending us data. If the
+existing user has a UID and the server sending us data supports TS6 then
+we must also issue a KILL for the existing users UID to the server sending
+us data.
+
+If only the new user is being collided, we must issue a KILL for the new user
+back to the server sending us data if the new user has a UID.
+
+Channel TS rules:
+A server receiving a command that requires normal channel TS rules must
+apply the following rules to the command.
+
+If the TS received is lower than our TS of the channel a TS6 server must
+remove status modes (+ov etc) and channel modes (+nt etc). If the
+originating server is TS6 capable (ie, it has a SID), the server must
+also remove any ban modes (+b etc). The new modes and statuses are then
+accepted.
+
+If any bans are removed, the server must send to non-TS6, directly connected
+servers mode changes removing the bans after the command is propagated.
+This prevents desync with banlists, and has to be sent after as clients are
+still able to send mode changes before the triggering command arrives.
+
+If the TS received is equal to our TS of the channel the server should keep
+its current modes and accept the received modes and statuses.
+
+If the TS received is higher than our TS of the channel the server should keep
+its current modes and ignore the received modes and statuses. Any statuses
+given in the received message will be removed. A server must mark clients
+losing their op (+o) status who do not have a UID as 'deopped'. A server must
+ignore any "MODE" commands from a user marked as 'deopped'.
+
+Simple channel TS rules:
+
+A server receiving a command that requires simple channel TS rules must
+apply the following rules to the command.
+
+If the TS received is lower, or equal to our TS of the channel the modes are
+accepted. If the TS received is higher than our TS of the channel the modes
+are ignored and dropped.
+
+Simple channel TS rules do not affect current modes in the channel except
+for the modes we are accepting.
+
+
<numeric>
source: server
parameters: target, any...
projects / solanum.git / blobdiff