This is a preliminary proposal to define the curation mechanism and guidelines for the Hats Modules Registry. I am seeking input on all aspects before bring the formal proposal later next week — by November 17 — so please weigh in!
This post has several sections:
- Design Goals, Considerations, and Trade-offs
- Preliminary Proposal
- Open Questions
Hats Modules are smart contracts that extend the functionality and behavior of hats, enabling customized and automated management of roles and their attendant authorities. Hats Modules expand Hats Protocol from a useful tool to a flexible and powerful platform for designing, building, and operating modern organizations.
Anybody can build Hats Modules and use them with their hats. Fulfilling their promise as a platform, however, requires separating Builders (ie those who develop modules) from Wearers (ie those who use them). Our goal is to give Wearers the full breadth of modules they need to meet their needs, and one of the best ways to accomplish this is to create strong incentives for Builders to create them. In other words, a marketplace for modules.
Thus far, we have planted the seeds for such a marketplace. Just a couple weeks ago, Haberdasher Labs (increasingly known as Hab Labs ) launched the Hats Modules Registry with a handful of initial modules, launched the Modules SDK that enable apps to distribute them to Wearers, and updated the Hats App with the Modules SDK to enable Wearers to select, configure, and deploy them.
This proposal aims to water those seedlings so that they can grow strong and resilient. It outlines mechanisms for how the Hats Modules Registry can be well-curated while navigating key trade-offs (3.1), and defines an initial curation rubric (3.2). It expects additional evolution and refinement will be necessary in subsequent proposals.
- Desire to evolve into a true marketplace, where Builders are compensated for the value they create for Wearers in the form of modules.
- Ability to decentralize over time, likely moving onchain in some form.
- Design for future automation.
- Healthy competition between modules drives quality and variety and therefore value to the ecosystem
- We should encourage developers to create better and more efficient versions of existing modules
- clear and fair process and requirements
- ability to compete
- good response time from the curation process
- Minimize curation overhead, including effort and attention required
- Similarly, minimize the amount of time it takes to review new registry submissions
- Minimize time to value for Builders: less time between building a module and having it distributed to Wearers.
- Automate what we can now.
- Wearers need to understand clearly what a given module does, how it’s different from other modules, and (potentially) when it’s useful
- Credible curation neutrality is important to attract Builders; a less opinionated approach is likely necessary to achieve this.
- Tradeoff between increased demands on curator attention and speed (time to value)
- Must handle conflicting module names
- Must disambiguate between similar modules
- Need to handle module versioning gracefully, including for deprecated / replaced modules
- Apps can — and probably should — be more opinionated and selective about the modules they serve up to their users
- Curators will need tools to curate well
- Module developers need to be able to test how their metadata is handled up the stack (ie the Modules SDK and apps)
Just like the multiple layers of the Hats Protocol stack enable broad credible neutrality combined with a variety of more opinionated components, Hats Module curation should have multiple layers.
The base layer is the Registry, the primary focus of this proposal. With the exception of the Other Curation Layers section below, the remainder of this proposal relates only to the Registry.
Getting this base layer right will create the conditions for other layers to emerge on top.
The base layer curation is:
- global: a single Registry shared by the entire Hats Ecosystem
- focused primarily on objective criteria
- creates the metadata foundation for apps to distribute modules to Wearers
Other curation layers can and will emerge over time. Compared to the Registry, they will be:
- pluralistic, multistakeholder, & polycentric
- more focused on subjective criteria; more selective; more opinionated
- can/will impose some down-stack pressure on Builders to make high quality submissions to the base layer Registry
- potential example: module lists
- similar to token-lists
- can be created by apps or any member of the ecosystem
- current thinking: should not require additional data to be added
Governing and curating the Registry is the responsibility and authority of the protoDAO. Under this proposal, the protoDAO delegates those responsibilities and authorities to a Modules Registry Curation Committee. Committee membership will be defined by a new Modules Registry Curator hat, to be created with this proposal.
The Modules Registry Curation Committee:
- 3 to ~7 members (initially Stewards) who wear the new Modules Registry Curator hat.
- Wearers will be selected by the protoDAO
- Description: The role of the Modules Registry Curator is to foster a healthy ecosystem of Hats Modules and to ensure a high standard of quality and functionality for modules within it. They do so by governing the Hats Modules Registry mechanisms, and by reviewing and approving submissions and modifications to the Hats Modules Registry in accordance with those mechanisms and in collaboration with fellow Curators and the protoDAO at large.
- review submissions and modification requests per the cadence outlined below
- uphold high level of quality for modules on registry
- Mechanism Governance
- ensure the Registry and Curation Mechanism meet the design goals and improve over time
- approve module submission PRs in the modules-registry repository
- approve registry/schema modification PRs in the repository
- merge PRs when approved by 2 or more Curators
- Mechanism Governance
- make changes to the submission schema and Modules Curation Rubric as needed
- admin: Hats protoDAO Role Admin
- eligibility: protoDAO
- toggle: protoDAO
- Max supply: 9
- Image: TBD
- Github PR approval
- Each module submission is a separate PR
- Requires approval from at least two Curators to be merged
- Standard cadence: Monthly.
- All newly approved modules and changes to registered modules are to be announced at the end of each month
- To be included in a given month, new submissions or changes must be submitted no later than one week before the end of the month
- Within this constraint, Curators may review async or devise their own process and timing
- Expedited review: module developers can request review outside of the standard cadence on an ad hoc basis
- Curator discretion for when they honor the request
- the module works as described; no bugs
- is not malicious
- Adheres to the registry submission schema
- metadata is complete
- implementation contract is deployed to at least one chain
- Automated tests pass
- metadata (including name, descriptions, other documentation) is accurate
- Legibility of metadata (Is it user-friendly? Is it a good name, description, etc?)
Due to the high cost of curator effort/attention at base layer involved in subjective assessment, the inclusion of subjective criteria in the rubric should be re-evaluated as the volume of Registry submissions increases.
- How should changes to the submission schema be handled? For example, what happens to existing submissions when the schema changes?
- How can we foster neutral access to expedited review? We don’t want to create an inherent advantage for certain Builders (eg Hab Labs) over others, but it’s also important for Hab Labs and other service providers to be able to move quickly when helping Wearers implement their hats trees.
- Who will the first Modules Registry Curators be? Ideally we can mint the new hat to them as part of this proposal.
This proposal includes insights and perspectives from protoDAO stewards BPetes, Payton, Ido, Scott, Juliette, and Brennan. Thank you!