-
Notifications
You must be signed in to change notification settings - Fork 15
Open
Description
Background
- We have existing APIs that perform primary name lookups.
- Currently, these APIs return only the normalized primary name.
- The "beautified" display version of a normalized name is a distinct idea.
- see docs on
ens_beautifyat https://github.com/adraffy/ens-normalize.js
- see docs on
- Additional docs on the "beautiful name" idea can be found here: https://github.com/namehash/ens-normalize-python
Goals
- In our APIs, whenever we return a primary name, we should return that name in multiple representations in distinct fields:
- The
name: which should be in normalized format and match the true primary name. - The
displayName: which should be the "beautified" format ofname.
- The
- Optimize the DX for people who use our APIs / hooks:
- Ideally they shouldn't need to install / use
ens_normalizeorens_beautifythemselves 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. - Optimize our docs related to use of our APIs and the related hooks, encouraging others to always display this
displayNamefield at a UI-level for optimal ENS UX. To help people understand why, it is probably helpful to cite a specific example where thedisplayNameis distinct from thename. - Update our existing logic inside ENSAdmin / ENSAwards to make use of this
displayNamefield in our UIs. Please feel welcome to transfer this idea into a separate follow-up issue.
- Ideally they shouldn't need to install / use
- 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.
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 relatedENSApi related
Type
Projects
Status
Todo