When a Safe updates an ENS Content Hash, the hash being written is very hard to decipher

[chrishobcroft]

Bug description

When updating a Safe's ENS name's Content Hash, the process for reviewing the content referenced by the hash is far from trivial, and would be way beyond the ken of most non-technical folks, as well as beyond the patience levels of most technical folks.

Given this level of obscurity for reviewing an update to one of the primary features of an ERC721 token representing an ENS Name (the Content URI), using one of the primary constructs for collaborating on ownership of names (the Safe), it seems to me that this is a bug which cannot conceivably be considered "expected behaviour".

Steps to reproduce

1. Get a Safe with an ENS name (obviously)
2. A signer in the Safe proposes to update the ENS name's Content Hash (signs their end of the transaction)
3. Other signers see the transaction for the proposed change and observe an incongruous hex string (see Screenshot 1).
4. They use the excellent "Transaction Decoder" to parse the data, and extract the data being proposed for the new content hash (see Screenshot 2).
5. They stop to take a breath
6. They research ENS to establish that the leading 4 characters after the 0x are some kind of ENS prefix and should be disregarded.
7. They use perplexity (or other) to convert the remaining hex string into an IPFS hash (see Screenshot 3)
8. They use their favourite IPFS viewer to view the content that the ENS name will be if the transaction is approved (see Screenshot 4, or https://blog.uncloud.eth.link).
9. They vow to never go through this process again (my very capable and learned friend actually did this)

Expected result

In my dream world, I expect that at step 3, other signers are able to directly view the content represented by the proposed updated hash / URI.

Alternative approaches might be to simply display the URI itself, e.g. in this case:

ipfs://bafybeifoq36li7adry3woj2gnskr6id4odeal7i3mb2ydi55ubjadc4hry

or in other cases bzz:// or https:// or even http:// URIs

Before you dismiss this idea as too niche...

I acknowledge that we have come a long way with being able to decode the transactions that we are being asked to sign (h/t ByBit).

I also acknowledge that there are many cases where transaction call data could benefit from being presented more coherently for non-technical users.

But in this case, given that an ENS name's Content Hash / URI is such a core component of an ENS name (it is a fundamental piece of ERC-721), it feels like a worthy candidate to be prioritised as we take steps towards making our onchain decentralised grassroots governance software more usable by the masses.

Acknowledgements

Thanks to @oed of https://github.com/stigmergic-org/simplepage for inspiring me to go through all this.

Screenshots

Screenshot 1

Screenshot 2

Screenshot 3

Screenshot 4