The Condorcet voting method might be a good basis for developing a voting system for p2p file-sharing programs, one which doesn't disadvantage new files.
Update: just found a program called iRATE which claims to do exactly what I've been propounding here. 13 May 2004 13:05 UTC
Remainder last updated: 12 May 2004, 04:25 UTC
Statement of problem
How to find good stuff (nice music) on a p2p file-sharing network.
Status quo
Currently, file sharing applications largely ignore this problem. They provide a popularity count, but this is problematic: in order to have a high popularity count, a file must be already popular.
A brand new, just-recorded file is available on only one computer (the artist's), and a pure popularity count system will keep it that way.
Currently, the most successful way of gaining a high popularity count is to have a recording company pay for an international advertising campaign; understandably, they're not entirely happy if this advertising ends up promoting p2p downloads rather than sales of shiny CDs.
Proposed solution
I think the solution is to let users to vote on files, in five or seven steps ranging from "excellent" to "terrible" in various categories. That way, the system can distinguish between "never heard it" and "hated it", and only count the latter against a file.
Details
One of the advantages of Condorcet voting is that the voter can rank only some of the candidates, and it doesn't count as a vote for or against the unranked ones. Thus, a user would rank only the files which he or she has seen or heard, without this automatically counting as a vote against those he or she hasn't.
Compared with a simple popularity count, which is what most p2p programs seem to use these days, this would have an advantage for new files (and therefore beginning artists): a popularity count introduces a positive feedback loop, so that popularity breeds more popularity without regard for other considerations. In particular, when a brand new file is added to the network, it's only available from one computer (the artist's), and a pure "number of copies" method will keep it that way.
A Condorcet voting system, on the other hand, would only need a small number of voters claiming that the new file is better than one of the already popular ones (in the absence of votes claiming the opposite).
I'd suggest having just a set of five or seven ranks (excellent, good, average, bad, terrible) that people give to songs. Condorcet can cope with that, it allows candidates to be ranked equal, and it's probably how people think.
For the purposes of P2P, the method would have to be augmented to deal with two problems:
- The lack of a well-defined electorate (and electoral roll). Most likely each person would either recommend others whose rankings they agree with (and to what extent), or publish calculated file rankings based on a combination of others'. Preferably, though, the user should not be required to maintain a list of such people, because it makes for poor out-of-box-experience.
Ideally, you'd want to start the program, select one of the pre-sets and have it start playing good stuff.
One possibility would be to search the network for others with similar votes, and copy off them. With careful tuning, this might be proof against dumb clone voters, because the algorithm can weigh each individual voter by the inverse of the number of similarly similar voters, though it wouldn't be proof against determined attackers.
- The sheer volume of data. Most likely, one would end up doing some sort of incremental approximation, and keep a cache of top n files, updating it as new songs and new votes come in over time.
There can easily be multiple categories, so that the same person can rank the same song as good "rap" but bad "blues" (or vice versa); and have automatic selection based on different categories depending on mood. In fact, there's no need to pre-define the categories, each node can simply define whatever categories it sees fit.
Misc notes
- The first advantage, ranking only some candidates, applies similarly for awards (Ditmars and similar).
- The Condorcet algorithm is available in GPL python at http://www.electionmethods.org/CondorcetEx.html
- A plain implementation of condorcet takes O(candidates^2) time and space; this would need to be improved. Possibilities: (a) People would only be expressing a few preferences; one might expect the number of published rankings per node to be constant-order. (b) Assuming votes change slowly, calculate incrementally, and perhaps crib the initial state off one of the nearby nodes.
- Anomalies from the voting for awards entry:
- Disjoint fan sets are not a problem, partly because we are interested in multiple top items anyway, partly because the system is ongoing and additional votes are assumed to be fothcoming.
- Restricted items are simply excluded; only files available at time of counting are candidates (though there's no need to flush them from calculation caches). Any slight advantage to good new files is a feature.
- This entry was inspired by thoughts on the topic of what if there were no RIAA?
- Another advantage of Condorcet is that all votes are strictly relative: a voter's "good" is just a ranking between that voter's "average" and "excellent"; it doesn't need to have anything to do with another voter's "good". Different people can have different scales. This is probably not all that important in practice, but it's a nice feature to have.
- Votes can be published as a file with a standard filename, which should be compatible with any file-sharing system, or they can be transmitted in some program-specific way (published in circle's hashtable, direct messages / RPC calls).
⇦ RenderMan talk | ⇨ Voting for awards |
