DAOstar One (Internal)
DAOstar One (Internal)
/
🛠️
Strike Team #11
🛠️

Strike Team #11

Last Edited Time
Apr 27, 2022
Created time
Jan 27, 2022
Participants
Created By
Type
Strike Team
Created
Jan 27, 2022
Zoom Recording
Property
Property 1
Attendees: 🌹 Josh, Eyal, Ido, Zargham, Selim, Lucia
Guests: Chris and David from Lit Protocol
Zoom video: https://stanford.zoom.us/rec/share/Wo-q1sjt3BhHNFFtmnItsivNJWBfiMwklliretBpQKfJBV2D5gk12sDkmbhiwI7w.KKSq0X0kT3iYujct
Goals
  • We’ll talk about the on-chain internal execution use-case (execution simulation)
  • We’ll talk about the off-chain binding execution use-case, with input from David and Chris here from Lit Protocol
  • Go over the previous to-dos from last week.
  • InteractionsURI
  • Finalize decision re: on-chain events for proposals
Decisions
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
2. 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.
  1. The framework is, roughly:
    1. The default proposal is to have no on-chain implementation, just proposalsURI.
  1. 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...
  1. Are there important use-cases, e.g. DAO2DAO use-cases, conditional proposals, subDAOs, etc. that we could support if we standardized some on-chain aspect? If not, stick with default.
    1. Three buckets to organize use-cases: (1) use-cases relevant to all DAOs, irrespective of on- or off-chain, (2) use-cases relevant to all on-chain DAOs on EVM, (3) use-cases relevant to various sub-flavors of EVM DAOs, e.g. Aragon, Moloch, etc.
  1. For whatever on-chain aspect we want to standardize above (whether just events or the entire proposal object), are we “going too far” by standardizing an aspect of DAO governance, which we don’t want to standardize? If so, stick with default.
  1. Can these use-cases be better supported by editing or enriching the proposalsURI, ref. long discussion on providing documentation of the proposal events ABI + modeling state transitions? If yes, stick with default.
  1. Off-chain binding use-case (from Chris + David).
    1. Presentation on Lit Protocol. Credentialing in some Web2 system via a Web3 tie-in.
    2. Michael: relates closely to the previous discussion aroudn waht the assets are. In this case, the “resource” lives off-chain and the proposal is giving the list of addresses with resource rights.
    3. Eyal: idea of membership comes with some affordances.
    4. David: to us, we want to standardize an ACL contract
    5. Ido: I think this supports a good integration with Lit Protocol, and that’s what I would want to be able to do.
    6. Chris: just thinking about it, where the data lives, we can easily support that for credentialing
    7. David: we’ve done with an integration with the POAP token for this. Example implementation.
    8. Zargham: This makes me think we should consider the entity resources in our entity model, and think treasury as a special case as well as this as a special case. but not sure if its realistic in our EIP
  1. Lucia: preview of the contract structures, support comparison.
