CHIP-0007: Off-chain metadata format for NFT1 #26

wriches · 2022-06-25T21:10:17Z

A standard for formatting off-chain metadata for NFT1-compliant NFTs on Chia's blockchain

BrandtH22

General comments

CHIPs/chip-will-riches-metadata.md

assets/chip-0007/example.json

BrandtH22 · 2022-07-07T04:24:57Z

assets/chip-0007/example.json

+    ],
+    "collection": {
+        "name": "Example Pokémon Collection",
+        "id": "e43fcfe6-1d5c-4d6e-82da-5de3aa8b3b57",


Based on the confusion between series and edition we should add the series information into the collection object here:

"series_number": 1,
"series_total": 10000,

I've added the series_number and series_total properties, but I added them at the document root rather than in the collection object, since I think the collection object should be the same for every NFT within the collection.

Shouldn't the series_total field be moved to the collection object? It still guarantees that the collection object is the same for every NFT, yet it makes more sense for this field to be there since it is a property of the whole collection.

series_total is not necessarily the same for the whole collection, since you can have multiple series within a single collection. For example, you might have a collection called "Photos of New York", and within that a series of photos of taxis, a series of photos of buildings, etc. Quite often a collection will contain a single series, but not always.

If a collection contains several series/sequences then more than one NFT from that collection may have identical series_number. If, additionally series_total are equal (for these NFTs) then it is not possible to determine which NFT belongs to which series. I see three possible solutions o distinguish sequences within a collection.

Do not allow sequences of the same size within a collection (that is, use series_total to distinguish sequences)

Introduce a new field to metadata, series_id or series_name to distinguish sequences.

Recommend creators to use name of the NFT in a way which allows series identification.
It seems to me that solution 2 is the best from the point of view of online services dealing with NFTs. Solution 1 seems to be unnecessarily and artificially restrictive. Solution 3 means essentially "do nothing, let creators to deal with that anyway they want". However, it will make automatic aggregation difficult in some case.

Agreed that solution 1 is too restrictive and arbitrary. Solution 2 will not be necessary when collections can be handled in a more verifiable manner, such as through Datalayer. If you introduce a series ID into the off-chain metadata file, there's also an argument to introduce an edition ID. Currently, marketplaces verify the collection by using the ID along with the creator DID, but having to do the same for a series ID (and edition ID) and handle conflicts seems to not be worth the effort. It's worth it for collections, but I expect very few collections will make use of multiple series at this point.

Solution 3 is effectively the status quo (it's common for NFTs to be titled as "Chia Friends #123", for example, both in and outside of the Chia ecosystem) and seems like a sensible approach until something like Datalayer is available for collection and series data.

DrakoPensulo

It seems to me that in this code update ("Add series_number and series_total properties") the word 'unique' should be replaced with 'distinct'. Justification: There can be a collection which contains 5 distinct NFTs each having some number of editions (identical copies). The NFTs in that collection will be unique only is each distinct NFT has 'total editions = 1'.

wriches · 2022-07-20T08:44:57Z

It seems to me that in this code update ("Add series_number and series_total properties") the word 'unique' should be replaced with 'distinct'.

Agreed, this terminology is clearer in this case. I've updated the wording. Thanks.

paninaro · 2022-08-02T19:32:32Z

@rifeljm @wriches what metadata fields should be added to support additional media types? At a minimum I think we should add something like "preview_uri": "<image thumbnail or video preview uri> to allow the client to display reasonably-sized (350x350?, 500x500?) artwork associated with the NFT. For audio NFTs this could be the artist's album artwork, or for a video, it could be a preview video. It could also be used for image NFTs to provide a smaller thumbnail.

OR would it be better to have media-type-specific preview uris? e.g. preview_image_uri, preview_video_uri. That way, the client wouldn't need to check the content type to determine how to display the preview content.

DrakoPensulo · 2022-08-11T13:30:32Z

I think it will be better to have "preview_uri" field since NFT can be a document of any type (image, video, text document, pdf, ...). In order to make content type identification easier to clients, a field like "preview_type" may be added (possibly optional) with values like jpg, png, mov, mp4, pdf, doc, txt, .... etc.

paninaro · 2022-08-11T16:19:26Z

I think it will be better to have "preview_uri" field since NFT can be a document of any type (image, video, text document, pdf, ...). In order to make content type identification easier to clients, a field like "preview_type" may be added (possibly optional) with values like jpg, png, mov, mp4, pdf, doc, txt, .... etc.

Yes, if we use a generic preview_uri field, we would want to also include a field identifying the type, as you suggested.

I've also been thinking that it would be useful to have a list of preview URIs whose loading priority is expressed in descending order. e.g.:

"preview_uris": [
  {
    "uri": <highest priority preview uri>,
    "type": "mp4"
  },
  {
    "uri": <second highest priority preview uri>,
    "type": "png",
  }
]

speedmann · 2022-08-11T17:28:41Z

@paninaro it always is a great idea to have something which looks and feels like some other thing, but does something totally different.

You do not want to have the preview url list to be able to hold different types of previews because that is contrary to all other url fields.

Additionally why the heck is this still an open discussion? This should have been merged and finalezied a month ago. There are over 1k collections and over 130k NFTs out there following this "standard". You missed the chance to adjust stuff now. IMHO if you really want to add/change stuff you should try to define a new CHIP for this.

wriches · 2022-08-11T17:34:38Z

Additionally why the heck is this still an open discussion? This should have been merged and finalezied a month ago. There are over 1k collections and over 130k NFTs out there following this "standard". You missed the chance to adjust stuff now. IMHO if you really want to add/change stuff you should try to define a new CHIP for this.

@speedmann Because that's within the confines of the CHIP process and would be taken into account for any changes i.e. changes that are breaking for existing NFTs would have a much higher barrier for acceptance.

paninaro · 2022-08-11T18:17:26Z

@speedmann so if I understand correctly, you would suggest that the list of URLs all refer to the same content type? Would the type field then be a sibling of the list?

I'm happy to hear additional thoughts on this as it's in the interest of the community to have this figured out for video/audio/other media types.

speedmann · 2022-08-11T18:22:17Z

@speedmann so if I understand correctly, you would suggest that the list of URLs all refer to the same content type? Would the type field then be a sibling of the list?

I'm happy to hear additional thoughts on this as it's in the interest of the community to have this figured out for video/audio/other media types.

IMHO it should point to the same preview everytime yes. This keeps the behaviour the same as data/metadata/license uris.

I also would limit the preview to any valid image type as i can really see chances for malicious actors here to annoy the heck out of people (Imagine getting rickrolled by an airdropped NFT)

paninaro · 2022-08-11T18:42:47Z

IMHO it should point to the same preview everytime yes. This keeps the behaviour the same as data/metadata/license uris.

I also would limit the preview to any valid image type as i can really see chances for malicious actors here to annoy the heck out of people (Imagine getting rickrolled by an airdropped NFT)

Agreed that the list should reference the same preview content across multiple mirrors, just like the on-chain URLs.

Re: limiting the preview to images only -- the goal that we're (the Chia frontend team) seeking is to provide artists/creators with a rich representation of their work. While I agree that there will be some actors that seek to abuse the system or annoy others, there are UX solutions to deal with that (don't auto-play videos, hide new NFTs by default, etc.). In fact, my original suggestion of supporting different types of previews was to support apps that may want to disable videos entirely, but still allow image previews.

paninaro · 2022-08-25T00:31:56Z

TL;DR:
Proposing an optional "content_type": <media type> field to support displaying NFT content beyond images. Assume image content if the field is not specified.

--

While working on support for displaying additional NFT content types, we've run into a bit of a quandary. Given an arbitrary content URL in the on-chain metadata, how can we determine what the content type is? This impacts how we display that content in the app (i.e. do we render into an <img> or <video> or <audio> tag, etc.)

File extensions are nice when available, but arweave/ipfs links don't provide them (at least on the NFTs that I've been looking at).

