ENSIP-18: Profile Text Records

[TateB]

opening feedback for the ENS profile spec, most crucially for:

• color-scheme, how it should be formatted, etc
• avatar/header design considerations (cropping)

[serenae-fansubs]

Thoughts about a standard video and/or audio record?

It doesn't come up often, but a few people have asked for that. Usually in the context of an avatar, like they're trying to put an MP4 file for that avatar which won't work most places.

This could be an intro video for a project/company, or a CV (video reel / audio reel), or just anything that the ENS user would like people to see or hear when they visit their profile, on any sites that happen to support it.

[TateB]

This could be an intro video for a project/company, or a CV (video reel / audio reel), or just anything that the ENS user would like people to see or hear when they visit their profile, on any sites that happen to support it.

hmm... myspace throwback... could be nice, but that feels like it's verging on "profile content" rather than "profile describers", am definitely open to it though

[ukstv]

It would be nice also to have a list of all the various text records seen in the wild along with the examples of how it should be displayed. Kind of HIG thing.

[mehdi-loup]

It would be nice also to have a list of all the various text records seen in the wild along with the examples of how it should be displayed. Kind of HIG thing.

Here is a list of the top20 text records (+count) based on our indexing at Zapper:

1. avatar (93 924)
2. com.twitter (30 710)
3. url (27 031)
4. email (25 049)
5. snapshot (14 300)
6. description (12 360)
7. com.discord (8 836)
8. com.github (7 022)
9. keywords (5 447)
10. org.telegram (4 731)
11. vnd.twitter (2 129)
12. notice (2 114)
13. name (2 104)
14. com.reddit (1 952)
15. eth.ens.delegate (1 660)
16. header (1 006)
17. vnd.github (1 001)
18. me.rainbow.displayName (619)
19. com.instagram (457)
20. location (242)

[ukstv]

@mehdi-loup OH wow! Niiicee! TYTY

[adraffy]

Just throwing out some random ideas and thoughts:

• is the expectation that header is always an asset? eg. to encode a solid color, you'd embed a 1-pixel data URL?
• will header support the eip155:chain/type:contract/token convention? can we generalize this to an URL convention that calls a contract function? can we embed an ENS in it?
• for records that reference external assets, should we outline the accepted mimes and provide target file sizes? eg. using an MP4 in "avatar". Should there be a convention for timeouts? eg. stale/dead IPFS data
• "appearance" — {dark, light} preference
• "text-zoom" — decimal float (1 = 100%)
• anything accessibility related
• "day-format" — YMD preference
• "ens-owner" — ENS name of owner/parent
• "purchase-contact" — how to contact the owner regarding the name itself
• "public-texts" — comma-separated list of keys you'd like shown on public profiles
• "profile-json-url" — url to external json object with additional data
• "accent-color"
• "display" — ENSIP-5 and https://discuss.ens.domains/t/ens-display-name-firstlast-eth-or-capslock-eth/8679
• "primary-contact" — a key that indicates your preferred contact (email, phone, com.twitter, etc...)
• "occupation"
• "cv" — URL for resume
• "url-embed" — url to miniature profile page for fixed aspect (3:1)
• "com.discord" has the issue: is it a user, a discord, or an invite code?
• "com.twitter" has the issue: is it a user, a hashtag, or a community?
• for all socials: do we include the prefix: @, /u/, ...
• records that correspond to information about you are kinda different from records that correspond to your preferences — should there be a key-prefix for preference-style variables? I guess this is related to the global/profile/service key distinction?
• ENS is a globalStorage? (like localStorage?)
• should there be a convention for combining 2+ values into 1 record? or a standard separator? or handle this per-record?
• is it better to "pack" simple things into a single record (dark mode bit) vs having dedicated record ("appearance") with low density data?
• should records that reference external resources have sanitation rules? eg. blindly inserting records into HTML eg. url → https://"><script>... https://url.spec.whatwg.org/
• should there be generic types, like avatar and header are ImageResources, things that are names must be normalizable, urls must be spec, contacts must be email | url | ...
• could the URL spec get a query string injection? eg. attach ?namehash=0x...
• how do you reference another key of your own record? eg. email = "[email protected]"; primary-contact = this.email (obviously not this syntax though)
• I agree with @ukstv, all records should have examples (good and bad)

[TateB]

