0016 XLS-16d: NFT Metadata

[HubertG97]

In addition to @WietseWind 's XLS-14d and @RichardAH 's proposal XLS-15d here is a proposal to create a standard for the creation of metadata for the tokens created with a CTI in the currency code.

When issuing an indivisible token on the XRPL the only data given is the currency code. For optimal usage, there has to be more metadata for an NFT. For example a description and a URI to an IPFS file.
Using the Concise Transaction Identifier, a prior transaction can be used to mark the metadata contained in the memo's field for the use of the NFT.

The Memos Field in an XRPL transaction is presented as an array of objects which contains one memo field per object. This field consists of the following fields:

• MemoData
• MemoFormat
• MemoType

The MemoData field can be used for the metadata itself and the MemoFormat indicates the nature of the given data inside the MemoData field (MIME type). To create a certain hierarchy for covering failure of the URI specified, the MemoType field contains the numbering of the data named as shown below followed by the MIME type:

• NFT/0 - Description - text/plain
• NFT/1 - Author - text/plain
• NFT/2 - Primary URI - text/uri
• NFT/3 - Back-up URI - text/uri
• NFT/4 - Reduced image Data URI as last back-up - text/uri

The usage of a back-up URI and Data URI can be seen as optional and can be replaced with other kinds of data that have the preference of the issuer of the NFT for example contact information.
The limit of storage is 1kb of data in the memo's field in total. Multiple memos can be used to give as much information as fits to the 1kb of data.

If there is only one memo on the CTI referenced transaction and the memo data contains a URI of any sort then this is deemed to be the NFT content. The multiple memo's structure will be the advanced method to issue NFTs. The standard will also be compatible with previously created NFTs referred to as the simple method.

---

Issuing

For the metadata, there has to be created a transaction from the same address as the issuer of the NFT to for example a hot wallet. This transaction of 1 drop contains the description and URIs needed for the NFT.

The currency code for an NFT consists of 3 parts:

• Prefix 02 for HEX currency code
• CTI (Concise Transaction Identifier)
• Short name converted to HEX for the NFT to a maximum of 12 characters or less (filled up with 0's if it's less)

After this, a Trust line can be set up using the above currency code and the NFTs being transferred from the issuing address to the hot wallet.

---

Advanced method

For example

Issuer: rBzoA1EXxE2FeGV4Z57pMGRuzd3dfKxVUt
Hot wallet: rp9d3gds8bY7hkP8FmNqJZ1meMtYLtyPoz

The JSON for the metadata transaction would look like this:

{
  "Account": "rBzoA1EXxE2FeGV4Z57pMGRuzd3dfKxVUt",
  "TransactionType": "Payment",
  "Amount": "1",
  "Destination": "rp9d3gds8bY7hkP8FmNqJZ1meMtYLtyPoz",
  "Fee": "100000",
  "Memos": [{
    "Memo": {
      "MemoData": "546861742773206F6E6520736D616C6C20696D616765206F66206D6F6F6E2C206F6E65206769616E74206C65617020666F72204E4654206F6E20746865205852504C",
      "MemoFormat": "746578742F706C61696E",
      "MemoType": "6E66742F30"
    }
  },
    {
      "Memo": {
        "MemoData": "48756265727420476574726F7577",
        "MemoFormat": "746578742F706C61696E",
        "MemoType": "6E66742F31"
      }
    },
    {
      "Memo": {
        "MemoData": "697066733A2F2F62616679626569686561786B696A3276656D6B7337726B716E6F67367933367579793337626B33346D697533776F72636A756F6833747532773279",
        "MemoFormat": "746578742F757269",
        "MemoType": "6E66742F32"
      }
    },

    {
      "Memo": {
        "MemoData": "68747470733A2F2F676574726F75772E636F6D2F696D672F707572706C656D6F6F6E2E706E67",
        "MemoFormat": "746578742F757269",
        "MemoType": "6E66742F33"
      }
    },
      {
      "Memo": {
        "MemoData": "646174613A696D6167652F6769663B6261736536342C52306C474F446C684641415541505141414141414142415145434167494441774D4542415146425155474267594842776348392F66342B506A352B666E362B7672372B2F76382F507A392F66332B2F76377741414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414143483542414541414241414C4141414141415541425141414157524943534F5A476D65614B7175624F74437A664D7551564D456937674D41494D554D684942554F4D784941454141544A736942674F4A674267654267456A476E413063673945524446464342364E4D6248305945684543454579784844414354316571383352486C69654D73474147414641414949436A495051776F4F66675A4A41544A5A5932414C4255634B535A516A684552424A41384355774F6750414B6649326445547156554A6A774166364345435352694F436F4D42416F6A6A61675149514137",
        "MemoFormat": "746578742F757269",
        "MemoType": "6E66742F34"
      }
    }]


}

