Karma System

This document should not be edited here. The most current version now lives in cvs as doc/guide/Karma.xml

KarmaSystem

There has been a lot of talk about a KarmaSystem for ["BZFlag"]. This page is to collect ideas about it. This document outline some ideas of the upcoming player database and karma system. This is work in progress.

Current Plans

TimRiker is asking for help in creating and moving to a new system with DbServers that implement the KarmaSystem.

The First 3 Sections only give a short description of the basic ideas. Section 4 contains some ideas on how to implement them. This is where you are invited to bring in your ideas.

Links

* http://Advogato.org/ - free software group trust metrics
* http://keyserver.kjsl.com/~jharris/ka/current/ - GPG trust matrix analysis
* http://ggz.sourceforge.net/ - possible platform, not planned at present

Objectives

There are two main objectives:

* prevent misuse of callsigns
* solve cheating issues on the social level

Player Database

The player database keeps entries for registered players. Each entry must at least contain the player's callsign, email address and some data to allow for authentication. This data must be accessible by public bzfs servers so that these can screen joining players. Any changes require private key signed updates.

Karma System

With the karma system, a rating - the so-called karma - is assigned to each registered player in the database. This value should represent the player's reputation within the community, i.e. well-known and nice players should have a high karma value whereas known cheaters will hopefully get a low value.

BZFlag servers can access this information and for example prevent people with too bad karma from joining the server. Players must have some means to rate other players, thus modifying their karma. It is important that the karma system is balanced and robust against abuse.

Implementation

player database / authentication

* The player database should probably be located in the list server bzfls, because this is a central service already.

* Authentication can be done by using a simple public key scheme. A player must be able to create an identity, i.e. a unique callsign and a keypair. The local and public key will be stored in the client config locally. The public key will be uploaded to the player database when registering. When a player needs to prove his identity, his client will sign a challenge with his private key. The party doing the authentication challenge can then verify this by using the player's public key from the database.

* Should a client be able to manage several identities from which a player can choose?

* It could be possible to play without registering as a guest on open servers. This might just be a transparent temporary registration if that is easier to deal with.

* Security issues: Should the private key be encrypted with a passphrase? Should the list server and each BZFlag server also have to authenticate themselves? I guess we do not have too high security standards here, so for example we do not need to encrypt all communication to prevent session hijacking and other attacks.

* Is it a good idea to allow a registered player to authenticate himself and still play with a different callsign if he wants to play anonymously? E.g., let's say a well-reputed player registered as 'GrimReaper', authenticates himself when joining a server who requires a high karma value, but is visible to the other players as 'Bozo'. - they still would not be allowed to use another registered nickname as their callsign.

* The data that is stored for each player in the database could include:
 * callsign (required)
 * public key (required)
 * email address (required)
 * full name
 * statistics: time of registration (age), last time of play, total playing time, time spent on different servers, with different settings etc.
 * karma data

Which of these should be mandatory?

* In addition to the stats data mentioned above we could also try to implement an automatic rating of the player's strength, similar to the Elo rating for chess players, maybe differentiating for different styles, server settings.

Registration process

Registration should be easy and can either be done with the BZFlag client or an extra executable for managing identities. The client will connect to the list server and send the data for the new player. The list server will acknowledge this if there is no callsign clash.

For changing the player data (like email address) later on, the client first needs to successfully authenticate itself by using the usual challenge/response procedure.

karma system

* A new player starts with a neutral karma value, I guess 0 is a natural starting point :-). Karma might be an integer of a floating point value.

* Each BZFlag server can be configured to require a minimum karma value for each player. When a player does not meet this criterion, he will be rejected. Hopefully, this reduced cheating on these 'high quality' servers. Of course there should also be some servers which are open to everyone, otherwise new players could never play and increase their karma. Server admins should balance reasons for specifying a low karma threshold, and thus allowing everyone to play on their server or requiring very high karma and possible improve the quality of people playing, but at the cost of ruling out many players and possibly having a very empty server.

* the server could also be configured with a minimum admin karma. Players that meet the criteria would be able to change server options, kick players etc. We may want multiple levels of admin access.

