dcplusplus-devel — Developer's list

Re: [dcplusplus-devel] Question about DC++ development

[Jacek S. <arn...@gm...>]

Hi,

I hope you don't mind be taking this question to the devel list..

In general, there were/are good reasons not to use filename based
sharing and I don't see mainstream DC++ going back, specially not to
downloading from unhashed sources.

However, one way to supply "instant" sharing at the uploading end
(which seems to be the actual functionality you're missing?) that
could make it into the core would be to generate the hashes
semi-lazily - i e allow search and browse by filename and somehow
prioritize hash-building for files that are in someones download
queue.

Also, if you would like to make a lan-version of DC++, we would gladly
accept any patches that would make maintaining your fork easier as
long as they would make reasonable sense in the hash-only core.

Regards,
Jacek

On Thu, Jan 19, 2012 at 2:19 PM, Lewis Hosie <lew...@gm...> wrote:
> Fantastic, thanks for that Fredrik.
>
> Hi guys,
> Over the last few years I've been attending LAN events in Melbourne,
> Australia. I'm not sure how aware you are of this but pretty much everyone
> around here uses DC++ (old versions of it) to share files at LANs. The main
> reason for this is that few other filesharing programs support organised
> downloading of entire folders, but can also share tens of terabytes without
> spending days to weeks hashing (especially when the LAN itself is shorter
> than the amount of time needed to hash).
>
> There have been a few attempts at original LAN-oriented filesharing apps
> (D-LAN etc) and have also been a few attempts to get people to switch to
> them (I even wrote a working demo of one myself), or to switch to the latest
> version of DC++, but these have always met with failure. The key problem I
> think is that nothing else has the combination of the ability to share
> without hashing as well as backwards compatibility with early versions of
> DC++ on NMDC hubs. The main two versions which are used in this manner are
> .306 (AFAIK last version not to hash) and .674 (AFAIK last version to load
> unhashed file lists), which of course are pretty damn old.
>
> There's also been a few attempts at building a version of DC++ that doesn't
> need to hash (LANDC etc) that are based on hashing DC but with hashing
> removed, making them incompatible with pretty much everything except
> themselves.
>
> While undoubtedly these events should be switching to ADC and newer versions
> of clients, and while purging unhashed and NMDC-based clients from the
> internet has been a long painful process, it's pretty much inevitable that a
> whole lot of people are going to stick with old versions (or unsustainable
> forks of old versions) until there is a solution that works with DC++ .306,
> works with newer versions, and allows instant sharing.
>
> Is the DC++ project as a whole entirely committed to never re-adding support
> for these things? Would the project suffer from a new version that allows
> downloading from (not necessarily uploading to) unhashed sources and the
> ability to add unhashed files for LAN connections only?
>
> I've made a few experimental clients for various protocols, but they would
> be entirely redundant if there was the possibility of DC++ covering those
> bases. I'm willing to put some work into creating a fork with these features
> if there's the possibility of reintegration into the mainstream client.
>
> Thanks,
> Lewis Hosie
> Developer at Prolapsoft
>
> On Thu, Jan 19, 2012 at 8:55 PM, Fredrik Ullner <ul...@gm...> wrote:
>>
>> Hi Lewis,
>>
>> I am no longer an active developer for DC++ (haven't been for some time).
>> The main developers are Jacek Sieka and poy (CC:ed). They should be able to
>> give you more information about where they want things to go with DC++.
>> (It'd be nice if I were on a CC since I'm curious about what you want. :) )
>>
>> If you have any particular question about the code or software, you can go
>> to <https://launchpad.net/dcplusplus>. Also, you can go to the developers
>> hub (via DC++) located at <adcs://hub.dcbase.org:16591>, where there are not
>> only developers for DC++ but for other Direct Connect oriented software.
>>
>> On Thu, Jan 19, 2012 at 5:16 AM, Lewis Hosie <lew...@gm...>
>> wrote:
>>>
>>> Hi there,
>>>
>>> I have a big question about both the application of DC++ and its overall
>>> development direction. Before I explain it in full, I'd like to know whether
>>> I'm asking the right person - are you one of the main developers of DC++?
>>> Can you speak for the overall direction of the project?
>>>
>>> Thanks for any response,
>>> Lewis Hosie
>>> Developer at Prolapsoft
>>
>>
>>
>>
>> --
>> Fredrik Ullner
>
>

[dcplusplus-devel] Fwd: OpenSSL Security Advisory

[poy <po...@12...>]

hey,

forwarding the OpenSSL message about the security fixes in 1.0.0f and 
why none of them affect us.

DTLS Plaintext Recovery Attack (CVE-2011-4108): we don't use DTLS (btw, 
someone should really pick up that UDP search results encryption...).
Double-free in Policy Checks (CVE-2011-4109): doesn't affect 1.0.0.
Uninitialized SSL 3.0 Padding (CVE-2011-4576): doesn't affect TLS.
Malformed RFC 3779 Data Can Cause Assertion Failures (CVE-2011-4577): we 
don't use that "enable-rfc3779" option.
SGC Restart DoS Attack (CVE-2011-4619): first i hear about SGC, but 
wikipedia seems to indicate this is a deprecated SSL extension.
Invalid GOST parameters DoS Attack (CVE-2012-0027): we don't use that 
GOST engine.

