I do not see why there should be a sudden rush to get this new standard finalized without adequate input.
There is no rush to get anything finalized… in case you missed it the CIP status is “DRAFT” and will remain so for a long time to give people a chance to give feedback and improve this standard.
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.
Not sure where your getting this idea that anyone is telling users how they can and cannot use the platform… we are simply standardizing fields in a JSON file so that people can put data into the JSON file in a standardized format and display the content in a standardized format on blockchain explorers, etc. Nowhere is anyone saying this is the only JSON structure that will be used, people are still free to create their own JSON files containing whatever info they want and point their asset to them.
Developers that are currently busy building things for the protocol should have a say on what this new standard covers
Again, see my first comment where I mention that the CIP is in DRAFT mode (I encourage you to read CIP1 and how the CIP process works, and specifically the various statuses and what they mean). I believe your misinterpreting a CIP being in the repo as it being finalized and for some reason have the mindset that something is trying to be forced through here, which is not the case.
Frankly the work arounds of hard linking three centralized hosting services should not be an official standard.
Huh? What are you talking about? CIP25 is about standardizing the JSON file format to support additional information and documenting asset formats which already work (again, I think your misreading / misinterpreting CIP25)… Nowhere does it say that we should standardize hard linking of centralized hosting services (in fact, the CIP25 is proposed so that we can put more information in the JSON file in a standardized way and get AWAY from using funky formats for centralized services.
If your issue is that we should not be linking any assets to imgur, soundcloud, or youtube in the past… well, one of the only reasons why XCP has NFTs and is able to easily link images to NFT tokens is BECAUSE I came up with the “hack” a few years ago to support this custom format in asset descriptions on xchain.io… this was never meant to be standardized as how people should link images forever… and was just a way for users to easily integrate their NFT image with an NFT token immediately… wether you agree with this “hack” formatting on xchain or not, there is no arguing that without these hacks, we wouldn’t have anywhere near the level of NFTs we have on Counterparty (5000+ NFTs link to imgur images)
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.
If you would like to put forth a proposal for your TTBOMK formatting idea, go for it. There are other proposals for storing meta-data on Counterparty as well such as the BVAM method. Please take the time to write up your proposal into a separate CIP for consideration.
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.
Yes, and the CP database was meant for storing transactions related to tokens, it was never meant to be a general storage for meta-data, as that would unnecessarily bloat the database with meta-data, slowing down database queries. Also what happens when someone changes their meta-data, we now have to bloat the database even further to store that new meta-data, and we are now storing a bunch of OLD meta-data as well. The counterparty database IS NOT the place to store asset metadata, as the database should be as small/fast as possible and only contain information on transactions (there is a reason why the original founders didn’t create a meta-data file and instead came up with the point asset to JSON with enhanced info method)
Meta-data can very easily be cached on servers to make it instantly available without having to make slower external calls to get JSON files from their original hosts (many are missing content-allow-remote-origin headers, so the API calls to get JSON fail).
Here is a simple tool I wrote up last week to start caching all JSON locally on xchain. The general idea is to get the JSON data for an asset available immediately in a single API call without the need to make external calls to get the remote JSON.
As you can see, caching the JSON metadata in an external database and using that database to return JSON can be very fast, much faster than if the meta-data was stored in the CP database… The solution to asset meta-data is NOT to bloat the CP database to allow storing this information (there is a reason the founders didn’t do this, and instead came up with a way to point assets as JSON files to get more meta-data… had they wanted the meta-data stored inside CP, it would have been trivial to do so, but a poor design decision)
I do have a concern that the more complicated the JSON structure gets, the more difficult it will be to program around.
All the new fields are optional. You can continue to use the existing spec as you do now, so not sure what is more complicated other than figuring out “oh, I want to show a video, that should go in the video array”… or “I want to show an image, put the image in the image array”. The JSON files can contain as much or as little data as the user wants.
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.
umm… this is EXACTLY what the CIP25 spec is doing, standardizing the fields in JSON files so that all block explorers can treat the data the exact same.
It is also troubling to see “undefined” displayed over and over again.
- if your going to mention seeing something, mention WHERE your seeing it
- the only reason that we see “undefined” on xchain is because there is no standard JSON spec defined… CIP25 solves this issue… so, your complaining about something, while not understanding that this CIP standardizes the fields that can be used, which will in turn get rid of the “undefined” message on xchain after I get a chance to update to start using CIP25 spec.