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
S 5 Intent 3 : Intent 4 - Improve Governance Accessibility
Proposing Delegate: Brichis 2
Proposal Tier 10 : Ember
Baseline grant amount: 36 K ( 18 K 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” 4 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:
Specify tangible use cases this interface will address
Enable Attestations to be issued in both OP Mainnet and OP Sepolia
Include locks to enhance privacy and prevent the publishing of PID onchain
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:
The post outlines a Delegate Mission Request focusing on driving the adoption of attestations within Optimism. The proposal aims to improve governance accessibility by creating an easy-to-use interface for Attestors. The Request requires understanding of EAS, previous experience integrating EAS, and completion of various deliverables. Progress towards the Mission will be tracked through bi-weekly updates and milestones. Impact assessment includes measuring the number of new attestations, new attestors, and feedback on the interface. The Mission Request was a collaborative effort involving various contributors.
AxlVaz: brichis:
How should badgeholders measure impact upon completion of this Mission?
I like this mission, I think you can add metrics to it:
Number of frontend forks.
LauNaMu: 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.
@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.
zainbacchus:
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.
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:
brichis:
Specify tangible use cases this interface will address
4 . Share proposed design and user flow in application (this should be evaluated by the Grants Council)
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:
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)
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:
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.
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:
kristofer:
they need to be able to create custom schemas for the specific thing they want to attest to
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!
Delegate Mission Request Summary:
Drive adoption of attestations within Optimism by creating an eas…
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
S 5 Intent: Intent 4 - Improve Governance Accessibility
Proposing Delegate: Brichis
Proposal Tier: Ember
Baseline grant amount: 36 K ( 18 K 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:
Specify tangible use cases this interface will address
Enable Attestations to be issued in both OP Mainnet and OP Sepolia
Include locks to enhance privacy and prevent the publishing of PID onchain
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:
AxlVaz: brichis:
How should badgeholders measure impact upon completion of this Mission?
I like this mission, I think you can add metrics to it:
Number of frontend forks.
LauNaMu: 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.
@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.
zainbacchus:
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.
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:
brichis:
Specify tangible use cases this interface will address
4 . Share proposed design and user flow in application (this should be evaluated by the Grants Council)
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:
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)
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:
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.
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:
kristofer:
they need to be able to create custom schemas for the specific thing they want to attest to
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!
Delegate Mission Request Summary: Drive adoption of attestations within Optimism by creating an eas…
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 S 5 Intent 2 : Intent 4 - Improve Governance Accessibility Proposing Delegate: Brichis 1 Proposal Tier 8 : Ember Baseline grant amount: 36 K ( 18 K 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” 3 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: Specify tangible use cases this interface will address Enable Attestations to be issued in both OP Mainnet and OP Sepolia Include locks to enhance privacy and prevent the publishing of PID onchain 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:
AxlVaz: brichis:
How should badgeholders measure impact upon completion of this Mission?
I like this mission, I think you can add metrics to it:
Number of frontend forks.
LauNaMu: 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.
@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.
zainbacchus:
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.
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:
brichis:
Specify tangible use cases this interface will address
4 . Share proposed design and user flow in application (this should be evaluated by the Grants Council)
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:
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)
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:
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.
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:
kristofer:
they need to be able to create custom schemas for the specific thing they want to attest to
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!
Hi everyone! I am an employee of OP Labs and speaking on my own behalf.
Super excited to see the ex…
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
Carlosjmelgar: 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.
brichis: Hi @zainbacchus! First off, thank you for taking the time to provide feedback on this proposal; I genuinely appreciate it.
zainbacchus:
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?
Here are a few examples I can envision:
A project creates an attestation for attendees to their event > A project say they had X amount of attendees on their event
1:1 call to onboard a project on Optimism: Mutual attestation between both participants > One person say that he/she onboard x project
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.
LauNaMu: 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.
@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.
zainbacchus:
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.
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:
brichis:
Specify tangible use cases this interface will address
4 . Share proposed design and user flow in application (this should be evaluated by the Grants Council)
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:
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)
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:
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.
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:
kristofer:
they need to be able to create custom schemas for the specific thing they want to attest to
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!
xiaohou77: zainbacchus:
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.
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.
Hi everyone! I am an employee of OP Labs and speaking on my own behalf.
Super excited to see the ex…
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/
Carlosjmelgar: 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.
brichis: Hi @zainbacchus! First off, thank you for taking the time to provide feedback on this proposal; I genuinely appreciate it.
zainbacchus:
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?
Here are a few examples I can envision:
A project creates an attestation for attendees to their event > A project say they had X amount of attendees on their event
1:1 call to onboard a project on Optimism: Mutual attestation between both participants > One person say that he/she onboard x project
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.
LauNaMu: 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.
@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.
zainbacchus:
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.
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:
brichis:
Specify tangible use cases this interface will address
4 . Share proposed design and user flow in application (this should be evaluated by the Grants Council)
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:
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)
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:
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.
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:
kristofer:
they need to be able to create custom schemas for the specific thing they want to attest to
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!
xiaohou77: zainbacchus:
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.
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.
brichis:
How should badgeholders measure impact upon completion of this Mission?
I like this…
brichis:
How should badgeholders measure impact upon completion of this Mission?
I like this mission, I think you can add metrics to it:
Number of frontend forks.
Hi everyone! I am an employee of OP Labs and speaking on my own behalf. Super excited to see the ex…
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/ 7
Carlosjmelgar: 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.
brichis: Hi @zainbacchus! First off, thank you for taking the time to provide feedback on this proposal; I genuinely appreciate it.
zainbacchus:
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?
Here are a few examples I can envision:
A project creates an attestation for attendees to their event > A project say they had X amount of attendees on their event
1:1 call to onboard a project on Optimism: Mutual attestation between both participants > One person say that he/she onboard x project
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.
LauNaMu: 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.
@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.
zainbacchus:
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.
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:
brichis:
Specify tangible use cases this interface will address
4 . Share proposed design and user flow in application (this should be evaluated by the Grants Council)
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:
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)
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:
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.
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:
kristofer:
they need to be able to create custom schemas for the specific thing they want to attest to
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!
xiaohou77: zainbacchus:
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.
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.
brichis: How should badgeholders measure impact upon completion of this Mission? I like this…
brichis: How should badgeholders measure impact upon completion of this Mission? I like this mission, I think you can add metrics to it: Number of frontend forks.
This is great context. I’m looking forward to seeing projects use attestations for service provides…
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.
Hi @zainbacchus! First off, thank you for taking the time to provide feedback on this proposal; I g…
Hi @zainbacchus! First off, thank you for taking the time to provide feedback on this proposal; I genuinely appreciate it.
zainbacchus:
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?
Here are a few examples I can envision:
A project creates an attestation for attendees to their event > A project say they had X amount of attendees on their event
1 : 1 call to onboard a project on Optimism: Mutual attestation between both participants > One person say that he/she onboard x project
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.
kristofer: brichis:
A project creates an attestation for attendees to their event > A project say they had X amount of attendees on their event
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?
Hey @AxlVaz! Thank you for the recommendation. I have updated the project and added that metric.
Hey @AxlVaz! Thank you for the recommendation. I have updated the project and added that metric.
This is great context. I’m looking forward to seeing projects use attestations for service provides…
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.
Hi @zainbacchus! First off, thank you for taking the time to provide feedback on this proposal; I g…
Hi @zainbacchus! First off, thank you for taking the time to provide feedback on this proposal; I genuinely appreciate it. zainbacchus: 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? Here are a few examples I can envision: A project creates an attestation for attendees to their event > A project say they had X amount of attendees on their event 1 : 1 call to onboard a project on Optimism: Mutual attestation between both participants > One person say that he/she onboard x project 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.
kristofer: brichis:
A project creates an attestation for attendees to their event > A project say they had X amount of attendees on their event
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?
Hey @AxlVaz! Thank you for the recommendation. I have updated the project and added that metric.
Hey @AxlVaz! Thank you for the recommendation. I have updated the project and added that metric.
brichis:
A project creates an attestation for attendees to their event > A project say they ha…
brichis:
A project creates an attestation for attendees to their event > A project say they had X amount of attendees on their event
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:
0 x 123 ...AbC: Main funding multisig
0 x 456 ...dsd: Rewards team Aragon DAO
0 x 789 ...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 0 x 789 ...dFe saying Brichis attended our nice project retreat, I can trust this attestation came from the right source.
Possible mission request? :slight_smile:
kristofer: ps. The use case is in part covered by this project I built:
attest-fest.party
Attest Fest!
Batch create onchain EAS attestations using the power of CSV and copy/paste. Supports any old ETH wallet as well as fancy new Safe multisig wallets. It's an attest fest, yaay!
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.-
LauNaMu: 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.
@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.
zainbacchus:
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.
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:
brichis:
Specify tangible use cases this interface will address
4 . Share proposed design and user flow in application (this should be evaluated by the Grants Council)
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:
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)
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:
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.
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:
kristofer:
they need to be able to create custom schemas for the specific thing they want to attest to
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!
brichis: A project creates an attestation for attendees to their event > A project say they ha…
brichis: A project creates an attestation for attendees to their event > A project say they had X amount of attendees on their event 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: 0 x 123 ...AbC: Main funding multisig 0 x 456 ...dsd: Rewards team Aragon DAO 0 x 789 ...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 0 x 789 ...dFe saying Brichis attended our nice project retreat, I can trust this attestation came from the right source. Possible mission request? :slight_smile:
kristofer: ps. The use case is in part covered by this project I built:
attest-fest.party
Attest Fest!
Batch create onchain EAS attestations using the power of CSV and copy/paste. Supports any old ETH wallet as well as fancy new Safe multisig wallets. It's an attest fest, yaay!
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.-
LauNaMu: 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.
@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.
zainbacchus:
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.
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:
brichis:
Specify tangible use cases this interface will address
4 . Share proposed design and user flow in application (this should be evaluated by the Grants Council)
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:
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)
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:
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.
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:
kristofer:
they need to be able to create custom schemas for the specific thing they want to attest to
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!
ps. The use case is in part covered by this project I built:
attest-fest.party
Attest Fest!
B…
ps. The use case is in part covered by this project I built:
attest-fest.party
Attest Fest!
Batch create onchain EAS attestations using the power of CSV and copy/paste. Supports any old ETH wallet as well as fancy new Safe multisig wallets. It's an attest fest, yaay!
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.-
ps. The use case is in part covered by this project I built:
attest-fest.party
Attest Fest! …
ps. The use case is in part covered by this project I built:
attest-fest.party
Attest Fest! 6
Batch create onchain EAS attestations using the power of CSV and copy/paste. Supports any old ETH wallet as well as fancy new Safe multisig wallets. It's an attest fest, yaay!
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.-
ps. The use case is in part covered by this project I built: attest-fest.party Attest Fest! …
ps. The use case is in part covered by this project I built: attest-fest.party Attest Fest! 6 Batch create onchain EAS attestations using the power of CSV and copy/paste. Supports any old ETH wallet as well as fancy new Safe multisig wallets. It's an attest fest, yaay! 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.-
Hi everyone!
I’m not the proposer of this Mission but have had extensive conversations with @brichi…
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.
zainbacchus:
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.
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:
brichis:
Specify tangible use cases this interface will address
4 . Share proposed design and user flow in application (this should be evaluated by the Grants Council)
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:
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)
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:
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.
Service Providers in the Optimism Ecosystem:
We can look at @Subli_Defi’s application for RetroPGF 3 . 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:
kristofer:
they need to be able to create custom schemas for the specific thing they want to attest to
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!
kristofer: LauNaMu:
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).
One way to make it really easy for the end user is to present a curated selection of schemas to choose from. Like:
What would you like to attest to?
Select from a list/grid of clearly described simple schemas
Input data according to schema
Basically, filling out a small form with the data the schema requests
Done.
chaselb: Based on this reply I’m leaning towards approving this proposal. It makes concrete the vision of attestations and where a project like this might fit into that vision. Also, the request budget is fairly low (less than 3%) compared to the budget for the intent.
Hi everyone!
I’m not the proposer of this Mission but have had extensive conversations with @brichi…
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 1 , 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.
zainbacchus:
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.
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:
brichis:
Specify tangible use cases this interface will address
4 . Share proposed design and user flow in application (this should be evaluated by the Grants Council)
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:
Definomics Lab 3 (for example, with the requested UI we could ensure no PID is put on-chain as was the case for this use-case)
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:
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 1 as a precedent to build expectation for this idea to be believable. I hope this also answers one of your questions @kristofer.
Service Providers in the Optimism Ecosystem:
We can look at @Subli_Defi’s application for RetroPGF 3 2 . 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:
kristofer:
they need to be able to create custom schemas for the specific thing they want to attest to
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 1 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!
kristofer: LauNaMu:
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).
One way to make it really easy for the end user is to present a curated selection of schemas to choose from. Like:
What would you like to attest to?
Select from a list/grid of clearly described simple schemas
Input data according to schema
Basically, filling out a small form with the data the schema requests
Done.
chaselb: Based on this reply I’m leaning towards approving this proposal. It makes concrete the vision of attestations and where a project like this might fit into that vision. Also, the request budget is fairly low (less than 3%) compared to the budget for the intent.
Hi everyone! I’m not the proposer of this Mission but have had extensive conversations with @brichi…
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 1 , 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. zainbacchus: 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. 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: brichis: Specify tangible use cases this interface will address 4 . Share proposed design and user flow in application (this should be evaluated by the Grants Council) 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: Definomics Lab 1 (for example, with the requested UI we could ensure no PID is put on-chain as was the case for this use-case) 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: 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 1 as a precedent to build expectation for this idea to be believable. I hope this also answers one of your questions @kristofer. Service Providers in the Optimism Ecosystem: We can look at @Subli_Defi’s application for RetroPGF 3 2 . 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: kristofer: they need to be able to create custom schemas for the specific thing they want to attest to 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 1 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!
kristofer: LauNaMu:
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).
One way to make it really easy for the end user is to present a curated selection of schemas to choose from. Like:
What would you like to attest to?
Select from a list/grid of clearly described simple schemas
Input data according to schema
Basically, filling out a small form with the data the schema requests
Done.
chaselb: Based on this reply I’m leaning towards approving this proposal. It makes concrete the vision of attestations and where a project like this might fit into that vision. Also, the request budget is fairly low (less than 3%) compared to the budget for the intent.
zainbacchus:
One of the key learnings from our attestation experimentation is: who the issuer …
zainbacchus:
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.
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.
Marcus01: 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!
fairsharing.xyz
FairSharing | Decentralizing Collaboration
FairSharing empowers web3 contributors to record onchain, gain community attestations, claim token rewards, and experience fair allocation based on contributions.
kristofer: This is where Praise comes into the picture . 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.
zainbacchus:
One of the key learnings from our attestation experimentation is: who the issuer …
zainbacchus:
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.
These are excellent insights. Big kudos to @zainbacchus
As a member of LXDAO (https://lxdao.io 2 ), 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.
Marcus01: 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!
fairsharing.xyz
FairSharing | Decentralizing Collaboration
FairSharing empowers web3 contributors to record onchain, gain community attestations, claim token rewards, and experience fair allocation based on contributions.
kristofer: This is where Praise comes into the picture . 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.
zainbacchus: One of the key learnings from our attestation experimentation is: who the issuer …
zainbacchus: 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. These are excellent insights. Big kudos to @zainbacchus As a member of LXDAO (https://lxdao.io 2 ), 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.
Marcus01: 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!
fairsharing.xyz
FairSharing | Decentralizing Collaboration
FairSharing empowers web3 contributors to record onchain, gain community attestations, claim token rewards, and experience fair allocation based on contributions.
kristofer: This is where Praise comes into the picture . 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.
That is so cool！
I am using Mike’s product fairsharing, he is able to record chained work certifica…
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!
fairsharing.xyz
FairSharing | Decentralizing Collaboration 1
FairSharing empowers web 3 contributors to record onchain, gain community attestations, claim token rewards, and experience fair allocation based on contributions.
That is so cool！
I am using Mike’s product fairsharing, he is able to record chained work certifica…
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!
fairsharing.xyz
FairSharing | Decentralizing Collaboration
FairSharing empowers web 3 contributors to record onchain, gain community attestations, claim token rewards, and experience fair allocation based on contributions.
That is so cool！ I am using Mike’s product fairsharing, he is able to record chained work certifica…
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! fairsharing.xyz FairSharing | Decentralizing Collaboration 1 FairSharing empowers web 3 contributors to record onchain, gain community attestations, claim token rewards, and experience fair allocation based on contributions.
This is where Praise comes into the picture :slight_smile:. Praise is system that allow communtiy m…
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.
This is where Praise 1 comes into the picture :slight_smile:. Praise is system that allow communt…
This is where Praise 1 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.
LauNaMu:
This scope of the tool to be developed in this Mission is an interface that enables t…
LauNaMu:
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).
One way to make it really easy for the end user is to present a curated selection of schemas to choose from. Like:
What would you like to attest to?
Select from a list/grid of clearly described simple schemas
Input data according to schema
Basically, filling out a small form with the data the schema requests
Done.
Yes! Exactly :slight_smile:
That’s what we’re going for with this mission request.
Yes! Exactly :slight_smile:
That’s what we’re going for with this mission request.
This is where Praise 1 comes into the picture :slight_smile:. Praise is system that allow communt…
This is where Praise 1 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.
LauNaMu: This scope of the tool to be developed in this Mission is an interface that enables t…
LauNaMu: 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). One way to make it really easy for the end user is to present a curated selection of schemas to choose from. Like: What would you like to attest to? Select from a list/grid of clearly described simple schemas Input data according to schema Basically, filling out a small form with the data the schema requests Done.
Yes! Exactly :slight_smile: That’s what we’re going for with this mission request.
Yes! Exactly :slight_smile: That’s what we’re going for with this mission request.
This is interesting to me, because previously I didn’t really get attestations. But I’m starting to…
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.
This is interesting to me, because previously I didn’t really get attestations. But I’m starting to…
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.
GM!
chaselb:
Why have up to 2 applicants?
We thought that having up to 2 applicants woul…
GM!
chaselb:
Why have up to 2 applicants?
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, uint 64 , and other technicalities. For instance, if you use uint 64 , 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.
I’ve already received messages from three different teams who want to work on this Mission. It seem…
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 @Pr 0 @web 3 magnetic @mastermojo @katie @PGov @StableLab @Tane
I am an Optimism delegate with sufficient voting power and believe this proposal is ready to move t…
I am an Optimism delegate with sufficient voting power and believe this proposal is ready to move to a vote.
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move…
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to mov…
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
Thanks @brichis and other contributors for this proposal. We would love to see more adoption of att…
Thanks @brichis and other contributors for this proposal. We would love to see more adoption of attestations with incentives properly assigned to good projects.
We are an Optimism delegate with sufficient voting power and believe this Request is ready to move to a vote.
GM! chaselb: Why have up to 2 applicants? We thought that having up to 2 applicants woul…
GM! chaselb: Why have up to 2 applicants? 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, uint 64 , and other technicalities. For instance, if you use uint 64 , 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.
I’ve already received messages from three different teams who want to work on this Mission. It seem…
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 @Pr 0 @web 3 magnetic @mastermojo @katie @PGov @StableLab @Tane
I am an Optimism delegate with sufficient voting power and believe this proposal is ready to move t…
I am an Optimism delegate with sufficient voting power and believe this proposal is ready to move to a vote.
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move…
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to mov…
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move…
I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
The Grants Council has opened early submissions as an Indication of Interest for this mission reque…
The Grants Council has opened early submissions as an Indication of Interest for this mission request here 18
For your application to be considered, the Mission request must pass the Token House vote on February 14 th. Early submissions will not be considered if a Mission Request is not approved on the 14 th.
Based on this reply I’m leaning towards approving this proposal. It makes concrete the vision of at…
Based on this reply I’m leaning towards approving this proposal. It makes concrete the vision of attestations and where a project like this might fit into that vision. Also, the request budget is fairly low (less than 3 %) compared to the budget for the intent.
I am not 100 % sure this mission request can accomplish its stated goals by just making attestatio…
I am not 100 % sure this mission request can accomplish its stated goals by just making attestations’s UX easier.
But trying to use attestations to create an on-chain identify of sorts and experiment with these ideas is not a bad idea for the requested amount of funds so I am going to vote for it (with some reservations).
I voted for, as I think this space is very promising, but I’m an unclear if this mission:
Is a cus…
I voted for, as I think this space is very promising, but I’m an unclear if this mission:
Is a custom mission created just to fund EAS.
Is meant to fund a competing protocol to EAS.
Or is meant to (or should!) fund useable, impactful apps that are built on top of EAS or an equivalent protocol.
Hey @Axel_T! It’s basically option 3 :slight_smile: thank you for your vote!
Hey @Axel_T! It’s basically option 3 :slight_smile: thank you for your vote!
