0024 XLS-24d: Metadata Structure for XLS-20d NFTs

[x-Tokenize]

0024 XLS-24d: XLS-20d NFT Metadata Structure

By: MikeCheckYaSelf

Affiliation: @x-Tokenize

Revision: 2

Revision History: XLS-24d Revisions

Contributors: Mwni, nkl, ajkagy, dangell7, CombatKanga, XPunkDS, TheCryptoonz, xDude, Andrew Kaskaniotis, PeerKat, moonkie, vet, Henk ter Harmsel

Introduction

An NFT (Non Fungible Token) is a type of digital asset that uniquely represents ownership or the right to access to "something" that lives off chain. This "something" can take many different forms in the physical/digital realm such as works of art, real-estate, contractual agreements, tickets to events, derivative assets and much more.

The data which represents the underlying asset/rights are often described and then (in most cases) stored somewhere off-chain such as on a centralized server or a decentralized file system like InterPlantery File System (IPFS). This data is known as the metadata of the NFT and can take many different forms depending on what the NFT represents.

Motivation

With the release of the XLS-20d NFT dev network, there has been significant development of applications utilizing the proposed XLS-20d standard. The areas of interest utilizing NFTs are vast and thus requires a scalable standard for the representation of metadata to facilitate NFToken interoperability amongst applications.

Advantages

• Increased interoperability amongst applications.
• Scalable data structure for new NFT use cases.
• Common fields shared with NFTs from other networks.

Revision Changes (current:2)

• Removed Metadata Standards Briefing(removed in r1)
• Proposal (modified in r1)
• Removed Real estate example (r2)
• Added more information to the schema definition process. (r2)
• By popular demand, the xrart.v0 nftType has been renamed to art.v0 (r2)
• Modified and finalized the art.v0 nftType schema. (r2)
• Provided several live (nft-devnet) examples of the art.v0 nftType. (r2)

Comments on Revision 2

Thank you to all the individuals that provided their feedback here and through other channels. All of your invaluable feedback has been taken into account in this second revision and we will definitely give credit where it's due!

The main goal of this revision was to expand on and provide additional guidance in the methodology assoicated with defining/advancing nftType schema definitions. Here we also provide a clear definition of the 'art.v0' nftType, have made changes to the art.v0 schema example in revision 1 and have provided additional examples to make it easier to follow along.

Proposal

NFTs are versatile in nature and defining metadata requirements/expectations for all different use cases and implementations can lead to an astounding set of metadata definitions. The key elements of an NFT's metadata structure must be defined in such a way that they are concise and are easily expandable as use cases evolve and more complex systems are designed.

Identifying an appropriate base structure for NFT metadata will significantly create a more scalable and interoperable environment for application developers/creators building on the XRPL. It is also important for such a structure to be interoperable with standards being applied on other networks. Interoperability with other networks will provide other network participants a low-barrier to entry if they would like to bridge their NFTs to the XRPL.

Revision 1 introduced the concept of attaching a JSON schema file to the metadata of an NFT.

A JSON schema is used to describe your existing data format(s), provide human and machine readable documentation and can also be used to validate metadata of an NFT. Describing metadata format(s) provides applications with a detailed breakdown of types, requirements and structure of the metadata that it reads. Validation is not only great for determining if an NFT will work appropriately with your application but, can also be used for filtering out unwanted 'nftTypes'.

There are many existing schema validation libraries which makes integration into an application very trivial.

To learn more about JSON schemas, check out relevant resources here:

• json-schema.org
• json-schema specification
• Getting Started
• Understanding JSON schema
• Schema Generators and Validators
• Schema.org

Utilizing JSON schemas, we as a community can define and version our metadata as the XRPL NFT space evolves. For different nftTypes, we expect community leaders of those NFT types to contribute and derive a set of schema definitions for those use cases and implementations.

Defining a schema for an nftType:

To create/update a schema for a specific nftType, it is important to consider the process as a set of building blocks;
If a schema for a specific nftType has not yet been defined, then it is up to it's creator to decide what are the absolute
bare minimum properties required for that nftType and should be an extension of the 'base.v0' nftType which can be found here:

Base Metadata

{   
    "schema":"URI://UriToBase.v0Schema",
    "nftType":"base.v0",
    "name":"Base NFT",
    "description":"An NFT using schemas."
}

$Schema File

{
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "type":"object",
    "required":[
        "schema",
        "nftType",
        "name",
        "description"
    ],
    "properties":{
        "schema":{
            "type":"string"
            "format":"uri"
        },
        "nftType":{
            "type":"string",
            "pattern":"(^[a-zA-Z]+.v[0-9]+$)"
        },
        "name":{
            "type":"string"
        },
        "description":{
            "type":"string"
        }
    }
}

Examining the 'base.v0' nftType, we can see that we include the schema, nftType, name and description which are all defined
as required properties within the schema file. These can be thought of as the foundational properties of everything in the sense
that everything has a 'name' and a can be described using a 'description'.

Expanding to Different Use Cases

Defining the required metadata fields and schemas for different use cases and asset types is certainly not a trivial task. When deciding the properties that should or should not be included in the specification, it is important to perform extensive research into the industry that the nftType is associated with and follow industry best practices associated with what that nftType represents.

Versioning of nftTypes will allow for backwards compatability for legacy NFTs as new implementations and applications arise. Advancing an nftType should be backwards compatible with previous versions such that all prior required properties are included and required in the latter. These properties and schemas can be derived from definitions of the specific asset type found on schema.org.

Art/Collectible NFT Guidance:

Many of the pioneering projects in the XRPL NFT space fall under the art/collectible category; for this reason we deemed it important to derive the foundational 'art.v0' metadata format for projects and creators to adopt. After much discussion and debate on what the foundational art.v0 type should be, it became clear that the legacy 'art.v0' nftType should be a representation of other familiar standards which were previously mentioned in the original version of this proposal.

art.v0:

The schema provided in revision 1 was meant to be an example and not a final version. Here you can find the final schema which can be used to validate nfts of the art.v0 nftType.

Art and collectible projects that are following this guidance should note that the nftType and schema should remain constant as art.v0 and ipfs://QmNpi8rcXEkohca8iXu7zysKKSJYqCvBJn3xJwga8jXqWU respectively. The contributing marketplaces, minting and viewing applications will post an updated nftType (art.v1) and schema as the ecosystem evolves! Since versioned nftTypes are backwards compatible, there won't be any issues when nftTypes are updated. Since the content of the art.v0 schema doesn't change, uploading and pinning the schema to IPFS would result in an identical CID. If your project is utilizing IPFS, it is encouraged that you pin the schema to contribute to it availability and longevity.

Changes from the r1 example schema to the final art.v0 schema:

1. Removal of $id property.
   • In JSON-Schema Definitions, the $id property is used to reference a baseURL where "$ref" properties within the schema can retrieve additional schema definitions when validating an input. This definition does not refer to any external schemas and thus should not include the property. The removal of this property would also result in having an identical schema accross all issuers, an identical ipfs hash and ultimately more availability for the schema definition.
2. Fixed the regex pattern for the nftType.
   • There was a mistake in the pattern.
3. Removed contentMediaType from the asset properties.
   • Many marketplaces/viewing and consuming applications will support multiple file types for different properties. Thus this will be addressed in a seperate section.
4. Changed attribute.name to attribute.trait_type.
   • The usage of trait_type is more prominent on other networks.
5. Changed attribute.value types from ["string", "int", "float"] to ["string", "integer", "number"]
   • There was a mistake here in the nomenclature of the types.

