Strike Team #21
Last Edited Time
Jun 13, 2022
Created time
Apr 14, 2022
Participants
Created By
Type
Created
Apr 14, 2022
Zoom Recording
Property
Property 1
Attendees:
- Ido Gershtein
- Cent Hosten
- Josh Tan
- Michael Zargham
- Michael Heuer
- Isaac P
- Keating
AIs
Delegate someone to attend the CAIP / Spruce talks at ETH Amsterdam
Isaac: Bring in James from Wildfire on comms and marketing roll out.
Cent: See if Andrej would know someone who could do this kind of work.
Have an example of the manager contract
Spend time next week specing out the Factory
Minutes
Introductions:
Zargham: This is about the way the data is stored rather than the what the data is. Maybe the emphasis should be moving towards the DAOIP process. The ontologies should be governed by a different entity other than who governed the smart contracts on the EVM. Setting the goals of the standards body would include breadth and depth. The expressivity of the data. We are standardizing what is represented and how it is exchanged, rather than what is contained.
Josh: we could partner with a standards body like w3c for how to implement the standards. We could run this ourselves, but with a commitment to upgrade so that the DAOIP is perceived as legitimate. There is also the CAIP, the chain agnostic IP. They will be at ETHAmsterdam, along with the people from Spruce. It might be wise to send someone there.
Updates
Review of Project Management
Isaac: No substantive updates on implementation. Meeting with other members of Moloch at ETH Amsterdam to get some work done
Ido: Also not much to say, on vacation. Need to do the html work to have the documentation on the site.
Adoption
Josh: Had a call with Etherscan. Someone from Etherscan will attend later calls. Would want to see the EIP finalized before they adopt, and/or want to see significant adoption by major DAOs before they adopt
Zargham: Makes sense. Key is to have the conversation open and make sure we are meeting milestones
Josh: Will follow up in ETH Amsterdam.
Josh: Let’s build more capacity in this group. Making commitments and relationships official,
Zargham: That would make sense, but we need to be clear what needs to get done, instead of simply making contracts. For this, we should identify specific DAOs to confirm reference implementations. Setup marketing campaigning to work on adoption.
Michael: At Aragon, there is a time / uncertainty question. We want to support this standard and we hope that it solidifies, but the question is: is this the stage where it is almost final?
Zargham: This part of the contract that is in the smart contract will not receive much revision. Potentially one more edit.
Z: After that, the deeper logic exists outside of the smart contract
Ido: The main logic of the EIP happens off-chain. One way to go is to have it totally unopionated. Not having any standardization of the off-chain API. But, my sense is that this will not be a good strategy for driving adoption.
Z: The on-chain part is the part that we need to say is not going to change. With the offchain part: we are discovering through our reference implementation and our partners, we are determining what patterns make sense.
Ido: The question is if we, internally, are in a mature place to go to DAOs and say to them, do you want to implement this standard.
Z: We need to do a lifecycle of planning. Is there any kind of ordering required. Who will take ownership of the paths. We need a DAG chart.
Z: We should bring someone in to focus on the social side of adoption (comms, marketing, etc).
Z: Abby is someone that is good at this.
Isaac: A wildfire intern could be good for this. Bring James in for this.
Grants
Review of grants management.
Multichain
Josh: Cosmos Chain - If we could find a way of listing all the Cosmos DAOs alongside the Ethereum DAOs.
Z: We need to standardize the smart contract structure for the EVM to be composable across multiple chains.
Z: Up one level, we would have an interface manager that woul dhave similar affordances. This would be DAOIP one.
Ido: Regarding implementation of the contracts — was there any follow up discussion on the proposal?
Z: There was discussion that some handshake needs to occure to prevent graffiti spamming.
Z: There may be more than one way to do this.
Ido: this is a good question. You can do this graffiti with a lot of other stuff. IT is a philosophical question of whether this matters or not.
Z: Since we are wanting to use this standard to have clarity around DAO discoverability, being able to push a DAO contract on a DAO would defete the purpose of the standard.
Ido: Agree that it is important, but also impirtant for the UX to do it in a way that is not complicated.
Z: If you are doing this with a factory, there should be a way of having the owner sign the DAO URI contract.
Ido: How do we anticipate usage of this? If every time the DAO wants to change the URI, it could mean for the DAO to interact with the factory again. But let’s say the DAO has this contract. Maybe in some use cases, there will be a write to an API that would involve some writing to this contract.
Z: There are two layers of writing: A write to the contract directly, or writing to some method at the offchain level where the API calls the DAO URI
Ido: What are the usecases. One ide: The members being able to write something; take the use case of safe snap, people are writing something offchain, and there is a predefined oracle that moves it onchain. Things in this would might be an example.
Ido: We have a contract that the DAO owns. Are there instances where a DAO would want to update the contract (add fields)
Z: We allow DAOs to do that, because it doesn’t exclude additional information, but there are very few instances where additional information would be necessary and couldn’t just be listed in the off-chain data/schema.
Josh: The question of what gets written to the blockchain is intersting. The on-chain contract includes a little imformation, and the URI offchain setting is where the main information is stored.
Z: Maintaining alignment might be an issue.
Josh: It is marginally easier to have the metadata immediately in the contract, but it doesn’t warrent the extra gas costs
Josh: One more oracle type interactions, this type of information should be another contract.
Z: The Factory could simply be a way of making custom contracts each time they want to publish a contract. The Factory is a DAO publishing mechanism. Similar to on-chain announcements.
Josh: On the factory contract. It would be good to build reference implementations directly into the factory contract. The contract could create the endpoint for them, se if there is an exiting template based on the consumed information, and then create an endpoint based on that.
Ido: Would also be nice to have a viewer for this. For example, a website you can go to and it would be like a DAO explorer.
Keating: The way we are setting things up, DAOHaus will have a factory contract, which is the main entry point for DAOs in the ecosystem. This approach is feasible.
Ido: Here you are talking about new DAOs, but there are also pre-existing DAOs, only to create a contract that is owned by the DAO that points to the URI.
Keating: We are going to push people to migrate from V2 to V3. This will require some type of contract interaction, and that migration can tie into the DAOIP.
Michael: We want to have it in the new iteration of the Aragon framework. Similar to DAOHaus.
Ido: This is also good for off-chain DAOs.
Zoom Chat Transcript