Client: Remove Role Identifier

[luisivan]

It's a technicality that users shouldn't even know about. We should remove the Role identifier column everywhere

[bpierre]

@luisivan I am thinking about some possible cases where being able to see the identifier could be useful:

• Clarity: an app could be using confusing descriptions for permissions, making it hard to understand what role identifier a description is referring to, or the other way. For example, an app author could decide to update a role description to make it clearer, while keeping its identifier the same for compatibility reasons. We could decide that it is the responsibility of app authors to provide good role descriptions, and recommend authors to ensure that identifier and description are easily recognizable.

• Consistency (with aragonCLI and daoCLI): people using both the CLI and aragon/aragon to set permissions could be looking for the identifiers in the UI. Even for a non-developer app (daoCLI), setting a permission will probably still require to use its identifier.

• Trust: being able to read the Solidity code of an app (e.g. published on Etherscan) and to verify that a specific permission is going to be the one that is going to be set. Not having identifiers would still make it possible to do that, it would just be a bit harder.

Do you think any of these reasons could justify making identifiers less visible instead of removing them entirely? (e.g. a tooltip on the name, as a secondary label below it, only in the manage panel and below the description, behind an “more details” action, …)?

[luisivan]

@bpierre thanks for the comments, replying to each point:

• Clarity: I think that it should be the dev's responsibility to write good notices. A user may stop using an app if it has weird descriptions, or not at all
• Consistency: I don't think Aragon and aragonCLI/daoCLI users are the same. If we want to have some developer-facing information in Aragon, we should have a development flag in the client settings
• Trust: We need to figure that out with a Radspec registry that is well audited, so users don't have to worry about this. I think those advanced users who want to ensure security will just look for the Radspec notice in the function they want to call, because they will know how permissions work. On the other side, normal users won't even bother looking at any code. So I think this is, again, something that could be hidden behind a dev flag.

About tooltips/secondary labels: that may clutter the UI too much, but maybe a tooltip could make sense until we have that dev flag.

[bpierre]

@luisivan Thanks for the answers, that makes sense. Let’s get #395 merged and decide later if we need this information, behind a flag or at all.

[bingen]

I like the idea of a dev flag.