Regarding arbitrary data in text records

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!

ENS rocks!

1 Like

There’s nothing inherently wrong with storing arbitrary text records in ENS; that’s the purpose of the text profile. To answer your specific questions:

  • the only issue with using text-based records is it can be relatively expensive compared to storing a custom format that could use a more compact binary representation
  • not sure what you mean by “handle” here. The resolver can return set and return text records with setText()/text() function calls
  • I took a quick look at xpub and it doesn’t appear to be a standard of any sort. Perhaps a first step would be for it to be a standard and then support for it could be included in ENS (apologies if it is a standard and I missed it; xpub is a relatively common term on the internet)
1 Like

Ohhh wait so the email, url, avatar, etc keys that I see in text records on app.ens.domains aren’t inherent to the contract? They’re just UI presets?

Bc if the contract can handle arbitrary keys then we’re 100% good to go.

1 Like

In addition to what Jim’s said - you can define a new ‘profile’ for resolvers; just see any of the existing ENS EIPs such as 205, 634, or 1062 for example. It’d be easy to specify one for storage of XPUBs in binary format.

2 Likes