ENS names as first class citizens, actual usernames, not just alias for addresses

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

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.



Hackathon Idea: Real ENS name support for Gnosis Safe

I have also posted this to the Gnosis Safe forum: ENS names as first class citizens - Safe Development - Safe Community Forum

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.

thanks for any comments or feedback.

-cobordism.

3 Likes

Thinking about this a little further, I think that we should allow for app-specific (sub-)resolver contracts.

In the DNS, the TXT record is a kind of catch-all. A blank space where new kinds of records can be created for applications that were not envisioned originally.

The ENS also has TXT records, and one could presumable hack together a sub-resolver system from there, but I feel that the true catch-all for the ENS should be a resolver contract, not a text entry. In this model I could register a new resolver contract for my DAO or for Gnosis Safe etc. and these resolvers would house all the application specific logic I describe in me original post.

This is just stuff I’m thinking about. I have no specific plan or proposal.

@nick.eth at devcon you briefly mentioned to me some ideas in the works surrounding sub-resolver contracts. Can you remind me what they were called, or suggest a place to read up on these ideas?

The more I think about it, the more often I find use cases for them :slight_smile: