CIP-0098? | Distributed Artifact Token Metadata

[wout]

In the past one and a half years, I've released three on-chain generative token collections on Cardano, and I developed this standard out of necessity.

Introductory information is available here:
https://docs.venster.art/dats.html

And a slightly more detailed version of this CIP is available here:
https://docs.venster.art/dat-metadata-standard.html

The content of the CIP on our documentation page is the same as in this PR but with a bit more inline information.

---

Rendered Proposal in Branch

[Ryun1]

Hey @wout, thanks for this interesting proposal!

Please see below the small editorial type comments mainly about the structure of the proposal. And can you rename the directory from CIP-0098 to something like CIP-XXXX or CIP-????.

I do have one larger question:

• How would this proposal be versioned? since you mention this could be extended over time.

[wout]

Thanks for going through it, and sorry for the many individual commits. 😊️

How would this proposal be versioned? since you mention this could be extended over time.

I hoped to discuss this here because I'm unsure how to approach it. Argument directives are a part of the CIP that should be open for additions. If someone comes up with something useful, we should be able to add it.

One idea I had was to use two-part versioning (e.g. MAJOR.MINOR) where MINOR could serve for argument directives. Next year I also want to start looking into how we can extend the DAT metadata standard to CIP-0068. The MAJOR part of the version would be useful there.

The other idea was to extract argument directives from the standard and maintain the list somewhere else. The content of the directives is not important to the standard, only their function is. But this approach would create fragmentation, which I don't like.

So, I'd like to redirect the question back here.

EDIT:
Argument directives are somewhat similar to external dependencies. This standard defines how to structure them, but the actual content is maintained elsewhere.

[rphair]

@wout FYI we are introducing this proposal at the CIP editors' meeting today (4PM UTC). I've seen you on Discord there; let me know if any other advocates of this proposal might be there & we can send them a Discord invite.

My preliminary review is:

• it seems to solve the problem that this deprecated proposal (CIP-0048? | NFT metadata references and payloads #249 (comment)) was trying to solve, without the features that led to its deprecation. Therefore it could be instructive to readers to mention in the Rationale why this earlier considered alternative (adding an "external metadata" tag to existing metadata structures) was unpopular.
• That proposal was deprecated in favour of the draft CIP-0088 (CIP-0088? | Token Policy Registration #467 (comment)), so could that other CIP approach be compared in the Rationale here as well?

You're not obligated to produce a CPS-like review of the whole problem, but to encourage people to adopt this as a standard it would be proactive to position it favourably compared to other potential solutions.

[rphair]

@wout I'm about to assign a number to this although the discussion at the meeting today was looking for more confirmation that this is used outside your own organisation.

Until that's established we have to remove the word Standard from the title at least... the feeling so far is that is a good proposal whose documentation can stand on its own in any case & could be merged as such if there's no counter-posting about why this wouldn't work.

Other editors were also interested in seeing a comparative explanation of your approach as requested in #530 (review).

[rphair]

p.s. update to title requested in https://github.com/venster-io/CIPs/pull/1.
(edit) p.p.s. this will also update the CIP number to the now officially assigned 98.

[rphair]

@wout I'm marking this Waiting for Author with no response to #530 (comment) after 5 weeks.

This PR came up in a review out outstanding proposals at the CIP Editors' meeting today and we noted some potential difficulties in passing review resulting from both these conditions:

• The proposal reflects particular design decisions & preferences which might not also be acceptable to a broader range of implementations.
• The implementation based on what you've posted as a CIP seems already to be in progress and therefore might not be possible to broaden after the fact.

Please respond about this reservation & what you might be prepared to do about it. We still don't have all editors expressing opinions about this, but it might not be possible to approve this CIP if it's only documenting a single implementation. If we don't have an answer with the usual review time frame we might have to eventually deprecate or close this.

[wout]

@rphair Sorry for the delayed reply. I'm going through some personal stuff and don't have the headspace for it at the moment.

[rphair]

Thanks for the update @wout ... feel free to open this again if & when you want to pursue the proposal further.