it would of course be sensible to upgrade in due time for the sake of 
being on the latest version; but this doesn't prevent 0.790 from going 
stable.

poy


-------- Original Message --------
Subject: OpenSSL Security Advisory
Date: Wed,  4 Jan 2012 21:04:06 +0100 (CET)
From: op...@ma... (OpenSSL)
Reply-To: ope...@op...
To: ope...@ma..., ope...@ma..., 
ope...@ma...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OpenSSL Security Advisory [04 Jan 2012]
=======================================

Six security flaws have been fixed in OpenSSL 1.0.0f and 0.9.8s.

DTLS Plaintext Recovery Attack (CVE-2011-4108)
==============================================

Nadhem Alfardan and Kenny Paterson have discovered an extension of the
Vaudenay padding oracle attack on CBC mode encryption which enables an
efficient plaintext recovery attack against the OpenSSL implementation
of DTLS. Their attack exploits timing differences arising during
decryption processing. A research paper describing this attack can be
found at http://www.isg.rhul.ac.uk/~kp/dtls.pdf

Thanks go to Nadhem Alfardan and Kenny Paterson of the Information
Security Group at Royal Holloway, University of London
(www.isg.rhul.ac.uk) for discovering this flaw and to Robin Seggelmann
<seg...@fh...> and Michael Tuexen <tu...@fh...>
for preparing the fix.

Affected users should upgrade to OpenSSL 1.0.0f or 0.9.8s.

Double-free in Policy Checks (CVE-2011-4109)
============================================

If X509_V_FLAG_POLICY_CHECK is set in OpenSSL 0.9.8, then a policy
check failure can lead to a double-free. The bug does not occur
unless this flag is set. Users of OpenSSL 1.0.0 are not affected.

This flaw was discovered by Ben Laurie and a fix provided by Emilia
Kasper <ek...@go...> of Google.

Affected users should upgrade to OpenSSL 0.9.8s.

Uninitialized SSL 3.0 Padding (CVE-2011-4576)
=============================================

OpenSSL prior to 1.0.0f and 0.9.8s failed to clear the bytes used as
block cipher padding in SSL 3.0 records. This affects both clients and
servers that accept SSL 3.0 handshakes: those that call SSL_CTX_new with
SSLv3_{server|client}_method or SSLv23_{server|client}_method. It does
not affect TLS.

As a result, in each record, up to 15 bytes of uninitialized memory
may be sent, encrypted, to the SSL peer. This could include sensitive
contents of previously freed memory.

However, in practice, most deployments do not use
SSL_MODE_RELEASE_BUFFERS and therefore have a single write buffer per
connection. That write buffer is partially filled with non-sensitive,
handshake data at the beginning of the connection and, thereafter,
only records which are longer any any previously sent record leak any
non-encrypted data. This, combined with the small number of bytes
leaked per record, serves to limit to severity of this issue.

Thanks to Adam Langley <ag...@ch...> for identifying and fixing
this issue.

Affected users should upgrade to OpenSSL 1.0.0f or 0.9.8s.

Malformed RFC 3779 Data Can Cause Assertion Failures (CVE-2011-4577)
====================================================================

RFC 3779 data can be included in certificates, and if it is malformed,
may trigger an assertion failure. This could be used in a
denial-of-service attack.

