NFT 'Showcase' ENS record and record standardization

🧑‍💻 ENS Development Developer Help
1

Hi frens,

Checking in from Twitter :saluting_face:. I have mentioned this there before but thought the forum might be the best place for action, and to reach the right people. I’ve been thinking a lot about ENS records, I feel like they are so powerful and the possibilities endless, especially with ccip coming up, making it much cheaper to set or change them :slight_smile:

The goal of this post is to suggest a new record ‘standard’ or ‘keyword’ and to ask how such a new standard would be formalized so it could be easily and widely adopted. (as hopefully there will be many more use cases, ideas and suggestions for new types of records in the future)

So first off, the record I am thinking about; I think a ‘showcase’ record would be amazing. Or a ‘featured section’ of your NFTs. So you (the owner) could decide which NFTs get shown first anywhere your wallet gets loaded, without you having to set that preference on every website (if even possible).

Soo much stuff is going on in crypto it’s hard to keep up, every day there’s a new dapp and of most I’m probably unaware. The majority have some sort of address page, where individual wallets are viewed. Like coinbase just launched their profiles or mint.fun too a couple days ago. But there’s maany more, these are just recent examples, and I imagine everyone has their personal favorites. (etherscan opensea ensvision rainbow debank zerion nimi .xyz .co tap etc etc(sorry don’t mean to leave anybody out)) There’s easily more than a hundred places that load your wallet addres (and the assets it holds), from more financially focused ones to more socially or nft oriented. The people reading this probably all understand how useful it is for your ENS name, avatar, bio and socials to show up automatically on each one of those platforms (records🤯). And how much easier it is then filling out the same info everywhere. Setting records not only turns your complicated address into a human-readable one (hopefully😂) but makes your account more personal, gives it more context and makes you easier to reach (if you want). Like ENS records turn your addres into a profile. And nfts are a (big) part of that.

I am by no means a ‘nft guy’, but I got a couple nfts that I like a lot and obviously I have some ens names that I love too hahah. Sometimes I like to show them to people, irl or online. And I use my .eth for that :sparkles: I like to stare at them myself too tho. A lot lmaoo. So what really bugs me is when I visit some website that loads my wallet, and the nfts shown (on top) are random spam, some of my least favorite ones or just the newest. And I definitely don’t like the thought of people encountering my wallet that way. I care about my appearance haha :lipstick::sparkles:
This is why I love Opensea’s ‘featured section’. And Rainbow’s 'showcase’. That way I could choose which of my nfts (and even in what sequence) people visiting my profile see first. I can pick my favorite nfts to highlight or maybe show the ones I want to sell.

I think such a feature would be very useful and makes a lot of sense (not just for me personally) as a ENS record. So I could just decide that once and update it in one place, my primary .eth, and every dapp could just pull my nft preferences. It might help to show the power and flexibility of ENS records to more people too and push them to set more :raised_hands:

And now regarding standardization(?). So let’s say everyone here agrees this should be done. How does something like this get implemented? What steps should I go through? How would every dapp know to integrate this new record? Is it as simple as posting the question here to get it integrated into the ENS manager? Making a new global key? And then just making dapps aware of such a record? What kind of/who’s approval would this need? ENS-IP and vote seems exaggerated, but obviously there needs to be agreement on a specific format. And I am not sure exactly what the best way technically is to implement this. Custom records are cool but I think some standard is necessary for this to be adopted as people could name the same record differently.

For the showcase I thought simply reusing the format of setting an NFT as your avatar (eip155:1/[NFT standard]:[contract address for NFT collection]/[token ID or the number it is in the collection]) might work and maybe having a limit (ten or twelve?). Also, similar to setting an nft as your avatar there needs to be some check that you own the nft you want to showcase.

Maybe this didn’t require so much context haha, because it already kinda exists, but oh well this is what happened this morning after (a lot of) tea. Maybe it provides a bit more clarity on why I think this would be awesome to have! Maybe this already has been discussed somewhere? Maybe I am missing context?

Curious to hear what people think (am I crazy :crazy_face:/ is this excessive/do or don’t you like it?) and thanks for reading!

Love,

Broke.eth