Minutes from last time
  1. Decision: we decided to host JSON-LD schema files in-line inside the EIP (rather than host it somewhere, e.g. at schema.org).
  1. 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.
    1. The framework is, roughly:
      1. The default proposal is to have no on-chain implementation, just proposalsURI.
      2. 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.
      3. Are there important use-cases, e.g. DAO2DAO use-cases, conditional proposals, subDAOs, etc. that we could support if we standardized some on-chain aspect? If not, stick with default.
        1. Three buckets to organize use-cases: (1) use-cases relevant to all DAOs, irrespective of on- or off-chain, (2) use-cases relevant to all on-chain DAOs on EVM, (3) use-cases relevant to various sub-flavors of EVM DAOs, e.g. Aragon, Moloch, etc.
      4. For whatever on-chain aspect we want to standardize above (whether just events or the entire proposal object), are we “going too far” by standardizing an aspect of DAO governance, which we don’t want to standardize? If so, stick with default.
      5. Can these use-cases be better supported by editing or enriching the proposalsURI, ref. long discussion on providing documentation of the proposal events ABI + modeling state transitions? If yes, stick with default.
    2. Josh: here are some arguments for on-chain standardization of events
      1. it’s already happening
      2. hypothesis supports certain, more rigorous use-cases
    3. Zargham: It’s tricky to standardize proposal events without standardizing the states!
    4. Zargham: can we make sure that on-chain proposal events are consistent with the proposal schema from proposalsURI. Want to make sure our concepts are not bound to Ethereum. Suppose a proposal is transitioning states. You can’t standardize the events in a tight way.
      1. +1 Sam
    5. Sam: we should standardize a state property to each proposal.
      1. Ido: what we already have is compatible with this view, we have a proposal with a property called state, and the state itself is a complex object, which can be empty.
      2. Isaac: so in proposalsURI, these are the states, and this is the ABI to parse our events?
    6. Zargham: have a base proposal type, that could get extended to an event-emitting stateful proposal.
      1. +1 Selim
      2. You have a Cartesian product of proposal state spaces! Could be a pretty clean way of supporting extensions to inter-DAO proposals?
      3. Conclusion: we should standardize a “vanilla_proposal” as as well as one proposal_type (aka process_type), “stateful_proposal”. We should define a non-opinionated approach to defining proposal types.
    7. Isaac: the URI could have more information about the ABIs to help people read and interpret the on-chain events.
      1. Have a base proposalURI with one stateful extension; i.e. the root proposal does not assume anything, it’s a very clean proposal object. But most of us here will probably use the stateful extension, which will define the on-chain state transitions through events.
      2. Will it define the possible states of the proposal or will it also define the transitions between states?
      3. Double-indexed structure: for any state transition that is possible.
    8. Eyal: in the version of the standard as it is, you just have to put a URI there and do nothing, so I don’t understand the value of it as is. It looks like we’re just pushing the actual standard into another schema. What if someone just gives an empty object for the URI?
      1. Zargham: you can compute over the information they post.
      2. Eyal: but if the standard is going to be useful, people have to be able to interact or communicate with that DAO that . So if I try to communicate with the DAO. They put something on their site that I qualify for the standard, and people are going to try to communicate.
      3. Eyal: what if someone messes with their URI?
      4. Isaac: plenty of ways of making sure things are immutable without having them stored on-chain.
    9. Sam: we should use ERC-165 and define an interface standard identifier so people can verify that it’s following the standard.
      1. Isaac: we could combine an extension of the base proposal type has these nodes, these events, AND supports these ERC-165 interfaces. Suppose some aggregator, how do I interact with this DAO beyond discovering it. I see it’s a type of DAO that in, with a vote button, with an execute button. The mapping from the on-chain objects to the JSON-LD can be very strange. You put the ABI and ERC-165 interfaces into that context?
  1. Sam: should we standardize the URI and where it should live?
    1. Josh: plans for DAOstar.org endpoint hosting service, but don’t think we should standardize it.
  1. Ido: the interesting events will come from standardizing the proposal objects yourself, they will NOT come from standardizing the proposal events.
  1. Decision: should we standardize a set of states or just say, there should be a state property. Conclusion: we should include a set of default states, but note that it can be (1) empty, and (2) extended.
    1. Sam: we should have a set of standardized states, not just a state property, every proposal needs to have a state type of one sort.
    2. Eyal: not many people specify state! For communication with other DAOs, I want to plug into this proposal, I would want to understand the actual process (i.e. transitions), but this process is very very different between different frameworks, and can get very very complex.
  1. Decision: should we standardize not only states, but state transitions? Leaning: no.
    1. Ido: this gets us into describing the governance of the organization
    2. Zargham: but i just want to give them a standard language to understand the meaning of the governance! we’re not.
    3. Sam: this is a huge topic.
  1. interactionsURI:
Action items
See top of EIP doc for remaining to-dos before Feb. 2.
Previous Items
Josh + Isaac: Membership
Ido: Proposals
 
 
DAOstar One (Internal)
DAOstar One (Internal)
/
🛠️
Strike Team #11
🛠️