• is the expectation that header is always an asset? eg. to encode a solid color, you'd embed a 1-pixel data URL?

yes

• will header support the eip155:chain/type:contract/token convention? can we generalize this to an URL convention that calls a contract function? can we embed an ENS in it?

header follows ENSIP-12, which outlines that you can use both CAIP-22, and CAIP-29.
can you clarify what you mean by "generalize this to a URL convention that calls a contract function"? i imagine it would be out of scope for this EIP.

• for records that reference external assets, should we outline the accepted mimes and provide target file sizes? eg. using an MP4 in "avatar". Should there be a convention for timeouts? eg. stale/dead IPFS data

accepted MIMEs are outlined in ENSIP-12, but target file sizes are not so it might be worth adding it to that existing spec since it's still a draft. imo timeout handling should be down to client implementation rather than the spec itself.

• "appearance" — {dark, light} preference
• "text-zoom" — decimal float (1 = 100%)
• anything accessibility related
• "day-format" — YMD preference

i don't think records that would never affect external viewers are particularly relevant.

• "ens-owner" — ENS name of owner/parent

this can just be dynamically resolved via ENS

• "purchase-contact" — how to contact the owner regarding the name itself

this has a lot of overlap with your suggested primary-contact, which i think is significantly more useful as a concept

• "public-texts" — comma-separated list of keys you'd like shown on public profiles

when setting text records on a (public) ens name, isn't this already assumed for every record?

• "profile-json-url" — url to external json object with additional data

not sure how useful this would be, can you give an example?

• "accent-color"

already included in color-scheme

• "display" — ENSIP-5 and https://discuss.ens.domains/t/ens-display-name-firstlast-eth-or-capslock-eth/8679

i was aware of this record, but i'm reluctant to expand support for it given existing handling for usernames/domain names/emails and the reasons that those all tend to be lower-cased.

• "primary-contact" — a key that indicates your preferred contact (email, phone, com.twitter, etc...)

definitely think this is a useful idea, will add.

• "occupation"
• "cv" — URL for resume

i think there is reason to potentially add those as global keys at some point, but as with some of the pre-existing global keys (notice/keywords/etc), they're outside of the "generic profile" scope imo.

• "url-embed" — url to miniature profile page for fixed aspect (3:1)

can't really see this being implemented in many places. there would also be various security issues with this.

• "com.discord" has the issue: is it a user, a discord, or an invite code?
• "com.twitter" has the issue: is it a user, a hashtag, or a community?
• for all socials: do we include the prefix: @, /u/, ...

i'll add a section regarding vendor usernames. they should always be without any sort of prefix/suffixes.

• records that correspond to information about you are kinda different from records that correspond to your preferences — should there be a key-prefix for preference-style variables? I guess this is related to the global/profile/service key distinction?

currently i don't think this spec includes internal preferences, not sure what records you're talking about specifically

• ENS is a globalStorage? (like localStorage?)

yes

• should there be a convention for combining 2+ values into 1 record? or a standard separator? or handle this per-record?

not opposed to creating a convention for it but given the very limited use-cases for it, i don't think it's necessary right now

• is it better to "pack" simple things into a single record (dark mode bit) vs having dedicated record ("appearance") with low density data?

it's very context specific, but i don't think we need to worry about that right now

• should records that reference external resources have sanitation rules? eg. blindly inserting records into HTML eg. url → https://"><script>... https://url.spec.whatwg.org/

i think value sanitation is implied

• should there be generic types, like avatar and header are ImageResources, things that are names must be normalizable, urls must be spec, contacts must be email | url | ...

this is pretty much already applied. image resources are ENSIP-12, urls must be valid, timezone is from tz database, etc

• could the URL spec get a query string injection? eg. attach ?namehash=0x...

what would this be used for?

• how do you reference another key of your own record? eg. email = "[email protected]"; primary-contact = this.email (obviously not this syntax though)

this would just be useful for primary-contact, right? in which case it's just context specific and can be inferred

• I agree with @ukstv, all records should have examples (good and bad)

will add examples

[galligan]

@TateB love this! I definitely think there's some huge room for improvement in ENS profiles. Selfishly I think that messaging use cases (such as with XMTP) could benefit a lot from some of the additions you've proposed here.

Questions/Feedback

(in no specific order)

name