* There must be a convenient way for a player to rate another player. I guess it's best to be able to do this in-game. Should rating just be done by using +/- resp. up/down? Or by giving a value from -5 to 5? For this to be easy, the player to be rated must be selected in some way. How? A player should be able to see the rank he has given other players easily. Perhaps even on the scoreboard.

* When doing ratings in-game, either the client or the server must send messages to the list server. It's probably best if the client sends a signed update to the server and the server forwards it (with game updates as well) to the list server and then updates the rated player info if the list server verifies the signed update packet. The signature is required so that the list server can verify the source of the ranking. Servers might otherwise fake ratings.

* Should karma value and/or individual ratings be publicly visible / visible to the player himself? Tim thinks so. Players should be able to see who has ranked them, but not what rank they have been given. They should be able to see all the players they have ranked at what rank they have given them. They should also be able to see any player's rank including their own.

* The karma value of a player must be calculated as a function of all individual ratings from other players. This must be done in a 'fair' way that is robust against misuse. A possible misuse would be a player A registering a lot of identities and giving a low rating to player B with all of his identities. So, ratings must be weighted by karma and player age. This must be designed very carefully, so I suggest stealing this from somewhere. It will be necessary to store the resulting karma value for each player as well as every rating given.

* Do we want or need some privileged players whose ratings have more weight? This might be needed to get the system started.

Basic rules for karma adjustment

* A user can only have one karma value per other player. This can be changed at any point
* Impact is determined by these factors:
 * Current rating
 * Assignment tendency (neutral = more impact, all good or all bad = less impact) [keep in mind that some users will ONLY rate players whom they like]
 * Player age - long-time players will have more influence
 * Playing time - people who spend their lives in BZFlag should have more power

Possible implementation

This is proton's idea:

Store the entire karma network as a weighted directed graph. Weights along the edges should go from -5 to 5 or some other range specifying the karma adjustment from one player to another. Each node would also have a weight, calculated from the other factors listed above (age, time, etc). When a karma adjustment is made, a walk of the graph is done, computing everbody's new karma (if someone near the root gets modded up, it could have repercussions through the entire tree, strengthening the adjustments they themselves have made). Nodes furthest from the root (note: the 'root' would be someone completely trusted, like TimRiker) have the lowest karma.

With this scheme, bad accounts could be deleted by the same type of algorithm as used for Advogato's trust metric, setting up a supersink and cutting away all bad nodes, thus preventing abuse.

Other database items

The KarmaSystem would use a central server (or servers) to store the data. TimRiker imagines that this system would include other useful bits like player ladder ranks, league membership, league ranks, map ranks, etc. It may contain gpg signatures, ssh public keys, or perhaps the karma server is a certificate authority for ssl keys and server keys and player keys are authenticated there. The player keys could actually be presented to the users's browser and use that information to log in to the karma website.

Karma Web Site

The website would show overall ranks for players on the trust scale and probably also ladder ranks, live servers, server stats, player stats, etc. A player would need to authenticate to edit settings. This page would show everyone this player has ranked and the rank they currently have. These would be highlighted to show if those players have ranked this player too. There would be a separate list of people that have ranked this player colored to show if this player has also ranked them. The actual ranks are not shown to encourage fair ranking.

Well, probably a whole bunch of stuff is still missing. Feel free to add anything.

TimRiker email

I would expect that we would run a separate process on a daily basis to update karma values through the system. We might want to run this more frequently, perhaps hourly. This will depend on the time it takes to do the update.

So we will have a user table with callsign, password, email, realname, karma, etc and the existing server table.

We need to indicate group membership. I expect we will have a table of groups with an admin listed. Then a table of group memberships to handle the many to many relationship between users and groups.

When the server asks bzfls to verify the cookie, that removes the cookie. They are one time usage.

When the server asks bzfls to verify the cookie it also lists the groups for which membership information is desired. This is to avoid sending tons of group membership information that the server does not offer any special permissions for anyway.

We will want a set of php pages that do administration. I'll put them up under SSL to protect passwords. Folks can login with email, password or callsign password. I'm tending towards email/password but I don't have a strong opinion.

* email entries need to be unique
* callsign entries need to be unique
* group names need to be unique