Goals

See to-dos on draft standard doc.

Decisions

Decision: change interactionsURI to activityLogURI

Decision: change constitutionURI to governanceURI, ________

From last time:

Decision: we decided to host JSON-LD schema files in-line inside the EIP rather than host it somewhere, e.g. at schema.org or daostar.org.

Decision: we decided to implement not only a state property for proposals but to add a standard set of states, but note (1) that the proposal state can be empty and (2) the proposal property can be extended with other states.

Minutes

“Less optional” fields
“More optional” fields
- Alex Kampas recommendation: use an “opt-_____” description to indicate it is optional?
- Zargham: you could also append a specific “opt” type. Does JSON-LD support this kind of “optional” note directly in the type.
Proposal: rename constitutionURI to governanceURI OR descriptionURI.
Proposal: encourage people to include additional metadata under a “metadata” or “properties” description, governanceURI. Plus a description of the use-case. Make sure to give SOME guidance.

Minutes from last time

Discussion: should we standardize some on-chain aspect of proposals, e.g. events? Decision: no decision yet. We laid out some a framework for making our decision, but we decided we need to see more concrete example implementations, e.g. with Moloch, before we can really resolve the questions raised.

The framework is, roughly:
1. The default proposal is to have no on-chain implementation, just proposalsURI.
Is it bad that we’re not standardizing any on-chain behavior? If not, stick with default.
1. Reasons why it could be bad: people might supply empty URIs but still call themselves DAOs.
2. Ido: what cool use-cases are we missing? Just standardizing things for the sake of standardizing things is NOT good!
3. Eyal: you have. Spoke to a couple of Solana projects implementing their own DAOs, and they put EVERYTHING on-chain, including discussions. Right now, we’re waving the white flag and putting nothing on-chain. Seems bizarre to me.
4. Ido: right now, we’re focusing on DAO orientation and discovery.
5. Ido: I do agree that if we want to standardize anything on-chain, we should be standardizing the proposal object.
6. Michael: standardization of the proposal object the “belongs in a contextual way”.
7. Eyal: I would like to look at use-cases with on-chain binding execution
8. Josh: even if not all proposals are on-chain, there must be SOME proposals that are on-chain
9. Josh: abstract class for the future of the internet vs this is an EIP for Ethereum
10. Michael: we should prioritize “thinnest possible version”
11. Eyal: you have to include assets in any discussion about the DAO, because without it you’re just left with governance, and we don’t want to standardize that. A DAO is a connection between assets / treasury and governance. We have 1000s of DAOs in DeepDAO with no real on-chain governance. So let’s make sure there is some stuff related to on-chain actions.
12. Michael: okay, let’s then dig in and subspecialize to Ethereum, and say that you need to have proposal objects that live on-chain. And to be clear,
  1. +1 eyal, selim, Josh
13. Eyal: we need an abstract class on assets!!! then we can go forward on substandardizing assets.
  1. Selim: would say no to this...