ENS names as first class citizens

I made the following post in the discord. It was suggested I post it here for more feedback/discussion.


Hello everyone. I’d like to get feedback - does this make sense as a hackathon idea?

Real ENS name support for Gnosis Safe
Currently the gnosis safe app allows me to enter an ENS name, but it immediately replaces it with the registered address of the name. I am suggesting to add ENS support to the safe in such a way that a name can be a co-owner of a safe.
Use case: treasurer.myclub.eth and president.myclub.eth are both co-owners of the clubs gnosis safe. Our internal governance mechanism will regularly reassign those names to new people (and thus new addresses). We want the gnosis safe signing privileges to automatically pass to new officers without having to do all the updating manually.
Things to think about:

  • At what point does the gnosis safe have to query the ENS record for the addresses.
  • How might one structure the ENS record to allow a different signing address for the gnosis safe than when that name is used to receive payments?
  • How to have an address be gnosis safe app-specific (“when name.eth is used in gnosis safe, use this address instead of the global address record”)? Should the Gnosis safe app have a standard search order when querying an ENS record (first app-specific address/key, then general app address/key, then the main ENS address)?
  • What should the behaviour be when the address associated with a name is changed after the name has already signed a transaction but before it has passed the threshold and been submitted? Should the new owner be able to undo the prior signature or should the owner list be fixed at the time the transaction is proposed?

I would also like to add that this is part of a general idea of mine to make ENS names be actual usernames and not just an aid in looking up an address - with the address taking the role of username.
A related hackathon idea of mine was ‘log in with ENS for dm3.network’.
I am posting that over at the ENS forum, but I will include a copy below so you better understand where I am coming from.

thanks for any comments or feedback.

-cobordism.


Hackathon idea “Log in with ENS”
More and more web3 sites have a ‘log in with metamask’ option, or more generally ‘log in with ethereum wallet’. A few of these even allow you to enter an ENS name. However all they will do is read the associated address to the ENS name and use that address.
I am proposing a log-in with ENS that actually uses the name and not the address.

Set-up: I have a different metamask wallet on each of my browsers (firefox, brave, vivaldi …) and each of my computers (home, work, …) and I have an ENS name tied to a hardware wallet. I want to be able to log in to the app from any of these locations.
The idea is to have myname.eth registered as the username, and have the ENS record at myname.eth maintain a list of addresses that are allowed to log in to the app in question. The hardware wallet would be needed only to add or remove any addresses from the ENS record, but would not be needed every time I want to log in to the app in question.

Things to think about:

  • How to structure the ENS records (txt records? custom resolvers? app-specific subdomains?) and how to go about updating them easily?
  • How to make an allowed address be app-specific (“use this address for skiff only but not for colony”) and how to make it more generally allowed? Should each web3 app have a standard search order when querying an ENS record (first app-specific address/key, then general app address/key, then the main ENS address)?
  • If the app needs a key for decryption, how to make the decryption key available on login? (Example, dm3.network chat is encrypted with some key. When you log in, you want to be able to decrypt your messages. Thus it must be possible to get the current decryption key from wherever you log in… so that key should have been encrypted with the public key associated to each allowed address so that this encrypted key can be downloaded from some decentralised storage network (IPFS/swarm) on demand.)
  • How one might go about adding a privacy layer. If I don’t want all my addresses easily linked on chain I might not want a list of addresses in txt records of my ENS name. Is there a way to use merkle proofs? or something even more zk-fancy?

Right now I don’t use ‘log in with ethereum’ for things like murmur or skiff because that ties me to the device / browser where I have the relevant key. If I create an account on my work computer in QubesOS then I cannot login again and take an action when I am at home in ubuntu or on the road on my laptop.
I have several computers and they tend to have two OSs each and multiple qubes or browsers in each one … most of these have their own local metamask accounts.
I would like to log in to murmur (for example) with myname.eth and have the ENS record contain a list of ~3-6 addresses (example: firefox on my work computer, brave on my personal computer, walleth on my phone, my ledger) with which I can log in to my account on murmur.
Think of these entries as login cookies. This allows me to add and remove devices as needed, using the security of my hardware wallet to maintain the list, but allowing me to use these dapps without being tied to a single device or sharing the same key across all devices.
I am suggesting that this should become more common, that we should develop a standard for adding/removing devices, that this should be possible globally and app-specifically, and I am suggesting dm3 chat and gnosis safe as a place to hack together a proof of concept.
THAT is what it would take to make your ENS name be your username.

6 Likes

Hi, @cobordism :wave:
This definitely makes sense to me.

We (dOrg) have been exploring similar concepts as we don’t want to tie the Safe owners to static addresses.
The approach we have looked into is specifying the holders of specific NFTs as owners of a Safe. In this case, the Safe will have a module with a public function (that anybody can call at any time) that will fetch the current holders of the NFTs and update the Safe’s owners accordingly.

specifying the holders of specific NFTs as owners of a Safe

… and of course an ENS name is an NFT.

Yes, but it sounded like you were planning on setting the address it resolves to as a Safe owner and not the owner of the ENS NFT.

ah yes indeed.
Moreover I was suggesting perhaps having a custom record in the ENS for this.

For the record, I have now posted this in the ENS forum as well.

What’s the advantage of your ENS approach compared to @manboy’s alternative? @cobordism

I think what I am proposing is more general - applying to any number of dapps. Furthermore, I like the idea that ENS names can be conferred like roles / job titles, and when they pass to a new office holder, the rights and obligations automatically go along with them.

I’ve been thinking that the best way forward might be to have dapp-specific (sub-)resolvers in the ENS - as opposed to using the txt records.

But this would then be a standards discussion for the ENS to have, rather than a gnosis-safe specific discussion.

1 Like