Skip to content

Return beautified display names #1501

@lightwalker-eth

Description

@lightwalker-eth

Background

  1. We have existing APIs that perform primary name lookups.
  2. Currently, these APIs return only the normalized primary name.
  3. The "beautified" display version of a normalized name is a distinct idea.
    1. see docs on ens_beautify at https://github.com/adraffy/ens-normalize.js
Image
  1. Additional docs on the "beautiful name" idea can be found here: https://github.com/namehash/ens-normalize-python

Goals

  1. In our APIs, whenever we return a primary name, we should return that name in multiple representations in distinct fields:
    1. The name: which should be in normalized format and match the true primary name.
    2. The displayName: which should be the "beautified" format of name.
  2. Optimize the DX for people who use our APIs / hooks:
    1. Ideally they shouldn't need to install / use ens_normalize or ens_beautify themselves to always display all ENS names in their ideal formatting. This is also relevant for people building ENS apps that aren't using TypeScript. Ex: a mobile app. They can just use our APIs to handle these details.
    2. Optimize our docs related to use of our APIs and the related hooks, encouraging others to always display this displayName field at a UI-level for optimal ENS UX. To help people understand why, it is probably helpful to cite a specific example where the displayName is distinct from the name.
    3. Update our existing logic inside ENSAdmin / ENSAwards to make use of this displayName field in our UIs. Please feel welcome to transfer this idea into a separate follow-up issue.
  3. For consideration: This may be an opportunity to also streamline the DX for what name to display for an identity that has no primary name.
Image

For example, if devs could always just simply display the displayName in the UI, no matter if the returned identity had a primary name or not, that seems nice for DX. Therefore, at a backend level, if a primary name lookup didn't return a valid primary name, we could generate a truncated address similar to what's shown in the screenshot above as the displayName.

Assuming we do this, there should be a strategy for how invariants would work for this displayName field. In the case of a primary name being returned, there must be an invariant that the ENS normalized representation of displayName === name. However, for the case there's no primary name, this invariant wouldn't apply.

Metadata

Metadata

Assignees

Labels

ensapiENSApi related

Projects

Status

Todo

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions