First of all it's the message delimiter \r\n that should be changed to
\n. There is no reason to favor the current win32 implementation of
new-lines here, it only adds bug-sources to code. Splitting messages
with only one 'char' is better in every possible way I think. And this
isn't http anyway ;)

Yes, I changed it just now...

Numbers should be at least double? "double" is implementation-specific
so I guess you mean 64-bit? And then, why? This must be, just like
integers being 64-bit, state dependant. Not all kinds of data needs such
large numbers, I'd say that's a specification that should be removed
from the protocol.

At least 64 bit, that's what double means in my eyes...as for different
sizes in different states, why bother? There aren't very many numbers anyway
in the protocol...(actually, the general double spec can probably be removed
since there are no doubles used...), and it's not like you'll run out of
memory on your precious machine if you use an int64 instead of an int32...

As sandos mentioned in the hub chat; "Filenames outside the root are
treated as special". Outside what root? What _exactly_ are you talking
about here?

Yes, that needs further explanation.../ is the unnamed root that counts for
the share, while for instance TTH/ could be the tiger three hash root...I'm
open to suggestions here though...

I think there should be support for binary data without base32 for
communication between client and hub (and also hub to hub if that is at
all supported), similar to the "DATA state". This might be very useful
and adds no complexity since hubs/clients that don't use it, won't need
to. Still it has to be in the protocol spec.

The problem is escaping mainly, i e if we use binary data then suddenly we
have to either send lengths (which defeats the purpose of a text-based
protocol) or escape the binaries (which is ugly)...

In the ERR message there are params and description. Since this protocol
says that message parts are delimited with space, and descriptions can
include space, how will I know what is a parameter to ERR and what is
the description? Maybe "ERR Code:Descr: param1 param2..." is a better
way, and force description not to include ':'.. It's ugly yes, but just
a note.

You escape the space?

In INF I couldn't see an ip port for TCP. How will client A be able to
connect to client B without knowing the TCP port? Maybe I missed
something..

Port is in the CTM so that one client can support many protocols...

And when speaking of INF, "HI"? Can an arbitrary user send that info to
become invisible? I think it should be used only for special occasions
of some kind of bots. And then it's prolly up to the hub anyway to "make
it hidden", so, I really don't see the use of this.

Then it's up to the hub to block it / add it appropriately...

I would like a "mode" where file sharing is disabled, a kind of "chat
only mode". That should be represented in the INF as well with HC or
something like that..

Use irc?

/J