Strike Team #11

Last Edited Time
Apr 27, 2022
Created time
Jan 27, 2022
Participants
Created By
Type
Strike Team
Created
Jan 27, 2022
Zoom Recording
Property
Property 1
Attendees: 🌹 Josh, Eyal, Ido, Zargham, Selim, Lucia
Guests: Chris and David from Lit Protocol
Zoom video: https://stanford.zoom.us/rec/share/Wo-q1sjt3BhHNFFtmnItsivNJWBfiMwklliretBpQKfJBV2D5gk12sDkmbhiwI7w.KKSq0X0kT3iYujct
Goals
  • We’ll talk about the on-chain internal execution use-case (execution simulation)
  • We’ll talk about the off-chain binding execution use-case, with input from David and Chris here from Lit Protocol
  • Go over the previous to-dos from last week.
  • InteractionsURI
  • Finalize decision re: on-chain events for proposals
Decisions
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
2. 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.
  1. The framework is, roughly:
    1. The default proposal is to have no on-chain implementation, just proposalsURI.
  1. 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...
  1. Are there important use-cases, e.g. DAO2DAO use-cases, conditional proposals, subDAOs, etc. that we could support if we standardized some on-chain aspect? If not, stick with default.
    1. Three buckets to organize use-cases: (1) use-cases relevant to all DAOs, irrespective of on- or off-chain, (2) use-cases relevant to all on-chain DAOs on EVM, (3) use-cases relevant to various sub-flavors of EVM DAOs, e.g. Aragon, Moloch, etc.
  1. For whatever on-chain aspect we want to standardize above (whether just events or the entire proposal object), are we “going too far” by standardizing an aspect of DAO governance, which we don’t want to standardize? If so, stick with default.
  1. Can these use-cases be better supported by editing or enriching the proposalsURI, ref. long discussion on providing documentation of the proposal events ABI + modeling state transitions? If yes, stick with default.
  1. Off-chain binding use-case (from Chris + David).
    1. Presentation on Lit Protocol. Credentialing in some Web2 system via a Web3 tie-in.
    2. Michael: relates closely to the previous discussion aroudn waht the assets are. In this case, the “resource” lives off-chain and the proposal is giving the list of addresses with resource rights.
    3. Eyal: idea of membership comes with some affordances.
    4. David: to us, we want to standardize an ACL contract
    5. Ido: I think this supports a good integration with Lit Protocol, and that’s what I would want to be able to do.
    6. Chris: just thinking about it, where the data lives, we can easily support that for credentialing
    7. David: we’ve done with an integration with the POAP token for this. Example implementation.
    8. Zargham: This makes me think we should consider the entity resources in our entity model, and think treasury as a special case as well as this as a special case. but not sure if its realistic in our EIP
  1. Lucia: preview of the contract structures, support comparison.