Note, however, that in the standard release of OpenSSL, RFC 3779
support is disabled by default, and in this case OpenSSL is not
vulnerable. Builds of OpenSSL are vulnerable if configured with
"enable-rfc3779".

Thanks to Andrew Chi, BBN Technologies, for discovering the flaw, and
Rob Austein <sr...@ha...> for fixing it.

Affected users should upgrade to OpenSSL 1.0.0f or 0.9.8s.

SGC Restart DoS Attack (CVE-2011-4619)
======================================

Support for handshake restarts for server gated cryptograpy (SGC) can
be used in a denial-of-service attack.

Thanks to Adam Langley <ag...@ch...> for identifying and fixing
this issue.

Affected users should upgrade to OpenSSL 1.0.0f or 0.9.8s.

Invalid GOST parameters DoS Attack (CVE-2012-0027)
===================================================

A malicious TLS client can send an invalid set of GOST parameters
which will cause the server to crash due to lack of error checking.
This could be used in a denial-of-service attack.

Only users of the OpenSSL GOST ENGINE are affected by this bug.

Thanks to Andrey Kulikov <am...@gm...> for identifying and fixing
this issue.

Affected users should upgrade to OpenSSL 1.0.0f.

References
==========

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20120104.txt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBTwSwVqLSm3vylcdZAQL8nwgAtNob9cIjI0SlNW1sLrlzP9bLPpNV9o6p
+sD9jIMBKsoMZcB9ANMMgcu6bMAz5Hm+7//ff35WJP9oDN4vYnw/cAzXuj8+dclm
qQLs9jR+qkyDtjh4Oiyabvjsq7uAgEp7D88pgFK+PF+0TRaH/2hyZgGNlg1JOrNR
SoFN5rVwNhIybkMhd3kNjU8cIkA2lI0vjNqmGOafZ5xTyWhViHuvN014hRyffiNS
JE4icLuQV25DidcZkvxjuiaHiJz70DZgerSOds5H8kNeoNlIevPxPzWEaZ7HMsuL
loK+hqE/nMMaL3lk29+a7k1lcqNvljt3M5dX/CVbevvV0NCV62bojA==
=56UI
-----END PGP SIGNATURE-----
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Announcement Mailing List                 ope...@op...
Automated List Manager                           maj...@op...

[dcplusplus-devel] Translations updated for DC++ 0.790

[poy <po...@12...>]

Hey,

Translations on <https://translations.launchpad.net/dcplusplus> are 
being updated for a release of DC++ 0.790 planned for Christmas.

Therefore, you have about a week to proceed with translations.

To see what the new version will be like, test builds are available on 
<http://builds.dcbase.org/>.

Have fun!
poy

[dcplusplus-devel] translation templates updated for the next release

[poy <po...@12...>]

hi translators,

the templates on <https://translations.launchpad.net/dcplusplus> are 
being updated for a release of DC++ 0.780 due in about a week.

there is a new template for the installer, which contains 14 strings - 
see <http://dcpp.wordpress.com/2010/09/21/installer-improvements/>. give 
it a go if you want your language to be included in the installer! most 
other standard installer strings are pulled directly from the Unicode 
NSIS <http://code.google.com/p/unsis/> translation database.

poy

[dcplusplus-devel] translation templates updated for DC++ 0.770

[poy <po...@12...>]

hi translators,

the templates on <https://translations.launchpad.net/dcplusplus> will be 
updated shortly in prevision of a release of DC++ 0.770 around the end of 
the week.

poy 

[dcplusplus-devel] translations updated

[poy <po...@12...>]

the translation templates on <https://translations.launchpad.net/dcplusplus> 
are being updated for a release of DC++ 0.762 due by the end of the week.

poy 

[dcplusplus-devel] translation strings updated

[poy <po...@12...>]

hi list,

translation strings on <https://translations.launchpad.net/dcplusplus> have 
been updated, for a release of DC++ 0.760 in about a week if all goes well.

if you want to see the changes for yourself, <http://builds.adcportal.com/> 
provides recent runnable versions of DC++ that should be close to the one 
that is going to be released.

have fun! :)

poy 

[dcplusplus-devel] blacklist

[poy <po...@12...>]

hi,

here is a patch to implement a blacklist function in order to alert the user 
when a hub list has fallen into the wrong hands. when such a hub list is 
selected by the user, the following message appears on top of the tab:

