Hats-Protocol / Hats-Protocol/hats-protocol
Hats wearing other hats
- 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
Assessment
This issue has not been assessed yet.