Schema File:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": [
    "schema",
    "nftType",
    "name",
    "description",
    "image"
  ],
  "properties": {
    "schema": {
      "type": "string",
      "format": "uri"
    },
    "nftType": {
      "type": "string",
      "pattern": "(^[a-zA-Z]+.v[0-9]+$)"
    },
    "name": {
      "type": "string"
    },
    "description": {
      "type": "string"
    },
    "image": {
      "type": "string",
      "format": "uri"
    },
    "animation": {
      "type": "string",
      "format": "uri"
    },
    "video": {
      "type": "string",
      "format": "uri"
    },
    "audio": {
      "type": "string",
      "format": "uri"
    },
    "file": {
      "type": "string",
      "format": "uri"
    },
    "collection": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string"
        },
        "family": {
          "type": "string"
        }
      },
      "required": [
        "name"
      ]
    },
    "attributes": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "trait_type": {
            "type": "string"
          },
          "value": {
            "type": [
              "string",
              "integer",
              "number"
            ]
          },
          "description": {
            "type": "string"
          }
        },
        "required": [
          "trait_type",
          "value"
        ]
      }
    }
  }
}

The art.v0 nftType defines schema, nftType, name, description and image as required properties to fall under the art.v0 category but, also provides validation support for additional properties found in other nft metadata standards such as animation, video, audio, file, collection and attributes.

This schema definition for art.v0 improves upon the one described in r1 as it no longer requires the nft creator to define their own schema because the variabilty has been stripped from the definition. A project that chooses to upload this schema to IPFS will notice that the resulting IPFS hash will be the identical.

If an NFT creator is using IPFS and following the art.v0 schema, it is encouraged to pin the following hash to ensure availability of the schema: QmNpi8rcXEkohca8iXu7zysKKSJYqCvBJn3xJwga8jXqWU

The contents of QmNpi8rcXEkohca8iXu7zysKKSJYqCvBJn3xJwga8jXqWUcan be found here.

Example 1) nftType: art.v0 with only required properties:

{   
    "schema":"ipfs://QmNpi8rcXEkohca8iXu7zysKKSJYqCvBJn3xJwga8jXqWU",
    "nftType":"art.v0",
    "name":"ART NFT #0",
    "description":"An ART NFT with minimum properties!",
    "image":"ipfs://QmcCST9U9qwJwuBxZyTJ6ePvdJHrub7yPkAcNeCKZQ3trn"
}

Example 1 shows a valid art.v0 metadata file which includes the bare minimum required fields.

Mint Tx
IPFS Hash: QmPeitiHkxakhdqZsAFo4QdkkNUkCjSSzrXzCEw8sAnGAD

Example 2) nftType: art.v0 with all supported properties:

{   
    "schema":"ipfs://QmNpi8rcXEkohca8iXu7zysKKSJYqCvBJn3xJwga8jXqWU",
    "nftType":"art.v0",
    "name":"ART NFT #0",
    "description":"An Art NFT with all properties supported by the art.v0 schema.",
    "image":"ipfs://QmcCST9U9qwJwuBxZyTJ6ePvdJHrub7yPkAcNeCKZQ3trn",
    "animation":"ipfs://QmfQGVwoxpqnAvDxFxW7bPsesivFas7FFjBcW9tVU5ymZQ",
    "video":"ipfs://QmWrLXyMFCB5XajAg9xRDkM9YtCvgMN7NqjmsgkoaV4k5k",
    "audio":"ipfs://QmQxMmXRrFZ8oMNtQjhaSnqosNTQFFzacT8F6kCoA4iSUd",
    "file":"ipfs://QmXVgDaHkXbyhnim8P9KmKG2khqLwnfT3fbZJRPBeVJDWY",
    "collection":
        {
            "name":"XLS-24D Examples",
            "family":"X-Tokenize Example NFTS"
        },
        "attributes":[
        {
            "trait_type":"Background",
            "description":"A dark background.",
            "value":"Black"
        },
        {
            "trait_type":"Text",
            "description":"A comforting message.",
            "value":"Hello XLS-24D"
        }
    ]
}

Example 2 shows a valid art.v0 metadata file which includes all of the supported fields that can be validated by the art.v0 schema definition.

Mint Tx
IPFS Hash: QmXA1nR96522ygY33KQoMk94LLHZLwfYkFhPU3c9jJ192o

Example 3) nftType: art.v0 with all supported properties and additional properties:

{   
    "schema":"ipfs://QmNpi8rcXEkohca8iXu7zysKKSJYqCvBJn3xJwga8jXqWU",
    "nftType":"art.v0",
    "name":"ART NFT #0",
    "description":"An Art NFT with all properties supported by the art.v0 schema and additional information required by my own project!",
    "image":"ipfs://QmcCST9U9qwJwuBxZyTJ6ePvdJHrub7yPkAcNeCKZQ3trn",
    "animation":"ipfs://QmfQGVwoxpqnAvDxFxW7bPsesivFas7FFjBcW9tVU5ymZQ",
    "video":"ipfs://QmWrLXyMFCB5XajAg9xRDkM9YtCvgMN7NqjmsgkoaV4k5k",
    "audio":"ipfs://QmQxMmXRrFZ8oMNtQjhaSnqosNTQFFzacT8F6kCoA4iSUd",
    "file":"ipfs://QmXVgDaHkXbyhnim8P9KmKG2khqLwnfT3fbZJRPBeVJDWY",
    "collection":
        {
            "name":"XLS-24D Examples",
            "family":"X-Tokenize Example NFTS"
        },
    "attributes":[
        {
            "trait_type":"Background",
            "value":"Black"
        },
        {
            "trait_type":"Text",
            "value":"Hello XLS-24D",
            "someOtherInfo":"Some cool info needed here"
        }
    ],
    "additional":"Some really cool info!",
    "issuer":"rLE5f3mJwrXLzmvQbNfTcfdxMYTfrxVrgX",
    "network":"XLS20 Devnet"
    }

Example 3 shows a valid art.v0 metadata file which includes all of the supported fields as well as additional properties that an issuer might need for their application. Although XLS-24d enables you to add as much additional information as you'd like, it is up to the marketplace/viewing application to determine if they will handle and display that information.

Mint Tx
IPFS Hash: QmfYHzY8UwyobMqbQyCTbeUNfy9EJv2KvEvk6ouhUmdUj5

Asset Property Media Types:

When declaring a "contentMediaType" for a property, JSON-Schema only allows for a single definition and is limiting. Marketplaces and viewing applications plan to support several media types for most of the asset properites (image, animation, video, audio, file). With this in mind below we have included a list of common media types for the different properties. These are not yet considered to be universally accepted. It is best to consult with your marketplace/viewing application of choice to determine their accepted content media types.

Asset Property	Common Content Media Types
image	.png, .jpg, .svg, .apng
animation	.gif, .mp4, .mpeg, .avi, .mov
video	.mp4, .mov, .wmv, .flv
audio	.mp4, .mp3, .wav, .m4a, .flac
file	.pdf, .doc, .docx, .xls, .html

In the coming weeks, we will post a concise overview of known supported media types for all of the properties accross many of the popular NFT marketplaces and viewing applications.

Conclusion

Defining a set metadata standards that applies to all NFTs is not possible because of the vast amount of use cases and asset types that an NFT can represent. It is important to emphasize that the goal here is not to provide a limiting standard but, to provide a scalable and interoperable methodology which can be applied to all nftTypes.

Although this revision includes guidance for the art.v0 nftType, it also shows that this approach enables creators to do what they do best and that's being creative. A creator can choose to add as much additional information within their metadata as they wish and it is encouraged to do so (assuming it doesn't interfere with the existing property definitions of that nftType). Adding information to your metadata, is what makes your project unique and can be used as a case study when determining revisions and additions to nftTypes (art.vX).

Discord

To actively participate in the discussion join the X-Tokenize Discord.

[Mwni]

