🛠️

Strike Team #24

Last Edited Time
Jun 13, 2022
Created time
May 12, 2022
Participants
Created By
Type
Strike Team
Created
May 12, 2022
Property
Property 1
Attendees: Sam, Michael Heuer, Isaac P, Ido Gershtein, Cent, Joshua Tan, James Brennan, Michael Zargham, Orion Reed
Guests: Mathias
 
AIs
  • Email Nick: Okay things to ask Nick: (1) how can we build on top of ENS + support the standard without making it too dependent & making it a single point of failure?
  • Michael and Isaac connect about things blocking on the implementation of the EIP
    Minutes
    JSON Schema v JSON-LD
    Josh: Are these the same thing?
    Ido: They are different standards
    • JSON Schema is a a standard for validating JSON objects
    • JSON-LD is not a standard for validating JSON objects, but they extend the JSON Schema
      • JSON-LD provides no enforcement of JSON
    Josh: What would we need to have the two standards work together?
    Ido: It would not be so simple to have them play together.
     
    Update from Ido:
    If looking at proposal, there is the calls property.
    A question had when talking with James is, when you go making documentation of a specific object, we will need to define clearly what the required properties are.
    Josh: Can we put up a functioning context file?
    Ido: We have it.
    This is part of what is confusing in the world of JSON-LD
    Josh: Even if there is no need to have something resolvable to for a URI, let’s still resolve to something as a URL
    Ido: We can do this.
    However, we haven’t clearly defined the required properties.
    In the proposal properties in the paper, there are calls, but is that a required property?
    Josh: We don’t need to specify requirements for json-ld context files, rght?
    Ido: That is true, but how do we know if a DAO is properly implementing the standard.
    Josh: To do this, would we need to, in a separate box, indicate which properties are required?
    I have the feeling, the truly enforceable thing will the the interface
    Ido: Yes, you could have a function that scrapes the data, but you need a URI that indicates what properties you need for the object to be defined as valid
    James: One option for now could be to document likely use cases and then see how DAOs use the standard.
    Josh: Persuaded by James.
    Zargham: The enforcement power might emerge by the apps that will consume from the standard
    Let’s imagine you follow the standard to the letter, but not in the spirit
    The consuming software might filter those out
    The application might not see the standard as being valid
    This is a more decentralized approach, that we are not the enforcers
    Josh: We should be clearer about what are SHOULD and MUSTs for the standard
    Zargham: What is the minimum viable registry? We set that. Other apps will draw from that in their interpretation of the standards
    Ido: We used JSON-LD because we were talking about defining, if loosely, an ontology of DAO objects. But, ontology is not a loosely created thing.
    Now we are in this middle space. We were talking about ontologies, but in the same breath we are not defining anything
    Zargham: Is part of that because we haven’t been prescriptive enough in the language?
    Ido: The way to do it striktly would be to define the ontology objects clearly.
    Zargham: Should we do that in the future? We had to get something done.
    James: My understanding of the middle ground. Defining an ontology doesn’t require strick definition. We can at the very least name the things that DAOs would be using. Rather than being an enforcer we can say that there are different types.
     
    Isaac Update on the spec
    Have added to the working copy of the EIP
    Do we want to enforce that every DAO uses an external contract? Are DAOs able to inherit as well?
    Zargham: Yes, that is fine.
    Isaac: Added language to say that a DAO MAY inherit the standard interface or MAY create an external registration contract.
    Isaac: Is there any case where we would want the registration contract to have a mapping between the daoAddress and daoRegisterd?
    Or, we could have it that two separate addresses point to the same URI?
    Josh: I can imagine cases where people would want to do two separate daoRegistration addresses
    This idea makes sense.
    Sam: You might think about building this on top of ENS
    Zargham: Hesitant to build ontop of ENS, but interested in having them complementary
    James: an ENS might help with spoofing and spam
    Zargham: What if we made it so ... how could we make the registration contract of our standard the registrant to the ENS. Creating a triangle between the ENS, the DAO address, and the standard.
    Ido: What do you achieve that you dont already get with ENS?
    Zargham: Separation of power.
    There is also a difference in building on ENS the project, and composing with the EIP-137 standard
    James: If we build into this, we can use this to have multiple registrations at once
    Zargham: This would move towards DAO identity resolution
    Josh: Have been in touch with Nick Johnson. Can we invite him or someone from ENS to have a conversation with us about integrating our EIP with EIP 137 or 634
    Zargham: We don’t want to over lever the ENS protocol as it makes it a point of centralized failure
    Ido: The point of working with ENS is the simplicity you get with it.
     
    Michael Heuer Discussion:
    There are questions about how to implement this standard in a decentralized way
    Isaac: The loose definition of membership is baked into the fact that the URI can be whatever you want
    Similarly trying to figure out the best way to stich this all together.
    Josh: One part is the hosting of these APIs.
    The original idea was that DAOs would own their own APIs
    They could use a DAOstar hosted service
    The thing to emphasze is some notion of better governance than what we think about when we think about AWS
    Michael: It would be good to have best practice examples for people on how this could look.
    Josh: To be clear are you talking about best practices for having an API data workflow.
     
     
    🛠️

    Strike Team #24

    Last Edited Time
    Jun 13, 2022
    Created time
    May 12, 2022
    Participants
    Created By
    Type
    Strike Team
    Created
    May 12, 2022
    Property
    Property 1
    Attendees: Sam, Michael Heuer, Isaac P, Ido Gershtein, Cent, Joshua Tan, James Brennan, Michael Zargham, Orion Reed
    Guests: Mathias
     
    AIs
    • Email Nick: Okay things to ask Nick: (1) how can we build on top of ENS + support the standard without making it too dependent & making it a single point of failure?
    • Michael and Isaac connect about things blocking on the implementation of the EIP
      Minutes
      JSON Schema v JSON-LD
      Josh: Are these the same thing?
      Ido: They are different standards
      • JSON Schema is a a standard for validating JSON objects
      • JSON-LD is not a standard for validating JSON objects, but they extend the JSON Schema
        • JSON-LD provides no enforcement of JSON
      Josh: What would we need to have the two standards work together?
      Ido: It would not be so simple to have them play together.
       
      Update from Ido:
      If looking at proposal, there is the calls property.
      A question had when talking with James is, when you go making documentation of a specific object, we will need to define clearly what the required properties are.
      Josh: Can we put up a functioning context file?
      Ido: We have it.
      This is part of what is confusing in the world of JSON-LD
      Josh: Even if there is no need to have something resolvable to for a URI, let’s still resolve to something as a URL
      Ido: We can do this.
      However, we haven’t clearly defined the required properties.
      In the proposal properties in the paper, there are calls, but is that a required property?
      Josh: We don’t need to specify requirements for json-ld context files, rght?
      Ido: That is true, but how do we know if a DAO is properly implementing the standard.
      Josh: To do this, would we need to, in a separate box, indicate which properties are required?
      I have the feeling, the truly enforceable thing will the the interface
      Ido: Yes, you could have a function that scrapes the data, but you need a URI that indicates what properties you need for the object to be defined as valid
      James: One option for now could be to document likely use cases and then see how DAOs use the standard.
      Josh: Persuaded by James.
      Zargham: The enforcement power might emerge by the apps that will consume from the standard
      Let’s imagine you follow the standard to the letter, but not in the spirit
      The consuming software might filter those out
      The application might not see the standard as being valid
      This is a more decentralized approach, that we are not the enforcers
      Josh: We should be clearer about what are SHOULD and MUSTs for the standard
      Zargham: What is the minimum viable registry? We set that. Other apps will draw from that in their interpretation of the standards
      Ido: We used JSON-LD because we were talking about defining, if loosely, an ontology of DAO objects. But, ontology is not a loosely created thing.
      Now we are in this middle space. We were talking about ontologies, but in the same breath we are not defining anything
      Zargham: Is part of that because we haven’t been prescriptive enough in the language?
      Ido: The way to do it striktly would be to define the ontology objects clearly.
      Zargham: Should we do that in the future? We had to get something done.
      James: My understanding of the middle ground. Defining an ontology doesn’t require strick definition. We can at the very least name the things that DAOs would be using. Rather than being an enforcer we can say that there are different types.
       
      Isaac Update on the spec
      Have added to the working copy of the EIP
      Do we want to enforce that every DAO uses an external contract? Are DAOs able to inherit as well?
      Zargham: Yes, that is fine.
      Isaac: Added language to say that a DAO MAY inherit the standard interface or MAY create an external registration contract.
      Isaac: Is there any case where we would want the registration contract to have a mapping between the daoAddress and daoRegisterd?
      Or, we could have it that two separate addresses point to the same URI?
      Josh: I can imagine cases where people would want to do two separate daoRegistration addresses
      This idea makes sense.
      Sam: You might think about building this on top of ENS
      Zargham: Hesitant to build ontop of ENS, but interested in having them complementary
      James: an ENS might help with spoofing and spam
      Zargham: What if we made it so ... how could we make the registration contract of our standard the registrant to the ENS. Creating a triangle between the ENS, the DAO address, and the standard.
      Ido: What do you achieve that you dont already get with ENS?
      Zargham: Separation of power.
      There is also a difference in building on ENS the project, and composing with the EIP-137 standard
      James: If we build into this, we can use this to have multiple registrations at once
      Zargham: This would move towards DAO identity resolution
      Josh: Have been in touch with Nick Johnson. Can we invite him or someone from ENS to have a conversation with us about integrating our EIP with EIP 137 or 634
      Zargham: We don’t want to over lever the ENS protocol as it makes it a point of centralized failure
      Ido: The point of working with ENS is the simplicity you get with it.
       
      Michael Heuer Discussion:
      There are questions about how to implement this standard in a decentralized way
      Isaac: The loose definition of membership is baked into the fact that the URI can be whatever you want
      Similarly trying to figure out the best way to stich this all together.
      Josh: One part is the hosting of these APIs.
      The original idea was that DAOs would own their own APIs
      They could use a DAOstar hosted service
      The thing to emphasze is some notion of better governance than what we think about when we think about AWS
      Michael: It would be good to have best practice examples for people on how this could look.
      Josh: To be clear are you talking about best practices for having an API data workflow.