1 files changed, 147 insertions, 0 deletions
diff --git a/doc/technical/ts5.txt b/doc/technical/ts5.txt
new file mode 100644
index 0000000..de10506
--- /dev/null
+++ b/doc/technical/ts5.txt
@@ -0,0 +1,147 @@
+  Overview of the TS5 system
+  Lee H <lee@leeh.co.uk>
+
+$Id$
+
+For the purposes of this document, ircd versions:
+  hybrid6.0
+  ircd-comstud-1.12
+  CSr31pl4
+
+and prior, are TS3.
+
+ircd-hybrid-6.2 and later support TS5.
+
+Whats TS5?
+----------
+
+The difference between TS5 and TS3 is what happened on opless channels.  TS
+works by establishing which server has the oldest version of the channel,
+the version that is oldest, keeps its modes and ops, the version that is
+youngest, removes their modes and ops, and accepts the older version.
+
+There was an exception to this rule with opless channels, if a channel was
+opless, TS3 would allow anybody to keep their ops and modes on the channel.
+TS5 aims to stop this, by removing this exception.
+
+Example1: 
+
+An irc network, with server A (every server is ts3)
+
+UserA is on ServerA, in channel #broken.  This channel is opless, and has a
+TS of 800000000.  ServerA splits, and whilst it is split, UserA cycles
+channel #broken, recreates the channel and is given ops.  On ServerA #broken
+now has a TS of 900000000 and has ops.  ServerA rejoins with the network,
+via HubB.  HubB realises #broken is opless, so allows UserA to retain ops.
+The TS is moved forward to 900000000.
+
+The network now sees #broken as having a TS of 900000000, with UserA being
+opped.
+
+Example2:
+
+An irc network, with server C (every server is ts5)
+
+Same scenario as above.  ServerC splits and UserC cycles channel #broken,
+recreating it with a TS of 900000000.  ServerC rejoins with the network via
+HubD.  HubD realises #broken has a TS of 800000000 locally, and ServerC is
+showing a TS of 900000000, it ignores ServerC's modes and ops.  The channel
+remains opless.  ServerC receives HubD's modes, and it notices HubD has a
+lower TS of channel #broken.  It removes UserC's ops, removes the channel
+modes on #broken, and accepts HubD's status.
+
+The network version of #broken hasnt changed.  It is still opless, with a TS
+of 800000000.
+
+
+As you can see, TS5 makes splitting a server to regain ops useless, as it
+cannot be abused to give ops after a netsplit.
+
+The problem with TS5 however, is what happens on a mixed TS5/TS3 network.
+Channels where the older TS has ops will behave the same way on TS5 and TS3,
+however an opless channel will behave differently, as you can see above.
+
+The result of TS5/TS3 mixed can be a desync:
+
+Example1:
+
+As per Example1 above, except the rest of the network is TS5, ServerA is
+TS3.  ServerA would keep its modes and ops, whilst the rest of the network
+would remove them.  This means only ServerA would see UserA as opped.  The
+desync can be abused, as UserA can send modes.  Hybrid6.0 servers will
+accept these modes from the unopped client, so if UserA ops UserB, who then
+ops UserA, the channel will be the same across all Hybrid6.0 and Hybrid6.1
+servers.
+
+Example2:
+
+As per Example2 above, except the rest of the network is TS3.  ServerC is
+TS5.  ServerC would remove its modes and ops, therefore UserC would not be
+opped on ServerC, therefore it could not send any mode changes to the
+channel.  Although it is opped elsewhere, it isnt opped locally, so the
+desync cannot be abused.
+
+As you can see, the desync's that can occur can either be resynced, or are
+useless to the user, so a mixed TS5/TS3 network is not a huge problem,
+although a desync is NOT a good thing to have.
+
+
+Why TS5?
+--------
+
+We have jumped to TS5 from TS3, because there was a version of ircd that was
+TS4, so it was thought better to avoid a clash with an existing version.
+
+
+Advantages
+----------
+
+It's a realistic event that a server will be attacked so it splits off a
+network, then used to regain ops in a channel.  TS5 makes this pointless,
+the server will never give ops on a netsplit.  TS5 is network wide, so it
+leaves individual servers free to choose options like NO_JOIN_ON_SPLIT,
+whilst keeping splits useless to users.
+
+
+Disadvantages
+-------------
+
+It's virtually impossible for a user to actively regain ops themselves (some
+regard this as an advantage..) because on a large sized channel, its
+impossible to get people to leave so it can be recreated, therefore if a
+network did not have some form of services, it could possibly end up
+requiring oper intervention, as you cant get everybody to leave, and you
+cant use splits to regain ops, therefore if the channel is open (an
+invite-only channel would gradually destroy itself as noone new can join) it
+could be impossible for a user to regain ops.
+
+On a network that has some form of services, The effect of TS5 would be
+minimal, however the services must be of sufficient quality to fix opless
+channels, as TS5 renders netsplits for ops worthless.
+
+
+Recommendations
+---------------
+
+If your network has good stable services, we recommend TS5 is enabled, as
+people have no reason to abuse netsplits anyway.
+
+If your network has no services at all, then TS5 may cause problems with
+users being left with a permanently opless channel.
+
+If your network occupies the middle ground, then its a choice between users
+needing to be able to use splits to regain ops, or making netsplits that are
+caused to regain ops worthless.
+
+If TS5 is chosen, the FULL network must upgrade and this should be done in a
+relatively short space of time to minimise the possible desync effects.
+
+
+Alternatives
+------------
+
+There is also NO_JOIN_ON_SPLIT and NO_OP_ON_SPLIT, however these use the
+configuration of minimum servers and users, and sometimes a split that is
+above these limits is enough to be abused to regain ops, whereas if the
+limits are too high, clients will never be able to join anything or be opped
+when they create a channel.