Converted to human-readable output's this transaction

Using this transaction's txn hash, txn_index, ledger_hash, and ledger_index creates a CTI of 23080995397183855
Converted to HEX it will be 52000B03B6296F

The name of the NFT will be 'Purple moon'.
After conversing this to HEX the complete currency code looks like this 0252000B03B6296F507572706C65206D6F6F6E00

02 - XRPL NFT identifier
52000B03B6296F - CTI
507572706C65206D6F6F6E00 - NFT name

When Issuing a token the same address has to be used as the sender of the aforementioned transaction.
As explained in this blogpost a Trust line has to be created between the Issuer and the hot wallet.

Make sure the issuer address has an AccountSet of SetFlag to 8

{
    "TransactionType": "TrustSet",
    "Account": "rp9d3gds8bY7hkP8FmNqJZ1meMtYLtyPoz",
    "Fee": "12",
    "Flags" : 131072,
    "LimitAmount": {
      "currency": "0252000B03B6296F507572706C65206D6F6F6E00",
      "issuer": "rBzoA1EXxE2FeGV4Z57pMGRuzd3dfKxVUt",
      "value": "1000000000000000e-95"
    }
}

In the currency field the HEX converted currency code is used.
The value is set to 1000000000000000e-95 which will result in 10 NFTs.
More explanation about this can be found in @WietseWind's proposal XLS-14d

Last step is to send the tokens from the issuer to the hot wallet.

{
"TransactionType": "Payment",
"Account": "rBzoA1EXxE2FeGV4Z57pMGRuzd3dfKxVUt",
"Fee": "12",
"Destination" : "rp9d3gds8bY7hkP8FmNqJZ1meMtYLtyPoz",
"Amount": {
"currency": "0252000B03B6296F507572706C65206D6F6F6E00",
"issuer": "rBzoA1EXxE2FeGV4Z57pMGRuzd3dfKxVUt",
"value": "1000000000000000e-95"
    }
}

Now there are 10 Purple moon NFTs on address rp9d3gds8bY7hkP8FmNqJZ1meMtYLtyPoz

Simple Method

The JSON for the metadata transaction would look like this:

{
  "Account": "rBzoA1EXxE2FeGV4Z57pMGRuzd3dfKxVUt",
  "TransactionType": "Payment",
  "Amount": "1",
  "Destination": "rp9d3gds8bY7hkP8FmNqJZ1meMtYLtyPoz",
  "Fee": "100000",
  "Memos": [{
    "Memo": {
      "MemoData": "697066733A2F2F62616679626569666C6A667870786F7A6E6A703273357266697270666A756E7876706B71737863727133766C626F6C346536717A376F7972693571",
      "MemoFormat": "746578742F757269",
      "MemoType": "7872706C2F6E6674"
    }
  }]
}

Converted to human-readable output's this transaction

After that, a trust set and sending the tokens is the same as the advanced method

[yyolk]

I like it!

My one inclination is thinking that the protocol scheme in the URI can indicate whether or not it's IPFS.

I think adopting IPFS directly is not a bad idea, but it's just a URI with a scheme.

