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