SourceCred Trust Levels

Durable record of my comments from the Office hours per @decentralion request.

This also crosslinks with sourcecred governance

Item 1: We should view the source cred community as going through a three phase process

  • Level 1: Non-Adversarial, everyone engaged in the dogfooding process is genuinely invested in figuring out how best to design and use a “reputation protocol for open collaboration”. At this stage we can be less concerned about closing off attack vectors than the space of possibilities. The risks associated with exposing an attack vector are nominal and in fact if we respond effectively, we are actually stronger for having found them. [antifragility]

  • Level 2: Exploits are real, at this stage contributors who are in it for compensation begin to contribute on a regular basis and the pots of money are large enough that someone identifying an exploit could profit enough to make it worth hunting down an exploit. However, the system is still relatively young and the sums of money are controlled release enough that while this may be harmful to the community. If the maintainers identify the exploit quickly the damage will be limited and we can reasonably expect to change parameters or otherwise mitigate the risk of future exploit by the same means.

  • Level 3: large scale community, at this point a large number of contributors are aware of the algorithms, happy getting paid largely automatically based on the metrics and will be very unhappy if tweaks impact their payouts in any considerable way. While payouts are automated the level of steering in the hands of the maintainers is enough to drive the system towards KPIs be assigning the source nodes of cred based on goals or values. The idea is that the steering or nudging associated with points and rates cred is issued is enough to guide the community without being dictatorial. In this case, exposure of attacks could do serious damage so it is best if the two previous phases were successful in flushing out any major vulnerabilities.

Item 2: Who are the maintainers? I proposed that we analogies maintainers to ‘validators’ and as we advance our thinking around governance we imagine how many maintainers a project can or should have, we can use concepts like nominated or delegated proof of stake to establish representative democracy in a tokenized way but we would need governance rules that determined what is a slashable fault (flag and punish undesirable validator behavior) and how the such a fault would demonstrated and accepted. This is by no means a complete thought but it is intended as an entry point regarding future discussions around tokens. No rush, just laying some groundwork and hoping to establish some shared language.

Item 3: Concrete proposal for the first financial dogfooding: I suggested that since we are in level 1 (see item 1), that we do a collaborative review of parameters BEFORE we allocate funds. Since we are in Non-adversarial phase, i think it would be really powerful way to explore our own thoughts and feelings. The the final decisions would still fall on @decentralion but it would provide a lot more knowledge about how users might react to the different choices if we give ourselves the opportunity to have that discussion as a group. It might also increase the likelihood that we identify attack vectors. It won’t be long before start to evolve into level 2 if there is money available on an ongoing basis, so let’s learn more while we can.

Thanks, -Z

4 Likes

@mzargham, thanks for the thoughtful post.

This framing makes a lot of sense. We should enjoy being in Level 1 (high trust / non adversarial) while it lasts!

I’ve been thinking more about this topic. Starting with the concept of "maintainers’ who act as “guardians of the cred” with a lot of influence over it makes sense, because insofar as we trust the maintainers, we can implement viable solutions very quickly. However, as rapidly as is feasible, I’d prefer to shift such judgements out of the hand of a specially-privileged class, and into a general cred-based consensus mechanism. I expect my share of SC’s cred to drop over time, and as that happens, my degree of control over the cred should drop proportionally. In other words, we need a way for the “benevolent dictatorship” to transition into a “cred-representative democracy”. Benevolent dictatorship can work for a little while, but it has a notorious succession problem. :slight_smile:

Do you suggest a one-off review of the parameters before any allocation happens, or that for each allocation, we do a public review? I’m inclined to do the latter: for each allocation, I post a link to the instance which has the scores, and we discuss the contributions, the parameters, and the weights together. At the end of the discussion, we finalize the allocation for that period. We may or may disburse funds for every allocation (e.g. if we do an allocation every week, we can disburse funds every month, to save on overhead).

I’m inclined to do an allocation every week, as it increases the amount and specificity of feedback/insight we get into the algorithm.

1 Like