Hats wearing other hats

[spengrah]

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.

[spengrah]

This may be infeasible, since...
a) there can be multiple wearers of a single hat (ie when hat.maxSupply > 1), and
b) a single person (or hat) can wear multiple hats

The issue is not with a hat wearing another hat, per se, but rather in our ability to find the address that wears the bottom-most hat that wears a given upper hat (in the case of A), or to find that uppermost hat worn by a given address (in the case of B).

In both cases, the search is potentially infinite, traversing an ever-expanding tree.

[nintynick]

Niran suggested on Townhall # 1 to leave out for v1, and possibly solve in v2 by giving Hats their own wallets (which solves this out of the box — as long as an owner can control a hat, and a hat can control an owner, then a hat can control a hat)

[spengrah]

started a research spike here: https://github.com/Hats-Protocol/hats-protocol/tree/feat/hats-wearing-hats

The basic approach is as follows:

1. convert Hat A's id to an address and mint Hat B to that address => Hat A is now wearing Hat B

2. extend the 1155 standard with a new balanceOfByPath function that takes a uint256[] array for a path of hat ids (ie instead of a single hat id).
   If the array has length N + 1, the function checks whether hat N - 1 is wearing token hat N (which is the main hat in question), and then if so if hat N - 2 is wearing hat N - 1, all the way back to hat 0 in the array. If all of those are true, then it finally checks if the queried address has a balance of 0.

Remaining challenges

• efficiently converting all the other functions to use similar logic
• getting apps to know how to read balanceOfByPath, ie do we need a new token standard?