Re: [Re: nick collide prevention ideas]

[borud@xxxxxxx]

[m de`jour]
| 
| After reading your comments about many of my other suggestions, and
| the technical and practical concerns, I think the last idea about
| adding an optional /rnick function would be the easiest to
| implement.

say that I want to take over a channel.  I connect to two servers that
have a few seconds of lag between them.  I monitor nick changes on the
local server on each of the connections and when a nick change happens
I duplicate it on the other server a fraction of a second later --
which I can due to the lag.  then what?


| The most likely application would be for 24/7 connection clients
| such as automated bots and screened ircII/BitchX type clients.

I've never understood the principle of taping the switch on the fridge
door just to be sure that the light is on inside the fridge when
you're not keeping the door open.

if someone takes over the channel, move to a different channel.  if
you manage to constantly attract negative attention find out why and
perhaps set up your own, dedicated  IRC server.  it's not like there's
a lack of tools and infrastructure to inform people, even securely,
where the channel is at riht now.

I've lived by the principle of keeping a low profile and just
disappearing if trouble shows up on the channel me and my friends
use at the moment.  subsequently the last 4-5 years on IRC I've never
had the problem that someone is able to sabotage my use of IRC.

if you beat the troublemakers by not giving them what they want,
pretty soon you'll see that you don't need bots and you don't need to
be on IRC 24/7.

| Also, if implemented, it would quire possibly result in fewer bots,
| since one of the primary reasons for having large numbers of
| bots/screens is for nick collide protection.

if you were a troublemaker and there wasn't really anyone there to
harass, wouldn't you give it up eventually?

| Only one op has to survive a mass collide.  With ten ops in a channel, nine
| can be collided but as long as one survives, the takeover attempt is a total
| failure.  Colliding 99% of the target ops is not good enough.  It has to be
| 100% or nothing.  In the simplest form, a channel of ten ops could be
| protected against mass collides if just one op decides to use  this special
| random nick.

if I have understood this correctly, when that nick is collided it
changes automatically?  how do you ensure that the collider doesn't
pull the trick I mentioned earlier?  


but hey, feel free to implement it.  the only way to prove your point
is to demonstrate that it works.  the code is available, it's not
pretty, but it's there. there are good books on C available as well.
knock yourself out.

-Bjørn