Hats-Protocol / Hats-Protocol/hats-protocol

Hats wearing other hats

Open
#7 3 comments 0 reactions 0 assignees View on GitHub
community feature idea
Dominant language
Solidity
Stars
98
Forks
29
PR merge metrics
No merged PRs in 30d

Description

Hats represent roles, conferring responsibilities, accountabilities and (via token-gating) their associated authorities/permissions on the wearer. Currently, all of those affordances are bundled into a single hat. This is really great, since it does away with the artificial separation of responsibility and permissions so common in organizations today. When a responsibility requires permissions, the two should go together.

But, this bundling isn't always ideal for all types of roles. Sometimes roles can change over time, requiring new permissions or no longer needing old permissions. And some roles can even change based on who is filling them. For example, one lead developer may have have a design background and need write access in figma, while her successor may be the world's worst designer and should *not* have figma write access.

So ideally, Hats Protocol should be flexible enough to enable the permissions and authorities of hats to be remixed and adjusted. One particularly elegant way to accomplish this would be to enable **hats to wear other hats**. If implemented, this would have the following advantages:

1. New permission N could be attached to an existing Hat A simply by "minting" Hat P to Hat A
2. Outdated permission O could be removed from an existing Hat A simply by revoking Hat O from Hat A
3. Since Hats could wear many Hats, individual Hats could have atomic, one-to-one relationships with access permissions / authorities

HOWEVER, implementing this is a hard problem. A solution may require a significant re-architecture of the protocol or an extremely innovative solution.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.