This document was last modified on June 12th, 1996.

This document attempts to describe both the TS and Delay concepts in an objective manner. Since I am known to not like TS, I have asked several people to read this document and help me making it as objective as possible.

  1. What is the purpose of these concepts?
  2. Summary of the two concepts
  3. Technical comparison
  4. Policital issues
  5. The ``problems''
  6. Last note

Why?

Both concepts (TS and Delay) attempt to solve two widely known problems with IRC 2:

TS

TS stands for TimeStamp.
The protocol is fully described by Roger Espel Llima, its author. It has been added by Chris Behrens and Shrihari Pandit to their own server versions.

Delay

The delay concept is implemented in the version 2.9 of the official IRC server. This version is still a beta release. It has not been documented yet (as of 96/06/06).

Note:The nickname delay concept was first introduced in the so-called E1 patch (for 2.8.21) and is NOT the one implemented in the 2.9 version.

The following descriptions do not pretend to be complete. The purpose of this document is to offer enough material for someone to be able to decide which method is better, if any.

It is important to note that there are two very different aspects of the problem:

Both aspects are different and should not be confused.

The TS concept

Nicknames

A TS server knows which of two nickname clients is the most recent. Thus it is possible for it to decide to kill only one of the clients.
This protects the older user from intentional nickname collisions.

Channels

As for channels, a TS server is able to decide which channel operator is the youngest (for each channel). This makes the removal of channel operator status for users who are riding splits possible.

Technical notes

The Delay concept

Nicknames

A server with nickname delay keeps users from using a nickname recently used, if the nickname has either split away or being killed.

Channels

A server with channel delay does not allow users to join channels which have recently lost their channel op because of split and which are empty. (e.g. joins are always allowed if a channel is not empty).

Technical notes

A simple technical comparison

  1. As a first note, neither of the two methods stops nickname collisions, nor channel takeovers. But they both have a different way to handle them:
    • TS will let users do whatever they want, and attempt to fix later when a conflict occurs.
    • With the delay concept, users aren't allowed actions which would possibly lead to a conflict later.

    This simple comparaison explains why Delay is often said to be annoying while TS is said to be transparent, but I find this to be a poor objection:

    • With TimeStamp:
      1. UserA with NickA and UserB with NickB are on IRC on different servers.
      2. There is a split inbetween the servers UserA and UserB are on.
      3. UserB nicks to NickA.
      4. The servers reconnect.
      5. There is a nick collision and the Timestamp says UserA's NickA is older so UserB's NickA is killed.
      6. UserA with NickA doesn't know the difference, but UserB does (because he got killed in step 5).

    • With Nickname Delay:
      1. UserA with NickA and UserB with NickB are on IRC on different servers.
      2. There is a split inbetween the servers UserA and UserB are on.
      3. UserB tries to change to NickA, but cannot because of Nickname Delay.
      4. The servers reconnect.
      5. nothing happens.
      6. UserA with NickA doesn't know the difference, but UserB does (because he was not able to get NickA in step 3).

    Both are 'transparent' to UserA, because he didn't know anything odd happened.

    Neither are 'transparent' to UserB, because in both cases, something unexpected happened as a result of trying to use NickA. For TimeStamp, the user was Killed. For Nickname Delay, the user was not allowed to take the nick.

    Depending on the situation:

    • TimeStamp can be found more annoying than Nickname Delay: If UserB is not trying to collide UserA, UserB will later get disconnected (killed) which is rather annoying.
    • Nickname Delay can be found more annoying than TimeStamp: If UserB is also UserA and switching from servers to get around the split, the user cannot user NickA (his/her own nickname) for a while.

    (Nickname) Delay tries to protect everyone, while TimeStamp tries to protect only the "rightful" users.

    Note: A similar example can be made with channels.

  2. One big difference between the two concepts is the way to handle problems. TS will always rely on the net, while Delay will never. This means that TS can cause havoc on the whole net (as seen on some occasions), while Delay will never affect remote entities.

  3. TimeStamp can handle splits of an abritrary length, Delay for only 15 minutes.

  4. Delay does not broadcast any extra info, TimeStamp does (mostly stamps).

    In the example above, TimeStamp broadcasts more information than Nickname Delay: nick change and the eventual nickname collision on every server on one side of the split.

  5. TimeStamp uses memory for stamps (100Kb for 25K users, 24Kb for 6K channels),
    Delay uses memory for Nickname Delay (close to 400Kb for 25K users). Channel Delay memory use is close to 0.

  6. TimeStamp requires a homogenous network to work effectively, Delay does, but not as much.

