findNftByMint and invalid metadata URIs

[katewayo]

Hi @lorisleiva. Hi @aaronlinsky. Wanted to note here that I have an interest in the fix to findNftByMint and the NFT object's behavior when the metadata URI is invalidated (potentially temporarily). Essentially, I would still like to be able to access nft.metadata while ignoring the invalid URI. Will that be the case or is that the problem you were referring to when talking about the metadata task?

I think allowing nft.metadata access under invalid URI cases post-NFT creation is desirable behavior in the protocol. The metadata URI could be valid at creation, become invalid at a later date while mints are in existence, but we want those mints to be successfully rendered via the on chain metadata previously produced by the metadata URI. Does that make sense?

In some ways, I think this may be pretty normal behavior if we want NFTs to be generally robust to the vagaries of the creator's metadata URI (network connectivity, configuration change, etc.) after NFT creation. Let me know if there's a better place to be discussing this issue. Thanks!

[lorisleiva]

Hi there 👋 This has been fixed and released in version 0.7.2 of the SDK. You can now create or fetch an NFT even if it has an invalid URI. The difference is that, of course, nft.metadata will be empty object (because no data could be fetched from the URI) and the metadataTask will have the failed status (accessible via nft.metadataTask.getStatus()). However, you can still access the other on-chain fields of the NFT object and you can access the metadata account via nft.metadataAccount.

[katewayo]

Got it. I think there's a different issue to potentially address though. Would Metaplex consider storing the data output from the metadata URI on chain in the metadata account? I don't think that's true today (but I could be mistaken being new to all this). That way, once the NFT is created, all the metadata is available on chain and any issues with the availability of the metadata URI would be avoided. What do you think?

[lorisleiva]

No, the on-chain data serves a completely different purpose than the JSON metadata. That will not be happening haha. What piece of data in particular do you think should live on-chain?

[katewayo]

In my particular case, it's the data for rendering the token sans the data for streaming the content (my token is backed by a playlist of music files). I'm ok with our service maintaining the data (we have to maintain the actual audio content as well anyway), but I'm trying to be as good a citizen as possible re: decentralized permanent assets backing the NFT.

I suspect we'll ultimately have to think through decentralized storage for this additional metadata in the same way we'll need to think about it for the audio assets. I plan to chat with the GenesysGo folks about what they're doing at some point.

If you're interested, I'd be happy to walk you through what we're building as that may make my barrage of questions easier to contextualize :-).

[lorisleiva]

I see. The idea with the JSON Metadata is not to make everything centralised but to only decentralise critical information such as the creators, the royalties, the collection, etc. Everything else can live outside under a certain standard and people can attach more data to it for their own applications.

However, the JSON metadata does not have to be centralised. In fact most users upload their JSON metadata using decentralised storage such as Arweave. In addition, you can make your NFT immutable so your community knows for sure you'll never be able to change it.

Now if that's not enough and you really really need on-chain data that's specific to your application, the recommended approach is to create your own Rust program to add another PDA derived from the mint of your NFT. The benefit of that is you can create your own logic on how to manage that data.