Re: ND/CD, collisions, ^Go whining

[Ville <viha@xxxxxx>]

On Sun, 17 Jan 1999, Kaspar Landsberg wrote:

> Hi,

> On Sun, Jan 17, 1999 at 03:14:38PM +0200, Ville wrote:

> | Some people used "it would result in an awful collision chain" as a
> | reason _against_ this. Wrong, wrong, wrong.

> what exactly is wrong?

The fact it already does. They can keep on colliding as long as they wish,
as because of the lag the collide-killer does not get killed himself and
a simple /nick will result in another collision.

> | Currently collision chains are just the case! People collide people to
> | annoy the heck out of them (the victims lose ops on "their" channels
> | and have to reconnect, also having their nicknames ND'ed).

> Currently, the client is reconnecting by itself after a nick collision (if
> configured that way). When you have FNC, the client can´t decide whether it
> wants to reconnect or not because there is no disconnection. It is therefore
> forced to keep being collided unless a manual /signoff occurs.

If we assume not everyone is running a irc2bot client which automatically
reconnects, gets oped on all its channels and so on, I would say users
prefer it this way. They _still_ can use /signoff just as well as before,
if they wish to run from the collisions.

Think of it this way: Earlier they had to reconnect if they wanted to get
back. I would count on that being the majority.


> | If the randnick patch is applied, collisions will lose their use. It
> | will not be fun or "useful" to collide anyone anymore, because the
> | server automatically restores all the modes and does not throw him
> | off (except ircd-wise).

> Well, you could use it pretty well to flood a channel in an effective way.

Effective? The effect is the victims get to keep their ops? While when
done the other way around, they ops are collided, lose their ops as well
as the channel (most of the time).

Smart clients ignore repeated joins, modes and so on, anyway.

> irc.2.10.x slows down nick changes pretty much when a channel is set +m. In
> order to make FNC work, you´d have to make server nick changes the exception
> to this behavior. But then collisions could be used to undergo the nick
> flood protection on +m channels...

No.

AFAIK the user is killed normally, then re-NJOINed by the server and
flags restored.

Not to mention it being a fair choice to add a 5-10 second delay before
the reconnect to stop people from bouncing and otherwise making things
look messy.

> Which brings us back to my original opinion that FNC is not a good
> respectively elegant solution and contains probably quite some ways to cheat
> it or to exploit new ways of abuse created by it.

You have not yet come up with one. When you do, keep us posted about it,
and we will probably find a way to beat it, just as well.

> | *** Users on channel #plah: @user luser
> | *** Signoff: user (server1 server2)
> | *** Users on channel #plah: luser
> | *** luser left channel #plah
> | *** luser joined channel #plah
> | *** Users on channel #plah: luser
> | *** user has joined channel #plah (+o)

> [Shouldn´t this be "blah"? ;-)]

Nope. Plah is Finnish for blah and once again I felt an urge to surprise
you lot with it.

I think this would provide a good temporary solution, while hopefully
the newest 2.10's already accept nicks beginning with a number from
other servers, just to make way to the future uniqueIDs.


> Bye, Kasi

Regards,

- Ville/viha@xxxxxx