Enhanced Asset Information Specification

The enhanced asset info spec we have from the founders is good, but is very basic.

I have been meaning to write a CIP to extend this asset information to allow for additional information to be specified in a standardized way, but have never got around to it.

Now that we are at a point where users are abusing the ‘description’ field on xchain.io and using it to insert audio and video players and other random html, I feel defining the spec is a must. It is clear people want to be able to use audio/video and other content in their asset JSON, but we have no standards defined to do so.

Below I have come up with a basic schema which allows asset owners to specify much more information about their token, including owner and contact information, social media, as well as a way to specify audio, video, images, files, and dns in a standardized format.

Proposed v2.0.0 JSON Schema

Proposed v2.0.0 JSON Example

This spec has been discussed in the Counterparty Dev channel on telegram, and suggestions from those chats have been incorporated into the above proposed spec.

@JPJA had some good feedback on how the spec should include support for sha256 hashes for audio/video/images/files in the JSON schema. He also suggested adding the sha256 hash to the asset description to make validation easier for those who wish to validate JSON data.

JPs suggestions have been incorporated into this new proposed spec.

His thread is Immutable JSON / CIP25

I feel like this is investing further in a kludge. The “description” field is not the best way to persist info about associated media, is it? Isn’t this approach likely to need continual revisions over time as platforms change? I’m expecting imgur to shut down any time TBH.

Media descriptors are such an important property of a token that they deserves to be a first class citizens IMO, and have a database field dedicated to it. Side benefit: we can use the description field for, say, actual descriptions! (or hashes for the nerds)

The “description” field is not the best way to persist info about associated media, is it?

I believe it is, since using a single description field we can point to a JSON file which can have an infinite amount of information associated with it.

Isn’t this approach likely to need continual revisions over time as platforms change?

Yes, in the future this spec may change to add some additional fields to allow specifying even more information, but the spec that I have defined allows for MUCH more information now than the current 1.0.0 spec. This 2.0.0 spec should work for many years into the future, as it supports image, audio, video, files, and DNS.

Media descriptors are such an important property of a token that they deserves to be a first class citizens IMO, and have a database field dedicated to it.

I disagree as I believe this would unnecessarily bloat the CP database by storing more information in the database than is necessary. The counterparty database needs to stay as small and fast as possible, which means only including necessary information on transactions, not storing all sorts of additional meta-data for an asset.

The JSON meta-data can be cached to make it just as highly available as the Counterparty database, without the need to unnecessarily boat the CP database by storing meta-data.

Good work! Only a few comments;

  • For images, should the types standard, large, hires have defined acceptable ranges of height, width, MB?
  • JSON format with Hash. Make it clear that the the hash must be of the JSON file itself; 64-character sha256 hash of the json file.
  • Make https:// optional for URLs in description fields.
  • Also allow a shortened hash format for json; domain.com/info.json;HASH_SHORT. I suggest sha256 encoded with base64 and truncated at 16 chars (96 bits).

The basis for the last two points is to fit op_return. The max description length that fits is 52, and even one more char is significantly more expensive (not a big deal now perhaps, but we should prepare for future higher fees). A quirk with asset issuances is that the description must be included in every subsequent issuance (like transfer ownership, issue additional), thus a long description makes all later issuance transactions more expensive too.

This project has gone its whole duration without upgrading the json information. I do not see why there should be a sudden rush to get this new standard finalized without adequate input. While the community reviews each other’s work before publishing, it would be prudent to set the due date for responses to this proposal at least 60 days in the future. I know I would personally like at least 30 days (from OP) to gather my research and experiments into a formalized proposal, outlined with explanations and example code.

Due to the nature of the current setup it is possible that someone can create whatever JSON structure they like for any token. Furthermore they can load this json data to their own webpage. Telling users how they can and cannot use the platform is absurd. In this case more than most. However it is important for artists, publishers, and developers alike to be on the same page. This should not be an edict, but something that is agreed upon by those who use it. While there may currently be only one explorer, it does not belong to the community. When new explorers are developed (as some are, currently), they should be given the option to conform to established standards, instead of encouraging their users to practice proprietary methods.

Developers that are currently busy building things for the protocol should have a say on what this new standard covers. It is important that current development is set forth cooperatively so that newcomers in the future can be easily familiar with common practices. Mostly it is important for developers to be able to take into consideration the various metadata structures that can be supported by the protocol, when creating something for users.

Frankly the work arounds of hard linking three centralized hosting services should not be an official standard. Suggesting use of these brands is tantamount to sponsorship or free advertising. AFAIK, Imgur was originally used with freeport because the developer claimed they did not want to curate content, and relied upon this free service for such. Youtube has a reputation for deleting content. Soundcloud offers a free limited space and requires users to pay for more. None of these services are based on peer to peer technology, none of them are open source and all of them are corporate endeavors who do not sponsor counterparty.

Food for thought on a matter of perception. The description value of each Counterparty token has a history. Each entry can be used to store and access data. For example, the sha256 of the main file of the token can be the first description. The next would be an IPFS CID. In this way, the asset itself can have the minimum required metadata on the protocol itself. These kinds of variables would most likely never change, and this information can be aggregated. The practice of limiting character/byte limit to 45 characters or less is usually followed as to avoid btc change issues in the wallet. The offset to that disadvantage is that doing so assists in permanence of cryptoart without reliance on clearnet webhosting and domains in perpetuity.

70 characters.

For that matter an often underutilized feature has not been brought into consideration TTBOMK. Using the broadcast feature allows the publisher to include any metadata on the protocol with a fee that increases with length. Broadcasting the metadata for a token, then using the token description to connect via tx# will allow for permanent storage of the metadata within the same system as the token. This guarantees that as long as the token is accessible, so is its essential metadata.

The above option is to be considered for permanent and most important aspects of the metadata. Other metadata, that may change over time, or is less vital can be stored with existing json linkage via URLS. Variables such as a description for visually impared, caption at the bottom of the image, alternative sizes of the file, the thumbnail image with less priority can be fetched and edited via linked description file. This can take into consideration the other utilization of history to have one description of a token link directly to the json data in a broadcast, followed by the json data linked in the next description update.

I do have a concern that the more complicated the JSON structure gets, the more difficult it will be to program around. It would be the best case if all explorers could have the proper functionality built in so that all enhancements do not break if one value is empty. It is also troubling to see “undefined” displayed over and over again. In order to look competent, the publisher currently needs to include a series of empty values in each file. With a dozen extra empty variables per token, that is quite a bit of data bloat on the side of the json web host. Not to mention more internet traffic which would add up once the number of bloated json assets gets to the tens of thousands or more.