This reminds me of a program that I had a play with some time ago, Framsticks. It uses genetic algorithms to 'evolve' both mind and body according to a user-definable fitness function (e.g. distance travelled). The virtual creatures can be modelled onscreen.
Some of the people who believe this is not a form of evolution might find this program helps to explain how it works. Seems like evolution to me. Just because in the article the body was pre-designed, doesn't mean the mind wasn't evolved.
To reduce the bandwidth/cpu of your suggestion, how about each client returns "Yes, I have that file, with a hash of: 34232SFDSFSDSDSD2323DSD and a mod of: Good/Bad/Unrated"
The amount of data returned isn't much more than the eDonkey-type name, size and hash, and the client can display percentages of good, bad and unrated along with number of locations. Incomplete or unchecked copies are marked as 'unrated' so that the client knows it is a valid source (from the hash/size) but doesn't count it in the scoring process (because the host hasn't rated it yet).
Perhaps the client could keep a record of name, hash, size and rating of previously rated (and deleted/no longer shared) files so that a bigger sample could be taken on each search, helping to outbalance the unfriendly nodes, although this is increasing bandwidth/cpu/storage again.
Slashdot Mirror
Some of the people who believe this is not a form of evolution might find this program helps to explain how it works. Seems like evolution to me. Just because in the article the body was pre-designed, doesn't mean the mind wasn't evolved.
To reduce the bandwidth/cpu of your suggestion, how about each client returns "Yes, I have that file, with a hash of: 34232SFDSFSDSDSD2323DSD and a mod of: Good/Bad/Unrated"
The amount of data returned isn't much more than the eDonkey-type name, size and hash, and the client can display percentages of good, bad and unrated along with number of locations. Incomplete or unchecked copies are marked as 'unrated' so that the client knows it is a valid source (from the hash/size) but doesn't count it in the scoring process (because the host hasn't rated it yet).
Perhaps the client could keep a record of name, hash, size and rating of previously rated (and deleted/no longer shared) files so that a bigger sample could be taken on each search, helping to outbalance the unfriendly nodes, although this is increasing bandwidth/cpu/storage again.