Being able to see up/down ratio of clients

[Wisp]

When you are in a hub, it would be handy to see what the upload/download ratio of a user is, so when a user is slotbegging you are able to see if he is worth a slot or he is just a leecher. The info can be stored at the same place as the e-mail or description.

[ivulfusbar]

define upload/download ratio.

[ullner]

Are you talking about the ratio at the bottom in the About box? It would be stupid to add it since it is easily faked by *anyone*. Just open up dcplusplus.xml and change it. Besides, the information says nothing about if a person is a leecher or not.

[bastya_elvtars]

define upload/download ratio.

bytesUp/bytesDown

And it would be a GREAT option as well - if it was worth to bundle it into MyINFO. Although it could possibly be faked, if it was not stored in an encrypted way, and could not be lost (but hey, in emule it could either!).

[Todi]

It would be impossible to verify, extremely easy to fake, and thus almost completely worthless, imho.

[Wisp]

Sharesize can also be faked but is still included in MyINFO

I mean, how many people are actively searching on warez networks how to crack dc++ to fake the info.. maybe 0,1%

[GargoyleMT]

Although it could possibly be faked, if it was not stored in an encrypted way, and could not be lost (but hey, in emule it could either!).

If it was used for any sort of preferential treatment, there would be great incentive to give false information.

Sharesize can also be faked but is still included in MyINFO

There's a difference between the two, isn't there? Your share size can be verified by summing the size of the files you share. And those files can be verified to exist by downloading their TTH leaves and making sure they match the TTH root. This is a much higher standard of than upload:download ratio could ever be held to.

[cologic]

Now, let's apply this to DRM.

In DRM, the attacker is *also the recipient*. It's not Alice and
Bob and Carol, it's just Alice and Bob. Alice sells Bob a DVD.
She sells Bob a DVD player. The DVD has a movie on it -- say,
Pirates of the Caribbean -- and it's enciphered with an algorithm
called CSS -- Content Scrambling System. The DVD player has a CSS
un-scrambler.

Now, let's take stock of what's a secret here: the cipher is
well-known. The ciphertext is most assuredly in enemy hands, arrr.
So what? As long as the key is secret from the attacker, we're
golden.

But there's the rub. Alice wants Bob to buy Pirates of the
Caribbean from her. Bob will only buy Pirates of the Caribbean if
he can descramble the CSS-encrypted VOB -- video object -- on his
DVD player. Otherwise, the disc is only useful to Bob as a
drinks-coaster. So Alice has to provide Bob -- the attacker --
with the key, the cipher and the ciphertext.

Hilarity ensues.

Also: I'd make sure this'd become configurable (well, if it's in the tag, it already is) in BCDC++.

[GargoyleMT]

I dug the two easiest last times this was suggested out of the archives:
http://dcpp.net/forum/viewtopic.php?t=9289
http://dcpp.net/forum/viewtopic.php?t=7231

[bastya_elvtars]

Yes, the problem is that on BitTorrent trackers store this information, thus individual on every single tracker. And making it different on a per-hub basis would be a pain, and would no longer be called DirectConnect.

[GargoyleMT]

Yes, the problem is that on BitTorrent trackers store this information, thus individual on every single tracker.

I thought that BT clients were supposed to distrust this value.