[READY TO VOTE] Building Identity - Driving Adoption of Attestations

Governance Fund Missions šŸ¹
,
1

Delegate Mission Request Summary:

Drive adoption of attestations within Optimism by creating an easy to use interface for Attestors. Attestations are the identity and reputation building block in Optimism both for projects and for individuals in the Collective, however their issuance is limited through code or leveraging the easscan site. Improving the End User experience can drive adoption of this primitive

S5 Intent: Intent 4 - Improve Governance Accessibility

Proposing Delegate: Brichis

Proposal Tier: Ember

Baseline grant amount: 36K (18K OP per applicant)

Should this Foundation Mission be fulfilled by one or multiple applicants: Multiple, up to two.

Submit by: To be set by Grants Council

Selection by: To be set by Grants Council

Start date: Two batches: One in March, a second one in May.

Completion date: 2-3 months after the applicants have been selected.

Specification

How will this Delegate Mission Request help accomplish the above Intent?
This Mission Request has the potential to fulfill two Intents. However, for budgetary purposes, it will be aligned with Intent 4.

Intent 4 - Improve Governance Accessibility:

  • Enable contributors to the collective to have on chain proof of their impact
  • Provide on-chain data to feed into evaluation of future RetroPGF Rounds
  • Increase transparency in contributions and accountability for contributors and the Ecosystem

Organizations and individuals are generating value for the Optimism Collective but much of the value generated by these actors is not trackable on-chain currently. During RetroPGF 3 we spoke about ā€œon-chain metricsā€ frequently but today itā€™s not really accessible for non-technical users.

Insights can be produced from the assessment of data points generated through these attestations. These insights about the strengths and weaknesses of the Optimism Collective can be used to inform governance decisions. Starting a robust feedback loop for fast and continuous improvement. For example, Badgeholders may use these data points to inform their allocation of RetroPGF, which addresses feedback provided by Badgeholders about having more on chain metrics for RetroPGF.

What is required to execute this Delegate Mission Request?

The applicant is expected to have an understanding of EAS . Previous experience integrating EAS is a plus.

Requirements:

  1. Specify tangible use cases this interface will address
  2. Enable Attestations to be issued in both OP Mainnet and OP Sepolia
  3. Include locks to enhance privacy and prevent the publishing of PID onchain
  4. Share proposed design and user flow in application (this should be evaluated by the Grants Council)

The expected deliverables are the following:

  • Deliverable 1: Design of the user flow to be shared in the Governance forum for feedback.
  • Deliverable 2: The creation of a user-friendly front end as a functional prototype.
  • Deliverable 3: Awareness and adoption strategy
  • Deliverable 4: Report on usage in the first month after deployment
  • Deliverable 5: Report on learnings and suggested improvements

How should the Token House measure progress towards this Mission?

Bi-weekly updates in the governance forum, with the following table tracking milestones, titles, deliverables, due dates, and evidence of completion:

  • Milestone 1: Completed front end design.
  • Milestone 2: Complete execution of the awareness and adoption strategy
  • Milestone 3: Successful usage of at least 30 issuers
  • Milestone 4: A well documented Github repo that enables others to fork this front end and has a clear step by step on how this was put together.
  • Milestone 5: Deliver an action plan on required upkeep of the repo and front-end so anyone can take it up if needed.

How should badgeholders measure impact upon completion of this Mission?

  • Number of new attestations created on standard schemas.
  • Number of new attestors who used the interface to attest
  • Qualitative and quantitative data points to allocate RetroPGF.
  • Metrics evolution for each of the schemas created.
  • Quantitative and qualitative feedback on the ease of use of the interface.
  • Number of frontend forks.

*Have you engaged a Grant-as-a-service provider for this Mission Request? If so, please disclose the details of this arrangement, to the extent possible:

No

*Has anyone other than the Proposing Delegate contributed to this Mission Request? If so, who, and what parts of this application did they contribute to?

@Cotabe - Initiated the draft and contributed to it.
@parrachia - Provided feedback.
@MonicaTalan @nicnode @sandusky - Contributed to the draft.
@LauNaMu - Contributed to the draft and polished all the details.

Thank you so much for participating in this collaborative Mission Request :sparkling_heart:

20 Likes
2

Hi everyone! I am an employee of OP Labs and speaking on my own behalf.

Super excited to see the expansion of attestations and non-financial use cases.

One of the key learnings from our attestation experimentation is: who the issuer is matters, what the attestation is important for how the attestation is used, as well as what the attestation is used for is important for adoption.

