Anakim Border writes:
> > http://www.dolda2000.com/~fredrik/doldaconnect/protocol.html
> > > > 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 online presence.

No, of course we don't _need_ persistent GUIDs. I was thinking that it
would be good, though. While noone should rely on the GUID for banning
purposes in that way (that's obvious), I was thinking that users that
want to identify themselves to hubs (aka registered users), could
likely find it useful, in the same way that a user who wants to find a
specific other user could do so, even if that user has changed his
nick.

I see your point about privacy, though, but in that case, I think that
client implementors could just as well implement an option to make the
GUID non-persistent. That's my thought.

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

Precisely my thought. However, I think that this is probably not the
time to discuss that. The first and foremost priority in my mind is to
make the normal functionality work as it should. I also hope that if
hub implementors start developing hub-to-hub protocols before we
include it in any draft, they would hopefully find it natural to use
the same protocol parser that they already have for the hub-client
protocol, and submit their specs to us for inclusion.

Speaking of x-to-x protocols; Eric had an idea that I found
interesting, namely to make to client-to-client protocol more-or-less
pure HTTP. After all, HTTP does almost exactly what the
client-to-client protocol is supposed to do. I would like people to
voice their opinions about that. In my mind, it is a very good
idea. Of course, it would have some DC-specific headers, but that
doesn't prevent anything at all. It would also make HTTPS quite
natural for encrypted transfers.

Fredrik Tolf