Well, if you use only two characters, you really only have 3*26 command
types.  Implicit was the idea that the first character is either H (for
client to hub), B (for client to broadcast), or C (for client to
client).  This way, if you're not validating commands, the logic
required to route the request is pretty simple. 

I think it is a big waste of space because the 2 main groups of commands are client-hub and client-client, the client to broadcast commands are only a sub-category of client-hub commands and is a very small set of commands (search query & public chat (only ?) ).

Eliminating whitespace between some commands with fixed-length parameters is definitely a worthy idea... though how much we need to reduce the protocol's bandwidth usage is something we should bring up again later.  Certainly we should code and measure a typical DC hub against a similar test protocol hub before we roll it out.

finding the most used commands is not difficult: 1) search query ($Search)
2) connection query ($ConnectToMe)
and if passive users are on the hub:
3) search reply ($SR)
4) reverse connection query ($RevConnectToMe)

Public and private chat commands are probably very insignificant even if they can carry a payload bigger than the 4 previous commands, most of hub have no public chat activity (except kick/ban messages but it is a waste of bandwidth to send such messages to everyone).
Assuming these commands are the most used ones, replacing nickname by GUID will IMHO have a big inpact on the bandwidth because all these commands use one or even two GUID and even a long nickname is shorter the GUID, especially because the GUID is in ASCII and not in binary (like described in a previous mail).

Eric
DCTC/dchub