Checking the "Content-Type" HTTP header would be great, but again, it's not always available (again, arweave doesn't seem to provide it).

If we naively assume that all NFTs are images, then there's no real issue -- we can simply render into an <img> tag and hope for the best.

As we open up to supporting new NFT file types, this has become an issue. And since this CHIP still hasn't been closed, I would like to suggest an optional addition to the off-chain metadata that would support displaying these new NFT file types.

"content_type": <media type> where the media type is a standard HTTP media type as described in RFC 7231

Examples:
"content_type": "video/mp4" --> MPEG-4 video
"content_type": "audio/ogg" --> OGG audio track
"content_type": "application/pdf" --> PDF document

Using the standard media type format used by the "Content-Type" HTTP header allows implementations to follow existing, well-understood semantics that would normally apply to the HTTP header.

The absence of the field would indicate that the NFT content should be assumed to be an image (as it is today). Since the field would be optional, the display of existing image NFTs minted today would not be impacted.

Signed-off-by: danieljperry <d.perry@chia.net>

wriches and others added 4 commits June 25, 2022 22:05

Add CHIP for metadata format

683fa57

Fix filename

6e71dfb

Fix formatting

19cc1c5

update status of metadata CHIP

1df682c

danieljperry changed the title ~~Off-chain metadata format for NFT1~~ CHIP-0007: Off-chain metadata format for NFT1 Jun 25, 2022