---
Warning: fraudulent hub list detected!

The current hub list ([url of the list]) has been blacklisted by DC++ for 
the following reason:
[reason]

It is strongly recommended that you do not connect to any of the hubs listed 
here and that you remove this hub list from your collection by using the 
"Configure" button below.
---
(see attached screen-shot)

the list can be updated via version.xml with this format:
<Blacklist>
    <Blacklisted Url="..." Reason="..."/>
    <Blacklisted Url="..." Reason="..."/>
</Blacklist>
(i haven't tested that particular update function.)

there has been concerns about the danger of allowing outside parties to 
remove hub lists in all DC++ out there; instead, this solution only displays 
an explicative message to the user, but doesn't act on her behalf. i hope 
this is an acceptable compromise.

as for performance, there shouldn't be much difference because the text-box 
control used to host the blacklist message is only created when needed, and 
destroyed afterwards.

the default blacklist contains only 1 list at the moment:
<http://adchublist.com/hublist.xml.bz2>
with the reason: "Domain used for spam purposes."

note that there is room for way longer explicative reasons if needed.

poy 

[dcplusplus-devel] use of the User::PASSIVE flag

[poy <po...@12...>]

searching for "User::PASSIVE" in the dcpp files shows that the flag is only 
set and un-set for users in NMDC hubs; however, it is being checked for in a 
couple of protocol-agnostic places:

in ConnectionManager::on(TimerManagerListener::Second:
    if(cqi->getUser().user->isSet(User::PASSIVE) && 
!ClientManager::getInstance()->isActive()) {
     passiveUsers.push_back(cqi->getUser());
     removed.push_back(cqi);

in QueueManager::addSource:
 if(aUser.user->isSet(User::PASSIVE) && 
!ClientManager::getInstance()->isActive() ) {
  qi->removeSource(aUser, QueueItem::Source::FLAG_PASSIVE);

as a result, it is likely that this feature that removes passive users from 
the queue is not working for ADC hubs. ideally Identity::isTcpActive would 
be used instead but i'm not sure how it can be applied there.

poy 

Re: [dcplusplus-devel] passive users sometimes considered active in ADC

[poy <po...@12...>]

> looks reasonable - adch++ looks for u4/i4 (the port) - maybe that should 
> be checked for too since
> it's needed to actually do the connect...

U4 (UDP port) is already being checked for, but the TCP port can't be 
checked in advance since it's not send via INF, but later in each CTM.

now the follow up, can i change ADCH++ to send IPs of every user, not just 
active ones? attached patch would do that.
it would allow some clients to process these IPs automatically and display 
them next to the nick for example. note that security is not a concern here 
since it's already possible to get these IPs with the +info command.

poy 

Re: [dcplusplus-devel] passive users sometimes considered active in ADC

[Jacek S. <arn...@gm...>]

looks reasonable - adch++ looks for u4/i4 (the port) - maybe that should be checked for too since
it's needed to actually do the connect...

/J

On 2009-12-11 18:07, poy wrote:
> when an ADC hub sends the IP of a passive user, DC++ considers that user
> active, eventhough that user hasn't set TCP4 / UDP4 in the SU field of INF.
> attached patch fixes it.
> 
> poy
> 
> 
> 
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> 
> 
> 
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel

[dcplusplus-devel] passive users sometimes considered active in ADC

[poy <po...@12...>]

when an ADC hub sends the IP of a passive user, DC++ considers that user 
active, eventhough that user hasn't set TCP4 / UDP4 in the SU field of INF.
attached patch fixes it.

poy 

Re: [dcplusplus-devel] Encoding in chat

[Fredrik U. <ul...@gm...>]

I can't say I fully understand encoding, codepages, locales etc, so here
goes; isn't the setting in favorites.xml indeed a user configuration option
(albiet quite non-obvious)?

(By the way, AFAIR, it was the LinuxDC++ people that wrote the setting and
its funtionality...)

It's possible that some people in adcs://devpublic.adcportal.com:16591 knows
more about this topic. (TLS enabled ADC client required.)

-- 
Fredrik Ullner

Re: [dcplusplus-devel] Encoding in chat

[Michał W. <en...@en...>]

Dnia wtorek 03 listopada 2009 o 08:01:06 Fredrik Ullner napisał(a):
> AFAIK, DC++ uses whatever that is system locale and it can only use those
> listed in http://msdn.microsoft.com/en-us/library/ms930130.aspx (Can be
> changed in favorites.xml.)
> 
I cannot see "codepage" in favorites.xml. I can see only Encoding="C", which 
is indeed default locale. Anyways, UTF-8 is used wider and wider, so could be 
good for many users (as user-configurable option). Especially users of 
LinuxDC++ likes this encoding, while windows users are bound to default 
codepage. It could be problem of linux users, while some of windows users here 
are using Polish and some are using English versions of Windows, which results 
in codepage mismatch. Is there no possibility to add codepage/encoding as user 
configurable option? thanks in advance.
-- 
Michał Wiśniewski

Re: [dcplusplus-devel] Encoding in chat

[Fredrik U. <ul...@gm...>]

AFAIK, DC++ uses whatever that is system locale and it can only use those
listed in http://msdn.microsoft.com/en-us/library/ms930130.aspx (Can be
changed in favorites.xml.)


-- 
Fredrik Ullner

[dcplusplus-devel] Encoding in chat

[Michał W. <en...@en...>]

Hi devs.
Maybe You find it strange, but some people are not using english in-chats and 
they would like to use diacritics. Moreover, some hubs are multilingual (here 
- Polish, Chinese and French). Is there any way to set UTF-8 as default hub 
encoding? it would be useful for many ppl.
Thanks in advance.
-- 
Michał Wiśniewski

Re: [dcplusplus-devel] DC++ userlist icon take 2

[poy <po...@12...>]

----- Original Message ----- 
From: "RadoX" <ra...@in...>
To: <dcp...@li...>
Sent: Tuesday, October 20, 2009 11:22 PM
Subject: [dcplusplus-devel] DC++ userlist icon take 2


> Here is an idea for new userlist icon 
> 
> http://img200.imageshack.us/img200/5236/dcusericons.png
> 
> RadoX

your messages have been received (3 times, even), don't worry. ;)

poy

[dcplusplus-devel] DC++ userlist icon take 2

[RadoX <ra...@in...>]

Here is an idea for new userlist icon 

http://img200.imageshack.us/img200/5236/dcusericons.png
 
RadoX

[dcplusplus-devel] OSS Usability Improvement

[Arif R. <ar...@uw...>]

Hi there
 
Please find below a link to a survey related to my PhD research work to evaluate OSS usability     improvement from Contributor's point of view.
It shall not not take more than 5 minutes of your precious time.
Your identity is neither required nor recorded. The participation is  highly valued and appreciated.

http://www.kwiksurveys.com/online-survey.php?surveyID=OLHOO_22480cb3

Thank you and Best Regards

Arif
P.S. This mail  has been sent to you with the permission of dcplusplus-devel mailing list administrator.

Re: [dcplusplus-devel] ADC: message timestamp

[Fredrik U. <ul...@gm...>]

Actually, I think a better venue is adcportal.com, as I don't know if others
read this fora.

On Tue, Aug 4, 2009 at 8:56 PM, poy <po...@12...> wrote:

> attached; a patch that adds the "TS" line to the ADC doc; and one that
> makes DC++ aware of messages that contain a "TS" param.
>
> if anyone wants to test it out, my bouncer on <
> https://launchpad.net/dcbouncer> adds the param to ADC messages it logs.
>
> poy
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>
>


-- 
Fredrik Ullner

Re: [dcplusplus-devel] ADC: message timestamp

[poy <po...@12...>]

attached; a patch that adds the "TS" line to the ADC doc; and one that makes 
DC++ aware of messages that contain a "TS" param.

if anyone wants to test it out, my bouncer on 
<https://launchpad.net/dcbouncer> adds the param to ADC messages it logs.

poy 

Re: [dcplusplus-devel] ADC: message timestamp

[Fredrik U. <ul...@gm...>]

>
> including the timestamp of the message in the message string is indeed the
> only possibility i have for the moment and it is an ugly hack, which might
> be acceptable on NMDC, but please allow for something more correct in ADC.
> that would be like saying "yeah, just send your message with /me in front of
> it, and the other client will assume it's 3rd-person" when in fact having a
> separate param to specify this is far more correct.
> moreover, sending the timestamp separately lets the client format it the
> way it wants to.
>
Bah. You just can't do that. You can't similize that to ME since I'd have to
agree with you. :)

-- 
Fredrik Ullner

Re: [dcplusplus-devel] ADC: message timestamp

[poy <po...@12...>]

> Could you not modify your bot to actually store the time, too? So it'd
> report the time it got the message... (Time would probably enlarge the
> entirety of messages compared to the TS param, but still.)

sure, my bot has to store a timestamp along with each message, that's not a 
problem. the question is: when i connect, and my bot sends me the messages 
it has been logging, how does it tell DC++ when each message was sent?

> Actually, I've been using a hub that have that exact functionality. "You
> have the following messages: 1) PM from <nick>: <msg>, <date/time of
> message>" -- i.e., it displays the date/time the message was sent (well,
> obviously received by the hub). Granted, having *exact* time in terms of
> message sent by client might be useful, but I think the (potential) lag is
> negligible. (Indeed, the hub is NMDC even...)

