Re: IRCOPS: Re: nick collide prevention ideas

[Diane Bruce <db@xxxxxx>]

Q says:
> 
> 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.

  Actually, as I had envisioned it.. Client would join channel,
be introduced as is presently by server, but with unique ID instead of nick.
nicks could be unique per channel actually. The same way there can be
multiple people named "Dave" at a party, but each of them can agree on a
nickname for the evening. "Dave Red" "David" "Davey" etc.

  Your client associates a nice easy to use nick with a complex 
nasty client ID. 

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

  Actually, if you relax the need for unique global nicks, and make it
per server, its quite easy to have the server do the mapping of
a server wide nick to a global client ID.

  This would allow a transition time.

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


  I fully agree.

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


-- 
Diane Bruce, http://www.db.net/~db  http://www.db.net email db@xxxxxx
--- I got bored with the last witty aphorism.