Maybe I'm the only one that thinks this, but I've been perfectly capable of storing assets for millions of users for years (longer) and for much cheaper than IPFS.

In that regard, my suggestion would be to recommend something like IPFS for "primary" URI, but not stipulate it.

NFT/2 - Primary URI - text/uri

[calvincs]

Also should mention, webtorrents DO allow failback HTTPS seed sources (like domains), just as normal torrents do.
http://www.bittorrent.org/beps/bep_0019.html
https://github.com/webtorrent/create-torrent

Pretty easy to write up, could add it to my example codebase @ https://github.com/calvincs/xrpl-nft-creator

[yyolk]

This is really good discussion thank you for the feedback!

I would feel remiss if I didn't mention that IPFS is directly correlated with FILecoin. Therefore, buying into IPFS will directly lead to buy in of $FIL. I don't wish to support the business model of $FIL which hasn't been proven.

While interacting with IPFS does not require using Filecoin, all Filecoin nodes are IPFS nodes under the hood, and can connect to and fetch IPLD-formatted data from other IPFS nodes using libp2p. However, Filecoin nodes don't join or participate in the public IPFS DHT.

"IPFS Distrubuted Hash Table" = torrent tracker

In lieu of today's events one can reason why $FIL doesn't directly call out it's intrinsically tied to IPFS.

I'd rather support protocols like torrents like @calvincs suggested, which is what IPFS is wrapping and calling a protocol.

The metadata store itself or pinning metadata is not necessary when we could include an alternative like magnet-links.

Sorry for diverging but I think defaults often imply trust and best option, when I, who is probably a minority, don't accept that's the case.

For me referring it to Primary URI over IPFS URI is thinking forward towards integrations requiring that to be IPFS, if it were to be suggested and accepted here.

When instead we could interpret like another web resource with a few suggestions for primary asset store, I also am inclined to believe that can change over time, and new things can be supported - with this suggestion being the least amount of friction for those already in NFT (albeit, in my opinion, a bit jaded with what they expect vs what is reality).

[HubertG97]

I just read your tweet about it and could create concern's using IPFS for NFTs. I will for sure try out using a torrent protocol. Also the majority of people are unaware of the storage of the actual file or image of a NFT.
Now we are just starting with NFTs on the XRPL we of course want to do it the best way possible and find the most reliant way of keeping the data available.
I also agree that these services will come and go, still hope for all the NFTs already minted on the ETH chain that IPFS nodes will stay up, and don't make the NFTs worthless.

[calvincs]

I do want to make sure we all understand that IPFS came before Filecoin. And BitTorrent before Justin S. from Tron bought it and eventually re-invented the stack to incorporate IPFS tech (BTFS).

While Filecoin in part runs on IPFS, IPFS does not require Filecoin. Same for BitTorrent. ETH also uses IPFS, and can use other protocols as well.

I would want to steer away from not using great technologies just because another technology uses the same protocol. The more we can incorporate Web3.0 tech, the better honestly. More of an "All ships rise" mentality.

[yyolk]

A few things i would be remiss if I didn't remark.

• BitTorrent is a protocol made by Bram Cohen. The company of BitTorrent may have been bought but that doesn't meant he owns the standard in the "protocol."

• in their own FAQ IPFS and FileCoin were made by the same company.
  via their FAQ

• Web3 is a facade of a standard intentionally made around buzzwords like web 3.0, which is semantic web. don't mistake web3 for a standard as well, it's a poor mish mash of bad user experiences, entirely geared for ETH. XUMM for instance uses recognizable flows, but is all done uniquely better IMO, and is similar to signing in to WhatsApp or discord through a QR code.

Apologies for tossing around words like standard/protocol, it's not very helpful and am trying to arrive at a better idea myself. I also may be a bit hyperbolic but I don't necessarily agree with "let's just copy what ETH does.", it's hard for me to accept that we have something good / emblematic to look at when it comes to ETH's NFT for good user experiences.

