EIP-634: Storage of text records in ENS

[ricmoo]

This is a discussions-to thread (as per EIP-1) for: EIP-634 Storage of text records in ENS.

This topic section may be updated occasionally to reflect additional information which becomes relevant to interested parties.

[axic]

There seem to be support for this resolver in ENS already. Is this widely supported? If it is, it would make sense trying to bring this ERC to the Final state.

I'd be interested in it for eip-automerger/automerger#7

[ricmoo]

I added and deployed this as the public resolver (resolver.eth) about 2.5 years ago, and it has been in every public resolver since, so I think we're good in terms of adoption. :)

[ricmoo]

Someone suggested a list of additional fields somewhere, but I cannot find it now. Some come to mind from that list and I will add it here. I think it makes sense to keep this one comment up to date with others' suggestions too. These may make more sense to expand into a separate EIP.

Field	Description	Examples
phone	A phone number using E.164	+1 416 555 1496
location	A geographic location	Toronto, Canada
geo	A GPS co-ordinate using decimal notation	-79.387057, 43.642566

Notes:

• GPS locations should be in decimal format (not minutes/seconds), separated by a comma and all whitespace should be ignored.

[axic]

Why not include them in the EIP?

[ricmoo]

@axic, I was thinking they should be up for discussion before including them in case someone has objections? Or in case there is a better standard I don't know about, for example to encode a GPS location or an ISO-XXXX for locations, addresses, etc.

[fulldecent]

For phone number, please specify E.164 formatting.

You can edit the above example to: +14165551496

[ricmoo]

Thinking out loud...

What about something for a label's canonical case used for display logic? It would need to be enforced (by the client) that the namehash(name) === namehash(canonical) (if not, ignore this field), but would allow clients to show case, for example:

• RicMoo.eth
• MetaMask.eth
• MyCrypto.eth

[axic]

@ricmoo I think it sounds looks a nice idea.

[yenda]

Shouldn't avatar be a contenthash (EIP-1577) rather than a URL?

[brantlymillegan]

Someone suggested a list of additional fields somewhere, but I cannot find it now. Some come to mind from that list and I will add it here. I think it makes sense to keep this one comment up to date with others' suggestions too. These may make more sense to expand into a separate EIP.

Field Description Examples
phone A phone number using E.164 +1 416 555 1496
location A geographic location Toronto, Canada
geo A GPS co-ordinate using decimal notation -79.387057, 43.642566
Notes:

• GPS locations should be in decimal format (not minutes/seconds), separated by a comma and all whitespace should be ignored.

I love this. What would we need to do to merge this to the EIP? Wondering if this got stopped due to some concerns articulated elsewhere @ricmoo

[ricmoo]

Oh, no. It’s still on-going. This thread is for discussions about new fields. I just want more community feedback before committing anything. :)

[brantlymillegan]

@ricmoo May I propose the following additional keys:

mail: a mailing address
pgp: a PGP public key (any considerations we need based on how big this would be?)
vnd.telegram: a Telegram handle
vnd.keybase: a Keybase handle
vnd.linkedin: URL slug that goes after https://www.linkedin.com/in/

Is there a good reason why we shouldn't just add standard keys for the handles of the top 20 social networks/chat apps?

[axic]

I've created a draft suggestion (just didn't push the PR) and included these:

+- **vnd.gitlab** - a GitLab username
+- **vnd.peepeth** - a Peepeth username
+- **vnd.twitter** - a Twitter username
+- **vnd.keybase** - a Keybase username
+- **vnd.reddit** - a Reddit username

So I'd second @brantlymillegan's keybase suggestion.

However I would say PGP doesn't fit in here, but should have its own specification for both fingerprint and public key. Reason: it takes less space storing it as a binary, than its text serialisation.

[brantlymillegan]

@axic Thanks. And yes, I agree re PGP.

[brantlymillegan]

Should the EIP specific an aspect ratio for avatars, e.g. 1 x 1?

[wpmonty]

Name: name.first, name.last, name.middle, name.prefix, name.suffix, name.nickname
PGP Fingerprint if not Public Key 💯
Reddit, Twitter, Facebook, LinkedIn, Github

[ricmoo]

Heya! Sorry for the delay... There was some discussion (I think on Twitter), about using reverse dot notation for vendor keys.

I think the ones already suggested should remain (e.g. vnd.twitter), but going forward any service may use their domain name as their key, without any need to update this EIP. For some examples:

• com.gitlab.user
• com.gitlab.project
• com.peepeth.profile
• io.keybase.user
• com.reddit.profile

