[MUD-Dev] Player run reputation system

[J C Lawrence]

On Mon, 25 Jun 2001 13:13:37 -0400 
John Hopson <jhopson at nc.rr.com> wrote:

> In the Advogato system, trust is a fluid, trickling down from one
> node (user) to another.  A small number of individuals, known
> formally as "Seeds" or jocularly as "Sun Gods", are inherently
> trusted at the highest level.  All users (including the seed
> users) rate each other, and these ratings are used to calculate a
> network (see figure 1) of nodes radiating outwards from the Seed.
> The Seed users are then given the most trust, those they've rated
> highly next, and so on out to the farthest node, a long way out
> from the seed.  Trust is a measure of how much you are respected
> by those who the seeds respect, with that respect being passed
> along, diminishing as it goes.

<nod>

> All trust flows outwards from the Seeds and new nodes/users start
> with no trust, two factors which combine to make the system
> resistant to invasion by twinks.  Consider the case where a group
> of new users colonize the game and begin rating each other very
> highly.  (Figure 4, under the heading "Security Proof") Because
> they start with nothing and those who have trust are presumed to
> have the judgement not to trust the twinks, their ratings are
> meaningless.  They can rate each other however they like, but
> until the system lets them in, until trusted users rate them
> positively, they have no effect.  The important feature here is
> that it doesn't matter how many of the twinks there are, their
> ratings can only gain meaning to the degree that they are
> respected by the community at large.

Almost.

The new crowd of user's ratings only gain meaning if and only if at
least one of the crowd gets rated positively by an already rated
member of the extant community.  

My attempt to reduce Advogato's trust metrics down to basics:

    You have no status until someone with status tells you you do.

    The status you get from them is proportional to both their
    status and how they rate you.

    Their status is proportional to how far they are away from God
    (a root node) both in vote chains (A voted for B who voted for C
    etc), and in the status they're awarded (he is an idiot, he is
    Okay, he's good, he's great, he's a God).

> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

> I think the Advogato system, which very impressive and apparently
> effective for what they're doing, is not suitable for muds as is.

It implicitly tends to build cliques, has no deflationary factors as
the rewards are for voting up, not voting down, and there is nothing
except down votes to prevent meaningless inflation.  Some of the
Advogato pages I linked to specifically complain of this fact.  In
Advogato's case they are relying on close social and reputational
ties to encourage deflation (masters value their status and are so
discriminating about spreading the wealth lest it devalue their
status by reflection).

> As I understand it, the code involves having all nodes in a list
> in real time, arranging them in a space, then assigning trust.

Actually he computes the table once on each update and then stores
it for later access.

> This works fine for the 400 something users Advogato has, but I
> suspect it would choke on the thousands or tens of thousands
> required for a MMPOG.

<<Gads that term is annoying>>

My impression is that three passes over the graph should get a good
enough approximation of steady state (back of the napkin work).  If
so, in all but corner cases that the compute load isn't too too bad
even for a player base numbered in the small tens of thousands.  Its
certainly not cheap, but given that the voting/rating rate is
unlikely to ever saturate (and can be controlled by mechanical
means) I don't see much problem here.

Its a back-end compute problem, isn't very time or latency
sensitive, and submits nicely to ad-hoc whacks of small chunks of
the node space on an as-accessed basis.

> My concern is that we're not actually talking about "Player run
> reputation systems" in this thread...

Yup, we're talking about mechanical systems that players can use to
maintain a player rating system on some metric they collectively
define (or not).

> We're talking about systems where the code uses player-ratings to
> come up with a reputation score that meets the same criteria as
> the rest of the code (not obviously abusable, objective,
> impartial, etc).  

If you drop the objective and impartial bits I'd agree.  I don't see
the worth (or use) in building systems that expect players to be
impartial, or which attempt to interpret and predict their biases
such that the system behaves as if they were impartial.  Not worth
it.  Also boring.  It comes down to attempting to determine intent;
possibly the slipperiest design slope there.

> I believe this is a wrong turn.  We really don't want to be in the
> position of flagging a player as trustworthy or untrustworthy...

Yup.  The trick is the gear the presentation so that we don't do
that and aren't (generally) thought to do that either.  Part of the
deal there is that a negative stat (degree of distrust) will
implicitly create perception problems with the players. 

> ...because if we're wrong, the players are pissed at us.  

Yup.

> What we want is for players to be able to see what other players
> think of someone.  We want players to be completely responsible
> for the system, and for that system to reflect what the players
> think is important about each other.

Under the Advogato system a key aspect is that the votes are exposed
such that a member can see how he got his rating, why, and via what
votes from whom.  I see little reason this same data couldn't be
exposed in a MUD.  Doing so would help take the admins out of the
blame loop.

The question of "what they think" assumes interpretation of intent,
something I we'd be wise to stay away from.  IF and as we supply
mechanisms, no matter what definitions and models we provide for
them, the players will derive their own definitions and their models
for them, and will then apply them accordingly.  The fact that we
called if XXX and meant it to measure XXX really has nothing to do
with it.  Players are both quite willing and capable of calling it
XXX and using it to measure cup sizes on female player characters
should that be their interest.

> As of now, I think the best solution is to have multiple rating
> systems and let the players choose which rating system they want
> to see.  Let's say I run a good-aligned group, the Knights of
> Niceness.  I submit a rating system to the game (-1 to 1, naughty,
> neutral, nice) and set it so my fellow Knights are all allowed to
> rate people on this system.  Anyone can set their preferences so
> they see on other players the ratings we give them.  If they don't
> like our system, they're free to complain to Knights or use
> another system.  Our name becomes a brand, letting people know
> what they get when they use our rating system.

Which is essentially equivalent to using the Advogato system except
that you allow each group to define their own stat group with their
own private-to-their-stat-group root nodes.

Its a named population thing.

> Another group might let anyone rate, or it might be just "Bob's
> ratings".  It would also be possible to put a couple coded
> systems, such as number of coded crimes committed, etc.  Players
> could even use multiple systems and see a composite rating.

> The nice thing about this is it takes all the burden off the game
> and its administrators.  Don't like the rating system?  Create and
> promote your own.  Wish there were a system rating OOC roleplaying
> ability player rather than IC criminality?  Go for it.  The system
> becomes whatever the players want/need it to be.

Doncha love soft code systems?

--
J C Lawrence                                             claw at kanga.nu
---------(*)                                http://www.kanga.nu/~claw/
I never claimed to be human.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev