Voyager Identity #9
Last Edited Time
Jun 13, 2022
Created time
May 6, 2022
Participants
Created By
Type
Created
May 6, 2022
Zoom Recording
Property
Property 1
Attendees
- Mendes
- Ryan Gill
- Balazs Nemethi
- Andrei Taranu
- Mateusz Rzeszow
- Pion
- James Brennan
Resources
Meeting Primer
Voyager Identity #5 Meeting Summary
Agenda
- Introductions
from last meeting this is still outsanding
- Bring in Isaac to discuss security issues
Meeting Minutes
Introductions
- James from metagove
- Mat from Polygon
- Pion from Justiceproject
Recapping Membership Primer
- Fernando
- What is the next step with this work?
- Mendes
- recap from the previous meeting
- introducing a scema how the flow of verification would go
- 2-3 dao-s to implement a usecase to test the service
- daostarone could be one potentially
- go into exploring the implementation in IRL between the dao-s
- proposal from last time:
- Josh
- In addition to the three DAO we want to service providers consuming information from each of the three DAO, and a set of users
- Govern and Closer
- A list of users and the DAOs they belong to
- See the IssuerURI as part of:
- James
- questin:
- 100 first users drop their eth address on twitter would work as safelist
- Fernando:
- the issuer (dao) would point to a trusted uri to select the service it will trust for creating safelist
- James
- q: job of the issuer to connect X event to ethereum wallet/address?
- most restrictive: eth address, but it can be extended
- F:
- job of the issuer is to connect address to the
- we might need proxy for the contract
- to verify signed attestation about ownership (in case of onchain asset )
- Andrei:
- using twitter replies as example
- fungibles would not represent membereship?
- but the dao would point to an other resource that might be centralized?
- Why is it better then using offchain service?
- F:
- the twitter is centralized data store usecase but most usecases will likely be onchain related
- checking contract to check attestion allows more composable ruleset
- James
- it means: whitelist power for the dao
- there could be a blacklist too
- gives more power then safelist
- Pion
- what is the essence of issuer?
- can it be a trusted member of a dao
- or it has to be a dao member
- B: we decided earlier that we stay at DAO level to be able to deliver an actual service
- F:
- if you give that power to indiviaudls in a dao then you need to get issuers be available
- this is beyond single individual
- having list of trusted issuers could be useful
- There are 3 daos:
- daostar voyager
- daostar one
- what the contract for each
Usecase exploration here
- Let’s try to set up a real world usecase that might get complicated
- what the attestation
- this topic has been left out for definition later not as part of this process
- first just use the first usecase to break down the IRL issues and keep extending
James
- make is simpler for the API to produce a minimum and then each project can go beyond
- metagov → strike team to host an API
- contract to basically work as a REST API
A:
- would not having the membership mechanism in the credential is basically the same as what’s already on the chain?
M
is there a mechanism for that?
A
- dao tooling uses the contract info
M
- the proposal is to tying attestations to an ethereum address
- privacy question about privacy and richer metadata points
- issue attestations to members will start to get specific
F
- might not want to reveal all the info I have
- I just want to reveal that I meet the requirements and not just
M
- many eth addresses that solve for
- web2 users might not be able to manage the complexity
- use ZK tech to provide soverignity
- identity wallet solves a few problems
James
Discussion on Polygon ID solution around ZK
but claims are still bound to an address, no?