As an example - Zain saying Zain is trustworthy is OK. Brichis saying Zain is trustworthy is better. Badgeholders saying Zain is trustworthy is even better.

RetroPGF cares about the impact to the Collective. What schemas are going to be used to capture this? Eg should the attestations be arbitrary or focus on specific metrics?

Finally, in between RetroPGF rounds, what is the userā€™s motivation to use this interface?

Without these improvements Iā€™m not sure how this interface is different than https://easscan.org/

9 Likes
3

I like this mission, I think you can add metrics to it:

  • Number of frontend forks.
4 Likes
4

This is great context. Iā€™m looking forward to seeing projects use attestations for service provides. This can be useful for the grants council and badgeholders.

5

Hi @zainbacchus! First off, thank you for taking the time to provide feedback on this proposal; I genuinely appreciate it.

Here are a few examples I can envision:

  1. A project creates an attestation for attendees to their event > A project say they had X amount of attendees on their event
  2. 1:1 call to onboard a project on Optimism: Mutual attestation between both participants > One person say that he/she onboard x project
  3. Workshop: The workshop host can receive an attestation if the attendees consider that the workshop was valuable > The workshop host say that # of people attend to the workshop.

Ethereum MĆ©xico generated attestations for organizers, volunteers, and attendees who checked in and had the NFT ticket from Ethereum Mexico 2023. However, this process was challenging. @LauNaMu had to guide me through the entire process, as creating a schema and generating attestations (particularly in a gas-efficient manner) is not straightforward for someone with a non-technical background like myself. This is not a criticism of EAS; I love the project, and they are welcome to apply. I would be excited to see how they can make attestations accessible to everyone.

2 Likes
6

Hey @AxlVaz! Thank you for the recommendation. I have updated the project and added that metric.

1 Like
7

I like the idea of projects and individual creating more attestations. But I must agree with @zainbacchus. What is the incentive for projects to visit this user interface to create the attestations? Even if they do, they need to be able to create custom schemas for the specific thing they want to attest to, which means, the user interface must provide lots/most of the functionality already found in easscan. Perhaps the flow on easscan could be packaged in a slightly more intuitive way, but there is no getting around that if you want to create a new type of attestation, you need to answer all the questions:

  • Is it going to be revokable?
  • What data types are included?
  • ā€¦

Adding to that, like Zain says, trust is key when it comes to attestations. Trusting the source of the attestation. An open interface to create attestations means anyone can create attestation. As a consumer of an attestation, how do I know who is the attestation creator? Do I trust the creator?

This is slightly off topic, but I would like to see a service similar to Gitcoin Passport but for projects and organisations. I can lookup a project profile and view its proofs. These are not ZK proofs but rather the opposite. A project profile proves it controls the project discord, the official Twitter account, the website etc etc. All the proofs are visible. In addition to those proofs, there are address proofs and labels, for example:

  • 0x123...AbC: Main funding multisig
  • 0x456...dsd: Rewards team Aragon DAO
  • 0x789...dFe: Event attestations

A bit like https://linktr.ee but for projects, organisations and perhaps individuals.

Now, I as a consumer of attestations know, next time I seen an attestation from 0x789...dFe saying Brichis attended our nice project retreat, I can trust this attestation came from the right source.

Possible mission request? :slight_smile:

2 Likes
9

ps. The use case is in part covered by this project I built:

It is meant to simplify the creation of multiple attestations at the same time, but could be extended to support single attestations as well. Perhaps Iā€™ll propose to extend Attest Fest to cover the requirements in this mission request.-

3 Likes
10

Hi everyone!

Iā€™m not the proposer of this Mission but have had extensive conversations with @brichis on what the end goal is, and helped inform and develop the final draft of this Mission. This also aligns a lot with the work I have been doing around pushing for broad adoption of Attestations as identity building blocks. With this in mind, this is my input to provide more context and the logic behind this Mission.

The goal for this mission is to enable anyone, regardless of their tech skills and in depth knowledge of EAS, to issue use-case specific attestations (as defined on the Mission Applicants proposal) that bring whatever they want to attest to on-chain (or off-chain), with an incredibly smooth UI. Imagine that anyone who has ever given a like on Facebook could have a similar seamless experience to attest to a well defined ā€œsomethingā€, thatā€™s what weā€™re aiming for.

The tool should provide guidance on the front end, without requiring all of our non-technical friends having to decipher or even look at EASā€™s technical documentation.

This is currently not the case with the existing EAS website, thatā€™s also not EASā€™s goal and weā€™re itā€™s great to avoid scope creep by limiting what we ask for and building new interfaces for it. Theyā€™ve given us an incredible primitive that weā€™re building on top of and the goal is accessibility and adoption. :smiley:

