Difference between revisions of "Crowdsourced reputation/voting"

From ICMS
Jump to navigation Jump to search
(→‎Local Centralization: conclude that this is the best starting system; remove draft notice)
(extracted stuff that doesn't belong here -- goes in online voting fraud)
Line 7: Line 7:
 
There's a simple way to get each user's score, and a simple exploit for that method. There are a number of more complicated ways that are less vulnerable to that exploit.
 
There's a simple way to get each user's score, and a simple exploit for that method. There are a number of more complicated ways that are less vulnerable to that exploit.
  
==Context==
 
This discussion makes some assumptions about the context in which voting is taking place:
 
* The voting software will be just one of a particular set of tools designed to work together.
 
* The various tools, the web site they run on, and the group of users at that site, constitute a [[social node]].
 
* The key software for running a social node is designed to make it easy for disgruntled users to fly off and open another branch.
 
** software is free/open-source
 
** sufficient user data is exposed to at least invite all users to a new node
 
* By the time these processes have gained enough usershare to have any significant influence, there will be many different social nodes in use (comparable to the number of wikis currently in existence).
 
 
==Methods==
 
==Methods==
 
===Simple Average===
 
===Simple Average===
Line 49: Line 41:
  
 
Another solution might be to penalize users whose ratings (of other users) "buck the system" by legitimizing a user others have explicitly rated low. This suggests the question of under what circumstances one user should "downrate" another, rather than not rating them at all (equivalent to saying "I don't know this person, but I have no reason to think they're fake").
 
Another solution might be to penalize users whose ratings (of other users) "buck the system" by legitimizing a user others have explicitly rated low. This suggests the question of under what circumstances one user should "downrate" another, rather than not rating them at all (equivalent to saying "I don't know this person, but I have no reason to think they're fake").
 
===Local Centralization===
 
A simpler solution that addresses all of the above issues is for each node to have a supreme [[dictator-sysop]] deciding which users are real and which are not, deploying whatever assistance or tools s/he feels are helpful in making that determination -- remembering that there would be many nodes for each user to choose from, and that any user or group of users who become disaffected with the way recognition is handled would be free to fly off and open another branch.
 
 
The obvious exploit here is that a single user could gain recognition at multiple social nodes and thereby have more than their "fair" share of influence, especially if they are a gregarious person known to many people with different interests. While this would be a problem if we want to keep strictly to a rule of "one person, one voteshare", it seems to me that the extra effort involved in getting to know more people and spending more time discussing things means that each extra voteshare of influence would be paid for in terms of participation-time, which is something we want to encourage. This is something to watch, but I do not yet see any mechanisms by which it could actually cause a problem.
 
 
Individual supreme dictator-sysops could also do some cross-checking amongst themselves, using people's real names in private, to minimize -- or at least prevent misuse -- of this technique.
 
 
One thing to note is that this scheme gives a certain amount of (limited) power only to those with sufficient technical skills to set up a node. While any kind of power is subject to possible misuse, the ability to leave the node in cases of mismanagement serves as a sharp check on this power -- and ''practical'' technical competence (as opposed to ''certified'' technical competence) as a pre-requisite for limited power seems refreshingly meritocratic when compared to the current political system.
 
 
This system seems like the best system to use early on, while the software is still in a state of testing and tweaking, since it will require less programming work to produce something usable.
 

Revision as of 13:22, 5 June 2011

About

Crowdsourced reputation is a possible solution to the problem of solves::online voter fraud. There are a number of different ways to do it, but the key features are:

  • Every voter may indicate whether any other voter is known to them personally.
  • Voters who do not have sufficient recognition by other voters are (essentially) prevented from voting.

There's a simple way to get each user's score, and a simple exploit for that method. There are a number of more complicated ways that are less vulnerable to that exploit.

Methods

Simple Average

In this method, each user's recognition score is the average of all other users' ratings of that user.

Math, for those who speak it:

Ex = (SUM(Ax:y) for [all y != x]) / COUNT(y)-1
Where:
  • Ex = overall recognition score for user x
  • Ax:y = user y's (recognition) rating of user x

The obvious problem is that a whole bunch of bots joining the network and giving each other positive recognition will overwhelm the influence of the existing legitimate users. If we allow negative recognition as well, they could even de-legitimize those legitimate users.

Weighted Average

This is where it gets tricky. Instead of taking each user's rating of another user (Ax:y) as being of equal value, we use that user's rating as a value-multiplier. The ratings of users with low recognition will be counted less than users with higher recognition.

Again, some math for those who like that sort of thing (where ratings range from zero to some positive number):

Ex = (SUM(Ax:y * Ey) for [all y != x]) / SUM(Ey)

(I have a strong urge to allow negative ratings, so as to allow users to flag known bots and sockpuppets, but at the moment I have no idea how we would interpret those numbers without accidentally giving actual bots and sockpuppets the ability to "vote backwards". Maybe "bot" and "sockpuppet" should be separate ratings.)

As with any kind of feedback network, the question now is how to handle the recursion. Each answer depends on the answers calculated the previous round. With enough iterations, the values will settle down -- but how many iterations do we need to do each time someone changes their rating of someone else in order to get a stable answer? There are a lot of different ways to do this. We can start by doing a large number of iterations when the network is small, because they each will not take much time, but eventually we will probably have to have the recalculation going continuously.

This method handles the "outvoted by bots" scenario in the Simple Average method with the assumption that the network will first be populated by "good" users, and that new users start with zero ratings and (therefore) no ability to influence anyone else's score. Real users won't recognize the bots, and won't give them any ratings. Problem solved -- as long as the bots don't succeed in convincing a legit user that they are real -- which may be a problem.

In order to minimize the temptation to "be nice" and legitimize users you don't actually know, one solution may be some kind of penalty to one's own reputation if a user you have legitimized is later discovered to be a ringer. This is inelegant, however.

Another solution might be to penalize users whose ratings (of other users) "buck the system" by legitimizing a user others have explicitly rated low. This suggests the question of under what circumstances one user should "downrate" another, rather than not rating them at all (equivalent to saying "I don't know this person, but I have no reason to think they're fake").