SV: [dcdev] Anyone still alive?

Hello all,

If adc finally is moving into 'stable' state, I have a few concerns...
First of all 2.1 states:

  "All text data in the protocol that is not entered by the user, including
protocol names, extensions etc may only contain viewable characters that may
be encoded by one byte in the UTF-8 encoding (ASCII codes 33-127). Although
the protocol is case-sensitive, names distinguished only by case are
disallowed (upper case is preferred)."

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... This is not a complaint or anything; I just wanted to
be clear of the issue that true Unicode enabled string functions are
required in ADC generally. As in contrast to 'regular DC' were currently,
any non-utf-8 enabled string function will (probably) do (no matter what
internal string encoding is used, for instance with dc++ gui being Unicode
nowadays), since UTF-8 is a nice encoding, and since DC doesn't support
anything but 'ACP'. So relying on current implementation when it comes to
string functions isn't a good idea I suppose. (Just a hint for any
"ADC-developer" if I have got it all right.)

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. I know of certain internet
providers (universities for instance), that have taken action against users
simply because of filenames in shares (that are being sent clear-text as bz2
filelists). They are using programs analysing this kind of traffic
automatically (you all probably know this, I know). This is not 'our'
problem, but I think it's not more than fair to try to develop a 'native'
support for an encryption base in the main protocol.
P2P encryption is probably not very difficult with individual key-pairs or
anything similar, but what's probably not so easily done is search replies
(and eventual client-hub encryption). 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.

/Gustaf aka 'Opera' (and yes, I'll convert from outlook to thunderbird one
day)

-----Ursprungligt meddelande-----
Från: [email protected] [mailto:[email protected]] För
Jacek Sieka
Skickat: den 28 december 2004 17:11
Till: 'Direct Connect developers'
Ämne: RE: [dcdev] Anyone still alive?