Thomas Kuiper wrote: > On Wed, 7 Jul 1999, Piotr Kucharski wrote: > > > On Sun, Jul 04, 1999 at 03:03:43PM -0700, Diane Bruce wrote: > --[snip]-- > > 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! > Why? Any reason as it's a UniqueID and the user is not killed, that the NICK has to be deleted (apart from backward server compatability) I see no real reason why 2 NICK's cannot co-exist, remembering that the nick rather than uid is just a nickname the user has given themselves, and therefore the server would track the uid. This of course could leave the chanops with a problem if 2 users joined, both with the same NICK, however it would solve the problem of ghost clients blocking NICK's etc... I suppose there would be no reason why a chanop command like +o would require the UniqueID in the event of 2 of the same Nicks on the same channel. Perhaps UniqueID by default... It may allow things to get confusing, but it might also solve the problem of collided nicks/op-cheating etc... I think the problem of UID's is going to be a problem of clients and backward compatability rather than good ways of implementing it. The would in my thoughts of an implementation not be any reason why the legacy servers cannot have the duplicate users on them, and as an upgrade path to the new style would follow that mulitple Nicks on new servers were disabled whilst old servers were linked. However, the uniqueID nick should not be killed on collision from an old server, just the nick on the old server. Then when legacy servers are no more just enable multiple nicks..... More thoughts anyone, or am I way off the mark? -- Yours Matthew =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I use technology in order to hate it more properly. -- Nam June Paik
begin:vcard n:Sullivan;Matthew tel;pager:+44 (0)181 564 5100 tel;cell:+44 (0)780 122 5744 tel;fax:+44 (0)181 564 5101 tel;home:Ex-Directory tel;work:+44 (0)181 564 5115 x-mozilla-html:TRUE url:http://people.netscape.com/matthews/ org:<TABLE cols=2 width=350 spacing=0 rows=1><TR><TD width=50><img src="http://people.netscape.com/matthews/penguin.gif";></TD><TD><TABLE width=250 spacing=0 border=0><TR><TD><FONT SIZE=2>Technical Support Engineer<TR><TD><FONT SIZE=2>Netscape Communications UK LTD<TR><TD><FONT SIZE=2>Northern Europe Technical Services</TABLE></TABLE> version:2.1 email;internet:matthew@xxxxxxxxxxxx note:Mickey@CMDnet - IRC adr;quoted-printable:;;No. 4 Status Park=0D=0ANobel Drive=0D=0AHayes;London;Middlesex;UB3 5EY;England x-mozilla-cpt:nemesis.netscape.com;10096 fn:Matthew Sullivan end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature