CIP10 - Transaction Metadata label registry

[SebastienGllmt]

This is another one of those cases where I'm pre-emptively reserving the CIP number 10 for this because we need to get this merged regardless and other standards already being written depend on this standard, so it's easier if people can just start referring to CIP10 now.

Abstract

Cardano transaction metadata forces metadata entries to namespace their content using an unsigned integer key. This specification is a registry of which use cases has allocated which number to avoid collisions.

[rcmorano]

What about something more dynamic that allows any type of metadata without the need of static reservations?

@Crypto2099 and I were discussing the other day a solution like having a json-schema registered on-chain (many will prolly need to be split in different indexes because of size) and then using index 0 to store the hash where the schema to validate metadata is stored.
This way "blockchain listeners" would only need to seek for transactions whose index 0 is an specific txhash (specific json-schema).

[SebastienGllmt]

@rcmorano any dynamic system like you're proposing would have to be built on top of a static registry. In your message, you suggest using "0" as a magic number, this is the same thing as reserving some static number and saying that everybody who uses that static number is doing it to post the hash of where the schema is located

If you want to propose a system where the schema is stored on-chain, probably the best way to do it is to

1. Approve of this CIP
2. Propose a new CIP that allocates a number from CIP10 and says that anybody using that number is following a new CIP you're proposing

[Crypto2099]

I don't think the two are necessarily mutually exclusive and we could hypothetically use this "register" suggested in this CIP to reserve a certain amount of index slots specifically for the purpose of storing Metadata Schema on-chain. I think of the suggestion to store the schema on-chain as helping aid in the immutability of data in the long term since any off-chain solution may be subject to change or modification over time. We would then hypothetically need a couple of different reservations to support this concept:

[Example Reserved Index]
[123]: Indexed reserved for metadata schema definition, should have the value of a block hash containing the schema definition
[123001-123099]: Indexes reserved for submitting metadata schemas to be stored on chain, reserving a hefty block of slots for large-scale schemas that require multiple metadata entries to define.