Thank you for this proposal and the additional work composing together a preview of the existing standards. I propose to unify the file directives:

• localization.primary_uri
• localization.secondary_uris
• properties.primary_display.primary_uri
• properties.primary_display.secondary_uris
• properties.files
• properties.expiration.files

as all of these serve the same purpose with some conditions/modifications. It hence makes sense to define one universal data structure with modifiers such as disposition or animated, like this:

{
    "type": "generative_art",
    "name": "XR-ART 1234",
    "description": "..."
    "files": [
        {
            "mime": "image/png",
            "uri": "ipfs://QmABCDEFGHIJKLMNOPQRSTUVWXYZ123456789101112",
            "disposition": "original",
            "encryption": "AES-128"
        },
        {
            "mime": "image/png",
            "uri": "https://bucket-name.s3.Region.amazonaws.com/XR-ART1234.png",
            "disposition": "original",
            "encryption": "AES-128",
            "mirror": true
        },
        {
            "mime": "image/png",
            "uri": "ipfs://HIJKLMNOPQmABCDEFGQRST56789101112UVWXYZ1234",
            "disposition": "display",
        },
        {
            "mime": "video/mp4",
            "uri": "ipfs://EFGQNOV101112URSWXYZ129T567HPQmABCD8IJKLM34",
            "disposition": "display",
            "animated": true
        },
        {
            "mime": "image/png",
            "uri": "https://xr-art.com/nfts/expired.png",
            "disposition": "expiration"
        },
    ],
    ...
}

[x-Tokenize]

I think that unifying the files into the root definitely simplifies the structure and makes a lot of sense.
Rather than embedding the disposition into the file object itself, I propose to convert the "files" field from an array to an object with the disposition acting as the field to prevent repetition. The community can then define a set of expected file field based on the "type" of the NFT.

{
   "type":"generative_art",
    "name":"XR-ART 1234",
    "description": "A masterpiece powered by code.",
     ...
    "files":{
        "display":[
            {
                "mime":"image/png",
                "uri":"ipfs://QmABCDEFGHIJKLMNOPQRSTUVWXYZ55555555555555",
            },
            {
                "mime":"image/png",
                "uri":"https://bucket-name.s3.Region.amazonaws.com/XR-ART1234.png",
                "mirror":true
            },
            {
                "mime":"video/mp4",
                "uri":"ipfs://QmEFGHIJKLMNOPQRSTUVWXYZ12345678910111245678",
                "animated":true
            },
            {
                "mime":"video/mp4",
                "uri":"https://bucket-name.s3.Region.amazonaws.com/XR-ART1234.mp4",
                "animated":true,
                "mirror":true
            }, 
        ],
        "localized":[
             ...
        ],
        "expired":[
            ...
        ]
    },
  ...

}

[Mwni]

I agree to this. This is definitely still a very optimal representation. The one thing that could cause issues however, is that there is no "none" field. Imagine if one were to translate a, for example, EIP-1155 structure to XLS-24d, there would be no clear answer to the "disposition" field. In the flat array structure, this filed could simply be omitted, and the decision how to handle this could be passed on to the developers.

[Mwni]

Using the flat structure, one could quite trivially program a "ranking" algorithm that is very tolerant. Let's say you want to present the animated thumbnail of a NFT. The ranking algorithm could then give files with the disposition 'display' +10 points, if the 'animated' field is set, give another 10 points. If it's a mirror, subtract 1 point, etc. Even if there is no exact match, you could still retrieve the most optimal file.

[Mwni]

I propose to move the localization definitions out of the scope of this structure, and only link to the localized meta files, like so:

• https://metadata.xr-art.com/nft/000B013A95F14B0E44F78A264E41 (this is the root meta file):

{
    "type": "generative_art",
    "name": "XR-ART 1234",
    "language": "en",
    "description": "This is true art"
    "creators": [
       ...
    ],
    "collection":{
        ...
    },
    "localization": {
        "de": "https://metadata.xr-art.com/nft/000B013A95F14B0E44F78A264E41/de",
        "it": "https://metadata.xr-art.com/nft/000B013A95F14B0E44F78A264E41/it",
        "fr": "https://metadata.xr-art.com/nft/000B013A95F14B0E44F78A264E41/fr"
    }
    ...
}

Following, for example, the link for the german meta file

• https://metadata.xr-art.com/nft/000B013A95F14B0E44F78A264E41/de

{
    "type": "generative_art",
    "language": "de",
    "name": "XR-ART 1234",
    "description": "Das ist wahre Kunst"
    "creators": [
       ...
    ],
    "collection":{
        ...
    },
    "localization": {
        "en": "https://metadata.xr-art.com/nft/000B013A95F14B0E44F78A264E41",
        "it": "https://metadata.xr-art.com/nft/000B013A95F14B0E44F78A264E41/it",
        "fr": "https://metadata.xr-art.com/nft/000B013A95F14B0E44F78A264E41/fr"
    }
    ...
}

This will allow for swapping out different locales without needing any additional code for parsing the localization directive.

[x-Tokenize]

With the addition of the alterations to your recommendations described in this comment, I expect localization to be handled as such:

{
    "type":"generative_art",
    ...
    "description": "This is true art"
    ...
    "localization":{
        "default": "en",
        "locales":["en","dn","fr"],
    },
    "files":{
        "display":[
           ...
        ],
        "localized":[
                {
                    "uri":"ipfs://QmABCDEFGHIJKLMNOPQRSTUVWXYZ123456789101112/{locale}.json"
                },
                {
                    "uri":"https://bucket-name.s3.Region.amazonaws.com/{tokenID}/{locale}.json",
                    "mirror":true
                },
        ],
       "expired":[
            ...
        ]
    },
   ...

}

Rather than returning an entire copy of the metadata file with just a few fields that were localized, I propose to only return the fields that were localized to prevent repetition and optimize size.

In your example of the German metadata file:

• https://metadata.xr-art.com/nft/000B013A95F14B0E44F78A264E41/de

{
   "description": "Das ist wahre Kunst"
}

[Mwni]

I agree as well, omitting identical fields are a neat way to prevent repetition. It should be noted though, that obtaining the the metadata then no longer is a trivial JSON parse, but rather a sophisticated deep merge of nested directives. Certainly doable, but are the few Kilobytes saved worth putting developers through this.

What I do not agree to is to put the link for the localization urls into the "files" directive, as I would like to see this directive solely used for the actual content of the NFT, i.e. the NFT itself, not its metadata.

[dangell7]

I actually think the entire metadata as the localized version as @Mwni suggested is better.

I would want the NFT to be read in its entirety and would think of the localization as "links" to the other documents.

[x-Tokenize]

The flow envisioned with this approach works like this:

1. The application loads an NFT with the default localization as defined by the creator.
2. User would then interact with the NFT within the application to translate fields to a localized version if one is provided and so desired.
3. If the user interacts to translate, via dropdown or if set in a global application setting (i.e. translate to "dn" if available) :
   3a. Make a secondary request to pull localized data and modify the original object on the application side with the localized data.

The rationale here is that if there are localization options for the NFT then the application will still have to make a second request regardless to pull the requested localized data which can then just be used to alter the localized fields. A few localization options would result in a just a few KB but, at scale repeating the data 155 times for all possible localization options would be a huge waste if repeating the entire file.

Perhaps an even better improvement would be to add all localization options to a singular file like this:

• https://metadata.xr-art.com/nft/000B013A95F14B0E44F78A264E41/localizedFields.json

{
   "description":{
     "dn":"Das ist wahre Kunst",
     "fr":"C'est de l'art véritable",
     "pl":"To jest prawdziwa sztuka",
      ...
      }
}