P.S some other records I have been thinking about and might apply to this (and are set on melvin.eth) are a dark mode on/off and favorite color. And I know all of you good some great ideas too :sparkles:

10 Likes
2

You’ll encounter limitations in terms of cost to create and/or modify records. I’ve done this on Predomain for the featured items on your profile - your selections are saved on your ENS.

2 Likes
3

love this idea, and here is an immature format (if I understood what you described above correctly):

add a txt record whose key is “showcase”, and the related value should preferably an array, like:

[
    "<NFT Contract Address A>:<TokenID A1>", 
    "<NFT Contract Address A>:<TokenID A2>", 
    "<NFT Contract Address B>:<TokenID B1>", 
   ...
]

users could generate this value by selecting specific NFTs from his wallet.

2 Likes
4

Thanks for reply Wolfram! Nice to see you again haha btw. No twitter anymore right?

Hopefully setting records will become cheaper soon. And maybe records like this could be set on l2. But still people set avatar etc atm too. Pretty expensive. Dont think that should be a reason not to do something like this.

Yeah its a great idea (def not really mine) but in the situation you’re describing, could those preferences be used by other dapps etc too? I mean if so why not set every record in such a manner?

2 Likes
5

Thanks liubenben! Yeah that looks great I think you got it! There is some special format for nft avatar already. Looks like that and I think this could/should be the same?

But im unsure what exactly happened with ensip-12 / how exactly NFT avatars work precisely atm

1 Like
6

Yes, I think that maybe the more formal format for “showcase”.

2 Likes
7

I like your idea

2 Likes
8

This is a good idea, I want to highlight some challenges we should solve alongside this if we move forward with a standard.

Basically you’re proposing a standard to go from specifying “1” avatar to “N” avatars/NFTs. This is good and sensible.

My immediate response is “will the N NFTs always be the same in all contexts”

By analogy: Are your Top 8 MySpace friends the same? Are you Top 8 work friends the same as your Top 8 family members? I suspect not.

Will you always want to choose the exact same N NFTs and sort them in the exact same manner? MySpace Top 8 Friends was not a popular feature on subsequent networks. Humans are contextual.

So, some additional challenge and tradeoffs for you to consider in designing this:

  • can we support multiple different “top N NFTs”
  • should there be only one “Top N” list, or should there be multiple possible with a default
  • how to cheaply update K-th NFT without paying to write all?
  • expected behavior when a user transfers one of the NFTs out of their wallet.

For designing abstractions and standards, it’s good to have at least three unique examples in mind before committing to a standard.

I’d like to see at least three different, unique apps independently design and propose a standard before enshrining something at the protocol level.

3 Likes
9

Thanks for your detailed reply Cory.eth! Definitely things worth considering!

I really like how this sounds! Simple.

Although as you mention with fees, having avatar and ‘showcase’ records separated would probably save people transactions, especially as one might want to update their avatar but not their showcase or vice versa.

The two things do seem very similar, which is why I thought it would be an ‘easy’ thing to suggest and try to make happen. (lol)

Cheaply updating without writing all the nfts might be accomplished by some sort of layered keyword(?) as individual (custom) records. Instead of one long showcase record there would be 1.showcase 2.showcase 3.showcase etc. Although this might make setting up the showcase for users more expensive and querying it for apps more cumbersome. (need to look more into possibilities of this/feedback)

Regarding the different featured items lists, I don’t see the direct need but I do think it would be good to have this option as hopefully the range of applications using eth increases in future. It could probably be done just by having multiple separate showcase records and indicating in the dapp itself which one you want to use. (Otherwise default) This is not ideal and there might be a more elegant solution.

In ENSIP-12, nft as avatar, (docs) the solution to transferred NFTs without updating records (which I think is great) is, before a dapp resolves the avatar nft they verify if the nft is owned by the same addres the name resolves to, otherwise act as if record empty.

Sorry I know you guys must be busy with subdomain stuff atm but tagging @nick.eth and @matoken.eth here as you are the authors of ENSIP-12 and I can’t really find what I am looking for. It says the proposal is still in draft? Is there any documentation of the current avatar implementation? (/can you point me in the right direction) And could you maybe expound upon what the process is for adding new global keywords and thoughts on that versus custom records. As hopefully in the future records will be used more (weirdly)/differently. And having some sort of automatic standard(for more basic stuff) would be ideal imo.

