Human-readable hat ids

[spengrah]

Hat ids are uint256 bitmaps that use the following structure to achieve an "address" for each hat that includes information about the tree of admins for the hat:

• The first 4 bytes are reserved for top hat id (we can think of this as the "domain" of a given hat, often corresponding to the DAO the hat belongs to)
• The remaining 28 bytes each represent a single hat level, fitting 1 admin hat and 255 "child" hats.

Displaying the id as a binary number would require way too much space, but displaying it as a base-10 number occludes the above address semantics. Displaying the id in hex is a good compromise, since it exposes bytes as described above.

But, starting with hex we can make hat ids even more human-readable by...

1. inserting dots between hat levels
2. trimming trailing hat levels (trailing empty bytes)

The result would look something like this:
For hat id 0x0000000101010000000000000000000000000000000000000000000000 -- which is the first hat at the second hat level, whose admin is the first hat at the first hat level, whose admin is the first top hat -- the human-readable id would be...

00000001.01.01 or perhaps even 1.01.01

[spengrah]

A key question is whether it makes sense to include this logic in the contract itself as well as the subgraph.

A couple benefits of including it in the contract

• users can read the human-friendly id when viewing contract state via block explorers
• we can include it in the URI, enabling front ends to directly display the human-friendly id without needing to read from the subgraph

The main drawback is increase in contract size/scope