This approach would allow for many localizations to be handled in the same file which significantly increases scalability, decreases storage requirements and minimizes the number of files that need to be tracked.

A disadvantage to this approach would be an increased probability of application error for deeply nested localized fields. One way to mitigate this risk would be to provide localization directly in the original metadata but, could result in bloated and useless data.

[dangell7]

An example of the localized display assets and even the contracts will help visualize it.

[Mwni]

In conjunction with my previous suggestion #69 (comment), which eliminates the need for the primary_display, primary_animation and files fields in the properties directive, I propose to flatten the whole properties directive into the root tree, for simplicity.

{
    "type": "generative_art",
    "language": "en",
    "name": "XR-ART 1234",
    "description": "This is true art"
    "attributes": [
        {
            "attribute_name":"background_color",
            "value_type":"string"
            "value":"#FFFFFF"
        },
        ...
    ],
    "expiration": {
        "type": "time",
        "time": 1645056753
    }
    ...
}

[x-Tokenize]

Flattening into the root definitely simplifies the entire structure and is a great idea. As this proposal evolves, the community will decide on what fields should be considered a bare minimum requirement depending on the "type" of NFT. With your feedback in mind, what are your thoughts on the updated proposed structure (as an example):

{
    "type":"generative_art",
    "name":"XR-ART 1234",
    "minter":"rXRARTMintingAddrrrrrrrrrrrrres",
    "description": "A masterpiece powered by code.",
    "creators":[
        ...
    ],
    "collection":{
        ...
    },
    "localization":{
        "default": "en",
        "locales":["en","dn","fr"],
    },
    "files":{
        "display":[
            {
                "mime":"image/png",
                "uri":"ipfs://QmABCDEFGHIJKLMNOPQRSTUVWXYZ55555555555555",
            },
            {
                "mime":"image/png",
                "uri":"https://bucket-name.s3.Region.amazonaws.com/XR-ART1234.png",
                "mirror":true
            },
            {
                "mime":"video/mp4",
                "uri":"ipfs://QmEFGHIJKLMNOPQRSTUVWXYZ12345678910111245678",
                "animated":true
            },
            {
                "mime":"video/mp4",
                "uri":"https://bucket-name.s3.Region.amazonaws.com/XR-ART1234.mp4",
                "animated":true,
                "mirror":true
            }, 
        ],
        "localized":[
                {
                    "uri":"ipfs://QmABCDEFGHIJKLMNOPQRSTUVWXYZ123456789101112/{locale}.json"
                },
                {
                    "uri":"https://bucket-name.s3.Region.amazonaws.com/{tokenID}/{locale}.json",
                    "mirror":true
                },
                {
                    "uri":"https://www.arweave.net/abcdefghigjklmnop/{tokenID}/{locale}.json",
                    "mirror":true
                } 
        ],
    },
    "attributes": [
        {
            "attribute_name":"background_color",
            "value_type":"string"
            "value":"#FFFFFF"
        },
        ...
    ],
    "expiration": {
        "type": "time",
        "time": 1645056753
    }
}

I will make a revision to the original proposal as participants join the discussion and provide additional feedback!

[drsm79]

How many value_types are expected? If the set is the same as what JSON supports you could simplify attributes to just be key:value pairs e.g "background_color": "#FFFFFF", if the set is undefined (e.g. I could make a value_type of blorp) then they're not that helpful for interchange (we'd need to agree on what a blorp is, which might be harder than agreeing on what an int is).

[ajkagy]

I like the idea of having a bare minimum spec for the schema, something simple based on EIP-721 to start. but having an optional reference to a schema file to tell any dapp/app/program how to parse the metadata for custom specs. I can see there being a need for more customized objects within the spec in the future based on the type of NFT that the metadata is describing (audio, metaverse, images, real estate, physicals, ect). Making this as flexible as possible, but at the same time not adding too much complexity will be key.

[Mwni]

I am captivated by this idea. How would such a schema file look like? Can you elaborate further, perhaps with examples?

[drsm79]

Yeah, I wonder if the current spec is a bit too 1:1 NFT:a file on the internet. Maybe it's worth having room for more abstract things (access to a safe, deeds of a house), or lists of entities (imagine an NFT that represents an album of music or a series of TV programs)?

[Cadey]

I agree with @drsm79 we need to be careful the definition isn't too "Art" like. I do have a few ideas of my own for a scheme but since this discuss has already started I will include them here in a few days time.

[KillaStryder]

I agree with this too @ajkagy! There should be different custom standards for the different types of NFTs that will come in the future. The bare minimum as the schema would definitly work. Then maybe each NFT type can create their own standard amongst their communities.

[dangell7]

Here is the standard I use in my dapps for saving/loading/parsing IPFS data that's NOT NFTs.

CLXS-004

The only addition I would suggest to the XLS-24d standard is the/a domain.

"domain": {
    "name": "swordfish.io",
    "version": "0.0.1"
 },

You already excluded external_url in your standard above and that IMO is a must.

This would be an upgrade but I honestly wouldn't upload an NFT to XRPL mainnet you couldn't change without the base fields from the well established companies (Open Sea, Solana, BSC). It could at any moment change and the interoperability would be missed.*

BASE:

name
description
external_url
image: 'ipfs://'
attributes

Notice how Solana duplicated the image and the files. I would also do this to ensure interoperability if you use the display field referenced above.

*They could add XRP or a side chain could be created to connect the two.

[JustinMKY]

Question about royalties, I know that Solana has on-chain royalty structure where royalties are automatically and instantly distributed from each sale on secondary markets, how would this work with XRP if there is a name as a creator? is this not used in addition to on-chain royalty distribution?

[Mwni]

The royalties mentioned in in the metadata have by definition no effect on the on-ledger transactions. I think the way @x-Tokenize intended these fields, and please correct me if I'm wrong, is for them to allow for additional transparency that has to be taken at face value.

[x-Tokenize]

The plan was to include the addresses of the creators and their split. With this information, wallet management software could automate the distribution among the creators on sale of an NFT. The revision I am currently working on completely omits the creators field all together for simplicity.

[KillaStryder]

I think having an address for the creator field would be the best. It would be easier to identify an individual as a creator of an NFT series. It would definitely help with the split of royalties, especially with other types of NFTs that would be minted in the future, other than images. You're right in saying that it would help with the automation of distribution among the creators. This could also be used as proof of the agreement between the creators

[Mwni]

Revision 1 really is next level. This approach is not only future-proof, but allows for complete compatibility with every standard that's already out there. My only concern would be, that this invites for a too chaotic schema usage, in the sense, that everybody will roll out their own. These schema fields still need to be read in and assigned to their designated purpose, and that is a human task. Perhaps it makes sense to propose specific schema standards as well.

[KillaStryder]

Yes every NFT project that work in similar fields will have to agree on a standard for their NFT types. This will in turn create some congruency in terms of minting and reading metadata!

[Mwni]

Yes, I think the power here really lies in the hands of the wallet and DEX interface vendors, not the NFT projects. Because the vendors sit at the core of user interaction with the network and the NFTs. We should reach out to XUMM, Sologenic, XRPLServices, etc, to come to consensus about the NFT types.

[KillaStryder]

Ah yes, true, but If there's an initial standard template for NFTs, the DEX and wallets should just be able to read that data first and then review the custom schemas if there are any. I'm interested in creating a standard for Music NFTs on the XRPL so I'd like to agree upon having the Music community decide on the standard for that. I agree with everything you're saying though

[Andrewkasko]