I will put some more thought into this (as I said just kinda shooting from the hip here) and try to reach out to dapps this applies to and get their thoughts. If you are reading this and think this is a bad idea or I am overlooking stuff please let me know. I am no technical wizard. (Here or Twitter dms are open) And if you like it, leave a heart haha.

1 Like
10

You could always send your spam to the deadzero address.

1 Like
11

Hey @broke.eth, welcome to the forums! Really cool first post…

Using a “showcase” key could work as @liubenben mentioned, but then platforms would need to adhere to that standard in order for it to filter out items in a standard way. Plus, adding and updating that amount of data to a record on L1 would be quite costly in gas.

What might also be a solution is for a marketplace (or some third party) to create a filtering service, and then a service key related to that. You can read more on service keys ENSIP-5.

I guess similar to how OpenSea’s Seaport Contract can be used across marketplaces, some type of filtering service could be used by multiple platforms/dapps/wallets.

DM3 makes for an interesting use of service keys. Different idea (they are a messaging protocol), but use service keys in ENS records in a unique way.

image
image1088×221 34.6 KB

Something like: com.nftpreferences.showcase as a service key, but the service nftpreferences[.]com would need to actually exist, maintain the preferences (JSON file or something), but then also platforms/wallets/dapps would need to rely on that service key (and the service) to know what are the items that should appear in a user’s “showcase” of NFTs.

3 Likes
12

It’s not recommended to interact with any kind of tokens that show up in a wallet that aren’t recognized.

2 Likes
13

Hey Zadok7 thanks for the great reply. Really helpful!

I will look into dn3 implementation of the service keys some more. First thoughts, it makes a lot of sense to first ‘try out’ this function for ENS in this way (setting a record when making a showcase through a dapp) vs making a new global key. I’m still curious what that process would exactly look like tho. (New ENS-IP? Vote? etc. ENSIP-5 does mention the possibility to ‘update this document’)

Worth considering tho: Name of the record should probably remain neutral (not named after dapp where showcase record is set) and still must be standardized (showcase record set in one app should be the same as record set in another, so on a third both could be loaded). And at that point how much different is a global key? I guess it depends on how tough one is too add. Also, most other records are set through the ENS manager. (so might be bit confusing. def cool too tho, esp if Opensea and Rainbow (who have featured section already would adopt this))

I think the format of CAIP-22 and CAIP-29 (used in nft avatar resolution too* and as I stated above) would be ideal. As this would also allow for websites to filter (out) certain contracts. Like ENS mps could then easily only resolve showcased ENS nfts. But yeah am not married to this if theres a cheaper/better way ofc.

*status of ENSIP12 says ‘draft’ atm and it’s pretty hard to find exactly how this is implemented rn. I have set my nft avatar this way tho in the past so I know that it works :slight_smile:

Next steps:

  • Make concrete suggestion for record key (imma dm you @liubenben /others for help :joy:)

  • Approximate how costly exactly setting these records would be. (On eth l1 in different configs)

  • Check interest of dapps in integrating this (/try to get (loose) commitments​:crossed_fingers: . I have been asking/shouting around bit already for feedback :grimacing::joy:)

p.s I hate spam NFTs and really would love my fav NFTs on top everywhere broke.eth/melvin.eth gets loaded

1 Like
14

I generally like the idea of setting ENS records that show your preferences. 1 way that may be possible to do this is to add each NFT to a record, and then using one record to put it all together. e.g:

"1.nft": "<NFT Contract Address A>:<TokenID A1>"
"2.nft": "<NFT Contract Address A>:<TokenID A2>"
"3.nft": "<NFT Contract Address B>:<TokenID B1>"

And then you could do things like textRecords['top nfts'] = "2,1,3"
And then use the same references for another type of list: textRecords['avatar'] = "1,2,3"

The above design would make it likely more expensive to create the NFT references, but cheaper to update different lists of NFTs. On standardisation, I think this could definitely be some kind of ENSIP if we were going to do it

4 Likes
15

