Metadata for NFTs

[friedger]

There should a standard that defines a schema for non-fungible tokens using SIP-009

[friedger]

I recommend to follow https://docs.opensea.io/docs/metadata-standards

[dantrevino]

Here is an example of the format i'd like to see:
It is a derivation of opensea's metadata standard and ERC-1155. IMHO it is simpler and easily extendable.

{
  "name": "test 3",
  "description": "asdfasdfasd ",
  "properties": {
    "series_name": {
      "display_type": "",
      "trait_type": "string",
      "value": "test 3"
    },
    "series_size": {
      "display_type": "number",
      "trait_type": "integer",
      "value": "100"
    },
    "date_created": {
      "display_type": "date",
      "trait_type": "date",
      "value": 1629737029184
    },
    "external_url": {
      "display_type": "url",
      "trait_type": "string",
      "value": ""
    },
    "animation_url": {
      "display_type": "url",
      "trait_type": "string",
      "value": ""
    }
  },
  "localization": {
    "uri": "",
    "default": "en",
    "locales": [
      "en",
      "de",
      "ar"
    ]
  },
  "image": "ipfs://bafybeiej6org5hquxstziqoiqwk65335vf2vqp7v6jfqukowxm7ldubxmy/1024px-Bitcoin.svg.png"
}

[markmhendrickson]

What's the next step here? @dantrevino @friedger might one of you want to open a PR with all necessary elements?

Note Dan's relevant comment here as well:

The following still needs to be managed:

1. metadata protocol. Is this service prepared to handle ipfs (ipfs://)/arweave (ar://) as well as http(s)?
2. metadata format. CSV? JSON? Excel? Clarity tuple? No standard is specified by sip009.
3. metadata properties. Are images named "img"? "image"? "imageUrl"? "imagen"? Is the name "name" or "title" or > something else?
4. what metadata properties must be provided?

[friedger]

@radicleart might be a good contributor

[radicleart]

I've gone with the open sea standards for props - 'name', 'image', 'attributes' etc - as in https://docs.opensea.io/docs/metadata-standards.

But props like 'image' and 'animation_url' could be better formalised for future proofing - i.e. what type of object is the NFT? Should it support physical as well as digital objects?

Going forward the attributes need to be free to adapt to many use cases and become much richer - beyond 'collectibles' in order to absorb the complexities? For example support for a gallery of images in a marketplace or for say corroborating documentation for the ownership of the NFT object (3 min videos for example of the artist making the work)? Or pointers into a decentralised taxonomy to help with search and discoverability.

Another issue is which fields should be allowed to change and which should be 'locked' - items on auction legally require that the title/description/images do not change during the auction. Be useful if we could provide a signature which guarantees this sub set of fields can never change - e.g. by hashing this with the nft object hash and storing it in the contract? Not sure how or if this should be standardised?

[kyranjamie]

I'd encourage whatever spec we land on to have a version number, akin to how web extensions have manifest_version 2 or 3. This will greatly assist with upgrades if later modifications are needed.

[314159265359879]

I wanted to add this here because it adds context to why this standard would help the Stacks ecosystem and NFT adoption on it. I think we should have input from the accelerators that are working on NFT's too:
Risidio (already involved)
Layer
Moonray
Shaderverse
bReal
Momento
Open Art Source
Rare sense

Ideally they commit to the standard that is being developed here and I think that is much easier if they have a stake/say in the development of it. I will ping Gary Riger from Layer and Rodrigo from Moonray. I have also asked Stackspunks/ArtOnStacks to get involved. Who can get the others involved?

[dantrevino]

I've gone with the open sea standards for props - 'name', 'image', 'attributes' etc - as in https://docs.opensea.io/docs/metadata-standards.

But props like 'image' and 'animation_url' could be better formalised for future proofing - i.e. what type of object is the NFT? Should it support physical as well as digital objects?

Going forward the attributes need to be free to adapt to many use cases and become much richer - beyond 'collectibles' in order to absorb the complexities? For example support for a gallery of images in a marketplace or for say corroborating documentation for the ownership of the NFT object (3 min videos for example of the artist making the work)? Or pointers into a decentralised taxonomy to help with search and discoverability.

Another issue is which fields should be allowed to change and which should be 'locked' - items on auction legally require that the title/description/images do not change during the auction. Be useful if we could provide a signature which guarantees this sub set of fields can never change - e.g. by hashing this with the nft object hash and storing it in the contract? Not sure how or if this should be standardised?

I think being free to adapt means a minimal spec.

The context you're looking to preserve could be kept in property objects. For instance:

{
"name": "foo",
"image": "bar",
"properties": {
  "making_of_video": {
     "display_type":  "uri",
     "trait_type": "string",
     "value": "protocol://identifier"
  },
  "video_md": {
   "display_type": "none",
   "trait_type": "xml", // string???
   "value": " <xs:element name="VIDEOMD" type="videoType"/>
        <xs:element name="VIDEOSRC" type="videoType"/>
        <xs:annotation>
        <xs:documentation>VIDEOMD: LC-AV Video Metadata Extension Schema. VIDEOMD contains technical ...
 </xs:documentation>
        </xs:annotation>
        <xs:complexType name="videoType">
        <xs:annotation>
        <xs:documentation>A complexType for encapsulating and organizing within a singleparent element ...
</xs:documentation>
        </xs:annotation>
     ..."
    },
 }

Properties can be optionally rendered depending on the wallet author. This allows makers to add whatever context they see fit, and allows flexibility on the display side for wallets who may be displaying things on a TV or a watch.

The bigger question here is why use an array, as opensea did for "attributes" and another object for "properties" ... imho, a single properties object covers both and is consistent with the overall format of the proposal.

[radicleart]

I agree with your point Dan that there only needs to be one array - I've used 'attributes' and not 'properties'. I could migrate to properties from here but this would be a bit of a pain as I'd have to support attributes for backwards compatibility.

I agree also we should keep this simple as it clearly gets very complex very quickly when you try going beyond the simplest attributes.

[dantrevino]

We're also having to support pre-sip009 and pre-metadata standard NFTs. And more every day. Its a consequence of leading early. Actually, until this standard is ratified, we're all in that same situation now.

[radicleart]

So the OpenSea standard is;

{
  "description": "Friendly OpenSea Creature that enjoys long swims in the ocean.", 
  "external_url": "https://openseacreatures.io/3", 
  "image": "https://storage.googleapis.com/opensea-prod.appspot.com/puffs/3.png", 
  "name": "Dave Starbelly",
  "attributes": [ ... ], 
}

Re-reading their document Dan it looks like they added support for properties specifically for the Enjin project. So I guess support for properties is more of an option whereas attributes is really the main standard?

[maximfadeev]

Hi all I'm Layer's smart contract developer. We are following the OpenSea standard for our NFT metadata as well. Only attributes, no properties though:

{
  "description": "Layer NFT description", 
  "external_url": "https://openseacreatures.io/3", 
  "image": "ipfs://QmTy8w65yBXgyfG2ZBg5TrfB2hPjrDQH3RCQFJGkARStJb", 
  "name": "Some Name",
  "attributes": [
    {
      "type": "Artist",
      "value": "Some Artist"
    }
  ] 
}

[markmhendrickson]

Would it be helpful to organize a meeting over Discord hangouts about this in the coming weeks to discuss where things stand generally, our various needs and any timing considerations we have in mind?

My sense is that talking about this synchronously could help move the process along.

If you're interested, please upvote this commit with an emoji and I'll work on organizing the session. 🙏

[dcsan]

some comments here as a generative artist working in the space, things that would make life more attractive in STX land:

image (url)

Agree on a list of image formats supported. obviously people expect png/jpgm, gif not always.. but more interestingly SVG support. It should just work in an image tag...
svg embedded in html with its extra files would be more interesting tho, it's hard to animate SVGs without external JS/CSS tho.

animation_url

Allows whole HTML scenes to be displayed in an iframe. but i think only opensea supports that so far

image_data

is a native data stream, eg SVG string or binary blob for png etc. (could be generated in the contract)
In eth land a lot of people are using this for putting out raw images and SVG data directly from the contract aka on-chain SVGs
https://docs.aavegotchi.com/overview/onchain-svgs

external_url

would allow NFT creators to link to an external site eg for roadmap or project info, so people really see the value of the NFTs. just convincing a buyer its worth an investment purely on the JPG is more of an uphill battle...

[markmhendrickson]

Thanks everyone for your interest in meeting about this above, and for your patience with me in scheduling a time.

Doodle may be easiest to get something on the calendar, so please indicate your available times to meet next week as listed here: https://doodle.com/meeting/participate/id/QeZ88w2b

Submissions are possible until EOD this Thursday, November 11th. 🙏

cc @radicleart @josecanhelp @314159265359879 @blockchainbrighton @dcsan

[dcsan]

note: solana exchange.art seems to have adopted the opensea format field names, and starting to add more formats beyond just JPGs. they just launched a 3d collection, which doesn't support the iframe, it's just a file which calls an embedded viewer.

https://exchange.art/single/DwGfMA9wsS16gDY47oKCgCUjyGsc47vPytoMCU4DPiwF

I'm not sure i've seen the properties:files structure before tho.

[dcsan]

link to the PR:
#44