Self-signed claims can act as a form of SBT but can also be applied to device ids, email addresses, legal corporate entities, product codes, or any other long-lived addressable entity. A common schema for signed trust claims, containing enough information to identify the issuer and the context of the claim, creates a powerful tool for coordination against bad actors - or against any actor. Misuse can be reduced by anchoring each user’s view of the network by their direct connections, and by gathering broad signals across domains.
A widely used, heterogeneous trust network will be more robust against attack, and will enable important but rare applications.
Use Case Examples
Spam: marking domains/headers/addresses as spammy, and preventing them from arriving
For example: positive trust could be assigned if individual opened email and did not trash it, negative if trashed. Detailed claims can be stored in encrypted decentralized storage and only scores extracted as public claims against "spammy" domains or positive claims for "real" domains. This way just normal behavior can automatically provide positive trust claims for legit domains.
Planned calls only: whitelist any phone number mentioned in an opened email or gcal event
Static whitelist apps exist to prevent incoming calls from unknown numbers, but this also prevents calls from desired contacts or takes work to whitelist each one. A positive trustclaim can be applied to any phone number in an opened email that was not trashed, or in a calendar event. The details would be private to the user but the score on the phone number could be made public (optionally, or by paid lookup only to prevent sharing of good phone numbers; or, shared only to entities with a sufficiently high non-spam score themselves)
Verified Philanthropy: impacted recipients verify that social impact is real for them
In philanthropy large amounts of funds are often spent on administration. Verifying direct impact to the intended target population is important to ensure good use of funds. Combining signed claims with photographic proof such as ProofMode (with metadata from the image) can generate many data points relating to social impact, signed by different recipients. If the recipients ALSO use their id to perform other activities in the graph this will help prevent "cartel" circles of false assertions.
Work Performed: Peer reviewed work, whether on a task tracker or github, is a useful source of reputation
Portable reputation based on units of peer reviewed work allow developers and team members to more easily move between projects. It is also possible to verify login on github, upwork or other platforms and import web2 reputation. This can be issued in an NFT into the developer's wallet but also can be used as an input to other trust score generation.
Server Reliability: It is possible to use the same format for recording data about servers and network nodes
In a decentralized network, the "bad actors" are servers or nodes that are unreliable, or worse, have some corrupted data or have been hacked. Allowing network nodes to automatically issue an claim about a node that fails a reliability or verification check can create an automated network to solve the byzantine generals problem. Essentially it is a decentralized gossip network.
DAO Tooling: Reputation is key in a fluid DAO ecosystem
* The granular signed trust claims act like a kafka event stream essentially - immutable stream of signed claims written to some decentralized storage. If Ceramic is used as the data layer, then the updates will be on libp2p. However the important thing is that the trustclaims are published and can be subscribed to in some manner, or at least spidered and scraped (which if the subject is a URI should be easy to do).
* Trust claims can be linked. The issuer of a claim who signs it can also be the subject of a claim. A claim may also be a relationship, ie that two identifiers have common control or are same_as.
* Models aggregate claims. Alternate models can be generated from the same data pool of linked trust claims, and their predictions can be evaluated.
* Aggregators can protect privacy. In many cases the granular claims should not be exposed publicly. However the trust predictions from aggregated claims may be valuable and acceptable to share. Some nodes will therefore have private trust claim data stores but will produce predictive output from a combination of private and public data.
To achieve decentralized, permissionless architecture it is critical that a shared schema be adopted. After discussions and experimentation in the dSocialCommons.org space the following schema is proposed: https://github.com/blueskyCommunity/OpenTrustClaims
# simplest possible conceptual framework
# that fully matches the use cases
# note that reason and source can be lists
issuer : who says
subject: structured obj, text or did
object: structured obj, text or did
qualifer: string, (optional)
aspect: fixed-vocab-string (optional)
how_known: thing or array of thing
source: thing or array of thing
confidence: float, 0..1 (optional)
reviewRating: (can use existing from schema.org, optional)
rating: float, optional
rating_max: float, optional
rating_min: float, optiona
Token economy: micropayments for predictions and for key/valuable inputs. Free to create assertions but only those subscribed to them will store.
B2B: risk is often outsourced ie to companies such as TechRadar. Generalized risk scores can help small/new companies esp in web3 protect themselves against attackers, spammers and scammers.
Positive advertising: entities identified with positive reputation may be willing to pay for advertising/coupons based on their positive credible reputation scores
## Related Work
### For DAOs
### Decentralized Content Moderation
### Networked Systems
## Risk Mitigations
## Driving Adoption
Live Demo (in progress)
Please contact https://twitter.com/gvelez17 or https://whatscookin.us
Thanks to Harlan Wood and Mark Foster for valuable early feedback and ideas, and to the Bluesky organization for supporting dSocialCommons where these discussions took place.