Strike Team #8
Last Edited Time
Apr 27, 2022
Created time
Jan 6, 2022
Participants
Created By
Type
Created
Jan 6, 2022
Zoom Recording
Property
Property 1
Attendees: 🌹 Josh, 🍫 Ido, ⚫ Zargham, 🎆 Isaac, Dennison
Observers: Lucia (Metagov)
Â
Goals
- Review current EIP
Minutes
Membership
- Dennison: is it a problem that this off-chain membership URI may not be synced with the on-chain representation?
- Isaac: it’s intended to be used more for indexing, not from other smart contracts. Not being synced could be a problem, but I think there the onus should be on building good demo implementations
- Zargham: yeah
- Dennison: seems really useful, definitely agree that there are members of DAOs that don’t hold any tokens. Think there’s now a need for understanding the best off-chain approaches that go beyond indexing, e.g. crawling IPFS as well?
- Decison: JSON-LD vs JSON [result: go with JSON-LD]
- Josh: multi-chain vs EVM issue
- Zargham: I want this as long as it’s feasible
- Ido: but defining the context can also be hard, and we need to create + host this context
- Isaac: we would need to define this anyways
- Zargham: for my use-case, I would need to use GitHub context, but I still have an Ethereum Aragon DAO holding the money, so in that case I would really want to use the GitHub identities...
- Ido: Do we want DAOs to edit these schema files as well?
- Z: Only a half-dozen or so relevant contexts today for DAOs. For Ethereum, for GitHub, Discord IDs, etc.
- J:
- Z: There are some use-cases, but there are immediate duplication of , so it’s not a great unique ID.
- Dennison: +1 on JSON-LD.
- Decision: optional fields for members? [result: let’s encourage people to add additional fields such as “details”, ____, ____, etc. ... The standard does not exclude other fields. People can extend the root schemas we implement at daostar.org.]
- Ido: e.g. not necessarily boolean membership. Can support somehow?
- Z: +1, e.g. what if there are multiple membership URIs?
- Z: moment we go down to details, the details can vary widely
Proposals
- Decision: model executionEVMdata as external call? [yes]
- Z: modeling as external call is okay. external calls are still state dependent. DO see a lot of use-cases.
- Decision: remove choices, selectedChoices, status, “startedAt”, “scheduledEnd”, “EndedAt”, and we’ll mention these in the discussion section even if they don’t rise to the level of something we want to standardize. [yes]
- Josh: let’s remove them.
- Z: we can remove these but add ability to extend using the schema.
- Decision: we should implement an “eventsURI” rather than impose standardization directly on the events that DAOs emit
- Josh: we should standardize some of these events, especially interactions between members and proposals
- Z: we should take the URI approach, more consistent with the rest of the document. Feel like standardizing events would be an overreach here.
- Ido: +1 we should do this downstream, just require that DAOs emit this eventsURI. It would be more useful to standardize teh on-chain form of proposals than the events. Standardizing the events has less use-cases.
- Decision: should we just unify all the URIs?
- Isaac: yes
- Z: yes, seems like it could be nice
- Josh: no, what about modularity
- Isaac: we could do the default implementation via a splitter, where you think of the top daoURI idea as an API of sorts. Largely static file that serves as the API to the other URIs. Follows the approach that NFTs use in any case, so familiar to the ecosystem.
Action items
Create root schemas for Member, DAO, Proposal that people can fork?
Previous Items
Josh + Isaac: Membership
Ido: Proposals
Â
Â