Open amanwithwings opened 11 months ago
Call arranged for everyone here next week to go over this + make plans for the Optimism Attestations project.
We need to schedule a new call with @frm present! @frm when are you available next week / later this week?
Pinged @frm today.
Noting that Mendes is not going to be available for the next couple of weeks.
REMINDER, updated attestations standard needs to be out by end of September.
@amanwithwings We (LXDAO) may help on one of the tasks "A web platform for attestations and contributions: This platform will be capable of displaying DAOIP-3 attestations and contributions for any given Ethereum address.", since we plan to do one for EAS as well, we plan to consolidate them and push the forward of the attestation standards. Cc@thelastjosh
We can connect next week on more details. @amanwithwings
@xiaohou77 , sounds good!
Josh is taking the lead on this and we plan to have a meeting around or after the 10th of September for status update
Josh proposed a time to meet around 10th Sept, might need to shift that slightly (sometime week of Sep 11). Need to publish V2 of attestation standard - we should be able to do that ourselves, no real blockers.
Next step: meet next week, at latest by early week of Sept 18th.
LXDAO is helping OPT build an attestation front end and list public schemas. Make existing schemas more discoverable for devs in OPT ecosystem. Second point of this issue aligns with some of LXDAO's work so might have room to collab there. DAOstar+LXDAO can explore applying for a future builders grant together.
Meeting getting scheduled for ~25th of Sep
Latest: we need to define a proper team to work on this, e.g. with Aman as PM, Rashmi + LXDAO, ideally Mendes if he's available.
Aman and I also discussed the need to have additional conversations with ecosystem actors to evaluate the need and place for the attestations standard, since this entire thing, including all the infra we are thinking of building, is really intended to support adoption of the standard, but many of the people who put effort into building in the initial standard are gone now (Avenue, Govrn, etc.). We should talk to people like Disco, DeWork, etc. to evaluate whether this standard is still useful to them. We should also talk to EAS to catch up.
We talked organizing the project management a bit more with a doc or some other tracking mechanism. For now let's just keep using this GitHub issue. Maybe Aman can just update the first post with necessary information as things evolve.
Updating the DAOIP-3 standard issue: https://github.com/metagov/daostar/discussions/39 Optimism issue: https://github.com/metagov/daostar/issues/100 PR for WIP update of v2, needs to be reviewed and merged this week: https://github.com/metagov/daostar/pull/95
Today we heard from Mike on the work LXDAO is doing with Optimism Attestations.
If LXDAO + DAOstar partner on this, we could consolidate this with https://github.com/metagov/daostar/issues/60 and have LXDAO push it forward.
Setting up a co-working session tomorrow with the team.
Update: Milestone 1 has been completed successfully. Update added on Charmverse.
I am proposing the attestaion standard framework as below:
The key is we can set the standard to conforming EAS's format, and it can be easily adopted by devs/apps. From DAO* standpoint, we can maintain the API endpoint for non-EAS use case if we want, and we don't need to maintain any API endpoint for EAS use case.
To be more specific: DAO* attestation standard is a simple and straightforward schema like this which conforms with EAS format:
The pros are:
For DAO URIs, since they are already stored in contract/IPFS thru DAO* registration contract, we don't have to store them on EAS again, at least, the value using EAS in this case is not clear and big.
In today's we reviewed part of the EAS flow and agreed it makes sense to support the integration, especially for DAOIP-3 attestations. We did not review the other uses of EAS yet (e.g. to support easier adoption of daoURI).
Next step: review this with Bryce and Disco. How can we make sure that we're building this WITH someone rather than just a standard that no one uses?
Current key users:
Strategy-wise: usually what we do in writing a standard is we find 2-3 groups who are willing to put this on their 6 month roadmap. We DID THIS for DAOIP-3 but Govrn and Avenue are no longer (really) active.
Now, we have an updated standard, supported by grants, so we're in a different situation. We don't necessarily need to lock ourselves into finding 2-3 such groups (THOUGH WE SHOULD DEFINITELY TRY). Especially, right now there's a lot of contraction in the DAO industry, especially in the West. Companies are not necessarily shipping new features but just trying to survive. It might be easier to go a more open-source direction, support new development on top of this standard by open-source and new entrants in the East. We don't know all the potential use-cases, but we should try to present this as a good open-source, public good foundation / stack that people can build on. I.e. instead of banking too much on "known names" we focus on (1) finding and cultivating use-cases within the community using the standard as a kind of asset (so this would emphasize giving presentations about the standard), and (2) to some degree building prototypes of use-cases ourselves (witness the attestation explorer we built).
Asked Gonna, from the OP Builders Grant committee on how grant milestones should be updated. Their reply:
"We are working on a solution for this. Builders are subject to 1 year lock and therefore milestone reports can be done by the end of the 1 year period. If you still want to give a date-by-date update you can do it in the forum here:
https://gov.optimism.io/c/updates-and-announcements/grant-updates/56
Please use tags: "Season 4", "Builders ", "Milestones".
If you do it, please add your Charmverse proposal link."
For the time being, I am choosing to not create an additional forum post on Optimism. For now, all updates, including milestone completion details, will be periodically added to Charmverse.
Discussion today with Evin + Carl at Disco. Suggestions for update to the standard: attestationsURI -> evidence, and changing type+id to id: {type, address}.
Note that EAS doesn't exist on all chains. Also, what's the difference in terms of trustworthiness between a DAO deploying a registration contract by signing an on-chain transaction, and them signing a EAS attestation? You may be talking about the first part, where we first deploy a daoURI JSON which must be "claimed" by a DAO's on-chain transaction. In which case a signed attestation is probably more trustworthy, in some sense, than just going through our interface. It may, eventually, make sense for our interface to just call EAS underneath the hood, at least for chains where EAS exists. Or, at least, to provide that option.
Before we go through any comparisons, I would just build the EAS option and test it, because we need to anyway.
On Mon, Nov 6, 2023 at 6:45 PM Rashmi V Abbigeri @.***> wrote:
I think we should implement DAO URI using EAS and Not the EIP 4824, it makes more sense to me At the end of the day DAO URI and it contents that is Attested is more relevant and more trust worthy than the DAO URI created by a registration form from our frontend. Because anyone can create a DAO URI from the reistration form, its not signed/attested
A DAO URI created with EAS attestation either onchain/offchain, someone attests it, from a wallet address/ens name/DAO address and then they make an EIP-4824 registration contract summoner with an onchain transaction from their DAO
I believe this would make the standard more credible and also make creating the DAO URI more "decentralized" (right now, we are the only one hosting the registration form to create the DAO URI)
Next steps would be to modify the contract to listen to the DAO URI attestations and just display it on our frontend. We would NOT need our Subgraphs, nor the DAO URI API infrastucture
But we would need to implement the Framework customization ( Snapshot, DAODAO, custom, moloch, safe etc) with an EAS attestation. We could do this easily by having a field on DAO URI for framework and a resolver contract which generates the Framework URI links for say Snapshot or any other framework
We need to think about "incentivising" the DAO Framework URI to be maintained by the framework maintainers themselves as it would be more in sync with any changes/updates a framework makes
— Reply to this email directly, view it on GitHub https://github.com/metagov/daostar/issues/100#issuecomment-1797041885, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACHA5PF4DBQO3GHUEWBS2P3YDFZBBAVCNFSM6AAAAAA2SRCPLOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJXGA2DCOBYGU . You are receiving this because you commented.Message ID: @.***>
FYI @Rashmi-278, I've closed issue #179 and moved the discussion here.
We (potentially) have Karma, Fairsharing, and Disco adopting DAOIP-3 and we need to make sure we have that indexing working. This was previously worked on for ONTOCHAIN.
From Josh:
_"From today: when we submit an attestation, it does work, but the API server that was pulling the attestations was hosted by Mendes, and that server is not returning anything, and Rashmi has no way to debug it. On the backend server though, the flow for submitting reputation attestations does currently work.
Do we need the front end? YES. The 3rd and final milestone of https://github.com/metagov/daostar/issues/100 requires having a frontend.
Next step: copy the current frontend, deploy a DAOIP-3 compliant schema(s), and add the ability to display EAS attestations. That should satisfy the milestone for https://github.com/metagov/daostar/issues/100."_
Present schemas:
Disco: https://github.com/discoxyz/disco-schemas/tree/main/json
Fairsharing: https://optimism.easscan.org/schema/view/0xc012dddde021c7258ff4671b1be08fe6b3b51d98bd0a89b43d020fafde24b476
Next step: suggestions to convert all 3 to being DAOIP-3 compliant.
Just will finish reviewing Aman's DAOIP proposal for EAS support ASAP
@thelastjosh, @Rashmi-278, this seems like a nice design for the attestation standard (explorer) front-end: https://tokenlists.org/ (their code is open source, so we can probably reuse a lot of it).
Once our schema is final, live on EAS, and projects adopt it, the front-end could display the schemas of all DAO attestations. It could look something like this:
Noting that there is an ecosystem project idea aligned with this: https://github.com/orgs/ethereum-optimism/projects/31/views/4?filterQuery=attestation+list&pane=issue&itemId=27292601
What are your thoughts? @Rashmi-278 Rashmi, how much heavy lifting does this entail?
@amanwithwings If we want the exact same website, we can get this up pretty quicky as the website is open source, It would take two days to add the EAS Attestation Indexing
Here's the cloned website for this on Metagov: https://github.com/metagov/Attestation-List
Let's do it; this will satisfy benchmark milestone 2. @amanwithwings could you create a new issue and add it to Milestone 2.1 Attestations?
Tiny clap for @Rashmi-278 for the great technical implementation 👏 some additional BD work remains. Progress mostly tracked in #226 .
Original proposal: https://app.charmverse.io/op-grants/page-31849314357430236
These are the key components of the project:
An attestation-based architecture and data model for DAO membership, member contributions, and other data (a.k.a., Attestation Standard V2)
A web platform for attestations and contributions: This platform will be capable of displaying DAOIP-3 attestations and contributions for any given Ethereum address.
Accompanying Infrastructure: This infrastructure will allow a client to deploy a new platform instance for a given Ethereum RPC-compatible network.
But the critical milestones of the project are:
Ideally, we want to complete all things promised under the key components by Q4 2023 and also try to get some adoption for it.