write. However, it would be good if people would start looking through
the sections that I've written about the semantics of the protocol and
give me some early feedback.
First of all, do we really need *persistent*
GUIDs? They won't help tracking
malicious users, since anyone can always force his client to generate a new
GUID when he likes. They can surely be used to differentiate two users
sharing the same nick on different time frames, but:
1) even if GUIDs are not persistent, i.e. they are generated each time a
client is started, the probability of a 128-bit UID clash is remote;
2) in the case that happens, rollback and TTH are more than enought to protect
against file corruptions.
All in all I don't see any real need to make GUIDs persistent, while I don't
like the idea of making all too easy the life of people willing to track my
In the "Semantic->Roles" section I find the following open question:
However, should this protocol define a hub-to-hub protocol as well, or should
that be left to the hub implementor?
I think the current hub model is showing many limits; simply put it doesn't
scale at all. Things could get better by making two or more servers work
togheter (thus the need of a server-to-server protocol spec). I don't know if
your draft is the right place, but I'd definitely like to explore the topic.