Strike Team #24
Last Edited Time
Jun 13, 2022
Created time
May 12, 2022
Participants
Created By
Type
Created
May 12, 2022
Zoom Recording
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.