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

How come, one asks. Easy. Imagine, that instead of nicks, all is done
using UIDs. So there's no
	Beeth!chopin@jantar.sgh.waw.pl PRIVMSG Dianora :hello
only
	0ABC01234!chopin@jantar.sgh.waw.pl 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@jantar.sgh.waw.pl' or even
'anything!chopin@jantar.sgh.waw.pl' 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.

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.
Of course, to avoid that fascist numbers appearing everywhere, clients
can signal ircd, that they would prefer to be known as some kind of
"nick", which could be shown to people to assign initial mapping, if
they wish. And eventually change those, if they want. Maybe not in
the form of "# Appears as ARMANDO" ;-) but rather
"0ABC01234!chopin@jantar.sgh.waw.pl NICK :Some New And Cool Nick",
which would be only local mapping suggestion.

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

p.