XLS-0089d Multi-Purpose Token Metadata Schema

[DennisDawson]

An updated version of this spec can be found here: XLS-89: Multi-Purpose Token Metadata Schema.

The earlier version can be found by looking at the edit history.

[BooneTB]

Great example, thank you Dennis & Contributors!

[WietseWind]

"Metadata can be accessed and verified on the ledger without having to fetch data from an external URI"

If the idea is to encode the JSON into a blob and store it on-ledger, I believe it would make sense to limit the overhead to the bare minimum. Close to 50% of the storage will be consumed by keys.

I would propose to support two different formats of JSON keys, short & long. If stored on ledger, I propose the shorter version to be used to save redundant key (UTF8) name storage:

{
  "c": "RLUSD",
  "n": "Ripple USD",
  "d": "Regulated stablecoin",
  "i": "ripple.com/assets/rlusd-logo.png",
  "cl": "rwa",
  "cs": "stablecoin",
  "a": "Ripple",
  "w": [
    {
      "u": "ripple.com",
      "c": "website",
      "t": "Official Website"
    },
    {
      "u": "xrpl.org",
      "c": "docs",
      "t": "XRPL Documentation"
    }
  ]
}

💡 Proposal: whenever a URL notation (weblink, icon, ...) is pointing to hosted content on https, skip the https:// component: that would be default. Only if another protocol/deeplink protocol is required, specify.

short	long	comment
c	currency	💡 Proposal: refer to as code instead of currency, it may not be a currency
n	name
d	desc
i	icon
ac	asset_class
as	asset_subclass
a	acct_name
w	weblinks	💡 Proposal: l, long: links, could be non-web?
w.u	weblinks.url	💡 Proposal: uri, doesn't have to be url
w.c	weblinks.type	💡 Proposal: c for category instead of type, to spare t for title
w.t	weblinks.title

💥 Note: I have no strong opinion about any of this, any standard would work for me, I mostly have three goals:

1. If there's a standard that would be stored on ledger (I like, saves lookups): keep it compact to not be wasteful with on-ledger resources
2. Not to have to support 14 standards over time. Let's get it right now, and build on what we settle on
3. Get a standard ASAP to prevent the horror situation from point 2

P.S. TLV over encoded JSON imo, but I can see the appeal for the average dev over TLV...

[WietseWind]

@arminas5 Wait, what: rippled decodes and validates HEX encoded JSON in the MPTokenMetadata MPT issuance BLOB - which is an unstructured BLOB field instead fo an (array of) STObject(s)? - I find that hard to believe?

[arminas5]

Ah, I checked it and looks like it was only my dream somehow :/

[zgrguric]

Ok, please update OP info with new proposed schema.

[julian78780]

Hey @WietseWind - thanks for sharing this.

For context, our team (DGE) worked on this standard, raised the PR, and it was merged into XRPL Standards a while ago: https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0089-multi-purpose-token-metadata-schema

There are some minor differences compared to what’s discussed here, so it’s worth reviewing the merged version. At this point, any updates should probably be proposed as a PR to XLS-89 rather than revisiting outdated proposals in this thread. We'll look into closing this discussion since Dennis is no longer at Ripple.

We’ve also been contributing to XRPL Meta and adding Explorer support for MPTs using the proposed metadata. Those Explorer changes should be live mid next week. Regarding your suggestion: I agree that shorter JSON keys make sense to save ledger space. I’ll review this with the team tomorrow to assess feasibility and the effort required to rework for short keys.

One thing to keep in mind: XLS-89 was designed to be interoperable with XLS-26 (IOU Token Metadata): https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0026-iou-token-metadata

If we shorten the schema here, we’ll need to think carefully about alignment with IOUs and XRPL Meta to avoid divergence.

[julian78780]

We will proceed with closing this discussion and raising the PR