Reconciling dynamic NFT metadata (and standardizing it?)

Hey everyone,

I can’t always make the NFT community calls, so I thought some discussions could also work asynchronously in between calls. After the last call, a question came up that I’m curious how standardizing subgraphs would work regarding metadata. I know Sam is making progress on this, and I’m not sure if he’s on this forum.

Currently it seems metadata usage varies wildly. A solution @sistemico shared in the call for the Superrare subgraph was to pull in the metadata from IPFS and parse it.

However, this still assumes a fixed subgraph schema. If the metadata changes or, one is pulling in metadata from varying NFT projects, is there anyway to make the metadata graphql schema itself dynamic? My knowledge of graphql is limited, so I’m not sure.

This compounds when for example Zora for example doesn’t have an opinion on structure of the metadata and rather let apps/builders defines shared schemas to use if they choose to. For example it looks like Zora’s standard metadata structure doesn’t even have the actual content/pointer.

I think it would be clear to mention again, as was discussed in the call, there’s a difference in smart contract level standardizing & subgraph standardizing. Even if metadata varies wildly on the project level perhaps there’s a solution to make a metadata standard on the subgraph very simple and allow the smart contract level to still have variance.

Trying to find a standard that applies to all metadata on fixed graphql schema that satisfies the past & future could be increasingly difficult. I would be amazing to still have some kind of metadata subgraph standard so one could query the metadata if needed. Also, I’m unsure how this would play in a future where subgraph composition becomes a possibility.

tl;dr - Metadata is very dynamic & varies wildly, how to reconcile this into a subgraph standard when the graphql schema needs to be fixed ahead of time?

3 Likes