divine-comedian commented 2 months ago

A system of vouching for an RPGF applicant’s trustworthiness using attestations.

This will allow anyone to use a given schema to attest that they back this project - meaning that, it is legitimate, and can be trusted to fulfill on its promises or has fulfilled its promises.

Using a subgraph and graphQL API we will be able to get a list of RPGF applicants and show them on a webpage along with information related to how many people have vouched for this project

Anyone can use the schema to attest for a given project but by default we are able to filter by if an attester themselves have received a certain attestation.

For example, we can filter if the person who is attesting for project x if they have received an attestation stating they are an Optimism badgeholder.

We are also able to see the addresses of who vouched for the project, this creates trust and accountability on the part of the vouchers

On top of this we can allow users to filter from other schemas, checking the projects that have been vouched for by recipients of a certain attestation.

Alternatively projects can flag a project for untrustworthiness or if the project is an imposter or not legitimate.

User Stories

Personas

Badgie Boris - Is an Optimism Badgheholder, he wants to be quickly look over projects and know which ones he can trust with his vote. He also wants to signal what the thinks of other projects between other badgies. Usually not a lot of time to dedicate but very knowledgeable of the ecosystem.
Data Debbie - Dedicated to gathering data on all RPGF applicants, performing analysis and sharing insights with badgeholders. Data Debbie could be a fellow badgeholder or owns a platform like growthepie
Dapp Dave - Dapp Dave is a donation/grants platform, they have many projects listed on their website and care about providing quality projects to their donors, they have a limited team and budget.
Impact Irene - Represents another group of individuals known for doing impact analytics on projects in the ecosystem. They are independent of any web3 protocols or donation platforms and have a rigorous process of analyzing projects and specifically look at how they make global impact.
Project Patricia - Manages a public goods project that is listed on many different places! She cares about getting positive exposure for her project in as many places as possible. She needs to receive funding to continue operating her project.

Stories

As Badgie Boris - I want to know of the projects that have applied for RPGF, which ones have my fellow badgeholders vouched, how many and who has vouched for a given project.
As Badgie Boris - I want to know which projects I should watch out for, projects that my fellow badgeholder’s think have a bad reputation or are suspicious.
As Badgie Boris - I want to easily signal what I think about a given RPGF applicant, either by vouching for it or flagging it as suspicious.
As Badgie Boris - If I change my mind or new information surfaces about an applicant I should be able to revoke an attestation I previously made.
As Badgie Boris - I want a way to see all the projects/grants I’ve vouched for in an easy way
As Data Debbie - I want to be able to programmatically fetch vouching and flagging done by certain attestation groups.
As Data Debbie - I want to have easy ways to sort & filter projects listed that have been vouched for.
As Impact Irene, I want my team to be able to vouch for or flag projects and be able attach our analytics rubric/data to back up our attestation.
As Dapp Dave - I want a way to allow my platform to integrate decentralized vouching data layer for the projects listed on my Dapp
As Project Patricia - I want a way to share the positive vouching I have received on my project with my community.

Features

Attestations

Allow users to vouch or flag a project by creating an attestation for it on Optimism
If a user belongs to more than one attestor group let them choose which ones (can be more than one) they wish to attest as (flag or vouch).
If the connected user has already attested to a project they can edit or revoke their attestation, available from project card & project details
- editing creates a new attestation
- revoke creates an on-chain revocation of attestation

Viewing Projects

Show project cards of projects from different sources (Gitcoin, Giveth, RPGF) that can be vouched for on a single “homepage” list view
- Project cards contain the following information:
  - Badge/Icon identifying the source of the project
  - banner image
  - Link to their project page on the platform they belong to
  - Show how many of each pre-defined attester groups have vouched for this project (if it isn’t 0)
  - Show how many of each pre-defined attester groups have flagged this project (if it isn’t 0)
  - button to vouch for project
  - button to flag project
  - A short preview of the project description
  - If the connected user has already vouched for the project
    - Share button that copies a link to the project details page to the user's clipboard
A detailed project page for each project listed
- Title of the project
- Who vouched/flagged for them
- Full description of the project (from API)
- If the attestor left a comment and what the content of the comment is
- If the connected user has already vouched for the project, as which attestor group
- Share button that copies a link to the project details page to the user's clipboard
- Show a badge or icon to identify which source the project is coming from

Project Sorting & Filtering

The list of projects can be FILTERED by various parameters, including:
- Which source the project belongs to
- text keywords in the project title
- Only for projects that a specific attester group have interacted with (from a pre-defined list)
- Only for projects that a custom attester group have interacted with. Takes two params:
  - Schema Id (or do we make them user OUR schema?)
  - Issuer address
The list of projects can be SORTED by various parameters including:
- ascending/descending vouch count for given filtered attester group (or across all attester groups if no filter is selected) from back-end service
- ascending/descending flag count for given filtered attester group (or across all attester groups if no filter is selected) from back-end service
On the project details page allow FILTERING according to:
- The Attestor Group(s) that have attested to this project - we should filter this into the back-end
- Filter out only vouches or only flags made to this project
On the project details page allow SORTING according to:
- ascending/descending order from date of attestations made

“My Attestations”

Allow the connected user to see all of the attestations they have made to listed projects
User can navigate to project pages linked from the “my attestations” table
User can edit or delete their attestations from action buttons available on the table
User can FILTER the table by:
- Project Source
- Flags/Vouches only
- Attestor Groups they vouched as (if they belong to more than one)
User can SORT the table by:
- Ascending/Descending order by date of attestation

External Integration/OSS

Allow queryable information from subgraph/subsquid for the following info:
- number of vouches for given project for given attestor group
- number of flags for given project for given attestor group
- list of addresses that have vouched for a project, filterable by attestor group (array of groups)
- list of addresses that have flagged a project, filterable by attestor group (array of groups)
Maintain a amendable list of pre-defined attester groups, by default our UI takes them into account, external groups can make PRs to modify this list. Takes in:
- Group Name
- schema id
- issuing authority address
- hex colour for badge (??)
As much as possible of what we query on our front-end should be reasonably accessible to external teams

Links

divine-comedian commented 2 months ago

Keep JSON on the back-end and people can update the JSON at the particular endpoint - without releasing a version of the front-end we can keep the data updated.

We'll need to create the documentation for other parties to use the API.

lets use two different repos for FE and BE

If we need a screen that takes from 2 or more data sources we should build a unified API so the front-end can call one endpoint. (list view of projects)

on the project details page we make one direct call to the given data source API

caching layer - three data sources there should be some form of caching, if we come to the same page in 30 seconds we don't need to load all the data from the API, we have some of it stored in the FE cache, because there are personalized elements - show if user has already attested to a given project in list view. We define how often we reload the projects into the cache

divine-comedian commented 2 months ago

Unified API is considered its own service and should have its own epic

Giveth / Roadmap

DeVouch - Decentralized Vouching #108

User Stories

Personas

Stories

Features

Links

Notion

Attestation Services Technical Design

Figma WIP :construction:

Agora (Optimism) REST API spec WIP :construction:

Gitcoin graphQL API

Giveth graphQL API

EAS Attestations graphql