After using the protocol for a while, we are still determining the authorities/permissions for the job’s completion.
This is a first impression, and we are sure a lot of thinking effort was put into making how it is built.
If the admin can do almost anything with the minted hats, Rn.
We have Toggle and Alagability, but the admin can do almost all actions and is only authorized.
We suggest A - consider for the wearer to be permitted by delegate authority from the admin to do most of the actions (the written permission in the contract) and mainly update the hat properties.
B - the wearer can update the details; the admin must only sign on it. That may be more of a client-side solution.
It doesn’t need to be updated now in one way or another, but a point to discuss further while using the protocol.
Hi @punterored.eth,
This is interesting and every org will probably have their own way of doing things.
B - the wearer can update the details; the admin must only sign on it. That may be more of a client-side solution.
Option B caught my attention (because of how we are using Hats) as the more autonomy you give to the different groups in your org → the more empowered they will feel experiment new tooling and ways of doing things better. And allowing a wearer to “request updates to my role” gives some interesting opportunities.
Did you have some use cases in mind?
Hi @Jaf
Thanks for the meaningful response.
Yes, I believe that even with the hat’s description, giving the wearer the option to describe her responsibility makes sense.
For instance, there are now ‘Hats Community Member’ for the Haberdasher Labs tree.
All the hats are duplicates of the same token. Are the community members fungible? Should the description of the hat be the same? I believe that letting the members describe each community’s role can be beneficial both for the community and to the wearers.
Another future example might be compensation negotiation. It might be a different elegant way for the hats to negotiate with the admin when the latter doesn’t dictate the terms but simply agrees.
Great points indeed!
Allowing hat wearers to request changes/updates to my role, could also bring new dynamics to the organization to not be structured from top-bottom only (by the DAO operator).
When teams continue working together they evolve and new responsibilities and accountabilities might arise from their day to day work.
It does make sense to me that this type of requests are possible, and eventually they help sharing and implementing best practices across teams.
Yes this is interesting, I love the bottom-up approach this is getting at
Currently, I see one way that people could suggest edits for their own hat: Using edit mode to propose edits to their hat, and using the export .json function or executable hex code to then send to an admin to deploy. There might be a way we could integrate this into the app, e.g., “request changes to hat”
Re: letting wearers of a hat that is worn by many to carve out their own roles, it is possible currently for wearers (e.g., of the Community Hat) to create a child hat that they mint to themselves, with details on the specific role they are holding. However, I think this could get messy for large communities, so this is definitely something worth thinking through…
We suggest A - consider for the wearer to be permitted by delegate authority from the admin to do most of the actions (the written permission in the contract) and mainly update the hat properties. B - the wearer can update the details; the admin must only sign on it. That may be more of a client-side solution.
A and B could both be handled by a custom Hatter contract. That’s what we’ve been calling a contract that wears an admin hat and then uses it to do things in the tree as an admin, on behalf of other code, people, or groups.
The most common example of this right now is a Claims Hatter, which is used to make a hat permissionlessly claimable if a potential wearer passes the isEligible check on the hat. The Hatter contract wears an admin of the hat to be claimed. Here’s an example: Hat #0 | Hats Protocol
This opens up a pretty broad design space, but I’m hopeful that there will be a power law of common use cases and reusable contracts the community will have patterns for!
I see one way that people could suggest edits for their own hat: Using edit mode to propose edits to their hat, and using the export .json function or executable hex code to then send to an admin to deploy.
In DAOs, this is particularly potent because a DAO member can export the transaction call data from the hats app and import it into a DAO proposal that they are already permitted to make. One of the huge benefits of the composability approach!