A new Metadata view to interop with NFT collections that store NFT in a offchain json file

[bjartek]

DimentionX and Rarible both store nfts in an offchain json file that follows the openSea standard. I think this should be formalized into a Struct.

I vaguely remeber that we have talked about this before @psiemens

[austinkline]

That was part of the the NFTView is for, would the goal be to translate the format from the OS struct to the NFTView?

[spacepluk]

I'm very happy to see this here :D

[psiemens]

When we talked about this before, the idea was to have a simple view that returns a URL pointing to a JSON file.

I think it'd basically just be a port of the ERC 721 / 1155 tokenURI function: https://docs.opensea.io/docs/metadata-standards#implementing-token-uri

As @bjartek mentioned, there are some existing projects that store metadata this way. I know that many of us are champions of on-chain data (myself included), but I still think its valid for off-chain metadata like this to be given a home inside a view.

[joshuahannan]

Anybody have any ideas for the implementation for this?

[bjartek]

A naive implementation would just be to have a struct that has a File, but then you would lose mediaType information, does anybody use anything but json for this?

Another option is to use Medias so that you can set the mediaType to what you want like application/json+opensea?

On ETH/opensea this is called tokenURI but I am not sure if that name is appropriate here. What about OffchainMetadataURI?

so what about

pub stuct OffchainMetadataURI{
   pub let media:Media
   
   init(_ media:Media) {
    self.media=media
  }

  pub fun uri() : String {
    return self.media.uri()
  }
}

[austinkline]

Anybody have any ideas for the implementation for this?

I would strongly suggest that we lay out an actual data format that is expected. This problem to me is framed with the following question:

"What is the purpose of exposing off-chain data, and who is expected to use it?"

My answer to that question is that exposing data this way is almost exclusively for third-party platforms. Products which store data off-chain such as Solarpups already know how their data is formatted for their own system to work. Guiding products to a specific unified (but flexible) format will be extremely important.

I think we have two options.

1. As @spacepluk has asked for in the past, we endorse vending all contents of the NFTView struct from this external URL
2. We encourage only a subset such as Traits and Display.

My preference here is that if we are going to start encouraging off-chain paths for data like this, we should just let all data be specified in this way. I definitely prefer data be on-chain as much as it can be, but I don't see a compelling reason to be restrictive in what is actually "allowed".

I think the struct that @bjartek has laid out above is fine for the view, but I would stress that the resulting format should be consistent, and we should definitely discuss what that should be at length as well

[psiemens]

While I think the best solution for Flow NFTs is to put the metadata on chain, I still think there should be way for projects using the OpenSea JSON format to make use of metadata views.

My preference here is that if we are going to start encouraging off-chain paths for data like this, we should just let all data be specified in this way.

@austinkline When you say all data, do you just mean that projects shouldn't use a mixture of off-chain JSON files and on-chain metadata?

I think the struct that @bjartek has laid out above is fine for the view, but I would stress that the resulting format should be consistent, and we should definitely discuss what that should be at length as well

Unless I'm mistaken, I think all projects that use JSON files follow the format in the OpenSea docs, which is an extension of the ERC721 Metadata JSON Schema.

I was thinking the view should just very clearly indicate that it expects the data to be in that format:

/// ERC721TokenURIView returns a JSON file that conforms to the ERC721 Metadata JSON Schema.
///
/// Note: the majority of Flow NFTs store metadata directly on chain rather than in an external file.
/// Please consider implementing the NFTView, which is designed to have feature parity 
/// with the ERC721 metadata format. 
///
pub struct ERC721TokenURIView {
  
  /// A JSON file that conforms to the ERC721 Metadata JSON Schema.
  ///
  /// Ref: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md
  ///
  pub let file: File
   
  init(_ file: File) {
    self.file = file
  }
}

[bjartek]

This suggestion works for me @psiemens it is very specific and easy to document!

[austinkline]

While I think the best solution for Flow NFTs is to put the metadata on chain, I still think there should be way for projects using the OpenSea JSON format to make use of metadata views.

My preference here is that if we are going to start encouraging off-chain paths for data like this, we should just let all data be specified in this way.

@austinkline When you say all data, do you just mean that projects shouldn't use a mixture of off-chain JSON files and on-chain metadata?

I think the struct that @bjartek has laid out above is fine for the view, but I would stress that the resulting format should be consistent, and we should definitely discuss what that should be at length as well

Unless I'm mistaken, I think all projects that use JSON files follow the format in the OpenSea docs, which is an extension of the ERC721 Metadata JSON Schema.

I was thinking the view should just very clearly indicate that it expects the data to be in that format:

/// ERC721TokenURIView returns a JSON file that conforms to the ERC721 Metadata JSON Schema.
///
/// Note: the majority of Flow NFTs store metadata directly on chain rather than in an external file.
/// Please consider implementing the NFTView, which is designed to have feature parity 
/// with the ERC721 metadata format. 
///
pub struct ERC721TokenURIView {
  
  /// A JSON file that conforms to the ERC721 Metadata JSON Schema.
  ///
  /// Ref: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md
  ///
  pub let file: File
   
  init(_ file: File) {
    self.file = file
  }
}

Two things:

1. My only hesitation is we would have two formats basically going on now since our onchain metadata differs slightly from the opensea doc. If we're okay as a community living with that just given the ubiquitousness of the Opensea standard, I can live with that. I did want to make sure we call that out and willing make that trade-off though. As an example, we have a rarity field built into our traits, the OS doc does not.

Is it worth considering where those two things deviate or is the consensus that this isn't a big deal and we can live with it?

2. Should this offchain data also specify things like NFTCollectionData and NFTCollectionDisplay views? Or are they expected to vend some things on-chain and some things off-chain?

[bluesign]

I still think there should be way for projects using the OpenSea JSON format to make use of metadata views.

Why should we endorse someone's mistake in the standard? They put metadata to an url with json, because it was not feasible to otherwise. But on Flow it is feasible.

I don't see any flow activity on OS ( despite announcement ages ago ) , is this a requirement from them ?

I believe this will kill metadata standard, if OS forces people to add this, and some projects started to support only this format. Then wallets will begin to support this json stuff and there would be no motivation left to keep metadata on chain. ( which is a big hassle compared to json file )

I am all in support for making this a struct covering JSON data , but external JSON is really a bad idea.

[franklywatson]

The requirement isn't coming from OpenSea no. I also agree with @bluesign, this will undermine our efforts to encourage the right on-chain practices.

[austinkline]

@bluesign @franklywatson the unfortunate thing is that whether we like it or not, applications will define their own off-chain formats when it suits their needs (Solarpups and DimensionX are both organized this way?). So if we want platforms to be able to show data coming from all sources (on or off-chain) either it gets defined here, or platforms like Flowty will just do it themselves.

I agree that it puts metadata standards at risk from being on-chain, that's why I would advise against the opensea format and instead just make it a json representation of the NftView. OR we could also state that only a subset of views can be off-chain such as traits, the rest would need to be on-chain