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 online presence.

IMHO, a persistent GUID is required. 1) to have a faster connection establishment with hub (see my previous mail with the modified "GUID ID" command. 2) to allow client to filter their upload. For example, a user can reject an upload request from a GUID not seen on the hub (Note: this must be improved because with such a simple idea, anyone can get GUID of a user connected to a hub, disconnect from the hub and do a direct download attempt).
3) to speed up dead connection deletion. Some people have dynamic IP. If the IP changes when they are connected to the hub, this create 2 things: a dead connection on the hub (takes ~15 minutes to disappear) and an "enumerated" user if the user comes back before the dead connection deletion. If a user has an unique GUID, when he comes back, its dead connection can be deleted immediately (Note: same problem as the previous one with "stolen" GUID).

To avoid the "stolen" GUID problem, a solution is perhaps to use a challenge based login.

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.

Hub clustering works well (dchub does this) but I don't think this draft should discuss about this because IMHO, communication between hubs of a cluster is heavily based on the internal structures of a hub and also because I think that people building such configuration will always use the same hub program.

Eric