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.
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
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:
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
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)
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
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
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…
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.
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?
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 w3name provider; 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
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?
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.
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.
Amazing!! I think you are right that free/cheaper record setting would be great for ENS. And there’s always still the option to set them on chain I guess. I have/am reading up on all of your stuff!
I believe too tho that another reason for the lack of record setting is that people see no benefits. And I think a showcase (if widely implemented) would be interesting to some.
Still the question remains:
Should there be a standard on how to format the showcase? So wherever the record is set, offchain/L2/onchain, it is formatted the same? And so there is only one type of showcase record for dapps to look for. I think the answer is Yes.
Although everybody has suggested very similar formats, it seems like having no exact standard could cause problems/ having one is inevitable. And as a part of your ENSIP-15 seems a bit out of context?
But then, what is the best path for the showcase to be adopted?
Should some apps just start setting/resolving these custom records or should the standard first be formalised within ENS? Case to be made for both I guess. But probably the latter, so things like this won’t get overlooked:
Whole ENS-IP seems a bit extreme to me tho but I guess that is just how stuff works?
Will try to get more feedback from NFT and ENS users, and sites that show NFTs. As in the end they would need to be convinced to implement this anyway I guess.
Like what if you’d want to make the reverse-- a ‘least favorite nft’ section.
So nfts you hide in one place get hidden everywhere else, or listed at the bottom of all your nfts. Many people already hide nfts on opensea for multiple reasons.
Obv gas costs are expensive rn I get that.
This could maybe use the same standard I guess. Just worth considering how ENS could help formalize/push new records. There are many dapps with custom actions that could probably be used across crypto/ integrated with ENS already.
But I will keep it simple and just focus on this specific record for now.
I will set records on all 65 of my names if they were free. Plenty of benefits, only gas standing in the way.
Yes, there should be a standard. Otherwise, there’ll be too much variance to accommodate. We’ll propose the ENSIP and see where it goes.
I wouldn’t say so; it seems well within context. You can come join us on Github discussions and open an issue there: namesys-eth · Discussions · GitHub. We’ll discuss further there.
To make the experience smooth for users, there are 2-3 moving parts and at least one novel implementation:
Generates IPNS private keys in real time on client-side. Thanks to this, user never shares their IPNS key with anyone. Having to share IPNS private key was one of the biggest drawback in all IPNS services so far. Literally none of them provided hands-off service so far until we came along. This part makes up majority of the ENSIP.
We have separated out the global contenthash (that hosts your usual “web-contenthash” + new records) from the “web-contenthash”. The reason for this is that we don’t want users to ruin their records every time they update their web-contenthash since they’ll be hosted in the same IPNS key. That’ll be bad design. So we made way for a bypass which needs to be defined explicitly in detail.
ENSIP should describe everything in sufficient detail which may make it a tedious read. We’ll draft easier docs for the layman too. All in good times.
This is real. Still think convincing people/providing clear benefits is part too. Just look at the amount of primary names set (520k) versus avatars (76k) or contenthash (20k).
Amazing @isX I’d really love to see this happen!! I’ll reach out to you Should there maybe then be some type of request off the community for other new records, so those might be implemented and specified in this ENSIP too?
Yeah easier docs will definitely help, and seeing it in action too