What are the priorities for version 5? I think one of the major ones will have to be getting rid of spam. Spammers are causing damage in at least four ways:

1. They generate dozens of spoofed results for some searches, which crowd out legitimate search results in transfer to ultrapeers.

2. They deface and redistribute files. This causes downloads to be wasted.

3. They sometimes participate in the download mesh for a popular file and send both bogus (spam-containing) chunks and bogus hashes. Limewire thinks the file was downloaded successfully, but the result's either (depending on size and how many legitimate sharers of the file were not busy and served chunks) corrupt, truncated, completely absent (zero length), garbled mixing legitimate and spammy content, or completely substituted with spam. (It may also depend on whether the spam is larger, smaller, or the same size as the real file. This also causes downloads to be wasted.

4. They reduce the value of the whole system in the process.

Spoofed search results are bad because they crowd out legitimate results and make rare files harder to get. Wasted downloads are bad because the file you were supposed to get (but didn't, or it was damaged) may have been rare and difficult to get, so again rare files are harder to get as a result. Spoofed results effectively narrow the horizon; the saving grace is they are easily recognized (just your query terms, in order, possibly altered in capitalization or with underscores added in places; lots and lots of T1 sources listed) so you can avoid wasting your time downloading them. Doesn't get you the file that didn't appear in the search results because a supernode had to drop it to make room for the spew, though. Damaged/substituted-in-transit downloads on the other hand appear to be completely unavoidable. Some particular files (usually either very popular or rare but interesting) seem especially hard hit by mesh polluters -- there are some that I have attempted to download dozens of times, only to get a damaged file or a spam every single time, even though the search result was legitimate! Others have taken several attempts before eventually an unadulterated copy was successfully transferred. And other files, indeed the vast majority, transfer without a hitch. Mediocre files don't seem to be attacked in this way -- only rare but fairly desirable files and highly popular ones, and the latter usually transfer OK due to the large number of legitimate copies being shared making the odds of getting chunks from a polluter minimal. Unfortunately, mediocre files are also the hardest to find with a search...

The spammers have to be stopped. Here are the 3 proposed changes, to be implemented in tandem to combat this plague:

1. Bitzi lookups are automated, and the star rating/whatever icon in a search result is colored based on the results. The current colors indicate not found; a red background or tint indicates a significant negative rating; yellow indicates a neutral rating (near zero, positive or negative); green indicates a significant positive rating.

The current Bitzi interface is pants. It launches a separate process (a Web browser) which is slow, and this is sent to a site which is slow and ad- and graphics-encrufted. A clean rating display of the sort described above would be vastly superior to having to manually Bitzi every search result and, for each one, wait for a slow Web page load.

Best would be to allow voting files up and down from within the Library tab on top of the above.

2. Fingerprints of known spoofed-search-result spams are tracked by supernodes and rejected as search results. No search result for a file with an ipod spam hash is propagated at all. Possibly add Bitzi integration on top of this: when a supernode has to drop hits, it starts at the bottom of the Bitzi ratings and works its way up, dropping bad rated results before neutral ones or unknowns, and these before good rated results.

This will remove the ipod spams entirely and make the supernodes, and search results generally, perform the better for it.

3. Mesh participants are no longer trusted to tell the truth about the hash (and contents!) of a chunk. Whenever multiple sources are known, hashes for each chunk are requested from at least two of them. If they disagree, a hash is requested from a third. If this agrees with one of the others, the remaining source is marked invalid. If none of them agree, the download stops and the file is flagged corrupt. Alternatively, an addendum to the protocol is made -- an extension for distributing file hash information. This might be used to better locate files on requery, as well as to weed out mesh polluters by making chunk hash verification work on a "majority rule" principle. Any bogus chunk slipped to you by a spammer would then cause the download to be flagged as corrupt, rather than silently mutate the file, even if the spammer sends a hash properly corresponding to the spammy chunk.

This will weed out the rest of the spew, and cause the files damaged by botched spamming attempts to properly appear as corrupt, rather than appear to download successfully only to turn out not to work, to be garbled, or to be truncated when you go to examine them.

Unfortunately it won't do anything about the case where the only non-busy host in the mesh for a file is a polluter rather than a legitimate source. Hopefully, such occasions are fairly rare.

It's time to stamp out Gnutella spammers!