including the timestamp of the message in the message string is indeed the 
only possibility i have for the moment and it is an ugly hack, which might 
be acceptable on NMDC, but please allow for something more correct in ADC. 
that would be like saying "yeah, just send your message with /me in front of 
it, and the other client will assume it's 3rd-person" when in fact having a 
separate param to specify this is far more correct.
moreover, sending the timestamp separately lets the client format it the way 
it wants to.

poy 

Re: [dcplusplus-devel] ADC: message timestamp

[Fredrik U. <ul...@gm...>]

>
> as for the use case, i have a bot that logs messages for me when i am not
> online, and when that bot forwards messages it has been logging back to me,
> i receive all messages as though they just got written, although some might
> be dating from a week ago. therefore, i want my bot to add a TS field to
> each message specifying when it was sent, so that when DC++ receives it, it
> displays it with its original timestamp.
>
Could you not modify your bot to actually store the time, too? So it'd
report the time it got the message... (Time would probably enlarge the
entirety of messages compared to the TS param, but still.)


> another similar example would be a hub that offers an "offline PM"
> functionality: send a message to a regged user, and if that user is not
> online, the hub logs it and wait for that user to come back to send her your
> message. in this case too, the lag is not negligible anymore and there needs
> to be a way for the sender of the logged message (be it a hub or a bot) to
> tell when the message was originally sent.


 Actually, I've been using a hub that have that exact functionality. "You
