---
tags: RIPs
author: [Bau]
co-author: [benedictvs]
date: 2022-09-21
category: RIP
layout: Post
---

# RIP: RaidGuild Skill Forest - Building Reputation w/ Verifiable Credentials

##### Resources:

###### Skills Forest
https://hackmd.io/ZpBBQsOKQCaQhTDHqFBsLA?view

###### Skills Bot / Quartermaster
https://hackmd.io/Fs_mnbS3R1qt3MXCyHwwew?view

https://github.com/MetaFam/skill-bot

###### Additional Resources

https://daostar.one/attestations

https://www.deepskills.io/

###### Note before we get started:
*An important aspect of Verifiable Credentials is selective disclosure over who and what applications can consume your credential data. That is to say, we want to make sure that users who are issued Verifiable Credentials have the ability to keep their credentials private or selectively disclose access to only those they trust and or, are willing to share their credentials with. Collab.Land is actively working to make sure that **only you** have the ability to provision access to other users or applications who wish to see your credential, a feature that will be available very soon.*

# Project Idea

Grant RaidGuild members the ability to make and accumulate skill based attestations using verifiable credentials, allowing members to gain reputation for work completed on Raids & RIPs.

### Project Submitted By
- Alec, Bau, & Ben

## Summary

RaidGuild Members can register their skills using a bot called Quartemaster inside of the RaidGuild discord server. These skills do not map to Discord Roles, but rather map to member Discord IDs. The mapping is stored inside of the QM bot DB.