Minutes from last time
  1. Decision: we decided to host JSON-LD schema files in-line inside the EIP (rather than host it somewhere, e.g. at schema.org).
  1. 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.
    1. The framework is, roughly:
      1. The default proposal is to have no on-chain implementation, just proposalsURI.
      2. 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.
      3. Are there important use-cases, e.g. DAO2DAO use-cases, conditional proposals, subDAOs, etc. that we could support if we standardized some on-chain aspect? If not, stick with default.
        1. Three buckets to organize use-cases: (1) use-cases relevant to all DAOs, irrespective of on- or off-chain, (2) use-cases relevant to all on-chain DAOs on EVM, (3) use-cases relevant to various sub-flavors of EVM DAOs, e.g. Aragon, Moloch, etc.
      4. For whatever on-chain aspect we want to standardize above (whether just events or the entire proposal object), are we “going too far” by standardizing an aspect of DAO governance, which we don’t want to standardize? If so, stick with default.
      5. Can these use-cases be better supported by editing or enriching the proposalsURI, ref. long discussion on providing documentation of the proposal events ABI + modeling state transitions? If yes, stick with default.
    2. Josh: here are some arguments for on-chain standardization of events
      1. it’s already happening
      2. hypothesis supports certain, more rigorous use-cases
    3. Zargham: It’s tricky to standardize proposal events without standardizing the states!
    4. Zargham: can we make sure that on-chain proposal events are consistent with the proposal schema from proposalsURI. Want to make sure our concepts are not bound to Ethereum. Suppose a proposal is transitioning states. You can’t standardize the events in a tight way.
      1. +1 Sam
    5. Sam: we should standardize a state property to each proposal.
      1. Ido: what we already have is compatible with this view, we have a proposal with a property called state, and the state itself is a complex object, which can be empty.
      2. Isaac: so in proposalsURI, these are the states, and this is the ABI to parse our events?
    6. Zargham: have a base proposal type, that could get extended to an event-emitting stateful proposal.
      1. +1 Selim
      2. You have a Cartesian product of proposal state spaces! Could be a pretty clean way of supporting extensions to inter-DAO proposals?
      3. Conclusion: we should standardize a “vanilla_proposal” as as well as one proposal_type (aka process_type), “stateful_proposal”. We should define a non-opinionated approach to defining proposal types.
    7. Isaac: the URI could have more information about the ABIs to help people read and interpret the on-chain events.
      1. Have a base proposalURI with one stateful extension; i.e. the root proposal does not assume anything, it’s a very clean proposal object. But most of us here will probably use the stateful extension, which will define the on-chain state transitions through events.
      2. Will it define the possible states of the proposal or will it also define the transitions between states?
      3. Double-indexed structure: for any state transition that is possible.
    8. Eyal: in the version of the standard as it is, you just have to put a URI there and do nothing, so I don’t understand the value of it as is. It looks like we’re just pushing the actual standard into another schema. What if someone just gives an empty object for the URI?
      1. Zargham: you can compute over the information they post.
      2. Eyal: but if the standard is going to be useful, people have to be able to interact or communicate with that DAO that . So if I try to communicate with the DAO. They put something on their site that I qualify for the standard, and people are going to try to communicate.
      3. Eyal: what if someone messes with their URI?
      4. Isaac: plenty of ways of making sure things are immutable without having them stored on-chain.
    9. Sam: we should use ERC-165 and define an interface standard identifier so people can verify that it’s following the standard.
      1. Isaac: we could combine an extension of the base proposal type has these nodes, these events, AND supports these ERC-165 interfaces. Suppose some aggregator, how do I interact with this DAO beyond discovering it. I see it’s a type of DAO that in, with a vote button, with an execute button. The mapping from the on-chain objects to the JSON-LD can be very strange. You put the ABI and ERC-165 interfaces into that context?
  1. Sam: should we standardize the URI and where it should live?
    1. Josh: plans for DAOstar.org endpoint hosting service, but don’t think we should standardize it.
  1. Ido: the interesting events will come from standardizing the proposal objects yourself, they will NOT come from standardizing the proposal events.
  1. Decision: should we standardize a set of states or just say, there should be a state property. Conclusion: we should include a set of default states, but note that it can be (1) empty, and (2) extended.
    1. Sam: we should have a set of standardized states, not just a state property, every proposal needs to have a state type of one sort.
    2. Eyal: not many people specify state! For communication with other DAOs, I want to plug into this proposal, I would want to understand the actual process (i.e. transitions), but this process is very very different between different frameworks, and can get very very complex.
  1. Decision: should we standardize not only states, but state transitions? Leaning: no.
    1. Ido: this gets us into describing the governance of the organization
    2. Zargham: but i just want to give them a standard language to understand the meaning of the governance! we’re not.
    3. Sam: this is a huge topic.
  1. interactionsURI:
Action items
See top of EIP doc for remaining to-dos before Feb. 2.
Previous Items
Josh + Isaac: Membership
Ido: Proposals
 
Â