DAOstar One (Internal)
DAOstar One (Internal)
/
🚀
Voyager Identity #4
/
Meeting Primer

Meeting Primer

Attestation framework
Content framework
1. Group Membership
2. Proof of Action
3. Metrics
Combining both frameworks
Discussion primer
Related Threads
 
Attestation framework
Previous framework on data sources from Voyager #3:
  • data from self
  • data from DAO
  • data from DAO peers
  • data from services
The above explores different classifications of how data is generated, not on the actual content.
 
Today, we are looking to focus discussion on the actual content we have in mind, separate from its lifecycle. This document is an effort to articulate examples of this content, offer abstractions, and guide us towards selecting a well-scoped starting point for our working group to find alignment on.
 
Content framework
Through observations across the DAO ecosystem, I see 3 common patterns:
  1. Group Membership: “I am a part of this group”
  1. Proof of Action: “I did this thing”
  1. Metrics: “I did/have/own X things”
 
1. Group Membership
  • base level is an organization
    • I work at Developer DAO
  • often include subsets of the organization
    • I work in the Marketing Guild in Developer DAO (”guild” example)
    • I work on the Product Team at FWB (”project” example)
  • timestamps showing start/end of involvement
 
2. Proof of Action
  • demonstrate action through something tangible service provided or artifact created
  • typically involves a reference to data residing in another service
    • www.github.com/pr/abc123
    • www.mirror.xyz/post/abc123
  • timestamp(s)
  • self-attestations typically include a high-level description of the work
    • “I built a smart contract that does X, Y, and Z”
 
3. Metrics
  • can be an aggregation of contributions
    • number of commits, number of deals sourced
  • token holdings
    • I hold 75 $FWB
  • numbers generated through other methods, e.g. “skill/reputation score”
 
🚧
One can notice that taking a more abstract approach to “Proof-of-Action” can satisfy all the outlined categories and that DID/VCs advocate for this model. Most things enumerated above can be expressed as a Verified Credential or an aggregation of VCs. I am writing this here so we can recognize it and move on; this is a framework of content, not infrastructure or mechanism.
 
Combining both frameworks
Now combining both categorization systems, here are some examples of how one could organize identity-centric information in a matrix with explicit references to some of the organizations in Voyager.
 
AttestationGroup MembershipProof of ActionMetric
SelfLinkedIn: I work for my orgLinkedIn: I did X for my orgă…¤
DAOStation: I hold my org’s NFT/VCPOAP: I hold my org’s X POAP Mirror: I made X blog postSuperDAO: I have been a member for Y time
Peeră…¤Dework: X person approves I did Y taskCoordinape: I received X $GIVE
ServicekycDAO: I verified my government ID Discord: I’m in X server with Y roleWonderverse: I did X task Sismo: I own X badge Github: I made X commit on Y repoDeepSkills: I have X value on Y skill Twitter: I have X followers [smart contract]: I hold X $TOKEN
(I hope it goes without saying that these are likely simplifications of what each of our orgs do, but this is just to demonstrate the framing with some base fidelity.)
 
Discussion primer
After exploding this matrix and highlighting some of our differences, one might say we’re poised to struggle finding much common ground because we are all doing different things. To take a step back, we are here to foster interoperability of our ecosystem.
  • we can’t foster interoperability if we can’t come to some agreement on how we want to structure data
  • we are less likely to come to this agreement if we have too large of scope
  • as it stands right now, the matrix above is too large and needs serious scope reduction
 
To focus our group, Josh and Balazs offer these questions:
  • what is the smallest unit of value we can agree on and make a collective proposal from DAOStar One?
  • where can we start that best positions us to continue defining more ecosystem standards?
 
One intuition for the above questions from the original document: “How does identity work within DAOs?”.
  • within DAOs → start by agreeing on how we want members to represent their DAOs
  • somewhat of the reverse of what EIP-4824 does with membersURI for DAOs
  • starting with organization membership is a natural beginning to other important data that we collectively find valuable
    • what sub-organizations is this person a member of?
    • what work has this person done within the organization?
    • what do other people in this organization have to say about this person?
 
đź’ˇ
How might we share interfaces for reading each other’s data about which organizations a person is a part of?
 
Regardless of if you put a URI on-chain, on a registry, or point to your API, some URI somewhere will return me data about a person when I request it. If that URI is to contain the organization-membership knowledge, let’s agree on what we want that format to look like.
 
đź’ˇ
Side question: is there an opportunity to leverage DAOStar One’s already-released DAO metadata standard, EIP-4824?
 
The EIP-4824 DAO JSON-LD Schema:
Conversation starter for a Member schema:
 
Related Threads
  • If we have the basis of defining organization membership, how can we guide ourselves to reuse each others data? How can we work towards a world where I define I contributed to DAOStar in platform X and it automatically shows when I go to platform Y? How do different infrastructure choices impact this ability to import each others’ data?
    • For example, Station is pursuing membership NFTs and VCs to create portable organization identity
    • What might a service look like that reorganizes Discord server membership data into DAOStar’s defined standard and makes it publicly readable
  • [ insert your own thread starters! ]
  • Trust score around issuers
 
