In short, I think that agreeing on a $Supports standard is probably the
preferable way to extend the current protocol.  Once that's in place,
we'll have an easier time rolling out things such as QuickList (
http://dcplusplus.sourceforge.net/wiki/index.php/QuickList ).  I this
might largely be in agreement with what you said, but if not, feel free
to correct me.

But If we agree on a such command, where is the need of a special $Key containing EXTENDENDPROTOCOL, it is faster to just check if the $Support command is received than checking if the string is found (and AFAIK, there was recently problem with hubs that send NONEXTENDEDPROTOCOL).

If you take a look at the latest BCDC sources, Cologic has a Tiger Tree
Hash (TTH) implementation well on its way to production quality.  (I
think this has advantages of the CMD4 code that I saw in DCTC, and the
first-couple-k MD5 in DCGUI-QT.)  I think it would benefit the DC
community if hashes are made the de-facto way of identifying files and
of searching for alternates...

Whatever hash method is used, we definitively need one.

Based on the way you phrased that, there's really no way to oppose that
point, is there? :)  I'm all in favor of getting something tangible to
the users short term.  ($Supports + Quicklist perhaps? or ClientID? Or
perhaps clients just cooperating with BZList, file lists, and small
files.)  Once we do that, perhaps it'll be easier to move on to heavier
subjects.

Using a public key as client idea can be a good idea and a good step toward connection encryption.

Eric
DCTC/dchub