Hello everyone, looking to get some feedback on our metadata that we will be using for our NFTs on XRPL. It is heavily based on the suggested standard.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://nftmaster.com/schemas/standard.json",
  "type": "object",
  "required": [
    "schema",
    "type",
    "name",
    "description",
    "image",
    
  ],
  "properties": {
    "schema": {
      "type": "string""format": "uri"
    },
    "nftType": {
      "type": "string",
      "pattern":(^[a-zA-Z]+\.v[0-9]+$)
    },
    "name": {
      "type": "string"
    },
    "description": {
      "type": "string"
    },
    "image": {
      "type": "string",
      "contentMediaType": "image/png",
      "format": "uri"
    },
    "animation_url": {
      "type": "string",
      "contentMediaType": "video/mp4",
      "format": "uri"
    },
    "video": {
      "type": "string",
      "contentMediaType": "video/mp4",
      "format": "uri"
    },
    "audio": {
      "type": "string",
      "contentMediaType": "audio/mpeg",
      "format": "uri"
    },
    "file": {
      "type": "string",
      "format": "uri"
    },
    "collection": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string"
        },
        "family": {
          "type": "string"
        }
      },
      "required": [
        "name"
      ]
    },
    "attributes": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "name": {
            "type": "string"
          },
          "description": {
            "type": "string"
          }"value": {
            "type": [
              "string",
              "int",
              "float"
            ]
          }
        },
        "required": [
          "name",
          "value"
        ]
      }
    }
  }
}

An example

{
   "schema":"https://nftmaster.com/nftmaster.v0Schema",
   "nftType":"nftmaster.v0",
   "name":"NFTMASTER NFT",
   "category":"Art",
   "description":"NFT DESCRIPTION",
   "image":"ipfs://bafkreics7w2f724qc2pfrcbrrkfmwzruho5m4nzkg75kfilju2cp3e3cxa",
   "video":null,
   "animation":null,
   "audio":null,
   "file":null,
   "external_link":"https://nftmaster.com",
   "collection":{
      "name":"Andrews collection",
      "family":""
   },
   "attributes":[
      {
         "name":"Background",
         "value":"Blue",
         "description":null
      }
   ]
}

[barryrknapp]

I agree with just about everything here except for attributes.name, should be attributes.trait_type to align existing standards.

[bigcjat]

Twitter handle of the minter would be useful

[KillaStryder]

I don't think that's a good idea, since people can lose their Twitter accounts. rather the wallet address being their identification and they link their gravatar to it. That way, if they ever change Twitter handles, it can be retrieved from there

[bigcjat]

People can lose their gravitar account or their wallet keys as well. It would be hard to deny that twitter is a major part of most NFT projects.

[bigcjat]

I see you can add twitter to your gravitar, maybe that's what you were suggesting. That'll work. Thanks.

[KillaStryder]

I think everybody who wants to mint NFTs should have a gravatar linked so that we can easily get their information without it being static information as part of the metadata. This can be optional though

[bigcjat]

Thank you, that'll work

[ignerious]

In order to allow for compatibility across different nft generating engines, marketplaces, apps and nft visualizers, I would recommend the following structure for the attributes array:

 "attributes": [
    { "trait_type": "Background", "value": "Black" },
    { "trait_type": "Eyeball", "value": "Red" },
    { "trait_type": "Eye color", "value": "Yellow" },
    { "trait_type": "Iris", "value": "Small" },
    { "trait_type": "Shine", "value": "Shapes" },
    { "trait_type": "Bottom lid", "value": "Low" },
    { "trait_type": "Top lid", "value": "Middle" }
  ]

It is used by Open Sea https://docs.opensea.io/docs/metadata-standards, adopted by many marketplaces / Nft visualizers and implemented by open source NFT generating engines such as hashlips art engine: https://github.com/HashLips/hashlips_art_engine
A description could be made optional as well and part of it, I think that's a good addition.

[ZoneSixGames]

Opensea actually does support the previous mentioned attribute format, they call it "Enjin" style -- but I agree that this format will work better for the majority of people using generators. I don't think it makes much of a difference other than visually, though?

[henkterharmsel]

No, I believe it does not, Enjin style is supported under "properties" instead of "attributes" I think.

[xVet]

I suggest to add a license field to have a license hash included, makes it easier to check license types such as CC0 - For lets say a merch store.

"schema":"URI://UriToXRArt.v0Schema",
""
"license":"URI://UriToLicense",

[KillaStryder]

Agreed!

[ajkagy]

since XLS20 seems to be only 2 weeks away from implementation onto main net I want to stoke conversation on this again.

XLS24 gives a lot of flexibility for future use cases beyond just art, but the immediate implications and use case in the next few months will be 95% art based NFTs. Thinking in broader terms of not just on the XRPL, but across the whole industry, projects should be cognizant of implementing a minimum standards (similar to the opensea standard) of sorts for easy implementation and compatibility. Many of the large EVM based chains have very similar metadata standards with small deviations/differences.

The Base Art NFT example above seems to fill that minimum standard.

A thought on adding collection attributes. on EVM chains collections are mutable user defined within marketplaces. NFTs are grouped based on the contract they were minted from, but users can add new NFTs from other sources into a collection. There are both pros and cons to adding collection attributes into the metadata itself.

[x-Tokenize]

I do believe we are just scratching the surface here with the application of NFTs on the XRPL. Like you have mentioned, most projects that are anticipating the amendment are art based and will be requiring a rather simple schema to get their projects out there. The base art example should be sufficient and is similar enough to other existing standards that marketplaces and consuming applications shouldn't have an issue parsing multiple schemas to create a visualization of the metadata.

Things will need to be more uniform when we are defining other NFT types like ticketing, digital identity, music, access control systems.
Most likely these other nftTypes will also contain similar fields described in the base art example therefore enabling them to be consumed by marketplaces and gallery applications; As an nftType becomes more popular, those applications will also adopt those schemas to visualize the additional information if it fits in their business model!

On the topic of the collection attribute, I thought it was good as an identifier for consuming applications to easily identify a project defined collection. Thinking further into it, this can also be handled in other ways such as using a combination of the taxon and issuer address.

[KillaStryder]

I agree with you, as I and the Sonar Muse team have created the NFT schema standard for music, and will continue to update it and share it with the community. The art schema for images is very simple and should be a standard set schema across marketplaces. I do think that it would be best for all marketplaces to create a table with all the different schemas and standards we have and then all agree on the most used standards for the different NFT types. Music is a broad and very deep aspect to tackle, hence why we, at Sonar Muse, will be handling that aspect in order to create ease for the rest of the marketplaces and projects to follow suit.

When it comes to collections, why not just use the collection ID field supplied by XLS-20? that's the easiest way to identify and separate different collections by the same issuer address

[ZoneSixGames]

I think you could also use the Taxon for this, to make it easier to query. Or is that what you're referring to?

[KillaStryder]

Yeah, that's what I was referring to. Thanks!

[KillaStryder]

If youre a marketplace aiming to mint music NFTs please don't hesitate to email the Sonar Muse team at info@sonarmuse.org as we're creating the music NFT standard for the XRPL and for interchain compatability. We would want to provide our service to marketplaces too, just to ensure there is congruency amongst all of us

[mworks-proj]

Hello Marc, have you assisted here with development on xrpl ?

…

On Sep 9, 2022, at 7:43 AM, Marc Zuze ***@***.***> wrote:  If youre a marketplace aiming to mint music NFTs please don't hesitate to email the Sonar Muse team at ***@***.*** as we're creating the music NFT standard for the XRPL and for interchain compatability. We would want to provide our service to marketplaces too, just to ensure there is congruency amongst all of us — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[KillaStryder]

Yes and I am currently assisting with development with my team

[barryrknapp]

After reading through this and seeing ideas, I'm just not sure which ideas are winning. Perhaps we can evolve the schema in a fork --> https://github.com/strategyengine/XRPL-Standards and still discuss in this thread. Anyone can create a PR in there and any 4 approvals will allow a merge. If this already exists somewhere, please let me know and I'll delete this repo.

