TL;DR
We propose adding a field to the schema metadata which links to an attestation that describes the representation of reputation within a schema. This is a standard way to describe the representation of reputation, without having to require the schemas themselves to adhere to any specific standard, but which will make interpreting the various reputation attestations much easier for developers.
Problem Statement
There are a growing number of reputation protocols gaining increasing adoption across web3. Use cases vary from proof-of-humanity, to trust scores for dapps and smart contracts, to developer profiles, to web3 user profiles derived from on-chain activity and more. As the space matures and continues to grow, there will be an ever increasing variety of reputation protocols, as well as a wide variety of on-chain representations of reputation derived from web3 sources.
This will represent a challenge to the ecosystem in terms of how we understand and consume these reputation scores and profiles. In its current form, end users struggle to understand the idioms of individual reputation scores (e.g. it might not be obvious that a GitCoin passport score > 20 means your human, or a Trusta Labs Sybil score < 60 means your human). Moreover, there is an overhead for developers that wish to consume reputation scores in understanding how individual scores are structured and how to interpret them.
One of the main motivations for establishing an on-chain attestation registry is to provide a consolidated location on-chain for schemas and attestations in order to make them easier to discover and consume and compose. However, providing a consolidated location on-chain does not go far enough in this regard. There is still fragmentation within the various schemas in the registry, which impedes the developers ability to effectively use the attestations that are based on the schemas within their dapps and protocols.
The root of the problem lies in the fact that the specific context of a reputation score isn’t included alongside the reputation score itself. Furthermore, reputation evolves over time, is utilized within different contexts, and each field within a reputation attestation may have its own data sources and requirements. It is therefore unlikely that a standard format for reputation attestations can be established successfully.
We therefore propose a Reputation Object Mode (Alnemr et al. 2010) as a standardized format for describing reputation schema. This will allow attestations that are based on those schemas to be easily interpreted by observers, without requiring those observers to have any prior knowledge or familiarity with the schema or the attestation issuer, and without requiring attestation issuers to adhere to any specific standard.
Proposed Solution
We propose extending the schema metadata to include reference to a Reputation Object Model, which is a specific attestation that is linked to a schema. The linked attestation is based on a standard Reputation Object Model (ROM) schema, and describes the representation of reputation with the reputation schema.
Benefits
Portability of reputation
A ROM allows consumers of reputation attestations to understand how to use the attestation, it allows them to understand what the possible values are and what the recommended threshold is, and therefore how they can actually use the attestation in their dapp / protocol. This information is linked directly with the schema and is instantly accessible.
Allows for easier composability of reputation
A ROM allows for composing attestations together to form a narrative or picture of the attestation holder. For example, we could combine a Nomis Score and an Aspecta Builder Profile with a Clique Twitter Followers attestation. It becomes much easier to understand how to consume the various attestations and to calculate a meta-score based on the combination of values from each attestation.
Allows for visualization of reputation attestations
Currently, users are looking at a list of attestations that does’t convery any meaning. A simple visualization will help to understand what their reputation attestation works, and how they can improve their reputation, and what the advantages are of doing this. Giving developers the means to easily visualize reputation attestations is a powerful and transformative primitive that would greatly improve the user experience.
Improves interpretability of reputation attestations
Makes it easier to interpret reputation attestations, and allows observers to more easily understand how attestations are interpreted differently in different domains. The recommendedThreshold parameter gives explicit guidance to consumers of attestations as to how they can use the attestation, e.g. the recommendedThreshold for GitCoin Passport Score is 20. Other dapps may decide to require a greater score, but at least dapps can have a recommended threshold to work with initially.
Description
A Reputation Object Model model, hereafter referred to as a ROM, is a separate document that is linked to from a schema’s ‘context’ property, and its purpose is to describe the representation of reputation in a structured and standardized manner.
A schema’s ROM is composed of the following properties:
struct DecayFunction {
uint8 base;
uint8 degree;
uint256[] coefficients;
}
struct Criterion {
string possibleValues;
string recommendedThreshold;
DecayFunction decayFunction;
}
struct ReputationObjectModel {
Criterion[]: criteraList;
string collectingAlgorithm;
string computationAlgorithm;
string documentation;
}
An explanation of the properties of the Reputation Object Model is described in the table below:
| Property | Description |
|---|---|
| criteraList | A collection of Criterion objects. Each criterion has a possibleValues property, which can be either a range, enum, or orderedList.e.g. range [0,100], or orderedList [“bad”, “average”, “excellent”], or enum [“developer”, “founder”, “researcher”]Each criterion also has an recommendedThreshold, which is signed integer.For a range, this is the value which determines whether the attestation is deemed valid, e.g. “20” to indicate that the reputation value should be greater than 20, or “-60”, to indicate the reputation value should be lower than 60. For an orderedList, the recommendedThreshold is the value after which the attestation is valid.For an orderedList, the recommendedThreshold is a m-of-n value, e.g. “must have any 3 of the 5 possible values to be regarded as valid”.The decay function describes how each criterion decays, or diminishes in value over time. It is described as a polynomial which allows for the expression non-linear decay function (perhaps the rate of decay accelerates over time), or linear, whereby a polynomial of mx+b can be described as base: 11, degree: 1, coefficients: [3, 2]. |
| collectingAlgorithm | This should be a URI which links to some documentation which outlines where the data upon which the reputation score is calculated is sourced, and how it is collected. |
| computationAlgorithm | This is either a description or a URI (though preferably a URI) which contains information on how the reputation values are calculated. The calculation can be based on any number of reputation algorithms, e.g. collaborative filtering, bayesian models, eigentrust etc. but the information should help developers to understand how reputation scores are calculated. |
| documentation | The value of this property should be a URI, at which is found documentation that helps both users and developers to understand how the reputation attestation can be useful. Crucially this documentation should help users to understand how to improve the value(s) in the reputation attestation. |
Relation to Context Property
The existing context property should ideally be embedded in the Reputation Object Model, however, the context property is hugely important for discoverability, and probably needs its own dedicated property within the schema metadata.
The context property should link to a common ontology, which allows for deriving semantic meaning for a schema. This will dapps to query the registry in terms of “give me all attestations of type “https://schema.org/Person” issued to wallet address 0xab27cf…
A common ontology would allow dapps to run queries like: “give me all attestations issued to this address that represent a human”. Dapps won’t need to know schema ids and which issuers issue attestations that prove humanity, they can just search by context.
It is becoming increasingly clear that we need to create our own ontology, and let it grow organically. This work is already underway with several collaborators and is therefore out of scope of this proposal.
Examples
Below is an example of how Trusta’s Media Score would be represented by a ROM:
{
"criteriaList": [{
"name": "sybilScore",
"possibleValues": "range [0,100]",
"recommendedThreshold": -60,
"decayFunction": {
"base": 10,
"degree" 1,
"coefficients": 30
}
}],
"collectionAlgorithm":"https://trusta-labs.gitbook.io/trustalabs/trustgo/media-indicator-system",
"computationAlgortihm": "https://trusta-labs.gitbook.io/trustalabs/trustgo/media-scoring-methodology",
"documentation": "https://trusta-labs.gitbook.io/trustalabs/"
}
Open Questions
-
Can the above ROM be used to reference reputation attestations that are based on schemas that have complex data structures? The
nameproperty is used to reference a property in the schema, but is this sufficient in order to reference properties within nested objects? -
Should we maintain a one-to-one relationship between schemas and ROMs? Should we allow a schema to have multiple ROMs?
-
Is the decay function useful and will it be used? On one hand it allows for dynamically changing reputation values inside of an attestation. On the other hand, perhaps attestation issuers are only interested in issuing static values to avoid ambiguity or misinterpretation.
-
Should we add a property to the Reputation Object Model called
intendedUse. This may be useful for attestation issuers that wish to qualify their attestation with a stated indeed use, for example, an issuer of a social account attestation may wish to state “I don’t stand over this to the degree that it can be used to prove a person is over 18”. Conversely, a KYC issuer may wish to say “I stand over this attestation and I fully attest to the fact this is a real person”. -
Should the
possibleValuesproperty by split intopossibleValuesType(e.g. “range”, “enum”, “orderedList”) andpossibleValueawhich is simply an array? Would this make it easier to parse?
References
The concept of the Reputation Object Model was first described in this paper:
Enabling Reputation Interoperability through Semantic Technologies
Alnemr, Rehab, Adrian Paschke, and Christoph Meinel. “Enabling reputation interoperability through semantic technologies.” Proceedings of the 6th International Conference on Semantic Systems. 2010.
Reputation Objects for Interoperable Reputation Exchange: Implementation and Design Decisions
Alnemr, Rehab, and Christoph Meinel. “Reputation objects for interoperable reputation exchange: Implementation and design decisions.” 8th International Conference on Collaborative Computing: Networking, Applications and Worksharing (CollaborateCom). IEEE, 2012.
From Reputation Models and Systems to Reputation Ontologies
Alnemr, Rehab, and Christoph Meinel. “From reputation models and systems to reputation ontologies.” Trust Management V: 5th IFIP WG 11.11 International Conference, IFIPTM 2011, Copenhagen, Denmark, June 29–July 1, 2011. Proceedings 5. Springer Berlin Heidelberg, 2011.