Why am I forced to re-join channels?

This FAQ is to clear up any discrepancies about the channel re-join feature added to PurpleSurge's IRC Servers; answer a few questions pertaining to this; and to give you a few hints about it as well. I'm sure if you've been on the Network, you've seen it. This feature will force a re-join of a user, if their host is changed/updated.


Here’s an example if you are still confused:


* +Spike (Spike@Red.Herring.Conundrum.Fallacy) has left #Help (Rejoining because of user@host change)

* Spike (Spike@Test) has joined #Help

* hybrid.purplesurge.com sets mode: +v Spike

Oh, I've seen that before! What does it all mean?

Well, let's start by dissecting it.


a. * +Spike (Spike@Red.Herring.Conundrum.Fallacy) has left #Help (Rejoining because of user@host change)


This is an event where "Spike" has left/parted the channel #Help. His part message says "Rejoining because of user@host change", which is the correct and valid part message used by the feature to let users know that is why he is re-joining. Note his user@host in this part, it is "Spike@Red.Herring.Conundrum.Fallacy".


b. * Spike (Spike@Test) has joined #Help


Here, "Spike" rejoins the channel #Help. Take special note of the elements that have changed. His user@host before the join was "Spike@Red.Herring.Conundrum.Fallacy", and now it is "Spike@Test", note the change in the host.


c. * hybrid.purplesurge.com sets mode: +v Spike


The server here simply returns his modes to him, just as they were before the forced re-join of "Spike".


Warning: Anyone can fake the part message, "Rejoining because of user@host change", so you can not always trust it. Here is a tip to prove a genuine forced re-join by the server, and not the user. First, look for the exact message that was mentioned above, it is case-sensitive, so even replacing lowercase letters with capitals means it is invalid. Second, this is usually a fast re-join. So, if a user parts with the message, then joins in 5 minutes, it is highly likely this is invalid. Thirdly, you will notice a fast user@host change. If someone parts with the message, and comes back with an exact same user@host, this may be a fraud. Lastly, when the user re-joins the channel, if they had any access modes set on them when they left, they will be returned by the server you are using.

What things cause this to happen?

Things that update/change your host. Such as commands like /ns update, and /hs on.

This is annoying, why do we even have this?

The main reason is to prevent Client Desync. You may be asking, what is a Client Desync? Well, it is when clients do not synchronize with the server, or updates itself. Only usually periodically, a client will update the Internal Address List (IAL), which stores all the client's hosts. With this new feature, once on re-join, the IAL of that user will be updated, thus keeping everything up to date and synchronized.

Why is an IAL update important?

For example, if you use mIRC. You also may have created an alias to let you kick and ban at once for convenience. You access the IAL when you ban through mIRC, and other clients as well. If the IAL was not updated, you may have banned a host that is not up-to-date, and when the user re-joined with a different host, you would have thought it was ban evasion. This feature's goal is to try cut-down, and eventually eliminate this problem.

How long will this feature exist? Is this just a trial?

The change is permanent. This is not a trial, and this feature will continue to exist on all of the servers connected to the PurpleSurge IRC Network.

Where can I find more support if I have any questions?

If you need more support on this feature, or anything relevant to PurpleSurge's IRC Servers/Services, you are free to join the official help channel, #Help. Though be forewarned, joining the channel and complaining about this feature, protesting and being stubborn will not get anywhere. In addition, you can file bug complaints here.


Documentation/FAQ written by Spike, with help from driew on March 21, 2010. Last updated March 21, 2010.