[tequdev]

Revision: 2
It appears that the ipfs file specified by shema is not formatted.

The following IPFS path is the content after formatting the shema text at JSON Prettiy Print.

ipfs://bafkreidm5jupaz3mljjzqkbd62znrevyp24nigkokbt4t3iwcphfz5pcr4

[x-Tokenize]

Good catch! I formatted the file and updated the hash above!

[EnigmaRidworld]

The metadata file should have both IPFS CIDv1 and CIDv0 like this image.
IPFS gives you for the NFT the CIDv0 but then what appears in the explorers is CIDv1. So there is always uncertainty about the true correspondence between the CIDv0 and the corresponding CIDv1. It exists the tool (CID inspector) that converts one to the other, but that information should be in the metadata file in order to anyone check the correspondence directly just opening the metadata file, not having to go to the CID inspector to make sure there is correspondence.

(To check in Bithomp: https://bithomp.com/explorer/rMGqQpJnjZhd64uzGzq7Zm1AZG7iD7NTu1

[ZoneSixGames]

We need to add 3D file types to the animation category or general file types. These include GLB, GLTF, OBJ, FBX, and DAE. This will allow marketplaces to implement 3D viewers for game assets. Proposal to move GIF and other video animations to the video category.

Proposal to change animation URL to align with OpenSea metadata schema:

[drsm79]

Should the standard define where the schema file is? For e.g. whats the right thing for a client to do if the URI of an NFToken is a directory? The standard could say something like "if the NFToken URI is a file with .json read the json, if it's a directory request index.json & nft.json" etc. I don't think the standard should require that the URI be to the schema file, not least for more exotic future uses of XRPL NFTs.

[oclostart]

[gadget78]

the .TOML file entry's that you list, is this for the domain .TOML file ?
as this file, and this XRPL integration system is very much underused :(

also im liking the collection entries...

[oclostart]

To be honest, in regards to the TOML file its not something I am familiar with yet in implementing. I brought up the need to be able to have certain metadata properties be dynamic and Chris Thompson brought TOML files as a possible solution. In my example, I list the fields that have a use case for the data to be dynamic. For example, I want my metadata to include social media pages. In case I lose access to one for whatever reason, I'd have the option to update the metadata within the TOML file with the updated social media page.

I was hoping this would bring up a convo. Either way. It is something I intend to implement.

Thanks, I think having the collection info in the NFT would be useful.

[taglia]

I wonder how marketplaces will support this. I understand the flexibility and the objectives of the standard, but the format is completely open-ended, thus very complex to support for a marketplace.

Have you considered having a number of required fields that will simplify the way tokens are shown in marketplaces? Making name, description, and image required (following what is done on Ethereum with the ERC-721 specification), would simplify displaying of arbitrary tokens, which could then have any other property described within the appropriate schema.

[danielwwf]

Hey @x-Tokenize, just wanted to check if you going to put a new revision out which has the "c_image" definition in we talked about on Twitter.

[KillaStryder]

Hi everybody. Just wanted to let you know that Sonar Muse has released our NFT music standard. the schema can be viewed here: https://sonarmuse.org/schema/v0

We've been working with web2 and web3 DSPs to create a standard that can support multiple songs and albums at a time, with all the necessary information about the music collection in the metadata. This can also be made interoperable with other blockchains in the future as we continue to expand on the many different use cases for music NFTs. This current standard is currently for listening only NFT rights

an NFT minted using our standard can be viewed here:
000836B0425D5408873C7C141C270879D254C84AC1CC10F0216B9CBE00000023

[danielwwf]

Why a new schema instead of incorporating?

[oclostart]

// THE FOLLOWING IS MEANT TO...
// 1. ASSIST PLATFORMS IN CREATING AN OPTIMAL USER EXPERIENCE BY ALLOWING CREATORS TO PROVIDE DATA & CONTENT
// 2. PROVIDE SUPPORT FOR PHYGITAL NFTs
// 3. PROVIDE MORE INFO TO ALLOW PLATFORMS FILTER OPTIONS
// 4. PROVIDE OPTIONAL FIELDS DEPENDING ON MEDIA TYPE
// 5. SUPPORT MORE THAN 1 MEDIA FILE IN AN NFT
// 6. ALLOWS FOR CUSTOMUZABLE FIELD PROPERTIES
// 7. DEFINES PROPERTIES FOR THE COLLECTION, CREATOR AND NFT
// 8. EVEOLVE NFTS FOR BUSINESS USE

// NOTE: DYNAMIC METADATA ISN'T IMPLEMENTED, SUGGESTED SOLUTION: TOML FILES

// COLLECTION DATA
"collection":
{
	"name": "Avengers", // collection name
	"description": "Limited Edition Avengers Collection", // collection description
	"family": "Marvel", // (redefine family) For example, instead of Stan Lee (creator/artist), use Marvel
	"rarity": "Exclusive", // collection rarity
	"network": "XRPL", // blockchain being used
	"date_published": "August 5th, 2023", // mint date
	"is_family_friendly": true, // does the collection exclude ANY mature content?
	"burnable": false, // does the collection contain ANY burnable NFTs?
	"royalty_rate": "10%", // collection royalty rate
	"issuer": "", // creator wallet address
	"collection_size": 200, // full collection size
	"collection_items": [{1, 200, "Avengers Character"}], // array of the collection items of their UNIQUE item number, qty, and item name.
	"phygital": true, // does the collection contain physical items?

	// Dynamic Metadata
	"phygital_items": [{1, 1, "Avenger Character Sticker", "selfhosted://item.png"}], // array of item number, qty of the physical item, physical item description, and item image 400x400.
	"collection_image": "selfhosted://CollectionPFP.jpg", // collection PFP 400x400, to help automate a profile
	"banner_image": "selfhosted://CollectionBanner.jpg", // collection profile banner 1500x500,  to help automate a profile
	"sponsors": null, // collection sponsors
	"is_copyright": true, // does the collection have copyrights?
	"copyright_holder": null, // copyright owner
	"copyright_year": null, // copyright year
	"keywords": ["Avengers", "Heroes", "Disney"] // collection keywords for platform search
},

// CREATOR DATA
"creator":
{
	// ARRAY OF CREATORS WITH THEIR INFORMATION
	"creators":
	[
		{
			"name": "Disney", // creator name
			"external_url": "https://www.disney.com", // creator external url

			// DYNAMIC METADATA WITHIN THE CREATORS ARRAY
			"creator_image": "selfhosted://CreatorPFP.png", // creator PFP 400X400
			"description":"", // creator description
			"is_business": true, // is the creator a registered business?
			"founding_date": "null, // founding date of the entity
			"members":
			[
				{"Member1", "Title1", "selfhosted://member1PFP.png"},
				{"Member2", "Title2", "selfhosted://member2PFP.png"}
			], // array of members full name, title, and PFP 400x400
			"email": "info@disney.com", // creator's email contact
			"telephone": "+1(714) 999-9999, // creator's phone contact
			"social_links":
			[
				{"web_page": "Twitter", "value": "https://twitter.com/OCLostArt"},
				{"web_page": "Instagram", "value": "https://www.instagram.com/oclostart"},
				{"web_page": "Facebook", "value": "https://www.facebook.com/oclostart"},
				{"web_page": "Tiktok", "value": "https://www.tiktok.com/@oclostart"},
				{"web_page": "Discord","value": "https://discord.com/invite/hqRd2D3rQ2"},
				{"web_page": "Youtube", "value": "https://www.youtube.com/channel/UCHduG7uW3jZaokLjWplo0vA"},
				{"web_page": "Telegram", "value": null},
				{"web_page": "LinkedIn", "value": null}
			] // creator's social media links
		}
	]
},

"nft":
{
	// GENERIC NFT METADATA
	"name": "Avengers Character #1", // NFT name
	"description": "Avengers Character description", // NFT description
	"nft_image": "selfhosted://NFTpfp.png", // NFT PFP to summarize all the media content in the NFT if more than 1 media
	"edition": 1, // NFT id
	"rarity": "Ultra Rare", // NFT rarity in collection
	"is_family_friendly": true, // does the NFT exclude ANY mature content?
	"collection_item": 1, // item number in the collection
	"phygital": true, // does this NFT come with a physical item?
	"phygital_items": [{1, "Avengers Character Sticker"}], // array of quantity and item name of the physical item
	"burnable": false, // is the NFT burnable?
	"language_code": "en-us", // NFT language code
	"attribute_count": 4, // NFT attributes
	"attributes": 
	[
		{"trait_type": "", "value": ""},
		{"trait_type": "", "value": ""},
		{"trait_type": "", "value": ""},
		{"trait_type": "", "value": ""}
	], // list of attributes 

	// ARRAY OF MEDIA IN THE NFT WITH ITS INFORMATION
	"nft_media":
	[
		{
			"media_type": "video", // info on the media type
			"file_type": "mp4", // file type name
			"file_size": "", // file size
	
			// IMAGE NFT METADATA
			"image": null, // "selfhosted://image.png" - faster response time
			"standard_image": null, // "selfhosted://image.jpg" - low to mid quality image for faster download
			"ipfs_image": null, // immutable media on "ipfs://image.png"
			"3D_file": null, // selfhosted 3D AR file
			"image_resolution": null, // image resolution
			"image_pixels": null, // pixels per inch

			// VIDEO NFT METADATA
			"video": "selfhosted://video.mp4", // selfhosted for faster response time
			"standard_video": "selfhosted://videoLQ.mp4", // selfhosted - low to mid quality video for faster download
			"ipfs_video": "ipfs://video.mp4", // immutable media on ipfs
			"dna": "dna1",
			"video_preview": null, // array with a start & end time, lets the creator inform the platform the optimal time to preview
			"closed_captioning": null, // url to SRT file, SRT file syncs audio with video
			"video_recording_date": null, // video recording date
			"video_resolution": "", // video resolution
			"video_duration": "", // video duration
			"video_bitrate": "", // video bitrate
			"video_frame_size": "", // video frame size
			"video_codec": "", // video codec
			"video_url":
			[
				{"web_page": "YouTube", "value": ""}
			], // video streaming links

			// AUDIO NFT METADATA (catered to music)
			"audio": null, // selfhosted for faster response time
			"standard_audio": null, // selfhosted - low to mid quality image for faster download
			"ipfs_audio": null, //immutable media on ipfs
			"audio_duration": null, // audio duration
			"audio_sample_rate": null, // audio sample rate
			"audio_bit_depth": null, // audio bit depth
			"lyrics": null, // lyrics
			"isrc_code": null, // song ISRC code
			"recording_type": null, // live, studio, etc
			"recording_label": null, // record label
			"audio_recording_date": null, // audio recording date
			"recording_stems": null, // song stems
			"instruments": null, // array of instruments
			"license": "ipfs_license_file", //immutable media
			"audio_preview": null, // array of start and end time for the audio preview
			"in_album": null, // album name
			"album_type": null // single, album, EP, LP, etc.
			"track_number": null,// track number in album
			"genre": null, // text - genre name, can be used as a filter
			"audio_type": null, // song, audio book, etc, can be used as a filter
			"audio_bpm": null / beats per minute, can be used as a filter
			"audio_url":
			[
				{"web_page": "YouTube", "value": null},
				{"web_page": "Spotify", "value": null},
				{"web_page": "Apple Music", "value": null},
				{"web_page": "Pandora", "value": null},
				{"web_page": "Platform", "value": "platform link"}
			], // audio streaming links
			"purchase_url":
			[
				{"web_page": "", "value": null}
			] //purchase links, can be used for video as well

			// array of NFT media contributors
			"contributors":
			[			
				// GENERIC
				{"title_name": "digital_creators", "value": ["Wartortle"]},
				{"title_name": "editors", "value": [null]},
				
				// IMAGE
				{"title_name": "artists", "value": [null], // array of artist names

				// VIDEO RECOMMENDED FIELDS
				{"title_name": "actors", "value": [null]}, // array of actor names
				{"title_name": "characters", "value": [null]}, // array of fictional character names
				{"title_name": "directors", "value": ["Lost Art"]}, // array of names
				{"title_name": "video_producers", "value": [null]}, // array of names
				{"title_name": "videographers", "value": [null]}, //array of name
			
				// AUDIO RECOMMENDED FIELDS
				{"title_name": "recording_groups", "value": [null]}, // array of recording groups
				{"title_name": "recording_artists","value": [null]}, // array of artists
				{"title_name": "recording_features","value": [null]}, // array of artists/group features
				{"title_name": "songwriters", "value": [null]}, // array of songwriters
				{"title_name": "song_producers", "value": [null]}, // array of producers
				{"title_name": "mixing_engineers", "value": [null]}, // array of mixing engineers
				{"title_name": "master_engineers", "value": [null]}, // array of mastering engineers

                                 //CUSTOM
				{"title_name": "custom_field", "value": [null]}, // array of any custom field
			]
		}
	]
}

[oclostart]

This 2nd version separates the Dynamic data to its own section helping to simplify the file. It was a suggestion made by AirdropGaming.

// THE FOLLOWING IS MEANT TO...
// 1. ASSIST PLATFORMS IN CREATING AN OPTIMAL USER EXPERIENCE BY ALLOWING CREATORS TO PROVIDE DATA & CONTENT
// 2. PROVIDE SUPPORT FOR PHYGITAL NFTs
// 3. PROVIDE MORE INFO TO ALLOW PLATFORMS FILTER OPTIONS
// 4. PROVIDE OPTIONAL FIELDS DEPENDING ON MEDIA TYPE
// 5. SUPPORT MORE THAN 1 MEDIA FILE IN AN NFT
// 6. ALLOWS FOR CUSTOMUZABLE FIELD PROPERTIES
// 7. DEFINES PROPERTIES FOR THE COLLECTION, CREATOR AND NFT
// 8. EVEOLVE NFTS FOR BUSINESS USE

// NOTE: DYNAMIC METADATA ISN'T IMPLEMENTED, SUGGESTED SOLUTION: TOML FILES

// COLLECTION DATA
"collection":
{
	"name": "Avengers", // collection name
	"description": "Limited Edition Avengers Collection", // collection description
	"family": "Marvel", // (redefine family) For example, instead of Stan Lee (creator/artist), use Marvel
	"rarity": "Exclusive", // collection rarity
	"network": "XRPL", // blockchain being used
	"date_published": "August 5th, 2023", // mint date
	"is_family_friendly": true, // does the collection exclude ANY mature content?
	"burnable": false, // does the collection contain ANY burnable NFTs?
	"royalty_rate": "10%", // collection royalty rate
	"issuer": "", // creator wallet address
	"collection_size": 200, // full collection size
	"collection_items": [{1, 200, "Avengers Character"}], // array of the collection items of their UNIQUE item number, qty, and item name.
	"phygital": true, // does the collection contain physical items?
},

// CREATOR DATA
"creator":
{
	// ARRAY OF CREATORS
	"creators":
	[
		{
			"name": "Disney", // creator name
			"external_url": "https://www.disney.com", // creator external url
		}
	]
},

"nft":
{
	// GENERIC NFT METADATA
	"name": "Avengers Character #1", // NFT name
	"description": "Avengers Character description", // NFT description
	"nft_image": "selfhosted://NFTpfp.png", // NFT PFP to summarize all the media content in the NFT if more than 1 media
	"edition": 1, // NFT id
	"rarity": "Ultra Rare", // NFT rarity in collection
	"is_family_friendly": true, // does the NFT exclude ANY mature content?
	"collection_item": 1, // item number in the collection
	"phygital": true, // does this NFT come with a physical item?
	"phygital_items": [{1, "Avengers Character Sticker"}], // array of quantity and item name of the physical item
	"burnable": false, // is the NFT burnable?
	"language_code": "en-us", // NFT language code
	"attribute_count": 4, // NFT attributes
	"attributes": 
	[
		{"trait_type": "", "value": ""},
		{"trait_type": "", "value": ""},
		{"trait_type": "", "value": ""},
		{"trait_type": "", "value": ""}
	], // list of attributes 

	// ARRAY OF MEDIA IN THE NFT WITH ITS INFORMATION
	"nft_media":
	[
		{
			"media_type": "video", // info on the media type 
			"file_type": "mp4", // file type name
			"file_size": "", // file size
	
			// IMAGE NFT METADATA
			"image": null, // "selfhosted://image.png" - faster response time
			"standard_image": null, // "selfhosted://image.jpg" - low to mid quality image for faster download
			"ipfs_image": null, // immutable media on "ipfs://image.png"
			"3D_file": null, // selfhosted 3D AR file
			"image_resolution": null, // image resolution
			"image_pixels": null, // pixels per inch

			// VIDEO NFT METADATA
			"video": "selfhosted://video.mp4", // selfhosted for faster response time
			"standard_video": "selfhosted://videoLQ.mp4", // selfhosted - low to mid quality video for faster download
			"ipfs_video": "ipfs://video.mp4", // immutable media on ipfs
			"dna": "dna1",
			"video_preview": null, // array with a start & end time, lets the creator inform the platform the optimal time to preview
			"closed_captioning": null, // url to SRT file, SRT file syncs audio with video
			"video_recording_date": null, // video recording date
			"video_resolution": "", // video resolution
			"video_duration": "", // video duration
			"video_bitrate": "", // video bitrate
			"video_frame_size": "", // video frame size
			"video_codec": "", // video codec
			"video_url":
			[
				{"web_page": "YouTube", "value": ""}
			], // video streaming links

			// AUDIO NFT METADATA (catered to music)
			"audio": null, // selfhosted for faster response time
			"standard_audio": null, // selfhosted - low to mid quality image for faster download
			"ipfs_audio": null, //immutable media on ipfs
			"audio_duration": null, // audio duration
			"audio_sample_rate": null, // audio sample rate
			"audio_bit_depth": null, // audio bit depth
			"lyrics": null, // lyrics
			"isrc_code": null, // song ISRC code
			"recording_type": null, // live, studio, etc
			"recording_label": null, // record label
			"audio_recording_date": null, // audio recording date
			"recording_stems": null, // song stems
			"instruments": null, // array of instruments
			"license": "ipfs_license_file", //immutable media
			"audio_preview": null, // array of start and end time for the audio preview
			"in_album": null, // album name
			"album_type": null // single, album, EP, LP, etc.
			"track_number": null,// track number in album
			"genre": null, // text - genre name, can be used as a filter
			"audio_type": null, // song, audio book, etc, can be used as a filter
			"audio_bpm": null / beats per minute, can be used as a filter

			// array of NFT media contributors
			"contributors":
			[			
				// GENERIC
				{"title_name": "digital_creators", "value": ["Wartortle"]},
				{"title_name": "editors", "value": [null]},
				
				// IMAGE
				{"title_name": "artists", "value": [null], // array of artist names

				// VIDEO RECOMMENDED FIELDS
				{"title_name": "actors", "value": [null]}, // array of actor names
				{"title_name": "characters", "value": [null]}, // array of fictional character names
				{"title_name": "directors", "value": ["Lost Art"]}, // array of names
				{"title_name": "video_producers", "value": [null]}, // array of names
				{"title_name": "videographers", "value": [null]}, //array of name
			
				// AUDIO RECOMMENDED FIELDS
				{"title_name": "recording_groups", "value": [null]}, // array of recording groups
				{"title_name": "recording_artists","value": [null]}, // array of artists
				{"title_name": "recording_features","value": [null]}, // array of artists/group features
				{"title_name": "songwriters", "value": [null]}, // array of songwriters
				{"title_name": "song_producers", "value": [null]}, // array of producers
				{"title_name": "mixing_engineers", "value": [null]}, // array of mixing engineers
				{"title_name": "master_engineers", "value": [null]}, // array of mastering engineers
			
				// CUSTOM
				{"title_name": "custom_field", "value": [null]}, // array of any custom field
			]
		}
	]		
},

"dynamic_data":
{
	"dynamic_data": "selfhosted file" // self hosted file with only the Dynamic data
}

//DYNAMIC DATA IN SELF HOSTED FILE

	// Dynamic Collection Metadata
		"phygital_items": [{1, 1, "Avenger Character Sticker", "selfhosted://item.png"}], // array of item number, qty of the physical item, physical item description, and item image 400x400.
		"collection_image": "selfhosted://CollectionPFP.jpg", // collection PFP 400x400, to help automate a profile
		"banner_image": "selfhosted://CollectionBanner.jpg", // collection profile banner 1500x500,  to help automate a profile
		"sponsors": null, // collection sponsors
		"is_copyright": true, // does the collection have copyrights?
		"copyright_holder": null, // copyright owner
	"copyright_year": null, // copyright year
	"keywords": ["Avengers", "Heroes", "Disney"] // collection keywords for platform search

		// Dynamic Creator Metadata
		"name": "Disney", // creator name
		"creator_image": "selfhosted://CreatorPFP.png", // creator PFP 400X400
		"description":"", // creator description
		"is_business": true, // is the creator a registered business?
		"founding_date": "null, // founding date of the entity
		"members":
		[
			{"Member1", "Title1", "selfhosted://member1PFP.png"},
			{"Member2", "Title2", "selfhosted://member2PFP.png"}
		], // array of members full name, title, and PFP 400x400
		"email": "info@disney.com", // creator's email contact
		"telephone": "+1(714) 999-9999, // creator's phone contact
		"social_links":
		[
			{"web_page": "Twitter", "value": "https://twitter.com/OCLostArt"},
			{"web_page": "Instagram", "value": "https://www.instagram.com/oclostart"},
			{"web_page": "Facebook", "value": "https://www.facebook.com/oclostart"},
			{"web_page": "Tiktok", "value": "https://www.tiktok.com/@oclostart"},
			{"web_page": "Discord","value": "https://discord.com/invite/hqRd2D3rQ2"},
			{"web_page": "Youtube", "value": "https://www.youtube.com/channel/UCHduG7uW3jZaokLjWplo0vA"},
			{"web_page": "Telegram", "value": null},
			{"web_page": "LinkedIn", "value": null}
		] // creator's social media links

		// Dynamic NFT Metadata
		"video_url":
		[
			{"web_page": "YouTube", "value": ""}
		], // video streaming links
		"audio_url":
		[
			{"web_page": "YouTube", "value": null},
			{"web_page": "Spotify", "value": null},
			{"web_page": "Apple Music", "value": null},
			{"web_page": "Pandora", "value": null},
			{"web_page": "Platform", "value": "platform link"}
		], // audio streaming links
		"purchase_url":
		[
			{"web_page": "", "value": null}
		] //purchase links, can be used for video as well

[mvadari]

@x-Tokenize can you move this spec to a PR? Note that this does not mean that the spec has been accepted/implemented/finalized.

I will move it to PR by copy-pasting the existing draft if there is no response in the next week.