DAOstar One (Internal)
DAOstar One (Internal)
/
🚀
Voyager Identity #4
/
Meeting Primer

Meeting Primer

Attestation framework
Content framework
1. Group Membership
2. Proof of Action
3. Metrics
Combining both frameworks
Discussion primer
Related Threads
 
Attestation framework
Previous framework on data sources from Voyager #3:
  • data from self
  • data from DAO
  • data from DAO peers
  • data from services
The above explores different classifications of how data is generated, not on the actual content.
 
Today, we are looking to focus discussion on the actual content we have in mind, separate from its lifecycle. This document is an effort to articulate examples of this content, offer abstractions, and guide us towards selecting a well-scoped starting point for our working group to find alignment on.
 
Content framework
Through observations across the DAO ecosystem, I see 3 common patterns:
  1. Group Membership: “I am a part of this group”
  1. Proof of Action: “I did this thing”
  1. Metrics: “I did/have/own X things”
 
1. Group Membership
  • base level is an organization
    • I work at Developer DAO
  • often include subsets of the organization
    • I work in the Marketing Guild in Developer DAO (”guild” example)
    • I work on the Product Team at FWB (”project” example)
  • timestamps showing start/end of involvement
 
2. Proof of Action
  • demonstrate action through something tangible service provided or artifact created
  • typically involves a reference to data residing in another service
    • www.github.com/pr/abc123
    • www.mirror.xyz/post/abc123
  • timestamp(s)
  • self-attestations typically include a high-level description of the work
    • “I built a smart contract that does X, Y, and Z”
 
3. Metrics
  • can be an aggregation of contributions
    • number of commits, number of deals sourced
  • token holdings
    • I hold 75 $FWB
  • numbers generated through other methods, e.g. “skill/reputation score”
 
🚧
One can notice that taking a more abstract approach to “Proof-of-Action” can satisfy all the outlined categories and that DID/VCs advocate for this model. Most things enumerated above can be expressed as a Verified Credential or an aggregation of VCs. I am writing this here so we can recognize it and move on; this is a framework of content, not infrastructure or mechanism.
 
Combining both frameworks
Now combining both categorization systems, here are some examples of how one could organize identity-centric information in a matrix with explicit references to some of the organizations in Voyager.
 
AttestationGroup MembershipProof of ActionMetric
SelfLinkedIn: I work for my orgLinkedIn: I did X for my orgă…¤
DAOStation: I hold my org’s NFT/VCPOAP: I hold my org’s X POAP Mirror: I made X blog postSuperDAO: I have been a member for Y time
Peeră…¤Dework: X person approves I did Y taskCoordinape: I received X $GIVE
ServicekycDAO: I verified my government ID Discord: I’m in X server with Y roleWonderverse: I did X task Sismo: I own X badge Github: I made X commit on Y repoDeepSkills: I have X value on Y skill Twitter: I have X followers [smart contract]: I hold X $TOKEN
(I hope it goes without saying that these are likely simplifications of what each of our orgs do, but this is just to demonstrate the framing with some base fidelity.)
 
Discussion primer
After exploding this matrix and highlighting some of our differences, one might say we’re poised to struggle finding much common ground because we are all doing different things. To take a step back, we are here to foster interoperability of our ecosystem.
  • we can’t foster interoperability if we can’t come to some agreement on how we want to structure data
  • we are less likely to come to this agreement if we have too large of scope
  • as it stands right now, the matrix above is too large and needs serious scope reduction
 
To focus our group, Josh and Balazs offer these questions:
  • what is the smallest unit of value we can agree on and make a collective proposal from DAOStar One?
  • where can we start that best positions us to continue defining more ecosystem standards?
 
One intuition for the above questions from the original document: “How does identity work within DAOs?”.
  • within DAOs → start by agreeing on how we want members to represent their DAOs
  • somewhat of the reverse of what EIP-4824 does with membersURI for DAOs
  • starting with organization membership is a natural beginning to other important data that we collectively find valuable
    • what sub-organizations is this person a member of?
    • what work has this person done within the organization?
    • what do other people in this organization have to say about this person?
 
đź’ˇ
How might we share interfaces for reading each other’s data about which organizations a person is a part of?
 
Regardless of if you put a URI on-chain, on a registry, or point to your API, some URI somewhere will return me data about a person when I request it. If that URI is to contain the organization-membership knowledge, let’s agree on what we want that format to look like.
 
đź’ˇ
Side question: is there an opportunity to leverage DAOStar One’s already-released DAO metadata standard, EIP-4824?
 
The EIP-4824 DAO JSON-LD Schema:
Conversation starter for a Member schema:
 
Related Threads
  • If we have the basis of defining organization membership, how can we guide ourselves to reuse each others data? How can we work towards a world where I define I contributed to DAOStar in platform X and it automatically shows when I go to platform Y? How do different infrastructure choices impact this ability to import each others’ data?
    • For example, Station is pursuing membership NFTs and VCs to create portable organization identity
    • What might a service look like that reorganizes Discord server membership data into DAOStar’s defined standard and makes it publicly readable
  • [ insert your own thread starters! ]
  • Trust score around issuers
Â