Addressable ids

[topocount]

This PR creates hat ids that indicate a hat's relationship to other hats.
The address can be parsed to find admins, and determine the hat's location
in a hat hierarchy without accessing storage. Child hats are now accessible
directly from an admin as well, though that requires peeking at storage.

This comes at the tradeoff of limiting a hierarchy (tree) to a depth of six
hat levels. and each hat may only administer a total of 255 hats directly.

I chose a depth of six because it seemed like a future-proof quantity of
levels for larger orgs, but we could change it to 4 and be back to a uint64.

Note, this code is still non-optimized so there are still improvements to be made in most bitwise operations. I tried to keep it in readable Solidity for the proof of concept.

[topocount]

mapping(uint80 => uint32) public hatSupply; // key: hatId => value: supply

[spengrah]

I think this function also needs to increment hat.lastHatId

[spengrah]

how come you're removing this line? If I'm interpreting correctly, without this line _mint would not change any 1155 token balances. What am I missing?

[topocount]

it just wasn't valid solidity so i shelved it for now

[spengrah]

ah I think I know what happened. I changed the ERC1155._balanceOf function from private to internal to enable Hats.sol to call it, but hadn't pushed that change up yet. I'm a bit confused how to handle the situation since I sort of forked the solmate repo. May need to bring that forked repo into the Hats Protocol org...

I just up the change, here. You can probably rebase and the code should now work. Let me know if it doesn't.

[spengrah]

same question here as for _mint

[spengrah]

I chose a depth of six because it seemed like a future-proof quantity of
levels for larger orgs, but we could change it to 4 and be back to a uint64.

What would be the downside of ramping all the way up from uint80 to uint256 for hatIds? That would allow us to support ( 256 - 32 ) / 8 = 28 levels. And as a smaller benefit would allow us to avoid having to type cast when working with ERC1155 standard functions.

Since we're no longer storing hatIds in the Hat struct, my anticipation is that doing so wouldn't increase any storage costs.

[spengrah]

In general, this is amazing! Well done @topocount 🙌

I left a few questions and comments above. Thanks!

[topocount]

I chose a depth of six because it seemed like a future-proof quantity of
levels for larger orgs, but we could change it to 4 and be back to a uint64.

What would be the downside of ramping all the way up from uint80 to uint256 for hatIds? That would allow us to support ( 256 - 32 ) / 8 = 28 levels. And as a smaller benefit would allow us to avoid having to type cast when working with ERC1155 standard functions.

Since we're no longer storing hatIds in the Hat struct, my anticipation is that doing so wouldn't increase any storage costs.

This is totally doable. if you think it'd a good product move i'll do it. Was just trying to see how small i could make everthing while allowing for plenty of breathing room.

[spengrah]

I chose a depth of six because it seemed like a future-proof quantity of
levels for larger orgs, but we could change it to 4 and be back to a uint64.

What would be the downside of ramping all the way up from uint80 to uint256 for hatIds? That would allow us to support ( 256 - 32 ) / 8 = 28 levels. And as a smaller benefit would allow us to avoid having to type cast when working with ERC1155 standard functions.

Since we're no longer storing hatIds in the Hat struct, my anticipation is that doing so wouldn't increase any storage costs.

This is totally doable. if you think it'd a good product move i'll do it. Was just trying to see how small i could make everthing while allowing for plenty of breathing room.

Ok great! If there are no (or minimal) storage cost downsides, support for as many levels as possible is ideal

[spengrah]

This address #18