Meeting Primer

Recap

Attestation framework

Previous framework on data sources from Voyager #3:

data from self

data from DAO

data from DAO peers

data from services

oracles? collab.land

Content framework

Previous framework on data content from Voyager #4:

Group Membership: “I am a part of this group”

Proof of Action: “I did this thing”

Metrics: “I did/have/own X things”

🔑

From here, we found alignment on focusing on one type of content: the top-level membership in an organization.

Attestation Investigation

Via Lucidchart, we attempted to model how to create Attestations that a particular user (identified by Ethereum address) is a member within an organization. The diagrams involve 3 key stakeholders: DAOs, members, and issuers of these attestations.

🔑

From here, we recognized that our efforts were going down into architecture patterns explicitly adopting DIDs/VCs. Although we have general agreement that this infrastructure will be useful for this class of problems, designing a standard around infrastructure none of us have taken to production is unlikely to be adopted in the near or midterm. Our goal is to make a standard that will be adopted, so we should focus on enabling current platforms to easily conform to our proposal.

In Voyager #5, we should:

Design the basic schema, focusing on ways of extending EIP-4824.

Spec out a basic experiment where we (platforms implementing some form of web3 profile or cv) share interfaces and reach each other’s top-level membership data.

In doing so, make progress on answering the question that Conner posed in Voyager #3: 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?

🔑

With this tighter scope alignment, we are now working on an initial proposal draft here:

🚀

Attestations for DAOs [DEPRECATED]

Making the use-case concrete

In Voyager #5, we:

Discussed the shape of the basic schema.

Discussed revocation vs. expiration approaches, as well as the need to (potentially) keep time-series data about participation

“What is membership”? All DAOs have a different definition + different mechanisms for defining it.

We reached consensus that we need to be able to interact with a variety of different data sources (token holdings, application-specific attestations, and so on) in order to produce a straightforward representation of membership that could then be consumed by a variety of different sources, from DAOs to services / tools.

But we then had a heated discussion about whether this data is actually useful for services like Station or Govrn or Closer or Disco. What will motivate adoption? What will incentivize our platforms to actually adopt this schema? For parts of the data (e.g. expanded member data provided by DAOs) this is relatively clear. But why would platforms want to share information between each other—is that even a use-case that we want to support?

For more details, see:

Reach consensus on adoption hypothesis / product-market fit

In Voyager #6, we should: 

Try to reach consensus on why DAOs & protocols will adopt this standard.

For example, should we bring people from DeWork, Backdrop, Wonderverse? Because these are the people who will be implementing it.

In Voyager #7, define common patterns for membership re: token-holding? Start to define some language for defining membership, so that it becomes a reusable component for people to be onboarded into DAOs.

Meeting Primer

Recap

Attestation framework

Previous framework on data sources from Voyager #3:

data from self

data from DAO

data from DAO peers

data from services

oracles? collab.land

Content framework

Previous framework on data content from Voyager #4:

Group Membership: “I am a part of this group”

Proof of Action: “I did this thing”

Metrics: “I did/have/own X things”

🔑

From here, we found alignment on focusing on one type of content: the top-level membership in an organization.

Attestation Investigation

Via Lucidchart, we attempted to model how to create Attestations that a particular user (identified by Ethereum address) is a member within an organization. The diagrams involve 3 key stakeholders: DAOs, members, and issuers of these attestations.

🔑

In Voyager #5, we should:

Design the basic schema, focusing on ways of extending EIP-4824.

Spec out a basic experiment where we (platforms implementing some form of web3 profile or cv) share interfaces and reach each other’s top-level membership data.

🔑

With this tighter scope alignment, we are now working on an initial proposal draft here:

🚀

Attestations for DAOs [DEPRECATED]

Making the use-case concrete

In Voyager #5, we:

Discussed the shape of the basic schema.

Discussed revocation vs. expiration approaches, as well as the need to (potentially) keep time-series data about participation

“What is membership”? All DAOs have a different definition + different mechanisms for defining it.

We reached consensus that we need to be able to interact with a variety of different data sources (token holdings, application-specific attestations, and so on) in order to produce a straightforward representation of membership that could then be consumed by a variety of different sources, from DAOs to services / tools.

But we then had a heated discussion about whether this data is actually useful for services like Station or Govrn or Closer or Disco. What will motivate adoption? What will incentivize our platforms to actually adopt this schema? For parts of the data (e.g. expanded member data provided by DAOs) this is relatively clear. But why would platforms want to share information between each other—is that even a use-case that we want to support?

For more details, see:

Reach consensus on adoption hypothesis / product-market fit

In Voyager #6, we should: 

Try to reach consensus on why DAOs & protocols will adopt this standard.

For example, should we bring people from DeWork, Backdrop, Wonderverse? Because these are the people who will be implementing it.

In Voyager #7, define common patterns for membership re: token-holding? Start to define some language for defining membership, so that it becomes a reusable component for people to be onboarded into DAOs.