For more on **Quartermaster**, check out the docs [here](https://hackmd.io/Fs_mnbS3R1qt3MXCyHwwew?view).

RaidGuild members want to experiment with issuing reputation based [Verifiable Credentials](https://www.w3.org/TR/2022/REC-vc-data-model-20220303/) to apprentices and members who wield certain skillsets using the Collab.Land bot.

By enabling members to easily make attestations to other members' skills and abilities, RaidGuild members will have the power to distribute and accumulate skill based reputation based on contributions within the guild.

In addition, RaidGuild members may distribute reputation VCreds to non-members or apprentices, which could boost signal and support the championing process for non-members who accumulate skill based VCreds to become full members!

Beyond member shares, RaidGuild members need a way of distributing VCreds. The power to issue VCreds within RaidGuild will be gated **only** to members who hold **role-based** VCreds that will be issued top-down to kick start this experiment in reputation based credentials.

## Why should we build this?

RaidGuild has an opportunity to experiment with the latest tooling available for issuing and tracking off-chain reputation.

For more than 18 months, RaidGuild has been searching for better methods of distributing reputation and tracking contributor acitivity across the guild, this implementation may give us a path to acheiving those objectives.

#### Problem

RaidGuild members do not have a way of distributing high-fidelity skill based reputation to members or non-members across the guild based on work done on Raids or RIPs.

#### Solution

Equip RaidGuild members (admins to start) with the Collab.Land bot to generate attestations and issue high-fidelity skill based reputation to members or non-members across the guild based on work done across Raids or RIPs.

#### Implementation
RaidGuild can register a command with the CL bot, such as **`/attest` `handle` `role` `level` `skill`**. The CL bot will communicate with a database (possibly QM) to fetch members' skills and present them in a sorted list of options that can be chosen from by RaidGuild members to issue VCreds as attestations to other members or non-members having those skills.

In addition to issuance, RaidGuild members may want to view their own or another member or non-members VCreds. Registering another command with the CL bot, `/lookup`, RaidGuild members will be able to *look-up* VCreds that have been issued in the RaidGuild server.


##### Schemata

Schemata provides meaning to a reputation system that follows a standardised approach to ensure interoperability. Thus, a semantic layer is built on top of the syntax provided by W3C compliant verifiable credentials (VCs) to express skills and reputation for RaidGuild members and its stakeholders. By defining the meaning of the issuance of certain VCs, limiting access to the issuance functionality of such, and limiting the composability of VCs with dedicated purposes, the implementation minimises the risk of a 'popularity contest'.

When meaning and structure of the VCs are defined, close attention can be paid to the context of creating, awarding, or earning reputation. I.e. the bot will enable rich pragmatics for the issuance allowing for transposability of skills. These layers of definition maximise certainty for interactions within RaidGuild and ensure skill-signalling beyond its Discord server because it allows its members and affiliates to become **proven experts**.

###### W3C Verifiable Credential format

An example of a JSON formatted credential, which is envisioned to be used in the proposed implementation exhibits the properties of context, subject, and proof as follows:

{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://raidguild.org/schema/credentials/raider/36",

"type": ["VerifiableCredential", "ContributorCredential"],

"issuer": "did:colX:X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G",

"issuanceDate":"2022-09-23T15:07:27.677Z",

"validityInDays":365,

"isRevocable":false,

"credentialRenderType":"membershipPass",

"name": "ContributorCredential",

"credentialSubject": {

"id": "did:colX:SUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiY",

"JobDescription":{

"name": "Job description",
"mime_type": "text/plain",
"value": "Smart Contract Engineer",
"lang": "en"
},

"OrganisationRole":{
"name": "Organisation role",
"mime_type": "text/plain",
"value": "Wizard",
"lang": "en"
},

"OrganisationType":{
"name": "Organisation Type",
"mime_type": "text/plain",
"value": "DAO",
"lang": "en"
},

"organisationName":{
"name": "Organisation name",
"mime_type": "text/plain",
"value": "RaidGuild",
"lang": "en"
},

"RankType":{
"name": "Rank",
"mime_type": "text/plain",
"value": "Member",
"lang": "en"
},

"memberLevel":{
"name": "Level",
"mime_type": "number",
"value": "5"
},

"coreSkill":{
"name": "Core skill",
"mime_type": "text/plain",
"value": "Solidity",
"lang": "en"
},

"additionalSkill":{
"name": "Additional skill",
"mime_type": "text/plain",
"value": "Rust",
"lang": "en"
},

"minorSkill":{
"name": "Minor skill",
"mime_type": "text/plain",
"value": "Typescript",
"lang": "en"
},

"membershipDate":{
"label": "Joined",
"mime_type": "date",
"value": "2020-01-01T00:00:01.000Z"
}
},

"proof": { "type": "credentialOfferRequest",

"createdAt": "2022-09-23T15:07:27.677Z",

"proofPurpose": "issuance",

"issuer": "did:colX:X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G"
}
}

###### Credential Types and Schemata

Schemata and credential types can be congruent, but are notionally different. Hence, two credential types may use the same schema, whereas two schemas shall not be of the same credential type. For example, VISA and Mastercard may use the same schema *CreditCard* while define different credential types, such as *VISACard* or *MastercardCard*.

This can create compatibility issues, as seen when trying to use a swipe card on a chip device. Nevertheless, different organisation may choose to convey additional meaning, which cannot or should not be expressed through semantics. Then credential types allow for decoupling use cases from rigid interoperability constraints.

For the creation of schemata, it is important to define a discrete set of claims of which one credential schema shall consist of. This creates certainty around what a given credential can attest to and which reputation it cannot wield.

In order to create schemata with discrete sets of claims, a set of schemata must first be created. Since this RIP sets out to specifically develop tooling for RaidGuild, which wields the power to be transferred to other Web3 organisations, credential types are a good starting point to asymptotically move towards interoperability, while protecting the scope of this specific project. A preliminary draft of these **credential types** that will lead us to defining schemas interoperably at a later stage, is displayed below.


After a desired set of credentials is defined, work can progress to map out existing skills within RaidGuild and subject it to a hierarchy, such as provided by schema.org. When RaidGuild as organisation, organisation roles of individuals, job descriptions of these, and their skills are organised, use cases are associated with claim clusters. The clustering process can be revisited on the [Miro board](https://miro.com/app/board/uXjVPREL-WI=/?share_link_id=963779264934).

More generally, however, all credentials should include the following metadata:
1. Output of bot commands
2. A reference to the encapsulated meaning.
3. Context definitions, i.e. pragmatic meaning
1. Discord server in which the VC was issued to attest to the holder or grant this persona a right.
2. The channel, which invoked the issuance
3. Information of the issuer, or a reference to the issuer DID, where this information can be retrieved from the DID document.
4. The time of issuance, validity of the offer, and expiration (true/false). If *true*, an expiration date must be given in an acceptable format.

#### Post Open Questions / Feedback / Modifications Below 👇

###### Questions:

1. Is collab.land 3rd party integration ready for us to use? I can't find docs on it and it feels like we might be a guinea pig on this, which doesn't feel like a good RIP.

2. Is Quartermaster ready to be relied upon for integration? It is cool, but I don't know that it has elevated to a product to rely upon rather than a clean proof-of-concept.

3. How is this related to the Collab.land zodiac raid and how do we keep the separation clean?

###### Feedback:

1. Being in on the initial skill forest discussions, a big point was that attestations occur in the context of a raid. This was so that it was specific work that was being judged and not just general feel for a raider (which would lead to corruption based on relationships). I think it is fine departing from that vision, but I'd like it to be acknowledged that this departure is taking place and why the trade-off is worth it to move the ball forward. It would also be useful to lay out more clearly how the reputation system will be employed within RaidGuild, in it's current form the problem and solution do not explain why this is something RaidGuild would benefit from.

###### Modifications:

1. We may want to consider creating "graduated thresholds" where if a Raider holds a specific number of Verifiable Credentials (gains enough XP), they can go and claim a ntNFT that represents the VCreds that they have earned. For example, "Raider Level-Up" - this could gamify the experience of earning VCreds & leveling up within RaidGuild, where there is a natural progression for members to move up the chain from:

- novice
- mediocre
- advanced
- expert

See [League of Legends](https://leagueoflegends.fandom.com/wiki/Experience_(summoner)) for a more advanced leveling system.

## Anything else you'd like to add?

Not at this time.

## Raid Party Skills Needed
- 1x Monk (PM)
- 1x Ranger (UX/User Testing)
- 1x Healer (Internal Ops)
- 1x Paladin (Backend Dev)

## Cost (in USD)

\$5000

#### Timeline
- Early October 2022: Approve RIP (PSA - Plan, Study, Act)
- Mid October ~ Early November 2022: Execute
- November 2022: Experiment & test, identify & squash bugs, iterate, refine
- December 2022: Review, fix bugs, package up as standardized tool that other communities / service DAOs can leverage. (RRR - Reflect, Review, Refine)

## Deliverables Overview (Fill in following preliminary review & feedback)
1. Creation of up to six credential types, which follow one schema respectively, for skill credentials to give differentiated insight to the reputation a raider holds.
- preliminary work has been undertaken on this [Miro board](https://miro.com/app/board/uXjVPREL-WI=/?share_link_id=963779264934)
- schemata are developed in adherance to the syntax of the [W3C verifiable credential (VC) format](https://www.w3.org/TR/vc-data-model/)
2. Bot commands to fill the schemata with values for issuance
- a graphical user interface (GUI) is built for the data input
- a minimally viable set of bot commands is defined as follows and implemented in the attestation bot
- /attest
- /create (for self-attested skills)
- /issue
- /champion
- /publish to [discord/users/thread/channel/server]
- /hide
- /accept credential
- /reject credential
- /proof [raid/RIP] attendance
- /show [my/user#] skills
3. A database for storing skill credentials and associating them with users is built and integrated with pre-systems of collab.land.
4. Testing phase TBD
5. Research for integrating a rudimentary implementation of [did:key](https://w3c-ccg.github.io/did-method-key/), [did:3](https://github.com/ceramicnetwork/CIP/blob/main/CIPs/CIP-79/CIP-79.md), or [did:ethr](https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md) for signing VCs is undertaken and a report written.
- The report shall evaluate the feasibility for collab.land and RaidGuild regarding
- method of authentication, i.e. *token gating*
- identification, i.e. compilation of raider lists for *RIPs* and *Raids*
- The report a cost and benefit analysis of individual did:method implementations includes
- A summary with concrete actionable items must be provided.

[See Roles ](https://handbook.raidguild.org/docs/overview-roles) 👇