The political issues

  1. The net has a spirit (also read an operlist post by M. D. Yesowitch)

    The net that we know has a long history, and many ``well known rules''. As far as I can remember, it has always been said that "nicknames and channels are not owned".

    This state of things is easy to notice on a net where collisions and takeovers are a common thing. With TimeStamp or Delay, things change, and what was clear before is not that clear anymore.

    The problem is that TimeStamp decides who the rightful user is and the logic used for this is far to be approved by everyone (read below, long splits and TS for one example). With the delay patches, no choice thus no mistake is ever done, but sometimes, it will let a conflict happens.

    It is now easy to understand that when TimeStamp makes the 'wrong' decision, the user who has been "punished" and who was "right" will require or at least expect someone/something to correct the situation. It is what leads to the need for ``services''.

  2. Channel service

    A channel service, as known on other IRC networks is something that goes against the long established "channels are not owned" and would be a big change on the net. This is one of the main reasons why people are opposed to TS, because, as stated above, it easily leads to "Now that we have TS, we need a channel service".

The problems

  1. lag-killer bots

    Quoting Doug McLaren talking about nickname delay: There's nothing to stop the `lag-killer bot'. This bot keeps two connections open - one on your server, one on a remote server. It also sits on a channel that you are on. As soon as it sees you change nick with it's local connection, it signals the remote connection to take the same nick. The two nick changes meet somewhere in the middle, and you get killed.

    TimeStamping does not really solve this either. It limits the abuse because the `lag-killer bot' has to be fast, but this is not really a problem.

    Roger Espel Llima says: neither solution deals with them completely; TS leaves them with a success rate of about 50%; with ND they're always successful

    Vesa Ruokonen answers: Nickname Delay doesn't make abuse always successful. With it, the kill can happen only once (on a given nickname), after that the nickname gets locked, and the bot cannot continue looping like with TS.

  2. restarted servers

    Quoting Doug McLaren talking about nickname delay: The same goes for a server that has just been /restarted or started. That case is a little better, because, if the server's C/N lines are set up right, it will start connecting immediately, only giving the colliders a few seconds to connect before it gets connected and processes the connect burst.

    I guess client connections could be delayed, in these conditions. But I don't really see any easy way to do it, nor to know that the server has processed the whole connect burst.

  3. long splits

    • nickname delay

      Quoting Doug McLaren talking about nickname delay: There's nothing to stop a server that has been split for more than 15 minutes from being used to nick collide. If one client on this server starts cycling through all the nicks it wants to kill as soon as the server reconnects to the net, it can be used to cause lots of nick collisions.

      This is quite true. But as you will read below, servers should not be split that long (at least not on a regular basis). Of course, it happens.

    • channel delay

      Quoting Doug McLaren talking about channel delay: If a server is split for more than fifteen minutes, all channel delays will have expired, and they'll be able to hack ops on any channel they want to, assuming nobody on this server is already on this channel.

      Network and machine outages often last more than 15 minutes ...

      There are three things to answers to these two statements.

      First, in its current version, channel delay does not expire after fifteen minutes on a server which is ``completely'' split. In such case, it will take longer.

      Second, I don't really know how you plan to abuse a server which is unreachable. If there's a network outage, only local users should be able to abuse, given that they won't see the other part of the net, they will only be able to act against known ``targets''.
      Also, it makes the number of potential abusers really limited.

      Finally, if a server, or part of the net is used to have long splits, my very personal opinion is that it should not be linked at all.

    • TimeStamp

      According to me, TimeStamp also has problems with long splits. I will take the example of TimeStamp on nicknames, but a similar comment can be made for channels.

      Let's assume two servers are split for a long time. Then, two users can use the same nick for an important amount of time, and only one will be killed on reconnect. I believe that there is no way to choose the right one.

      This can lead to have someone who usually uses a nickname to be killed (if he restarted his client recently, or changed nicknames at some point).

Last note

I believe this document gives quite a complete overview of both concepts. The purpose now is for you to think and may be decide which one you prefer. But you should be at least able to make up your mind, on your own (forgetting all what you have heard so far).

You should probably read this again, because there are many important points which are rather hidden because of the length. I tried to address all issues, they all have different importance, but this is quite subjective.

The most important thing to know and remember, is that either concept is only FULLY effective if the whole IRC net is running it.

Thanks to the following people for reviewing this document, and commenting it:

Christophe Kalt <kalt@stealth.net>