Gustaf Räntilä wrote:

Here, "names" are nick-names I suppose. Should they (as they once Are
"entered by the user") be able to contain multi-byte UTF-8 chars or
single-byte > 127? I believe that's what "All texts must be sent as UTF-8,
including file lists, searches, nick’s, hub lists etc." means.
In this case, hubs must include full UTF-8 supported case insensitive
matching I suppose... <... snip elaboration ...>

Secondly, I've said this before (far over a year ago) I like the idea
of encrypting the traffic, and I barely see theoretical limitations
to this, even though p2p data speeds are 'high' nowadays. <... snip
...> Maybe  something like the
GPA/PAS-routine could be done for client-hub ciphering to avoid usual
 encryption keys (if this is heavy for hubs to  generate/encrypt/decrypt). If
encryption becomes native, a key-propagation in the search message  should be
easily implemented, so the clients encrypt the search reply with the
given key. Note; if this is Not natively implemented in the base
protocol, then  future
implementations are a lot more difficult, since there is no exchange
of "extended client features" in the usual client2hub communication.
There are  no way to know another clients public key/ in other words. This could
be sent in a wider INF for sure, but I'm not certain it would be any
more efficient, so "making room" for this natively could be a good
idea.

I have the feeling that encryption isn't something most of you are interested in, but I still want to know how you feel about it. And I
would like feedback on my urge for the native support of (I agree,
maybe  _future_) key exchanges in the base messages presented by the protocol.

I recently brought case-insensitivity on the development hub, and it's a noticeable issue. According to Tim Bray at http://dotnetjunkies.com/WebLog/sriram/archive/2004/11/18/32707.aspx#32794, whom a few here might recognize:

XML markup is case-sensitive because the cost of monocasing in
Unicode  is horrible, horrible, horrible. Go look at the source code in your
local java or .Net library.

Also, not only is it expensive, it's just weird. The upper-case of é
is different in France and Quebec, and the lower-case of 'I' is
different here and in Turkey.

XML was monocase until quite late in its design, when we ran across
this ugliness. I had a Java-language processor called Lark - the world's
first - and when XML went case-sensitive, I got a factor of three
performance improvement, it was all being spent in toLowerCase(). -Tim

I'm sure hub authors will love that when they were (only partially tongue-in-cheek) suggesting $ClientID sorts of mechanisms to save CPU time because parsing the tag is just so horribly slow. I'm mostly indifferent with mild bias against mandatory case-insensitivity for unrelated reasons, but best to know this beforehand.

Further: I would like not only for encryption, but for some traffic shaping-resistance in the form of, in Gargoyle's words, doing SSL [or TLS] from the outset. It even looks pretty practical speedwise; I had OpenSSL report to me the 1000s of bytes per second processed under each cipher on an Athlon 800MHz, and came up with:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
rc4              63129.39k    71440.23k    73317.55k    74151.25k 74446.17k
aes-128 cbc      18007.45k    18464.32k    18731.69k    18789.38k 18814.29k
aes-192 cbc      15695.25k    16054.23k    16252.50k    16294.57k 16315.73k
aes-256 cbc      14000.18k    14208.81k    14367.32k    14404.27k 14417.92k

It drastically exceeds a 10Mbit/s connection's capacity, and that of a 100Mbit/s connection less drastically, even on a slow machine, and in the former case by an order of magnitude even when not using 100% CPU as that test allowed. However, I fully expect that should encryption appear, 100Mbit/s users might disable it as I gather they reasonably commonly disable zlib compression.

I'm unsure as to the nicest way of avoiding ever revealing the presence of a DC connection by encrypting from the very first packet of a connection, but I would strongly support that. http://l7-filter.sourceforge.net/technicaldetails and http://l7-filter.sourceforge.net/protocols provide insight into what the programs you mention can detect, and thereby means of defeating them. I'm fairly ignorant of the capabilities and limits of the commercial versions.

-cologic (who would love for Opera not to top-post, and assumes there's such a modification of Outlook around)