search

ethereum / EIPs

The Ethereum Improvement Proposal repository
https://eips.ethereum.org/
Creative Commons Zero v1.0 Universal
12.82k stars 5.24k forks source link

EIP-634: Storage of text records in ENS #2439

Closed ricmoo closed 1 year ago

ricmoo commented 4 years ago

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 commented 4 years ago

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 https://github.com/eip-automerger/automerger/issues/7

ricmoo commented 4 years ago

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 commented 4 years ago

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:

axic commented 4 years ago

Why not include them in the EIP?

ricmoo commented 4 years ago

@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 commented 4 years ago

For phone number, please specify E.164 formatting.

You can edit the above example to: +14165551496

ricmoo commented 4 years ago

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:

axic commented 4 years ago

@ricmoo I think it sounds looks a nice idea.

yenda commented 4 years ago

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

brantlymillegan commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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

brantlymillegan commented 4 years ago

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

wpmonty commented 4 years ago

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 commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

hesusruiz commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@ricmoo I propose default text record keys for:

github-actions[bot] commented 2 years ago

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 commented 2 years ago

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[bot] commented 2 years ago

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[bot] commented 2 years ago

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 commented 1 year ago

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:

Screenshot 2022-09-30 at 13 23 47

https://user-images.githubusercontent.com/742796/193263680-969bca92-89bc-430d-aa89-c889c314e9c6.mov

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

dont-cut-artwork

markvital commented 1 year ago

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

fit-me-into-square

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 commented 1 year ago

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 commented 1 year ago

Why not a multiaddr?

SamWilsn commented 1 year ago

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