[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IRCOPS: Re: nick collide prevention ideas



On Wed, 7 Jul 1999, Piotr Kucharski wrote:

> On Sun, Jul 04, 1999 at 03:03:43PM -0700, Diane Bruce wrote:
> > Simplest way of getting rid of nick collisions. get rid of nicks.
> 
> Here I think the same.
> 
> With introducing uniqueIDs (http://akson.sgh.waw.pl/~chopin/uniqueID.txt)
> we could get rid of nicks we all know them today.  We gain:
>  o certainty of delivering message to proper client or not delivering
>    at all, thus no op/msg stealing
>  o no collisions at all (as uniqueIDs will be guaranteed to be unique
>    netwide)
>  o freedom of choice how to name our friends

I already name my girl friend "honey" :P

> 
> How come, one asks. Easy. Imagine, that instead of nicks, all is done
> using UIDs. So there's no
> 	Beeth!chopin@xxxxxxxxxxxxxxxxx PRIVMSG Dianora :hello
> only
> 	0ABC01234!chopin@xxxxxxxxxxxxxxxxx PRIVMSG 0DEF01234 :hello
> or even
> 	0ABC01234 PRIVMSG 0DEF01234 :hello
> 
> The same with modes and everything. What are the implications? See:

> 
> _Your_ _client_ maps '0ABC01234!chopin@xxxxxxxxxxxxxxxxx' or even
> 'anything!chopin@xxxxxxxxxxxxxxxxx' to "Beeth"; then anytime I speak,
> you see "Beeth" speaking. If you know me rather as "Fascist Operator",
> no problem, you can assign that name to my handle. Moreover, that
> allows virtually dozens of "Hero"es, "Vesa"s and other commonly
> wanted "nicks" ;-) as these are only _local_ bindings.

doing this 100 times for a big channel? please not :)

> 
> How to recognize your friends, if they don't have same user@host each
> time? Simple. Do it as now, talk to them, then add local binding.

where should this bindings be stored, what if I disconnected
accidently?

> Here comes to mind getting rid of channels with same scenario. Each
> channel name is uniqueID, and clients just map it, as they want.
> No more takeovers, as anyone can map anything to anything. :) Of course
> I see some technical problems here, but I think we could resolve it
> somehow. :-)
> 

I think unique-id should be there if someone thats /mode mynick +u
for backward compability, if you set that mode, the server send you
your unique ID, where others on the net can reach you.
its propagated at the time you set that user mode to the other service

If someone has set this mode too, he will get this if someone joins
a channel: UNIQ Engerim :08154711

So someone will see your _prefered_ name is Engerim

He can /msg 08154711 and /msg Engerim too. The ID should be generated
as CRC32 from servername+originalnickname+signontime really fast and easy.

so you might wonder now what will happen if another Engerim
(not thereal one) will try to collide the poor Engerim?

Simple. Your _prefered_ name gets invalid/deleted (no such nick/channel)
and only your unique ID can be messaged anymore, if you try to message
engerim now as user without +u you get a

"NOTICE $n :Engerim has unique ID 08154711 please message this. "
You can get this only if servers already have that unique patch!

if Engerim(08154711) tries to message the channel now only users with +u
can see him, the other not upgraded servers get a normal kill.
Engerim messages the channel now in this format, only for +u users:

08154711 PRIVMSG #foo :hello

A good client will of course remember that 08154711 is/was Engerim.
After a delay the server makes the nick valid again to the ID by
sending the UNIQ Engerim :08154711 again around the network.

This is imho the only way to have backward compability and
a unique ID which allows you still to chat.

Greets,
Engerim