Yes, I think that maybe the more formal format for “showcase”.
2 Likes
I like your idea
2 Likes
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
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
You could always send your spam to the deadzero address.
1 Like
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.
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
It’s not recommended to interact with any kind of tokens that show up in a wallet that aren’t recognized.
2 Likes
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 
Next steps:
-
Make concrete suggestion for record key (imma dm you @liubenben /others for help
) -
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
)
p.s I hate spam NFTs and really would love my fav NFTs on top everywhere broke.eth/melvin.eth gets loaded
1 Like
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
Hi @jefflau.eth thanks for the reply, this is very clean! Simple and kinda combines everything above
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
@wolfram 
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
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
Could always count on you! Really good sir.
5 Likes
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 So I still think this is worth pursuing and I will 
5 Likes
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… 
4 Likes
ENS’s true power lies in the Resolver. Resolver is essentially an adaptor for a name and can act as an Account Abstraction hook; it is extremely capable. But it hasn’t been used as much until very recently, except by our team and by zkMoney for stealth payments. Gas was always the biggest issue standing in the way of ENS adoption, not onboarding, not wrapped subdomains, etc etc. Wrapped subdomains haven’t taken off simply because the gas fees to wrap them are not worth the upside. Why will a large org force its users to pay crazy gas to use a name when they can just as easily use CCIP-Read and make off-chain registries. CB.ID did just that. More will follow. Off-chain records are here to stay, only a matter of who implements them efficiently first. CCIP2 will take gas out of the equation while removing the kinks in the off-chain record management infrastructure. Records will now be free and smoothly accessible.
4 Likes
Sounds very cool! Thanks for all links need to dive deeper (again hah) Don’t know much about Nostr, heard lot about it tho! I need to start following you and need to look into what @neiman doing too he’s always up to cool stuff I think. Read up on IPNS. Gasless records sounds like heaven.
Sorry for my ignorance lol but so practically users would need to update their resolver (transaction) and then they will be able to sign messages updating the contenthash? (free) And where would users set these records? Or would dapps integrate this?
And @isX this all is very cool. Never really thought about it like that. What @jefflau.eth said also kinda blew my mind haha. Probably went a lot of thought into cb.id too! Hope more do follow!
So you both think basically all on chain text record setting won’t be necessary? And it will all move to off chain registries basically? Via contenthash? And there’s no downsides to that? Certain records (like socials) still should be more ‘visible’ than others. I imagine it would be possible to separate/indicate such preferences?
Are there any risks to losing these off chain records? And if it somehow all would fail people could just set up with a new resolver? For a showcase this doesn’t really matter I guess but it sometimes might. (bit unsure about this part as I would first assume onchain better/more secure but might be overkill I guess)
I would go crazy setting records without gas fees, can tell you that for sure haha. And obviously the different types of records people would set and would experiment with would go UP too.
Are there any timelines on this? Know ccip was ready(?)
And to tie it all back to the showcase/favorites record. Is this the way to go? Would it still be as easy as resolving a name for any app to integrate the showcase?
2 Likes
Correct, you can already take the demo client for a spin on Goerli: https://ccip2.eth.limo
- Users will have to pay one-time gas fees to migrate their current public Resolver to CCIP2 and to set their global contenthash. All records from then on will be stored in the user’s contenthash that they just set. These records are free and infinitely update-able.
Whenever a user sets new records (on https://ccip2.eth.limo), their signature is attached with the records. Upon each resolution, the realtime signature will be matched with the provided signature. This will avoid bad resolutions.
These records can be set on our client https://ccip2.eth.limo. ENS App doesn’t support viewing or editing off-chain records.
No need for anyone to integrate anything. Our stack is based on ENSIP-10 and ENSIP-10 is already integrated.
You can do anything you want. World is your oyster and there are no gas fees. Resolvers are highly programmable. No downsides other than the records being off-chain, which is not really a downside but an aspect that can be optimised. An expensive on-chain registry is not worth more than a free off-chain registry, provided that security is not compromised.
You can “lose” your records if your contenthash disappears from the IPFS network, i.e. basically if your off-chain data disappears. That can be easily taken care of. There are plenty of free IPFS providers that users can additionally pin their data, besides the data hosting that we will provide through our IPFS node. A better question would be: are my records secure and uncompromisable? Yes, that’s why we will:
-
make you sign your records so that they stop resolving if your name changes ownership.
-
your IPNS keys will be generated client-side in browser and pinned through
w3nameprovider; this way your IPNS private keys remain with you and never leave your browser.
2-3 weeks maximum. Our client is ready. Contracts are being tested. We’ll full send soon
2 Likes
Boooom 
Thanks for answering! This almost sounds too good to be true 
But yeah if dwebsites work similarly, why not records too? Offchain seems fine tbh and secure enough how you explain it, definitely with how records are used right now (simple info). But again (as probably is clear by now haha) I am no expert, so it’s hard for me to exactly consider the pros and cons. The wildcard resolution is very cool. I’ve read it before but never really realised the full implications and possibilities I guess. Super exciting!
Just to confirm, so if I can do anything I want and these gasless ccip2 records will show up anywhere without any sort of extra integration (besides ensip10), dapps can choose to resolve part of the records and users can set any sort of record? Address, avatar, socials, any custom text record basically?
Take the showcase for example? Wouldn’t there still need to be some standard? Especially as different addresses will use different resolvers. And content is set in different places. Or is something like
enough? And would it kinda be an ‘informal’ standard?
And if so would such a record be something you would consider let people easily set?
1 Like
In hindsight, it will be the thing in plain sight that should have been built on sooner 
Correct. Off-chain resolution is already integrated in ethers.js and there is no additional integration required. Standard ENS integration used by dApps comes with CCIP-Read feature. That’s why CB.ID works seamlessly for Coinbase users.
Anything.
Currently, setting a text record of this nature will cost you $30 at 50 GWEI gas with only 2 NFTs in the showcase. It is unusable. With CCIP2, you can go crazy and add hundreds probably.
We plan to propose this as an ENSIP standard. Here is the work-in-progress draft: https://github.com/namesys-eth/ccip2-resources/blob/main/docs/ENSIP-15.md
@0xc0de4c0ffee already teased it before here in the forum: Support IPLD Contenthash - #6 by 0xc0de4c0ffee
Absolutely. That’s all it is: securely hosted info, and ENS is no more than an on-chain database. On-chain secures this info with gas, we’ll secure this info with signatures.
2 Likes