+ /* 1.1 FJOIN works as follows:
+ *
+ * Each FJOIN is sent along with a timestamp, and the side with the lowest
+ * timestamp 'wins'. From this point on we will refer to this side as the
+ * winner. The side with the higher timestamp loses, from this point on we
+ * will call this side the loser or losing side. This should be familiar to
+ * anyone who's dealt with dreamforge or TS6 before.
+ *
+ * When two sides of a split heal and this occurs, the following things
+ * will happen:
+ *
+ * If the timestamps are exactly equal, both sides merge their privilages
+ * and users, as in InspIRCd 1.0 and ircd2.8. The channels have not been
+ * re-created during a split, this is safe to do.
+ *
+ *
+ * If the timestamps are NOT equal, the losing side removes all privilage
+ * modes from all of its users that currently exist in the channel, before
+ * introducing new users into the channel which are listed in the FJOIN
+ * command's parameters. This means, all modes +ohv, and privilages added
+ * by modules, such as +qa. The losing side then LOWERS its timestamp value
+ * of the channel to match that of the winning side, and the modes of the
+ * users of the winning side are merged in with the losing side. The loser
+ * then sends out a set of FMODE commands which 'confirm' that it just
+ * removed all privilage modes from its existing users, which allows for
+ * services packages to still work correctly without needing to know the
+ * timestamping rules which InspIRCd follows. In TS6 servers this is always
+ * a problem, and services packages must contain code which explicitly
+ * behaves as TS6 does, removing ops from the losing side of a split where
+ * neccessary within its internal records, as this state information is
+ * not explicitly echoed out in that protocol.
+ *
+ * The winning side on the other hand will ignore all user modes from the
+ * losing side, so only its modes get applied. Life is simple for those
+ * who succeed at internets. :-)
+ */
+