🛠️

Strike Team #13

Last Edited Time
Apr 27, 2022
Created time
Feb 10, 2022
Participants
Created By
Type
Strike Team
Created
Feb 10, 2022
Zoom Recording
Property
Property 1
Attendees: 🌹 Isaac, Zargham, Ido, Josh, Eyal
Observers: John D. Storey
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.
  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.
Action items
See top of EIP doc for remaining to-dos before Feb. 2.
Previous Items
Josh + Isaac: Membership
Ido: Proposals
 
Zoom chat
10:07:38 From Joshua Tan to Everyone: Draft standard: https://www.notion.so/daostar/EIP-1234-Decentralized-Autonomous-Organizations-2e426a37e8be436f82fc876b89df2a01#5c275008f301454bb877cf5b10612edf 10:08:25 From Joshua Tan to Everyone: Minutes for today: https://www.notion.so/daostar/Strike-Team-12-d9214cf6685d436abfc320234d5f294d 10:11:10 From Michael Zargham to Everyone: legibility 10:17:23 From sam to Everyone: And in the worst case there is still the power of anon accounts haha :D 10:21:20 From idogershtein to Everyone: brb 10:50:35 From Michael Zargham to Everyone: +1 10:50:56 From Joshua Tan to Everyone: https://github.com/thelastjosh/govbase/tree/master/documents/constitutions 10:59:40 From Michael Zargham to Everyone: I was speaking with the RMIT folks (Jason Potts and Chris Berg) about “data governance of governance data” yesterday — that’s basically what we’re discussing — assuming you track changes to these URIs over time 11:00:51 From sam to Everyone: Anarchy can be a form of governance ;) 11:02:55 From Isaac P to Everyone: Have to drop, will follow up in tg 11:05:59 From sam to Everyone: I’m good with Ido’s approach👍🏻
🛠️

Strike Team #13

Last Edited Time
Apr 27, 2022
Created time
Feb 10, 2022
Participants
Created By
Type
Strike Team
Created
Feb 10, 2022
Zoom Recording
Property
Property 1
Attendees: 🌹 Isaac, Zargham, Ido, Josh, Eyal
Observers: John D. Storey
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.
  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.
Action items
See top of EIP doc for remaining to-dos before Feb. 2.
Previous Items
Josh + Isaac: Membership
Ido: Proposals
 
Zoom chat
10:07:38 From Joshua Tan to Everyone: Draft standard: https://www.notion.so/daostar/EIP-1234-Decentralized-Autonomous-Organizations-2e426a37e8be436f82fc876b89df2a01#5c275008f301454bb877cf5b10612edf 10:08:25 From Joshua Tan to Everyone: Minutes for today: https://www.notion.so/daostar/Strike-Team-12-d9214cf6685d436abfc320234d5f294d 10:11:10 From Michael Zargham to Everyone: legibility 10:17:23 From sam to Everyone: And in the worst case there is still the power of anon accounts haha :D 10:21:20 From idogershtein to Everyone: brb 10:50:35 From Michael Zargham to Everyone: +1 10:50:56 From Joshua Tan to Everyone: https://github.com/thelastjosh/govbase/tree/master/documents/constitutions 10:59:40 From Michael Zargham to Everyone: I was speaking with the RMIT folks (Jason Potts and Chris Berg) about “data governance of governance data” yesterday — that’s basically what we’re discussing — assuming you track changes to these URIs over time 11:00:51 From sam to Everyone: Anarchy can be a form of governance ;) 11:02:55 From Isaac P to Everyone: Have to drop, will follow up in tg 11:05:59 From sam to Everyone: I’m good with Ido’s approach👍🏻