Do you think that name as a global key might get confused with "ENS name"? My specific concern is that without context when reading the keys, this might be confusing—especially in instances where it's set to the same value as the ENS name. Perhaps alias might help to distinguish it?

I saw in @mehdi-loup's post that name has a bit of use—not sure if that overlap could create unintended consequences, so worth mentioning.

theme

I love the idea of providing some additional customization to one's ENS theme—it could start to act as a hub for a "web3 linktree" type thing. It's clear you've already thought about some of the challenges around passing in specific hex values for colors—notably where you call out contrast ratios.

Enabling front-ends (including ENS manager) to easily adhere to WCAG guidelines, as well as…well…just reigning in some aesthetically questionable color choices, may be something helpful to explore here. While ENS itself, by way of the record, should express no specific opinion on color choice (hex values), there should be a simple means by which front-ends can have a bit more opinion in the interest of better UI. Perhaps alongside an update like this, there could be a simple nearest color app that could be socialized. I'd imagine it as a developer passing in a list of color values (such as the Tailwind colors library), and having the app pick the nearest neighbor—possibly with a little bit of extra logic to get the contrast right.

All in all, I like the use of hex values here—just think it would be helpful to find a way for it to not also make it tough on people's eyes, or see themes depart significantly from an app's palette.

avatar

The image should not have any visible blank space.

I'm wondering if there's a way to get a little bit more specific here. It's unclear to me if this is guidance for developers building front-ends that can manage avatars, or for those displaying avatars. Perhaps it's both?

header

This is more of an opinion on language, but "header" seems to imply a specific placement on a page—makes me think of Twitter a little bit, and their header image. A name that pops out to me is cover which might convey the same intended meaning, but without an implication of placement. To each their own though, just thought I'd bring it up.

location

Just a small language nit here, more from the perspective of a developer reading the docs.

This shouldn't be resolved to real coordinates, as it can be a non-existent location.

"This value should not be assumed to be real coordinates or properly formatted place, as it may be a non-existent location"

Profile Service Key compatibility with decentralized social

One thing that intrigues me about this one is in how social "mu" namespace has evolved since ENSIP-5—specifically in the growing adoption of decentralized protocols. For protocols like ActivityPub (Threads, Mastodon), AT (Bluesky), or Farcaster, there may more than just a domain consideration.

