Hello ENS friends!
My name is Bo, I’m an engineer working with Connext and we’re getting ready to set up ENS support in preparation for MetaMask updating their Instapay feature to use V2 of our state channel platform.
Our new state channel system utilizes
xpubs aka extended public keys. It’s a lot like a mnemonic but for public keys/addresses so it can be shared publicly to give someone access to a subset of addresses controlled by a mnemonic. xpubs are arguably even uglier than eth addresses so MetaMask wants to hide them as much as possible from end users. Naturally, ENS is the solution of choice for this kind of thing.
The end goal is to configure an ENS name for users (eg
bohendo.connext.eth) that can be used to resolve either an on-chain address or an in-channel xpub.
Long term, I think xpubs will end up being useful pieces of data to tie to an ENS name and we’re drafting an ERC to kick-start a discussion regarding whether resolvers should support an xpub record or an xpub key as part of the text record.
Short term, it seems like there’s no clean way to add arbitrary data to an ENS record so the best path forward appears to be hijacking an existing data field (eg the description key of text records).
Battle plan at the moment is to use an address record to store then on-chain address and the text record’s description key to store our xpub. This way, both pieces of info are available to use depending on the context & one ENS name will be able specify a recipient either on-chain or in-channel. Seems like a good plan in the sense that it gives us the functionality we need w/out us having to wait for new resolves to be deployed before we can use this solution in production.
But it feels ugly and I’m curious to hear your thoughts. It seems like we can’t be the only team in this situation and adding a set of predefined text record keys is just asking for them to be used in ways that wasn’t intended.
- Will there be any consequences of using random text-record keys to store arbitrary data (other than potential conflicts w existing data)?
- Are there any plans for a resolver that can handle arbitrary text-record keys (or any reason why this isn’t feasible)?
- Longer term, do you think an ERC suggesting an xpub record or xpub key in the text-record would be better received & why?
Thank you for your time!