update links

13fad99

BrandtH22 reviewed Jun 26, 2022

View reviewed changes

wriches added this to Draft in CHIPs Backlog via automation Jun 26, 2022

wriches moved this from Draft to Review in CHIPs Backlog Jun 26, 2022

wriches self-assigned this Jun 26, 2022

Add sensitive_content field and change trait to trait_type

dc2e294

BrandtH22 reviewed Jul 7, 2022

View reviewed changes

wriches added 2 commits July 12, 2022 15:44

Add NFT data object

2d3d81b

Add series_number and series_total properties

c9d8a50

DrakoPensulo reviewed Jul 19, 2022

View reviewed changes

Changed wording

0046899

wriches and others added 4 commits September 22, 2022 02:49

Update filename with CHIP number

05b6916

Add CHIP editor

e3bc98c

Correct spelling mistake

f0bd9fa

Update status to Last Call

45d727f

Signed-off-by: danieljperry <d.perry@chia.net>

Update metadata CHIP status to Final

71388a2

Signed-off-by: danieljperry <d.perry@chia.net>

danieljperry approved these changes Oct 1, 2022

View reviewed changes

danieljperry merged commit a2f327f into main Oct 1, 2022

CHIPs Backlog automation moved this from Review to Accepted Oct 1, 2022

danieljperry deleted the metadata-schema branch January 12, 2023 03:26

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CHIP-0007: Off-chain metadata format for NFT1 #26

CHIP-0007: Off-chain metadata format for NFT1 #26

wriches commented Jun 25, 2022

BrandtH22 left a comment

BrandtH22 Jul 7, 2022

wriches Jul 12, 2022

DrakoPensulo Jul 21, 2022

wriches Jul 21, 2022 •

edited

Loading

DrakoPensulo Jul 24, 2022 •

edited

Loading

wriches Jul 24, 2022

DrakoPensulo left a comment •

edited

Loading

wriches commented Jul 20, 2022

paninaro commented Aug 2, 2022 •

edited

Loading

DrakoPensulo commented Aug 11, 2022

paninaro commented Aug 11, 2022

speedmann commented Aug 11, 2022

wriches commented Aug 11, 2022 •

edited

Loading

paninaro commented Aug 11, 2022

speedmann commented Aug 11, 2022

paninaro commented Aug 11, 2022

paninaro commented Aug 25, 2022

CHIP-0007: Off-chain metadata format for NFT1 #26

CHIP-0007: Off-chain metadata format for NFT1 #26

Conversation

wriches commented Jun 25, 2022

BrandtH22 left a comment

Choose a reason for hiding this comment

BrandtH22 Jul 7, 2022

Choose a reason for hiding this comment

wriches Jul 12, 2022

Choose a reason for hiding this comment

DrakoPensulo Jul 21, 2022

Choose a reason for hiding this comment

wriches Jul 21, 2022 • edited Loading

Choose a reason for hiding this comment

DrakoPensulo Jul 24, 2022 • edited Loading

Choose a reason for hiding this comment

wriches Jul 24, 2022

Choose a reason for hiding this comment

DrakoPensulo left a comment • edited Loading

Choose a reason for hiding this comment

wriches commented Jul 20, 2022

paninaro commented Aug 2, 2022 • edited Loading

DrakoPensulo commented Aug 11, 2022

paninaro commented Aug 11, 2022

speedmann commented Aug 11, 2022

wriches commented Aug 11, 2022 • edited Loading

paninaro commented Aug 11, 2022

speedmann commented Aug 11, 2022

paninaro commented Aug 11, 2022

paninaro commented Aug 25, 2022

wriches Jul 21, 2022 •

edited

Loading

DrakoPensulo Jul 24, 2022 •

edited

Loading

DrakoPensulo left a comment •

edited

Loading

paninaro commented Aug 2, 2022 •

edited

Loading

wriches commented Aug 11, 2022 •

edited

Loading