For example, @[email protected] might be my Mastodon username (in which case the @ symbols are service-specific, but necessary, and my AT protocol profile might be @matt.galligan.xyz. In either case, I'm not sure what the record key should necessarily be.

Farcaster makes use of an ENS namespace for its IDs, such as *.fcast.id, which does not resolve on its own—one would need to use a front end for the Farcaster protocol.

Messaging with XMTP also has a similar challenge in that there are many front-ends, and people have their choice of which to use when wanting to send a message.

The current restriction of Service Keys must contain at least one dot doesn't have straightforward compatibility with some of the use cases above. @TateB Have you considered, or have you seen any ideas on how these sorts of cases might be included in an ENS profile?

[adraffy]

@TateB I appreciate all the responses! I think I got off-track when I interpreted "color-scheme" as a preference and then started thinking about user-settings... 😆️

• profile-json-url would just be a simple off-chain extension, eg. point to some external asset, https://abc.com/profile.json which is simply {"url": "https://...", "avatar": ...} that gets merged into the standard profile values.

Again, not advocating, just brainstorming.

---

Do we need anything like an optional "avatar-small"? For when you're loading profile pics on a leaderboard-like page? Or maybe an <img srcset> like syntax for "avatar" and other image keys so you could include an iconified file? Kind of a shame the web didn't implement this as just query string with various URIs encoded for different size keys...

[TateB]

name

Do you think that name as a global key might get confused with "ENS name"? My specific concern is that without context when reading the keys, this might be confusing—especially in instances where it's set to the same value as the ENS name. Perhaps alias might help to distinguish it?

I saw in @mehdi-loup's post that name has a bit of use—not sure if that overlap could create unintended consequences, so worth mentioning.

there is definitely potential for confusion, but as you identified, the main reason for name is the pre-existing utilisation.
alias sounds like a suitable alternative to me though, can't think of any other reasons not to switch

Enabling front-ends (including ENS manager) to easily adhere to WCAG guidelines, as well as…well…just reigning in some aesthetically questionable color choices, may be something helpful to explore here. While ENS itself, by way of the record, should express no specific opinion on color choice (hex values), there should be a simple means by which front-ends can have a bit more opinion in the interest of better UI. Perhaps alongside an update like this, there could be a simple nearest color app that could be socialized. I'd imagine it as a developer passing in a list of color values (such as the Tailwind colors library), and having the app pick the nearest neighbor—possibly with a little bit of extra logic to get the contrast right.

the spec briefly touches on nearest neighbour colours, but an example implementation/library for other apps to use makes sense to me

I'm wondering if there's a way to get a little bit more specific here. It's unclear to me if this is guidance for developers building front-ends that can manage avatars, or for those displaying avatars. Perhaps it's both?

this is specifically about cropping, both for setting and retrieving avatars. "blank space" refers to the avatar not fitting the 1:1 aspect ratio. when setting, it means making sure the avatar is 1:1 aspect ratio (for non-nft images). when retrieving, it means if an avatar isn't 1:1, it should be filled to be 1:1 from the centre with no extra space. i'll try to reword the "blank space" sentence but i might just remove it, seems like it creates more confusion.

This is more of an opinion on language, but "header" seems to imply a specific placement on a page—makes me think of Twitter a little bit, and their header image. A name that pops out to me is cover which might convey the same intended meaning, but without an implication of placement. To each their own though, just thought I'd bring it up.

it's intentional that header has an implication of placement. a user would potentially want to use a different image if it were placed elsewhere on a page (e.g. footer). header also has pre-existing usage so i'm inclined to just keep using it unless there's a very strong reason not to.

Just a small language nit here, more from the perspective of a developer reading the docs.

This shouldn't be resolved to real coordinates, as it can be a non-existent location.

"This value should not be assumed to be real coordinates or properly formatted place, as it may be a non-existent location"

will add

For example, @[email protected] might be my Mastodon username (in which case the @ symbols are service-specific, but necessary, and my AT protocol profile might be @matt.galligan.xyz. In either case, I'm not sure what the record key should necessarily be.

i'll add that specifically optional service-specific symbols should be removed, rather than all

Farcaster makes use of an ENS namespace for its IDs, such as *.fcast.id, which does not resolve on its own—one would need to use a front end for the Farcaster protocol.

Messaging with XMTP also has a similar challenge in that there are many front-ends, and people have their choice of which to use when wanting to send a message.

The current restriction of Service Keys must contain at least one dot doesn't have straightforward compatibility with some of the use cases above. @TateB Have you considered, or have you seen any ideas on how these sorts of cases might be included in an ENS profile?

can you clarify what you're saying here? i don't really get what you're suggesting

[TateB]

Do we need anything like an optional "avatar-small"? For when you're loading profile pics on a leaderboard-like page? Or maybe an <img srcset> like syntax for "avatar" and other image keys so you could include an iconified file? Kind of a shame the web didn't implement this as just query string with various URIs encoded for different size keys...

generally i don't know how willing someone would be to spend pretty much 2x gas for something they won't benefit from. we could create a standard for a query string to use when retrieving avatars/headers though. it wouldn't be that hard to implement into existing ENS avatar resolution implementations

[Dsinghbailey]

Would a query string solve file size considerations for the avatar/header?

Running a smooth dapp can be rough when someone logs in with a 1 gig profile pic and it'd be nice to not have to resize on the fly.

Alternatively/ Additionally: consider a max file size recommendation for avatar/headers?

[access0r]

Do we need anything like an optional "avatar-small"? For when you're loading profile pics on a leaderboard-like page? Or maybe an <img srcset> like syntax for "avatar" and other image keys so you could include an iconified file? Kind of a shame the web didn't implement this as just query string with various URIs encoded for different size keys...

generally i don't know how willing someone would be to spend pretty much 2x gas for something they won't benefit from. we could create a standard for a query string to use when retrieving avatars/headers though. it wouldn't be that hard to implement into existing ENS avatar resolution implementations

I think 64px, 128px, 256px, 512px are good choices. Maybe an option to load a high-res with a limit size?
Should have a configuration file. Look at my ens-tooltip. This tooltip returns all ENS text records when the plugin is added. Automatically generates a HTML Element based on the returned key name.

[cloudflare-workers-and-pages]

Deploying ens-docs with    Cloudflare Pages

Latest commit:	f5a64f5
Status:	⚡️  Build in progress...

View logs