Blockchain Validated Asset Metadata provides a mechanism to define detailed information about a Counterparty asset without trusting a central web server to give you the correct data.
At Tokenly, we anticipate a significant need for detailed asset metadata and expect other projects will benefit from having a shared standard. As such, we’d like to propose a formalized standard of BVAM and adopt it as a CIP. Here is the full proposal:
This proposal builds on top of the idea proposed by @loon3. We have modified and extended some of the details, but the idea remains basically the same as what @loon3 proposed.
Of note, we are proposing an optional identity verification standard in this proposal in addition to blockchain validation. The blockchain verification attests that the BVAM document was authored by the issuer. And the identity verification layer ties the author and issuer to an organization name or website domain using industry standard x.509 (SSL) certificates.
At this point of the CIP process, we are looking for technical and general community feedback. If there are no technical issues expressed by the community and the proposal is deemed well-formed, then it will be adopted in “draft” status.
This is an informational proposal meaning that it requires no changes to the Counterparty code or protocol. It is simply a standard that the community may wish to follow if it finds useful. BIP 32 is a classic example of an informational proposal in Bitcoin.
Regarding the Category Schemas (this section specifically),
“The address of the first broadcaster becomes the owner of a given category schema ID. This owner address may broadcast future updates to the BVAM Category Schema with this ID by increasing the version number and providing a new URL.”
I’m not against the idea of introducing new scarce namespaces into Counterparty, but something like that should be given its own CIP and the rules should be very explicit. Using Broadcasts to store namespace data with a unique ruleset probably warrants a separate CIP as well.
It doesn’t matter if they can be up to 1000 characters long, the fact that the first to broadcast a category schema becomes the “owner” makes them scarce.
The rules only affect BVAM in your current implementation, but broadcasts could be used for storing a variety of ordered data sets. A more generalized methodology and standardized rule set for that deserves its own CIP.
Agreed. That could be an interesting use case for Counterparty broadcasts.
But that is more than what we need for BVAM Category Schema IDs.
The schema ID can be something completely opaque like “cffe8740ddb1”. It just needs to be unique. Game currency issuers, for example, might create an in-game currency standard called “The IGCC In-Game Currency” with an ID of “IGCC In-Game Currency 201609”.
I went back and re-read the Category Schema section. I was thinking initially that these would be broad categories of token types that could potentially attract squatters if they caught on (DEED, TITLE, POINTS etc.)
I think I understand your intention now (specific applications). That being said, storing this information accessible via URL in a separate tx is somewhat heavy handed and not really all that necessary. Why not just have a top level “map” parameter in each asset BVAM that contains the Category Schema object? It’s one less tx, one less remote url query, and it accomplishes the same thing.
Why not just have a top level “map” parameter in each asset BVAM that contains the Category Schema object? It’s one less tx, one less remote url query, and it accomplishes the same thing.
Good question. I was torn on that one. There are some advantages in embedding the category schema right into the BVAM for sure.
Here are 4 reasons I want to keep them separate:
It is just easier to reason about. Say Acme, Inc. issues a game currency token and embeds their “Game Currency” Category Schema. Then BetaGames, Inc. releases a currency with a slightly different embedded “Game Currency” Category Schema. Then how can a wallet know which is the standard one to follow? Does it have to look at all token issuances and check them for a previous category definition? It feels like mixing very different concerns when merging a category definition and token metadata.
Multiple categories are easier to deal with. Our intention is to create “types” or “categories” of tokens that become standard. It anticipate we will see a pattern of small token types emerge and many tokens will subscribe to several categories. So a token could be a “TCA Token”, a “Redeemable Token” and an “Artist Coin” all at the same time. It is easier and cleaner to refer to these categories by ID.
Schemas should be able to be updated separately from the token BVAM. Schemas can be upgraded in a backwards compatible way. So IGCC v1.0.2 is compatible with tokens that validate with IGCC v1.0.1.
Efficiency of data. I anticipate a handful of category schemas compared to a lot of token issuances. It is more efficient to not duplicate the category schema for every issuance.
I do realize so much of this is guesswork at this point since the use cases for this are just starting to emerge. But my instincts tell me that it will be easier to deal with the category schemas separately from the token metadata.
In the same way you use JSON Schema v4 as a design parameter, client’s would be designed to handle whatever custom template the associated assets are utilizing. There’s no value added by writing the template into a transaction because you need to know what it is ahead of time when developing the client.
You can just publish your different schema templates on github for developers to reference.
Again, just update on github. At the end of the day, any changes will need to be written into the client software that utilizes that schema template.
You probably don’t even need to write it into the asset metadata, but even if you do, we’re talking about a very small amount of data. Since the data itself is not being written into a transaction, the increased metadata size is negligible. For example, if I run a website using Bootstrap, users don’t know or care if I’m using a CDN or hosting the CSS locally.
A wallet can show the name of the categories that a token belongs to without knowing anything special about the metadata.
There is value in writing a template hash into a transaction. You gain decentralization, immutability and public auditability.
There is no reason you can’t host your schema template on github. This does not prevent anyone from doing that.
By recommending that schema owners broadcast the schema ID and a hash, we gain the benefits of anchoring it into the blockchain (immutability and auditability).
A schema on github can be modified or deleted by the owner. Github could delete or suspend an account.
You seem very against publishing a schema hash into the blockchain. I don’t understand your resistance. Why wouldn’t we want to do that? What do we have to lose?
The wallet would still need to download the specific asset metadata to gleen that information. I don’t see how pulling template data from another URL is a benefit here.
I’m against including it in the formal standard because IMO it’s completely unnecessary and adds extra complexity and limitations. If a schema template is actually being used, it would be referenced in the client software that’s using it so there isn’t a risk of censorship. Asking clients to query a second URL containing the template data makes the “owner” of the category name the weak link because he/she must maintain the server that’s hosting the data as well as secure the private key that manages the “ownership”.
You are suggesting that wallets hard-code the schemas into their software. I think that is totally feasible and a good idea. And nothing about this spec would prevent wallets from doing that. Wallets are not compelled to download the spec from the URL if they don’t want to. They are completely free to ignore a category schema if they don’t care about that type of token metadata.
You don’t need to maintain a server to do this. Our BVAM provider will host this data for you and I expect other providers may elect to as well. There are also free alternatives like rawgit:
I think this is where we disagree. I agree that it adds some extra complexity. But, unlike you, I think the complexity is worth it for immutability, auditability and most importantly to deterministicly resolve universal ID clashes. The Bitcoin Blockchain is pretty good at that. I say let’s use it.
If you can think of a better way of handling Category Schema IDs to avoid clashes, I'm certainly open to suggestions. I thought about Namecoin or an Ethereum contract. But those are way too complicated and depend on other unrelated technologies.
My point is you don’t need specific IDs. If you’re working on a metadata template that you want to use and want others to use, you just need to share it on your github repo and developers will choose whether or not to use it for their assets or to write client software that recognizes assets with metadata in that format. That’s exactly what this CIP is. Do you propose we write the hashes of CIPs into the block chain? You don’t need to block chain all the things. None of the schemas here (GitHub - fge/sample-json-schemas: Sample JSON Schemas) are written into the block chain and that hasn’t stopped people from using them.
I do want specific IDs for the category schemas. And I want anyone to have the option to create a schema and an ID and then broadcast it.
I understand your argument and it is totally valid to do it your way. Tokenly could create a github repository of schemas and accept pull requests for new schemas and additions to schemas. That would totally work.
But that just isn’t what I want to propose in this CIP.