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

[Jan Kr0]

I first sent this mail to the list 3 days ago but it seems like it got lost 
somehow.

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.
Note that this paragraph deals with implementation details, it's just to point 
out how the ID approach can actually improve everything.

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. Here's an overview:

- nick (token: n)
- domain (d) - domain the user is registered with. This is, obviously, useless, 
since we query the domain's server to get this information, so do we really 
need it?
- custom (c) - this can be used by the dbserver for just about any kind of info
- real (r) - classic real name
- ident (i) - the ident bit as used in today's hostmasks
- host (h) - the hostname, may be cloaked
- priv (p) - privileges on IRC
- idle (i) - idle time
- server (s) - server the client is connected to currently
- list of channels (l)
Dbservers could choose themselves which of those fields they'd use - they could 
even decide to disallow nicknames (fun that would be)...

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]
The Good Thing (tm) about this: we'd have a searchable database of all domains 
on our IRC networks. Everybody could (in theory) find another user, no matter 
what domain they're using.
This searchable database might also include channels - this could prevent from 
duplicate channels establishing everywhere.


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.
This will also (hopefully) reduce non-chatting traffic since clients would 
cache data and decide themselves how often whether they want to know about nick 
changes and stuff.
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.

Here's a question: what if we get rid of @+ prefixes in channels? That would 
reduce traffic again. Like, people would contact the dbserver to request a 
change of modes and the dbserver would confirm it, but no new prefixes would 
have to be displayed to all channel members. Also, this would probably kill 
free op channels, since there'll be nothing you can show off with (except for 
some powers). People would have to query the dbserver to find out what 
privileges people have (the dbserver can of course decide not to publish this 
information to people without power on the channel) and it wouldn't show 
prefixes but allowed operations.
The dbserver could then allow for a very finetunable configuration of channel 
powers without having to introduce n+1 prefixes.

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