Improving reputation

[kronosapiens]

After a year and change of usage, it seems like reputation as currently envisioned is too restrictive. A number of suggestions have been made about how to make reputation more flexible. After a call with Jack, Raul, and Arren, here is the proposal to move forward:

• [ ] Introduce the ability to set a "reputation rate" for any token, not just the native token, e.g. payments in DAI could give reputation at a rate of 2:1, while payments in CLNY would give reputation at a rate of 1:1. The default setting would be native token at 1:1, and all other tokens at 1:0.

• [ ] Introduce a per-domain scalar which scales the reputation earned in that domain. If a domain scalar is not set, the domain inherits the scalar from the parent.

• [ ] In extraordinary circumstances, a colony should be able to edit the reputation earned by a payment to an arbitrary amount. It may be possible to implement this using the payoutScalar, or may require creating an additional motion.

• [ ] Remove ability to give bonus reputation using the expenditure's payoutScalar

• [ ] Allow variable decay rate for colonies

[area]

Introduce the ability to set a "reputation rate" for any token, not just the native token, e.g. payments in DAI could give reputation at a rate of 2:1, while payments in CLNY would give reputation at a rate of 1:1. The default setting would be native token at 1:1, and all other tokens at 1:0.

We discussed this ourselves originally, and this still seems fine to me.

Introduce a per-domain scalar which scales the reputation earned in that domain. If a domain scalar is not set, the domain inherits the scalar from the parent.

As described, at a glance, I'm not convince this can work, but if more thought has gone in to it than this statement, then I could well be proved wrong. Concerns I have that I would want to see addressed:

• When a user earns reputation in a domain, how is reputation earned in parent domains scaled? If I have permissions to create a domain, I could set the scaling in that subdomain to be very high, and, under a naive implementation, gain control of the root domain.
• Similarly, when a user is punished, how is the punishment scaled in child domains?
• Does this change the current truth that is held that my reputation in a domain is (EDIT: always greater than) the sum of my reputations in its child domains? If so, how does this work with escalating motions, and do we use that assumption elsewhere?
• How do all of these changes interact with reputation mining and resolving a dispute?
• When the scalars are changed, do all of the answers to the above questions still work?

In extraordinary circumstances, a colony should be able to edit the reputation earned by a payment to an arbitrary amount. It may be possible to implement this using the payoutScalar, or may require creating an additional motion.

What is the 'extraordinary circumstance' where the current ability to arbitrarily award or take reputation away from a user is inadequate, but this is sufficient?

[arrenv]

• When a user earns reputation in a domain, how is reputation earned in parent domains scaled? If I have permissions to create a domain, I could set the scaling in that subdomain to be very high, and, under a naive implementation, gain control of the root domain.

This could be addressed by using a scalar with a max of 100% of the parent domain.

• Does this change the current truth that is held that (within rounding errors), my reputation in a domain is the sum of my reputations in its child domains? If so, how does this work with escalating motions, and do we use that assumption elsewhere?

It wouldn't change this truth. Reputation would still be summed in the same way, it would just be earned at a fraction of a 1:1 as in root or a parent domain.

• When the scalars are changed, do all of the answers to the above questions still work?

If scalars are changed, it would not change previously earned reputation, only reputation earned in future.

Update: Scalars changes will need to be changed on the 2nd reputation mining cycle after making the change, to prevent changes to reputation changes that have already been made but not mined.

What is the 'extraordinary circumstance' where the current ability to arbitrarily award or take reputation away from a user is inadequate, but this is sufficient?

Examples of 'extraordinary circumstances' could be distributing tokens to investors, making payments to service providers e.g. hosting, transferring funds to external contracts for treasury management purposes.

As discussed, and mentioned by Krono, we could use payoutScalar, or create an additional motion with Smite or Award (requires creating a Motion in Root). With leveraging payoutScalar we could only allow the custom reputation option to be possible with an Advanced Payment (i.e. Expenditure).

Additional feature

Make it possible to have a variable decay rate for individual colonies, or individual addresses in a Colony. E.g. You could set it to be a faster decay, a slower decay, or pausing altogether. Decay rate changes will need to be changed on the 2nd reputation mining cycle after making the change.