[Unity-irc3] user IDs, distribution among dbservers and uniqueness of nicknames

[Jan Kr0H9H 
A]

I've been talking about giving unique IDs to all users on the network.
The last design I talked about was a 48 bit ID, composed of:
 * domain ID (16 bits)
 * client ID on domain (32 bits)
Question: will we ever have 4 billions of users on one domain? If not, we could 
make the ID a bit short to save some more space.

Here's a concept on how to give out those IDs to clients:
when a client registers with a dbserver, the dbserver will pick out a random 32 
bit value and see if there's a user associated to it yet. Since we won't ever 
have close to even 2 billion users, we will (statistically) always get a free 
ID with two attempts. If we have a good randomization algorithm, this would 
also provide us with a nice way to split the database - the distribution across 
32 bits would be very good. If we, for example, had 32 dbservers on one 
network, we could decide which one was to get a new account by looking at the 
first 5 bits of the ID.

When we consequently use this ID approach, we could make all servers (and 
clients!) handle users by their ID only. If a client wanted a nickname for a 
user, it would send a query to a dbserver about that ID and would be supplied 
with loads of Good Stuff (tm). A client could then also choose to ignore nick 
changes (and override nicks with customly chosen ones).
This would get us rid of nickname registration forever, since the only 
important thing will be some kind of username to use in the hostmask (if at 
all). But that's an issue the individual dbservers will have to deal with, so 
let's not get too deep into it.
Of course, a lot of people won't like that, but nobody will be hogging 
nicknames any longer. To make a user identifyable by other users, the dbserver 
could choose to provide additional information (e.g. a "real name", a cloaked 
or real hostname, a username, an URL or just about anything else, this is not 
our problem right now).
Sample protocol (to be tokenized and/or binarized):

---------
[> - client to server
 < - server to client]

> DB WHOIS 19231738927
< RPL_WHOIS_INFO 19231738927 nick=billyboy domain=QuackWeb   
custom=BillGates213 real="Bill Gates" ident=bill.gates   
host=cloaked-5f243db34.macrosoft.com priv="IRC server operator"   
priv="Database operator" idle=100239 server=irc3.foo.uk.quackweb.org
----------
nick, domain and so on are here predefined fields for WHOIS queries, we'd need 
to agree on what kind of fields irc3 will need.

Clients could locally store the non-connection related information (i.e. nick, 
domain, realname) locally and refresh when needed. Of course, we would need 
some tag for domains that don't want permanent registration of users so we can 
let the client know not to save any info for those domains but only cache it in 
memory.

CHANNELS
========
We could make exactly the same things apply to channels. Of course it would be 
up to the dbserver whether to allow multiple channels with the same name (same 
goes for nicknames, actually. Of course, keeping track of uniqueness of 
nicknames or channels will put additional load to the dbserver since we'll have 
to use hash tables then).

SEARCH on names of users/channels
=================================
This would of course be very CPU intensive compared to doing a whois on an ID. 
That's why I suggest we add yet another tier of servers for that kind of stuff. 
Dbserver could regularly publish nick and host info and all the like to this 
searching server if they want to. [This idea taken from Ian Frechette too]


BIG ADVANTAGE
=============
Routing servers would need an amazingly small amount of memory since they don't 
need to know a lot about remote clients and channels. We could stuff all of 
this into the dbservers.
We could also use another thing Ian suggested on the-project, which is storing 
the IDs of locally connected members of channels only. That is, don't store 
info about what remote clients are in a channel - only store the ID of their 
server. Saves a lot of memory.

Let me know what you think about all of this.
--jast