Hi guys,
I got a response to a text record related question on Discord that got me thinking. What enhancements would I like to see around the design and use of ENS text records? I have captured my thinking in the sections below. I posted my views on Discord but was re-directed to this forum site, which I agree is better suited for this discussion.
- From a quick scan, I cannot see on the forum that these proposals have been discussed already. If you know better, please let me know. I am happy to merge with the respective proposals where appropriate.
- The sections below are my way of capturing what I have learned so far about ENS text records and what I believe to be worthy enhancements. I hope that with your feedback we can initiate a pull request to enhance ENS text record capabilities.
- One last point before we proceed. I have been playing around with smart contracts, but I am not a developer. I appreciate that some aspects below may have knock-on effects that need to be fully considered. I have therefore left open comment sections for further inputs. With your feedback the pull request will be able to address such inputs.
Enough preamble mumble. Let’s get to it.
Bit of background
In October 2019, the ENS team introduced Text Records to ENS names This feature was added initially as a means for storing arbitrary data. At launch there were eight predefined keys to which values could be assigned, as shown below:
- Addreses
- Content
- Text Records
- url
- avatar
- description
- notice
- keywords
- com.twitter
- com.github
To address the need for text records types that had not been predefined, a later improvement announced in March 2020, was to add custom text records. The custom fields feature was in line with Richard Moore’s EIP 634, which ENS adopted originally. Richard preferred custom keys, which behave like DNS use of TXT records, because of their flexibility and reduced load to manage at the resolver. His thinking however anticipated applications creating the custom fields, not end users, by themselves using the ENS interface or (as I envisage in future) their wallet app.
By introducing custom fields, users are now able to add many more record types. While this solves the need for variation problem, it does not tackle the familiarity and simplicity users expect. Being able to add text records easily and quickly for commonly used services. Being non-standard, an excessive use of custom fields could also complicate the work of ENS integration partners. This document sets out some recommendations for improvements to the design and use of text records.
Today’s problems come from yesterday’s solutions
The problem with custom fields today – a couple of quick thoughts
- Custom means different things to different people. Let us take the example of a popular service like the video hosting platform YouTube. There are several ways that a user may conceive of adding such a platform. Here are some example keys:
- com.youtube (a keen user who wants to conform to the other predefined keys)
- YouTube[.]com
- https[:]//youtube[.]com
As shown in the screenshot below, the end user’s wallet or any service provider consuming ENS data is left to clean up the mixture of keys received. Transferring an upstream design issue into considerably more work downstream. This creates a broken customer experience for the ENS name end user.
[screenshot removed to meet posting restrictions]
- Custom keys should be the exception, not the norm. Any time we have a significant volume of keys that are custom, we should use the opportunity evaluate the need to convert such a key to a standard version, pre-defined.
The proposals - first draft
Below are the proposals in order of their relative importance (imho):
#1: Expand the list of predefined text record keys.
Modify the list of predefined keys to include popular keys as in Table 2 below. These are currently the more popular platforms globally. Users will find these keys familiar. They will more easily and quickly capture their details.
#2 Add a visual cue for custom records.
Add a visual cue for the option to create a custom record. Conscious that UI changes are planned, this would add a label “Add custom” in the dropdown.
The current design of the Text > Key fields does not signify to a user that custom fields are possible. Even so, how to create a custom field is only evident after text has been inserted. To know this, is only possible after having read Brantly’s blog post, being told by someone else or by happenstance.
#3 Alphabetical sort order of text record types.
The order of the text record types is sorted alphabetically in the drop-down menu and within the display of the ENS name. This change makes it easier for users to identify text record types; see suggestion in the below.
#4 Permanent avatar.
Enable the ENS web app to resolve IPFS link value in the avatar key. This change would fetch and display the digital image file hosted at the IPFS location. The user is now with a permanent avatar.
The next step to this is to provide an upload feature to IPFS. Users can select and upload an image from their device to IPFS and the avatar record is updated to the IPFS link.
#5 Reject cryptocurrency addresses being added as custom text records.
Users can—unknowingly or intentionally—create custom text records for cryptocurrency addresses. By permitting this action an end user creates addresses within text records, which wallets and service providers will not resolve.
#6 Include help text to explain the syntax for entering values for pre-defined text records. This will make it easier for the end user to know whether to include just their username or full URL. Avoiding the problem shown earlier in this doc.
#7 Copy the full syntax structured text record (key and its value).
Currently only the value is copied when a user selects to copy from ENS web app. This enhancement should carry over with wallets and service providers in their environments so that a user clicking on a text record gets the URL and not just a username for example.
#8 Switching from displaying reverse dot notation
Reverse dot notation does not make sense to the average user that is expected to populate the field. The temptation would be to reverse their own URL or worse yet their username.
Table 2: Proposed composition and order of text record keys
