A further consideration could be to directly reference a tx hash. I’ll amend the spec to include this 
1 Like
Hosting images and large data via url, ipfs, arweave, etc is cheap but meta data and on-chain storage is not as well as being intentionally limited for performance and sustainability. For most NFT the generator for the accessories, tags, data, etc is run off-chain and it is simpler to pin the combined results and reference them.
That said meta data can literally be anything you want and while standards are nice for setting community guidelines and application expectations for universal types they should aim to be as concise as possible and solve a problem that improves or supersedes previous solutions. We already have ways of referencing hashes or previous transaction or “pointing to pointers” as you mentioned.
Ultimately you have to ask the question “How is this better?” in as many ways as possible:
- Is it more flexible or more generic than existing standards for NFT meta data?
- Does this reduce the amount of meta data needed?
- Could type be implicitly inferred from value?
- Compatibility with existing tokens?
- More compact than CBOR?
- and so on …
For each “yes” there should be a compelling reason to describe in the CIP. For each “no” there should be an alternative solution, change to the proposal, or a compelling reason why. When you can answer “yes” to the majority of questions you or anyone else can think of then you should then have a CIP worth merging and implementing at large that is self explanatory!
1 Like
Thanks for taking the time to respond.
I believe I can answer most those questions:
- More flexible, yes. Because we give the user multiple ways to reference other transactions or onchain data.
- In certain usecase it can. For example if data is repeated it can be stored in one txhash and referenced with a few bytes explained in a comment above
- Yes it could, but I think using the shorthand ‘p’:<policy_id> is cleaner and is a mere 4-5 bytes extra (‘p’:,). As for mime type such as test/plain that could be done by the client but providing a standard helps avoid confusion.
- Backwards compatible due to the version 2.0 tag this just expands upon EIP721 (which is explain in cip25)
- This could be argued. The choice to use json is as such because it’s popular for web dev. Using some other format could save a few bytes here and there but at the cost of usability (json parsing is easy and commonplace on the web).
The standard could also easily be updated in the future by simply altering the version tag.
Most functionally can be explained by glancing at the specification section I tried to ensure all options have clear definitions and examples.
1 Like
One place I believe this CIP would be super useful is game based nfts and distributions.
-
As a game developer I want to distribute my game on an opensource platform that respects the consumer
– create payload transactions with the legal information of the game and terms of usage… this could require over 16kb of data
– for every new sale mint a nft that references the legal info and the games title metadata
– now due to references that main payload isn’t duplicated unnecessarily -
As a game developer I want to put assets on the blockchain
– Create a payload transactions with external links to the asset (probably ipfs)
– Mint the asset pointing to the correct references. With the proposed CIP it would be easy to plug in unique variables at a small byte cost to Cardano.
– now we can mint fully unique game assets on Cardano thanks to the ordering feature of references that allow variables to be placed at defined spaces or in a set order.
2 Likes
I’ve recently altered this to be two CIP’s.
- A CIP to handle modular expansion of NFT’s on Cardano
- A CIP to handle on chain data within a policy (or external policy)