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

Re: IRCOPS: Re: nick collide prevention ideas



Thomas Kuiper wrote:
> 
> On Wed, 7 Jul 1999, Piotr Kucharski wrote:
> >
> > _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 :)

Everybody can have a nick, which would be send on join, in some way.
But you could tell your client to give it an other nick if you want.

> > 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

Backward compatibility is going to be a problem yes. But I don't like
the idea of using an umode for it. I would more like to see a command it
sends before registering. Different nets use different umodes, it would
give clients problems.

> 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.

I would more like to see /msg nick be removed, only /msg uid. Since we
have something other then nick that is unique, nick doesn't have to be,
so you could allow different people to have the same nick.

> The ID should be generated
> as CRC32 from servername+originalnickname+signontime really fast and easy.

I have no idea how to do it yet, but that doesn't look like a good idea.
More something like serverID + userID, where userID is probably
something based on the fd.


Q