Hi @jefflau.eth thanks for the reply, this is very clean! Simple and kinda combines everything above :slight_smile:

Still a bit confused on why ‘eip155/’ prefix is used for the nft avatar if this is possible?

As short as possible is definitely best tho. One of these records would be the same length as an avatar or url— so setting ten and changing them frequently would get pricey (iirc >$3 at 20gwei) (coming from someone who set like 50 avatars tho lol). Layer 2 would be ideal. I guess that should be possible?

I will look to get more feedback from people. Make a list for who it might be interesting to integrate. From my (limited) checking I have the feeling I am not alone. And some apps already have this feature/ are specialized in ‘showing your NFTs nicely’. Doesn’t mean people would actually (pay to) set this. But onchain>>>

Again why this might be interesting:

For individuals- show others your favorite NFTs, make sure your address looks nice/ the same everywhere

For marketplaces, social apps and nft explorers- cleaner discovery and user experience (for users and to onboard new), middle ground between showing (hundreds of) NFTs yes/no

For NFT projects, promotional, ask (reimburse?) your community to ‘favorite’ the NFT (a bit farfetched maybe as isn’t done for avatars)

1 Like
16

@wolfram :pray: we kinda solved ENS gas issues forever with fancy IPNS+CCIP design *without running any web2 servers for CCIP. Check our beta works after ~1 year of slow and zero funded experiments. NameSys.eth · GitHub / Gitcoin Grants Beta Round - #9 by 0xc0de4c0ffee

using avatar format.

[
    "eip155:<chain_id>/<NFT_Type>:<contract_addr_orENS>/<NFT_ID>",
    "eip155:1/erc1155:0xb32979486938aa9694bfc898f35dbed459f44424/10063",
    "eip155:1/erc721:bensyc.eth/666"
]
4 Likes
17

I wasn’t part of that standard, but I believe it’s to be clear that that part is related to the chainId.

Could be done using a resolver that accepts signatures as proof that the owner wants you to set some records and then the owner wouldn’t have to even submit the transaction

3 Likes
18

Could always count on you! Really good sir.

5 Likes
19

That sounds super cool!! Way over my head tho haha. The owner still would need to set/approve such a resolver right, to be able to write on your .eth.

@0xc0de4c0ffee owe you a coffee I guess lol. Amazing, free or cheap records would be so great. Think that opens many doors. Any big tradeoffs in your opinion, storing everything in content hash vs separate L2?

This all is getting a bit complex for me haha. But like learning more about ENS. Diving deeper.

In the end for users it would be great just to click favourite, sign and the record is set. Hope we get there. If dapps and nft projects would prompt you/pay to do so even better ofc. Think they have incentive to do so.

Been discussing with more people and gas fees the primary concern (like here). Haven’t heard much negative things really or this is not possible, but maybe they just don’t respond :joy: So I still think this is worth pursuing and I will :muscle:

5 Likes
20

ENS records stored in L2 require extra web2 servers to CCIP-read requested data from DB or L2 chain to return as json {data:…} format data signed by gateway’s keys. Our design is simple, all records are stored in domain.eth’s dweb content and signed by owner or manager of domain.eth, and it auto supports deep wildcard *…*.sub.domain.eth in same off-chain format.

We’re still working to smoothen IPFS & IPNS sides as it’s not always reliable after few ~days without active IPNS services ( like non-custodial https://web3.storage’s w3name and custodial IPNS service from our dear frENS @neiman & @tomlightning’s https://dwebservices.xyz/ or a local IPFS node) watching over everything, pinning & republishing same IPNS version everyday on backend to make sure it’s propagated globally… We’re also testing brand new IPFS Helia client (GitHub - ipfs/helia: An implementation of IPFS in JavaScript) on browser.

FYI, it’s part of our bigger web3+web2=web5 stack (https://dostr.eth.limo/) mixing ENS with Nostr to rebuild old abandoned ETH:Shh (Whisper) tech for fully dynamic dweb-sites and open services like DeFi/NFT markets, stealth payments/AA, etc NOT controlled/owned by anyone. Mixing ETH maxi stack with BTC maxi stack is crazy experience on itself… :stuck_out_tongue: :vulcan_salute:

4 Likes