Of course, each service can decide how they want their hierarchal namespace broken up. Perhaps keybase simply wants io.keybase. But this allows each service to add additional categories.

Also, a service can use any fully-qualified name they own. So, peepeth may decide to use eth.peepeth (if they own it? I'm not actually sure) for example.

What do people think? I will take a look and merge the above suggestions that don't conflict with this one next week and depending on what the discussions lead to, include the rest too.

[MicahZoltu]

Why retain vnd.twitter instead of com.twitter.<handle>? That seems like an unnecessary outlier recommendation when we could just have a standardized format.

[ricmoo]

I do agree, except things are already using it.

Maybe there could be a “applications SHOULD check for com.twitter.user then vnd.twitter, with the former superseding the later and application MUST set the former and MAY also set the later for legacy support”?

Although, maybe it is enough to coordinate with the ENS app, which I think other than maybe ethers CLI is the only thing I know of that uses it?

[ricmoo]

@wpmonty sounds good. In addition, the name namespace should have a name.phonetic, which is often used in Japanese names (and likely other CJK?).

[MicahZoltu]

For standards, I recommend thinking about 5-10 years in the future rather than right now. If the standard you want is com.twitter.<handle> then specify that and leave out the rest. In the backward compatibility section it may be worth mentioning that an earlier draft used vnd.twitter and some people may have names with that so tools may want to query that as a backup for an unspecified amount of time, but I wouldn't include it as part of the specification.

[brantlymillegan]

For standards, I recommend thinking about 5-10 years in the future rather than right now. If the standard you want is com.twitter.<handle> then specify that and leave out the rest. In the backward compatibility section it may be worth mentioning that an earlier draft used vnd.twitter and some people may have names with that so tools may want to query that as a backup for an unspecified amount of time, but I wouldn't include it as part of the specification.

I tend to agree. Also, I'd bet very few people or dapps (if any) are making use of this right now. Not sure how hard it would be for someone to run a check?

[ricmoo]

Sounds perfect. I'll just make a backwards compatibility note. :)

[hesusruiz]

Sorry to jump into the conversation so late. I think TextResolver is very interesting for many use cases where I am involved.

Have you considered using for the names of standard keys the vocabulary of Schema.org? It is used heavily in other environments and it defines not only the names of many attributes for many entities, but also in many instances the semantics involved and the specific format for the values.

For example, here you have the attributes for Person (https://schema.org/Person), including of course name, address, birthDate, etc.

Another example is GeoCoordinates (https://schema.org/GeoCoordinates), where if you use latitude and longitude, the spec requires to use WGS 84 for their values.

This may reduce creeping of vendor keys for many use cases where they want essentially the same entity. Even in the cases where the entity is not in Schema.org, there is a defined process to extend the vocabulary, either to the base vocabulary or creating and industry-specific extension. For example, see here for the Automotive extension: https://schema.org/docs/automotive.html and here for Banks and Financial Institutions: https://schema.org/docs/financial.html.

[MicahZoltu]

Shouldn't avatar be a contenthash (EIP-1577) rather than a URL?

This was never answered, and now that I'm actually using ENS a bit more I do feel pretty strongly that this should be the case. I believe we should really be building things to be censorship resistant by default, and part of that means making choices that make censorship resistance the easiest path for integrators to take.

By having avatar be a URL, you can use ipfs://... but almost everyone who adds support for displaying an Avatar will add support for http://... and call it a day. By using content hash instead, all of those apps will instead take the easy path of fetching from IPFS and/or a gateway, which allows users who desire censorship resistance of their ENS content to actually work properly.

As a prime example, the ENS manager app itself doesn't support ipfs://... because the easy solution was to just do <img src=...>. If this was a content hash, that app would have instead done something like https://ipfs.io/ipfs/<contenthash>. As is, someone who puts a censorship resistant URL in won't work even in the ENS app itself, while someone who puts in a censorable avatar URL will work great.

[ricmoo]

This is another reason I need to update it to allow dotted notation. There is often nested data you want to include, and you could imagine a solution similar to how namecoin's website did it back in the day, which is to allow a "proof" field.

So, for example, I want a com.twitter.profile of "ricmoo" and a com.twitter.profile.proof to be a url (on my twitter) to a tweet that verifies the two-way peg. So, you could imagine a avatar.hash which maps to the hash of the content. I'm still not sold on this idea though. I think we need something similar to text / setText for bytes / getBytes. A lot of data makes more sense as raw data, and let the key be in charge of specifying how the dat should be interpreted. In that same guise, the things currently handled by text could just be in bytes, and the keys are known the data should be used as utf-8 data for things like com.twitter and website.

I have earmarked some time this week to catch up on this EIP and a bunch of other things I've been putting of way too long. Would love to get some active discussions this week.

[heyJonBray]

Why retain vnd.twitter instead of com.twitter.<handle>? That seems like an unnecessary outlier recommendation when we could just have a standardized format.

Yeah this was very very non-intuitive when setting up. Essentially every application of said notation uses com.website.handle.* format. The vnd.* just seems... strange.

Also, regarding PGP keys and their size, it may make more sense to add your PGP fingerprint and make use of a keyserver? Either query existing keyservers or have a dedicated one for .eth domains.

[brantlymillegan]

@ricmoo I propose default text record keys for:

• Header image for a profile page. Should we have a namespace for images? "image.header", "image.avatar", "image.nft" (for replacing ENS NFT image), etc? Or this could just be "header" since we already have "avatar" as it's own thing.
• Your name (legal name or pseudonym, whatever you want to go by). @wpmonty proposed having a namespace for different names ("name.first", "name.last", etc) but idk seems complicated to me? Simply "name" could suffice and people could put either their real name or pseudonym (whatever they want) in it
• Where you are located. You already proposed "geo" and that could work for me. Also "location" could work
• Birthdate. Could just be "birthdate"

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[ricmoo]

I am considering moving this EIP to withdrawn, once we have a similar repo to EIPs for ENS, citing the reason that it is being moved to that repo.

Does this sound good?

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

There has been no activity on this issue for six months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[markvital]

brantlymillegan
Should the EIP specific an aspect ratio for avatars, e.g. 1 x 1?

@brantlymillegan I think there should be a placement option for avatars. Something like this

avatar : "1/erc721:0xbd3531da5cf5857e7cfaa92426877b022e612cf8/395",
avatar.placement : "crop_left" // or 'crop_right', 'crop_center', 'crop_top', 'crop_right_10%', etc...

Similar to how avatars work on social media and web/mobile services: when a user selects a picture for an avatar, she can move the cropping window.

Here are the examples from my Facebook and Twitter:

Screen.Recording.2022-09-30.at.13.20.42.mov

What worries me is that some heads can be cut in half and the users can’t do anything.

[markvital]

Another perhaps less pressing problem might be that some 👥 artists and 👥 designers might not be happy about cropping their arwork at all.

So it might make sence to consider adding an option to fit the artwork into a square:

avatar" : "1/erc721:0xbd3531da5cf5857e7cfaa92426877b022e612cf8/395",
avatar.placement : "fit" // fits into a square

I think this feature might play well together with ENS background gradients

@brantlymillegan what do you think?

[Atlasoin]

Shouldn't avatar be a contenthash (EIP-1577) rather than a URL?

This was never answered, and now that I'm actually using ENS a bit more I do feel pretty strongly that this should be the case. I believe we should really be building things to be censorship resistant by default, and part of that means making choices that make censorship resistance the easiest path for integrators to take.

By having avatar be a URL, you can use ipfs://... but almost everyone who adds support for displaying an Avatar will add support for http://... and call it a day. By using content hash instead, all of those apps will instead take the easy path of fetching from IPFS and/or a gateway, which allows users who desire censorship resistance of their ENS content to actually work properly.

As a prime example, the ENS manager app itself doesn't support ipfs://... because the easy solution was to just do <img src=...>. If this was a content hash, that app would have instead done something like https://ipfs.io/ipfs/<contenthash>. As is, someone who puts a censorship resistant URL in won't work even in the ENS app itself, while someone who puts in a censorable avatar URL will work great.

Sorry to jump into this discussion.

With the confusion "Why not all text records are content hash rather than a URL? Or otherwise why not EIP-1577 use a URL just like other text records, rather than a content hash?" in my mind, I browsed and came to this discussion seeing your explanation.

It seems content hash is used to make the resource identification by design in a censorship-resistant approach. But I am wondering if the content hash is designed to exclude all non-censorhsip-resistant protocols? E.g. if having avatar be content hash, will an HTTPS URL encoded in multiformat be supported? Or only "hash" related protocol(ipfs/arweave...) supported?

[Pandapip1]

Why not a multiaddr?

[SamWilsn]

A discussion thread has been opened for this proposal: https://ethereum-magicians.org/t/eip-634-storage-of-text-records-in-ens/14138/2