@zainbacchus I would really appreciate if we can all connect (@brichis and myself) with you to learn more on the key learnings the team had with OPā€™s Attestation Station (challenges, user needs, etc) so we ensure we can leverage that info as we polish this Mission Request.

I think these are all really good points that can be included in the UI that explains to a user why who is issuing the attestation matters, along with the privacy requirements weā€™ve included in the mission request. I believe thereā€™s a couple of approaches we can use here to emphasize the relevance of the issuers identity.

On what is the attestation for:
Mission requests for this Season are meant to be open for anyone to apply, while providing a structure of what is expected in terms of requirements and how this can provide value for the Collective. We have left the exact use case open for Mission Applicants to suggest so that weā€™re not restricting it to a single use case. However, to avoid non relevant use-cases we have included this requirement:

By having the use-cases evaluated by the Grants Council, we are looking to ensure that: any proposed use-case, the logic behind the schema design (if a new one is suggested), or schema selection is relevant to the Collective before being approved.

You do bring a really good point in that we should explicitly include the logic behind the schema being used as one of the requirements. Weā€™ll include this!

As @brichis mentioned on her comment, thereā€™s already some existing use cases leveraging attestations in between rounds so that this data can be leveraged for future rounds. As we continue to move towards data driven evaluations in RetroPGF, the first thing weā€™ll need is data, and this proposal could give us a good insight into what kind of data are members of the Collective believe is valuable to generate.

Here are some of the examples weā€™ve observed in the wild in between rounds:

  1. Definomics Lab (for example, with the requested UI we could ensure no PID is put on-chain as was the case for this use-case)
  2. Optimism en EspaƱol Events

While the Mission Request is broad, here are some use-cases that have been identified by members of the Collective that would be valuable to explore:

  1. Events: Providing attestations to event participants can enable analyzing the behaviour and engagement of participants through time in the Optimism Ecosystem on-chain. Weā€™re fortunate to have an incentive for data generators through the RetroPGF mechanism if there is a perception (and proof) of standing a better opportunity to receive RetroPGF in the future based on provable/verifiable data. We can leverage the past and projected use of OSO and the Metrics Garden as a precedent to build expectation for this idea to be believable. I hope this also answers one of your questions @kristofer.

  2. Service Providers in the Optimism Ecosystem:
    We can look at @Subli_Defiā€™s application for RetroPGF3. Projects that Subli worked with could have attested to their work, making this data easier to consume and evaluate. Having a straightforward and easy way to attest to the work being done can also incentivize an increase in providing services particularly for underserved audiences in the Collective. Additional use-cases for this were mentioned by @brichis above.

As mentioned above, the goal for this Mission is to target very well defined and specific use-cases (as the two described above) this means weā€™re limiting the need for this:

By having specific schemas being used, we also constrain how the data is generated and enable easier builds for tooling to analyze the generated data.

I agree with you on how important trust is when value is given to attestations, however, the current design allows for anyone to build attestations as long as they have some degree of technical knowledge on how to use the EAS site. The only thing happening right now is that the website design blocks non-technical people to use this primitive. An interesting question that arises is: Would we be endorsing this gatekeeping as the status quo by not creating an accessible gateway for non-technical folks in the Optimism Ecosystem?

As consumers of data, any protocol/project/product is able to choose the degree and the parameters under which they trust any source as best as they see fit, this already happens with all on and off-chain data that is generated, an example of this is Gitcoin Passport or Ceramic.

This scope of the tool to be developed in this Mission is an interface that enables the generation of data, not its consumption. The concern on the parameters and degree to which said data would be valued is out of scope and is upon data consumers. However, this Mission does offer an advantage in pushing for a MVP of driving adoption of a standardized data model for at least two specific use-cases (could even be more depending on the proposals).

The Attest Fest website doesnā€™t cover the need for simplifying the use of Attestations. People still need to understand all the schemas to then from the EAS website extract the UID they want to use. I would argue that Attest Fest actually increases the steps and is already contained within EAS since easscan.org does have the functionality of on-chain batch creation of attestations without going to an external website with data (the Attestation UI) you needed to get from the schema list. However, it could be a good starting point.

Thanks everyone for your thoughtful comments and looking forward to continue to improve this Mission Proposal together!

3 Likes
11

These are excellent insights. Big kudos to @zainbacchus

