The current disincentive to freeload is to afford preferential treatment to some uploaders based on how many files they purport to be sharing. Unfortunately, this is misguided at best, broken at worst. People without much bandwidth, with clients like Limewire that scale very poorly to sharing huge numbers of files and start crashing once it gets into the thousands, etc. are instead incentivised to fake it. And the methods they are using are as devious as they are varied. The obvious would be for a hacked client to falsely report thousands of files shared when asked for a count, even if there are really only 2. Another obvious one is just to host a lot of files nobody wants with alphanumeric names containing no words anyone ever searches for, if bandwidth is the problem rather than a client that scales poorly even if nobody's actually downloading the files.

And then there are the really wacky things I've seen. People host popular files and set up six zillion upload slots on their modem-connected 286, resulting in every file you want showing up on this modem speed source and downloading at 0.001kb/s. (This seems to be especially common among Shareaza hosts, for some reason.) Perhaps these are trying to get around preferencing based on #upload slots. Then there's the idiot I just ran into. Like several such idiots I've encountered, he lets you connect and start downloading a file and then hits cancel download to conserve his precious bandwidth while fooling almost any anti-freeloader detection, even one that is based on observed successful download starts of a file and not just on a host claiming to have a file. (In fact, since he did it at exactly 1/3 of the file sent, and again at 2/3 when I tried to resume it, it's almost certain it's actually automated, meaning someone has written a deliberately malicious client that will send 1/n of a file and then deliberately pretend the connection died, presumably so idiots can semi-freeload without seeming to freeload.) First, though the download was throttled down -- it had reached 32% and then the throughput began dropping precipitously. Within ten seconds, throughput had ceased entirely, and the file hadn't even made it to 33%. Of course since I was watching when this happened I got annoyed and lo and behold the bugger's chat was on. So I hit chat ... nothing. Hit it again...nothing. Hit it again -- what? Greyed out? The jerk had disabled chat. The client obviously gives them some option to reject a chat without the sender receiving any reply packet, instead of auto-accepting like Limewire does if chat is enabled. He knew he was being buzzed, but blocked it, and when it happened twice quickly, he disabled chat. More evidence of a client designed for use by arseholes, since nobody else is going to need features for screening out irate chats. A bit after, the jerkwad pulled the plug on the download entirely -- busy signal. I hit resume and it went to 34% and straight back to busy. Resume again, 42%, busy. Resume again, 67%, and then the throughput started dropping off again. I right clicked -- jerk had turned chat back on. So I hit chat -- nothing. He never turned it back on but he never replied, though I tried twice more. Window never appeared (it should so long as the menu item wasn't grey, IMO). Of course, a bit later he interrupted the download again. I hit resume, and the jerkwad sent a bogus remaining 33% of the file -- it rapidly went to 100% and then File Corrupted.

B*#&ARD!!!!!!!!!!!

If you really don't want people to download the file from you DON'T SHARE IT, MORON!

So why was he sharing it? There's only one possible reason: to evade classification as a freeloader. It certainly wasn't actually to successfully share files, given that he kept trying to abort the transfer and then when it became clear I wouldn't be fobbed off with busy signals purposely polluted the file, which was pure spite since he'd spent as much bandwidth as sending the file properly, and there was really nothing further to be gained by doing so... This behavior is actually being encouraged by current anti-freeloader preferencing measures. Those measures are therefore causing more problems than they solve and need to be changed.

The solution is something needed for antispam measures anyway: reputation management. Integrated reputation management of files is needed for antispam purposes, and reputation management of clients to nerf the thousands of self-votes the spammers will submit for themselves and their spammy files. Reputation management of clients can then be used to give freeloaders a poor rap as well: they can get some sort of "less of a freeloader" points for each successful, verified file someone downloads off them and doesn't subsequently vote bad. Then jerks like the above example will quickly get a bad rap even if they score well on current freeloader-detection systems: files that get to some percent and then languish in busyland won't count for anything, and corrupted transfers may actually count negatively. (Spam certainly will, against whoever hosted it as well as against the spam itself.)

Give us working reputation management in 5.0 please! The current bitzi thing is basically useless -- it's so cumbersome to use, especially involving an external app (and a big, slow, bloated web browser at that) and a slow, graphics-encrufted Web site as it does, that nobody uses it. Worse, you can look up search results with it but when you download a file and decide it's misleading, you can't do anything about it -- there's no "mark this file eeevil" option next to the "preview" option or in the previewer itself. Until it's easy to participate in rating files, reputation management will not really work well, and until it's easy to review at a glance all the ratings of all the results of a search it will not really work at all. Fully integrated reputation management, for files at least, is sorely needed Real Soon Now.