[shortthefomo]

An important read https://twitter.com/jonty/status/1372163423446917122 some of the ISSUES with NFT's

[calvincs]

Agree with all these concerns; let me address my thoughts on a few of them.

In the link above yours, "Who is responsible for NFT data", they bring up a good point; at some time, another person will be responsible for maintaining the property.
Whether it be a physical copy or digital (which you could argue is still physical in some sense), someone needs to maintain that property.

With that in mind, the property itself shouldn't have to live on the wire to be used or considered valuable.

Some of my thoughts on this:

1. The owner of the NFT should own the responsibility to maintain that property. That is their responsibility. That needs to be clearly defined in a legal section within the NFTs metadata.

1a) NFT metadata should contain legal verbiage that spells out the responsibilities of all parties.

2. We, as developers of an NFT should provide as many ways to decentralize the initial data storage as possible, within reason. And fully express this limitation to the end-user for awareness (see above 1a) IPFS/WebTorrents/HTTP/others

3. All NFTs files should, in their metadata, contain a link back to the "proof" of ownership that exists on a chain, whether it be XRP, ETH, or any other chain. As an example, see the metadata in the mp4 file https://ipfs.io/ipfs/bafybeiccp7ikixrum3kizkbezqtvl4fylomiihdtg4pm2wyhojhsp3wdgu/BigBuckBunny.mp4
   It contains a string "XRP://XVNFT2byUWwpzimqh1LjN2RcrYBNbymJEChnuSrE1n4n8jH" and other details which help prove our ownership.
   This should be a standard for NFTs content in general, IMHO.

4. Optional but undoubtedly beneficial, having a multichain NFT would serve a similar purpose as data storage in proving ownership and building in the resiliency of proof across multiple chains.

5. All NFTs should provide multiple hashes of file content which helps prove the data is owned by the NFT holder, despite the platform. As such CIDs, SHA256 checksums, WebTorrents all provide this in some fashion.
   These hashes should be easily visible in the blockchains they are associated with for easy validation of content ownership.

A downloaded copy of the work will have the same SHA256 as the original and still allows the owner to retain the work offline if they so choose.

6. As developers, we should support tooling which easily allows users to retain local copies of their NFTs. These local copies should support re-pinning or hosting the content and, or if they so choose, leaving it offline. But if even offline, having the ability to prove cryptographically they own said works.

[calvincs]

Transferring thoughts from another thread: #34 (reply in thread)

If the CTI pointer is failing to resolve to the meta, how does the end users application pull the meta that it requires in order to show the content, or validate they own the digital objects?

This is one thing I really like about the XRP ledger, and I find as one of its strong suites as compared to other block chains, you don't require a full history of TXs. If we begin to use the meta in the memo of a TX, and then use a pointer which can roll off (unless you maintain full history), you create complexity. Over time the system will become fragile (NFTs).

However, if the pointer/meta is in the Account Root, no number of transactions is required for storage for later retrieval.
Are my assumptions of this limitation incorrect?

If not, I think we should really consider putting the meta/pointer data in the Account Root, like the Domain/Email/Msg Key hash, or create a new field (I dont think this is required tho).

Im writing a piece of software which may help with this by providing Account Root summary data in a p2p fashion for clients. And while some hosts would need to periodically query the ledger to compile said data, those hosts would not require the full processing power of a full history rippled node to do that, as we are only examining the latest state of the ledgers accounts. And clients as simple as phone web browsers should be able to acquire, parse, and locate whatever services or meta they require from the ledger, from a given address, in a reasonable time period.

If you can use the strengths the XRP ledger gives you out of the box, and boot strap your apps that way instead of requiring heavy services like full history nodes, IMHO it makes the app and the use cases stronger. Small light weight apps should have as easy of a time locating services or pointers tied to assets on the ledger as possible w/o requiring resource intensive infrastructure.