have the following messages: 1) PM from <nick>: <msg>, <date/time of
message>" -- i.e., it displays the date/time the message was sent (well,
obviously received by the hub). Granted, having *exact* time in terms of
message sent by client might be useful, but I think the (potential) lag is
negligible. (Indeed, the hub is NMDC even...)

-- 
Fredrik Ullner

Re: [dcplusplus-devel] ADC: message timestamp

[poy <po...@12...>]

> How often would this feature be used? I.e., would (should) clients add 
> that
> every X message to ensure that they are not lagging (or every X seconds
> etc)?

clients supporting the version of ADC that has this MSG field should be able 
to understand such a MSG and display the timestamp they were given instead 
of making up their own. the field is optional, so they don't have to add it 
to every outgoing message; they can choose to if they want to get fancy.
also, using this to measure the lag isn't what this was intended for, but if 
a client wants to use it for that purpose, no problem...

>
> While I can admit that it might be interesting to have real timestamps (if
> not simply for the fact that it'd be similar to other protocols), I fail 
> to
> see the usefullness for normal clients. (How would the client know when it
> should send with timestamp and when it shouldn't?) At most, though, it 
> seems
> this feature would only be really useful in a debugging environment.

indeed, normal clients won't add this field to any of their messages; they 
should simply be able to treat incoming messages that have a TS param 
accordingly.

as for the use case, i have a bot that logs messages for me when i am not 
online, and when that bot forwards messages it has been logging back to me, 
i receive all messages as though they just got written, although some might 
be dating from a week ago. therefore, i want my bot to add a TS field to 
each message specifying when it was sent, so that when DC++ receives it, it 
displays it with its original timestamp.

another similar example would be a hub that offers an "offline PM" 
functionality: send a message to a regged user, and if that user is not 
online, the hub logs it and wait for that user to come back to send her your 
message. in this case too, the lag is not negligible anymore and there needs 
to be a way for the sender of the logged message (be it a hub or a bot) to 
tell when the message was originally sent.

poy