Voyager Identity #11
Last Edited Time
Jun 13, 2022
Created time
May 20, 2022
Participants
Created By
Type
Created
May 20, 2022
Zoom Recording
Property
Property 1
Atendees: Josh T., James Brennen, Cent H., Aaron, Mendes, Pion
Resources
Meeting Primer
Voyager Identity #5 Meeting Summary
Meeting Minutes
We are cutting PII and DSL. We are focusing on how to aggregate data from multiple service providers.
Reviewing the updates to the membership by attestation standard.
Discussion
There are two levels of trust
Is the publication of data synced between two different services?
How are we making updates across data structures?
Could this be a good time to add the DAO standard EIP-4284 and use key matching?
We could say that we need to match using signatures, and use DAO URI as a publishing mechanism.
Josh: The usecase for DAO URI is that there is separate inforamtion about a DAO. It is a minimal attestation from a DAO that says these are a minimal set of URIs that we trust.
M: We are saying here area lit of services that we trust, and can be queeried. Syncing all of these services is not feesible in the short term.
People who want to ue this standard would be able to pick which service providers they want to consume information from. Like schoose your own attestation flavor
M: An example where Josh belongs to three different DAOs. One requires a token, one an NFT, and another with an edgecase (requirement is having received payment in USDC from specomposable cific project). Tried to capture three scenarios. In this case, joshua.eth and josh.eth are the same person but with different ENS, this information wouldn't be properly aggregated.
In this case, if josh uses DisCO, the two .eth addresses can link the two addesses without revealing the link.
See the draft schema.
This requires relaying information across organizations / DAOs.
This produces a composable membership profile
There is a contributions section and a score section for reputation
JB: Re Govrn, does this mean the DAO has a relationship with Govrn, and hey " we want you to regularly update you API" Tell Govrn, here is a formula for calculating contributions.
A: Govrn
JB: It is on the users end to self-report, not the DAO.
A: Govrn is producing the onchain data of contributions.
JB: Thinking about the USDC case, you could look at the treasurey on-chain allocation and that could be a proxey for contribution
A: This is more akin to what you have been "rewarded" on, but this is different from contributions. We are working on a contribution graph that lets you say here are things I have done and either want credit on or reward for. And you can then push that information to a DAO and let the user say I want to be rewarded.
JB: The question is now how automated and streamlined can these be?
A: Depends on what step f automation you are talking about. Working on integarations and rules. For example, if you ever tweet, that is moved to a staging environment, and then you can push that forward on-chain as a social attestation. We do roll ups of attestations based on verification roles.
M: Think of this as a REST API and integrate into each other. This will resutrn specific information from aDAO belongs to and then we can combine them into member profiles. We need to develope the contributions section.
A: We can help with the contributions section. The key thing will be -- most of the metadata will live somewhere else. What happens in the URI can be minimal and can also point to the IPFS record. The only assumption Govrn makes is a privacy concern. Our big asumption is that you make everything public. The metadata can be encrypted and kept private. Once you make a contribution public, that information is public and no longer private.
JT: So we are all on the same page with this basic architecture. Treating it as a communication standard between different service provicders.
JT: How can we start building the standard, use an example service, and make a mockup?
JT: Reviewing the SPecification [link to page]
JT: Will dogfood for the three DAOs from DAO*1.
JT: In the initial phase, having the on-chain is not important. The Data flow is more important.
JT: v0.1 -- See doc
JT: Interested in what it would look like to Govrn to consume DisCO identity resolution.
A: Go to DisCO, and say, here is an address, and be able to learn if there are other linked addresses. And then merge the information from DisCO into Govrn. (potential v0.3)
JB: Question about permenance of attestation. Does DisCO or Govrn forever maintain that inforamtion?
JT: This is where the experation dates come into play. Ownership of wallets can change so identity is not static. It is on the service provider to keep up to date information on them. You are trusting the service provider to keep good records.
PM: Thinking about room for abuse with system. I can register Josh, do nothing in one small DAO, go to this system, and merge me with this Josh.
JT: This is something that DisCO has a defence against. That would be, I assume, through a signing workflow.
A: Would like to see if we can create a standard on how to trustlessly merge identities.
A: Need to better understand the VCs that DisCO is keeping. We would ask (stage for them) the user if they would want to published a linked ID.
JT: Govrn does not allow transfer ID or Profile?
JT: I think it is legitimate to havee multiple wallets within a DAO.
A: We assume that a DAO should only have one wallet per DAO. This is linked to reducing sybil attacks.
JB: If you wanted one person one vote, but also waant tokens. It should be up to a DAOs contract to sort between these two types. Building this standard should be to allow for wide scope, and not create a bottle neck. (This standard could help support this type of functionality).
JT: The gol at this stage is to prove that identity/membership is interoperable.
JT: Going to but Luke on this to engineer the spec.
Reviewing the Specification document