Idea name: Use ENS Custom Text Records rather than setPubkey() on an ENS Resolver for publishing Status Chatkeys
Description: Abandon using setPubkey() for publishing the chatkey for an ENS name in the ENS Resolver (aka EIP-619) and use EIP-634 Custom Text Records on the ENS Resolver instead
Use case: To manage ENS Records using standard tools rather than a custom setup flow.
Target user: All ENS users on Status
Why this is important:
Although the interfaces for setPubkey() (aka EIP-619) and text() (aka EIP-634) were both proposed roughly at the same time in May of 2017, the latter has experienced much greater uptake in the ETH community, in both public awareness and user-facing tools that support it.
Currently, the ENS setup flow in Status is inflexible and using setPubkey() has many other issues:
- The setup flow assumes the user owns the corresponding ENS ERC-721 NFT in one of the accounts in the app: Either through purchasing the ENS name directly in Status, importing a wallet, or transferring the NFT into a Status wallet.
- Many users treasure their ENS Names and do not feel comfortable transferring their privkey into Status just to setup their ENS. Furthermore, the ENS may be owned by a L1 or L2 contract wallet such as a Gnosis Safe or Argent wallet or an existing hardware wallet beyond a Keycard, such as a Ledger, Trezor, Grid+ Lattice, etc. I believe this is a competitive disadvantage and seriously hindering adoption for new users who just want to use their existing ENS to chat without also adopting Status as a ETH wallet.
- There are no easily accessible DApp/Web3 UIs to call setPubkey(). The official ENS Manager DApp at app.ens.domains does not have the functionality to display the current Pubkey or set a new Pubkey. However, adding Text Records, such as a Github user name, e-mail address, Twitter handle, or Telegram handle is trivial and extensible through the addition of arbitrary keys. Although, I made some headway into making a one-page DApp to call setPubkey() this is not a sustainable solution, and having users manage their ENS metadata through a one-off DApp rather than through the official ENS portal is bad UI/UX nor should users be encouraged to trust one-off DApps.
- Calling setPubkey() from Etherscan on the user’s chosen ENS Resolver is cumbersome and impossible for the non-technical user, requiring the user to splice their Chatkey hex string to extract the secp256k1 x/y coordinates of their Pubkey and find/calculate the node id of their ENS name. app.ens.domains is unlikely to create a UI to handle parsing a secp256k1 key.
- Although, as far as I can tell, Status is the only user of setPubkey() at the moment, there is no established convention precluding other uses, potentially creating confusion down the road.
- Many tools understand ENS Text Records, such as Etherscan & eth.xyz, and will automatically generate hyperlinks. For example, setting
"vnd.twitter"=>"ethstatus"will result in a link tohttps://twitter.com/ethstatuson Etherscan’s ENS introspection page. Likewise, Status could ask such tools to generatehttps://join.status.im/u/0x1234links, increasing adoption.
Any other comments:
Given the above reasons, I propose the key im.status be used in an ENS Resolver to set a compressed chatkey per 2/ACCOUNT - Status Specification (modulo potential extensions mentioned below).
Clients should gracefully fallback to calling pubkey() if text('im.status') is not available, however to prevent confusion, text('im.status') should superscede pubkey() if both are available, primarily, in order to prevent ambiguity in the case the pubkeys differ and, secondarily, for reason #5 above.
Furthermore, by using text records, im.status may point to a Community or Group Chatkey if desired, for example, status.eth may point to a Community rather than an individual user. Perhaps it may be necessary to have a flag such as c/0x1234 preceding a community key, or even a full JSON blob. Alternatively, the key for im.status could be a status-im protocol link such as status-im://0x1234. Or perhaps subkeys like im.status.community may be the preferred design. Ultimately, whatever the text key(s) for im.status or im.status.* become they should be human-readable so that users can troubleshoot for themselves using standard tools like app.ens.domains.
Finally, (not relevant to the current topic, but for consideration in concert with the topics mentioned above), there could be a reverse record registry for pubkeys if that becomes desirable or useful.
Relevant Links:
https://medium.com/the-ethereum-name-service/new-custom-text-records-means-every-project-can-have-its-own-ens-record-a68022bb8f86