draft sealed nft metadata

[pizzarob]

No description provided.

[lightclient]

I left a couple comments. On a higher level, I'm not sure how the sealedURI is much different than tokenURI. Additionally, we already have a decentralized storage mechanism. It's called "Ethereum" :) It's just really expensive. You could just encode the NFT data in a data-only URI.

[pizzarob]

Thanks @lightclient .

As NFTs continue to evolve so will the media files associated with them. Your suggestion is completely unfeasible and not scalable. It may work for the absolute smallest amount of data, but what about for 10,000 NFTs with a 500kb or 1MB image associated, or what about a video file?

Ethereum is not built to store these types of files and even if it could the cost would make it unaffordable. You should be storing the smallest amount of data possible on Ethereum. This is why a decentralized URI is preferable. I prefer IPFS given that it is content hashed.

The difference between the tokenURI and the sealedURI is this - the sealedURI 1) cannot be changed after it is set, 2) should point to a decentralized file storage system, 3) points to a JSON file which contains metadata for many NFTs rather than just one. Number 3 is what makes sealedURI incompatible with tokenURI. The tokenURI function returns a URI which is the metadata for a single NFT, sealedURI can be many.

If you are familiar with the growing NFT space then you will know that metadata longevity and verification is an issue. Given that ethereum will never be able to communicate with a storage layer (which is actually built for storing files) then we need a solution which allows us to verify the metadata will persist.

[lightclient]

That makes sense. My comment was mainly tongue-in-cheek :) Thanks for the info though, it helps my understanding.

[alita-moore]

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

 - File with name EIPS/eip-3569.md is new and new files must be reviewed

[MaxflowO2]

Hey I work with NFT's 24/7...

You want to override _tokenURI with one JSON and let the wallets break down the solo ID's from it? Thus saving a mapping(uint256 => string)? Just trying to figure out the long game on this... and if you need help.

-Max

[pizzarob]

@lightclient how can I remove this draft from the EIP repo?

I no longer wish to champion/do not think this is needed for the following reasons:

• A dynamic base token URI could, as efficiently, handle many different token IDs and so a JSON map of token ID to token URI is not needed.
• There are different ways an NFT author could effectively "seal" the metadata. A couple being: 1) render the metadata entirely "on-chain" 2) change the owner of the smart contract to address(0) after updating the base token URI to an IPFS hash.

[MicahZoltu]

@pizzarob Submit a PR that changes status: Draft to status: Withdrawn.

[axic]

How was this merged with a PR as discussion url? 😅

[lightclient]

Sorry, this is my mistake. I've created a FEM thread and a PR to update: #4221

[axic]

Oh just seen the recent discussion above, in that light my comment doesn't matter that much.

[axic]

@pizzarob I was wondering however what do you think about OpenSeas recommendation to emit PermanentURI(uri, tokenId)?

[pizzarob]

@axic Yeah it's interesting for sure. Do you know if they have drafted an official standard for that? It's simple which is nice. I'd expect that if the event was emitted for a token ID it should not be allowed to be emitted again for the given token ID.

Although I just realized this would be very inefficient if you have many tokens. This wouldn't be feasible for any of the 10k collections that have been coming out recently. Maybe a permanent base URI would make more sense, and the token ID is dynamically appended within the smart contract. PermanentURIBase(baseUri)

[axic]

@pizzarob haven't found anything else, that's how I ended up at your ERC.

I'd say a range option as yours may be also a good solution: PermanentURI(uri, firstTokenId, lastTokenId).

[pizzarob]

Oh yeah! A range would work well too. It's more flexible and I could see a project like art blocks using it - where the contract houses many different projects.