As a member of LXDAO (https://lxdao.io), Iā€™ve spent over six months contemplating the intricacies of attestation and am eager to share the insights Iā€™ve gathered to inspire more builders.

The fundamental question is: Where do attestations originate? Tracing back through history, it is obvious that attestations stem from trust, and trust is born from enduring cooperation during the hunting and gathering era.

Thus, meaningful attestations are a byproduct of human collaboration. This implies we canā€™t merely create arbitrary attestations en masse; we must anchor them in collaborative contexts/boundaries to ensure their value. For instance, establishing a project with a select number of contributors allows them to attest to one anotherā€™s contributions based on their collaborative actions.

2 Likes
12

That is so coolļ¼
I am using Mikeā€™s product fairsharing, he is able to record chained work certificates fairly and accurately, which helps a lot and I think his product is perfectly suited for eas task applications!

13

This is where Praise comes into the picture :slight_smile:. Praise is system that allow communtiy members to praise the actions of other community members. Praising is done on Discord, see for instance the feel-the-love channel on the OP Discord.

The impact of praise is periodically quantified and the score is turned into ā€¦ attestations! See the OP attestation explorer.

How to interpret the Praise score: A person with a high praise score is an impactful contributor to the OP, based on the assessments of other community members. Which in turn would mean that additional attestations by this person carries more ā€œweightā€ than by a person with low or no Praise score.

1 Like
14

One way to make it really easy for the end user is to present a curated selection of schemas to choose from. Like:

  1. What would you like to attest to?
  • Select from a list/grid of clearly described simple schemas
  1. Input data according to schema
  • Basically, filling out a small form with the data the schema requests
  1. Done.
3 Likes
15

Yes! Exactly :slight_smile:

Thatā€™s what weā€™re going for with this mission request.

17

This is interesting to me, because previously I didnā€™t really get attestations. But Iā€™m starting to understand now. Theyā€™re data building blocks for measuring trust/identity. Even though the data consumption methods arenā€™t fleshed out yet, weā€™re trying to create the rudimentary building blocks for data creation. Questions/concerns:

Why have up to 2 applicants?

and

My main concern with this project is that, like those above saying, thereā€™s no incentive to get people using these attestation systems. So even if we build out this interface, thereā€™s no guarantee that someone will use it, because thereā€™s no profit motive to give out attestations. If anything, there should be some sort of attestation subsidization to encourage attestation creation (because a good plethora of attestations is good for data consumption). It seems like attestations are primitives of a much larger public good structure, and we should be trying to work on the whole problem in a somewhat coordinated fashion, instead of giving small grants for parts of the problem.

1 Like
18

GM!

We thought that having up to 2 applicants would allow us to create a community knowledge base. The first applicant would serve as more of an experimental phase, while the second one would be able to build upon the learnings from the first, resulting in a clearer path forward.

Regarding incentives, personally, I believe we already have some incentives with RetroPGF. We are placing more emphasis on impact metrics, and projects that are not part of the Open Source category often struggle to demonstrate their impact without resorting to vanity metrics such as the number of followers or viewers. Improved impact metrics lead to better applications, and better applications typically yield better results on RetroPGF. I know many people who are interested in using attestations because they understand the impact it can have on establishing an on-chain reputation. I personally have this understanding and could serve as a trusted issuer. However, I find it challenging to use the EAS interface. While Iā€™ve created attestations in the past with a lot of assistance, itā€™s still difficult because you need to understand the differences between bool, string, uint64, and other technicalities. For instance, if you use uint64, you must modify the date format. Additionally, you need to comprehend concepts such as resolver addresses and the distinctions between being revocable and non-revocable, as well as off-chain and on-chain dynamics. The interface is not intuitive for someone with a non-technical background. Itā€™s important to note that EAS is a wonderful product, but we need to make it more user-friendly for non-technical profiles like me, as well as organizations like HER DAO LATAM, Ethereum MĆ©xico, Ethereum Lima, and others who are already interested in using it.

1 Like
19

Iā€™ve already received messages from three different teams who want to work on this Mission. It seems to have generated good engagement and a significant amount of interest. Iā€™m tagging some the delegates who signed up to be assigned to review different Mission Requests, and I would appreciate it if you could review one more mission. In case youā€™d like to see this project built, please provide your approval as a Top 100 delegate before the deadline at 19:00 GMT. Thank you! :raised_hands:
@olimpio @GFXlabs @lefterisjp @Joxes @kaereste @OPUser @Pr0 @web3magnetic @mastermojo @katie @PGov @StableLab @Tane

7 Likes
20

I am an Optimism delegate with sufficient voting power and believe this proposal is ready to move to a vote.

1 Like
21

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

2 Likes
22

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

2 Likes