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
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
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