I understand Xumm has a well maintained back end, full history nodes, beefy post processing w/ lookup tables, etc. But not all apps have that power, and if possible, if we can make that not a dependency for applications, XRP dependent apps and services would be better for it. This would also allow more agility for apps, less dependence on said heavy services like full history nodes do function normally.

This is why when I built the demo code I did, it used the Account Root, the one thing that always carries forward.
Thoughts?

[RichardAH]

Transferring thoughts from another thread: #34 (reply in thread)

If the CTI pointer is failing to resolve to the meta, how does the end users application pull the meta that it requires in order to show the content, or validate they own the digital objects?

This is one thing I really like about the XRP ledger, and I find as one of its strong suites as compared to other block chains, you don't require a full history of TXs. If we begin to use the meta in the memo of a TX, and then use a pointer which can roll off (unless you maintain full history), you create complexity. Over time the system will become fragile (NFTs).

However, if the pointer/meta is in the Account Root, no number of transactions is required for storage for later retrieval.
Are my assumptions of this limitation incorrect?

If not, I think we should really consider putting the meta/pointer data in the Account Root, like the Domain/Email/Msg Key hash, or create a new field (I dont think this is required tho).

If your concern is that there will be no full history servers and full history will be lost then you should be equally concerned that there will be no validators and the current state will also be lost.

Using data stored in (current) account state means the data is mutable. It can always be changed after the token is issued by the owner of the account unless the account is blackholed. It is also a very limited storage, much smaller and less versatile than a txn memo.

My suggestion for making CTI based metadata more “permanent” if you are worried about history loss is to record the full canonical ledger for the CTI along with the signed validation of it by the then-current UNL. This can be placed into an NFT certificate in the form of a PDF or similar and given in hard copy if needed as permanent proof of issuance.

[calvincs]

I'm not honestly overly concerned about lack of full history nodes, but rather that not all people will have the same access to that data. And requiring that data, in the long term, adds complexity to the system by requiring that full history nodes would then need to exists in some fashion. Its even possible requiring full history nodes, due to the cost associated with their storage creates some form of centralization, or in balances due to who has the ability to host such data. I think adding the signed validation by the then-current UNL will be helpful, but still not completely resolve that issue.

While the account root data is mutable, the account address itself is not. If the Digital object we create is pointing to the account address, and the account address is pointing back to the Digital object, they now have a relationship that confirms their authenticity. And while I do understand that the account domain could be changed, I actually see this as a positive thing. This allows the person with the Digital object to check the account, see the meta link is broken, and therefore unless the domain is set properly, the contract between those two items can be voided. The owner of the digital object can release the Digital Object back to the ecosystem (think public domain) for all users, and reclaim the XRP value from the account deletion. I think this is a powerful concept, among others this allows.

[RichardAH]

While the account root data is mutable, the account address itself is not. If the Digital object we create is pointing to the account address, and the account address is pointing back to the Digital object, they now have a relationship that confirms their authenticity. And while I do understand that the account domain could be changed, I actually see this as a positive thing. This allows the person with the Digital object to check the account, see the meta link is broken, and therefore unless the domain is set properly, the contract between those two items can be voided. The owner of the digital object can release the Digital Object back to the ecosystem (think public domain) for all users, and reclaim the XRP value from the account deletion. I think this is a powerful concept, among others this allows.

I don't think this is an either/or thing. Taken together XLS14d, XLS15d and XLS16d describe one way to publish NFTs on the XRPL. There's nothing to prevent you from publishing for example an XLS18d as a competing or alternative standard. Provided the first byte of currency code is always a disambiguator then multiple standards can co-exist. It's up to wallets to implement them and authors to use them.

[intelliot]

The "blogpost" link goes to https://coil.com/blogs/edit-post/ckljw6y1a9dba0894xk8inqa0 which is not publicly accessible (I get a 404 error).

[HubertG97]

Thankyou! I will edit it right now

[mvadari]

@HubertG97 should this spec be moved into PR and kept in the repo or should it be closed? 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.