CIP-0001 | Add extended taxonomy

[NetWalker108]

This update revises certain aspects of the current CIP-0001 document(Version 2). Changes and additions include:

• The extension of the Header Preamble and framework for grouping CIPs via the introduction of a distinct taxonomy system.

• The introduction of a new Living status to better identify certain proposals such as this one (CIP-0001) as living documents.

• The reintroduction of Type as a grouping and the addition of new groupings such as Classes, CRCs, and other subcategories to better signal and organise proposals according to their precise scope of focus in the Cardano project.

• The introduction of Cardano Request for Comments(CRC for short) as a standard provision to better allocate and compartmentalise application-level proposals, improvements, and standardisation such as smart contract design conventions (for langs such as Plutus-TX, Aiken, Plu-TS, etc.), Metadata standards, NFT token standards, Fungible Token standards, etc.

Note: The appropriate changes have also been made to the document schema for writing a CIP and CPS, in accordance with Version 3.

This revision takes a lot of inspiration from Ethereum's EIP system(as it is one the most vibrants systems of its kind).

The goal is to receive input on these modifications and successfully merge them to advance the CIP standards and the broader application-level (as well as core) standards of Cardano.

View rendered version

[KtorZ]

@NetWalker108 hello, I am unsure what problem of the current process the introduction of a taxonomy comes to solve? In the PR description, you say: "organise proposals according to their precise scope of focus in the Cardano project" yet I don't see how the re-introduction of Types really helps?

We ditched types in the last revision of the process and introduced categories instead as there was a general consensus that filtering by topic was more useful than filtering by nature. CIPs types were also quite unclear and often ambiguous for many CIPs sitting in-between two types.

Here, you're suggesting to not only introduce types, but also classes which I am afraid will lead to even more confusion. Besides, one of the core changes in the latest CIP-0001's revision was to make project explicitly enlist to the CIP process for areas that are maintained by a single entity. That is the case for anything that would go in the "core" class as proposed in this PR and it seems to me that introducing a "core" class will again lead people to believe that any parts of the core stack is open to CIP -- which isn't true.

Finally, I am not sure to get the rationale behind the "Cardano Request for Comments" category given that, all CIPs are request for comments. The CIP process is primarily a mechanism to propose idea and capture feedback. So it seems redundant to have it as category, especially because it doesn't provide any useful categorization for filtering.

All-in-all, I am not convinced about this change proposal 🤔; it seems to come a bit out of the blue and I do not understand the rationale (i.e. what problem does this solve?) behind the changes.

[rphair]

@NetWalker108 upon trying to read the changes to CIP-0001 I felt exactly as @KtorZ says above - that the extra vocabulary doesn't allow us to do anything we aren't already doing. Everything else I also agree with (e.g. throwing out "types") based on experience with previous iterations of the CIP process.

My short reaction is that I also don't see any reason why we should do this. But if this idea is to stay on the boards for general consideration then would you please refactor your changes to CIP-0001/README.md so it has the same white space and formatting as the original? Reviewers will need to see a usable "diff" and right now we don't have that.

[NetWalker108]

Hi @KtorZ

I am unsure what problem of the current process the introduction of a taxonomy comes to solve?

I explain this in the Prelude section found in the Rationale.

We ditched types in the last revision of the process and introduced categories instead as there was a general consensus that filtering by topic was more useful than filtering by nature.

I make note of this concern of confusion and elaborate on how this proposed revision solves for the many shortcomings(or lacking elements) that were in the earlier versions(v1 specifically).

CIPs types were also quite unclear and often ambiguous for many CIPs sitting in-between two types.
you're suggesting to not only introduce types, but also classes which I am afraid will lead to even more confusion.

This proposed revision solves such confusions and significantly mitigates(if not completely eliminates) all forms of ambiguity with a dedicated taxonomy intended to cater for various proposals per their specific focuses.

it seems to me that introducing a "core" class will again lead people to believe that any parts of the core stack is open to CIP -- which isn't true.

Currently, most(if not all) work on Core components such as the Consensus stack of the Cardano protocol are reserved to IOG and thus receive no improvement proposals from the outside world(although the CIP process is gradually changing this norm).

However, with the imminent arrival of changes such as the Voltaire era and the potential alternative implementations of the cardano-node, as well as the goal to make the Cardano project more of a truly open source project by the CF and IOG teams, it is imperative that the CIP process be evolved to accommodate such a future.

This proposed revision primes the CIP process to be adequately and appropriately compatible with the post-Voltaire era of contributions. We prepare for tomorrow, today.

Finally, I am not sure to get the rationale behind the "Cardano Request for Comments" category given that, all CIPs are request for comments.

Yes, in practise all CIPs are akin to Request for Comments(as seen in other industries). What the categorisation of "Cardano Request for Comments" does is introduce an artificial abstraction of proposals as a rank for application-level specific proposals.

This abstraction is intended to suggest a clear separation of proposals from the scope of core_protocol changes and assert a sense of flexibility in how these proposals can be adopted so they may not be misunderstood/received as strict rules that are meant to be followed by all application-level developers.

Case in point:

• the reception of CIP-68 and how many in the community(users and developers alike) assumed it to be an overarching design ruleset for the NFTs on the Cardano protocol.
• the lack of an appropriate distinction between fungible native assets(eg. DeFi tokens) and non-fungible native assets(eg. avatars and other collectibles), at a high-level.

There's good reason why ERCs exist in Ethereum and their use in practise further solidifies the need to adopt similar standards and practises in Cardano.

Must be noted: Per this proposed revision and context of the CIP process, all CRCs are CIPs but not all CIPs should be identified as CRCs.

All-in-all, it is my hope that this explanation does justice at answering your questions, in addition to detailed documentation provided in the proposed revision itself.

Cc: @rphair

[rphair]

@NetWalker108 I still don't believe the "confusion" that this CIP purports to address has actually been presented by the community. I can assure you it has not been presented by the editors and in fact as @KtorZ already pointed out we have dropped some of the typing which turned out to be not useful in practice... especially when compared to the Category added in #366 which establishes practical responsibility for acceptance and implementation.

Still I might be in favour of this if it were presented on the basis of a community need. Individual notions of "the way things should be" can often be accommodated if they come from more than one unrelated source... which we don't yet have in this case.

You can compare a somewhat related situation when some people were asking for more explicit CIP abbreviations which were based on typing as well as versioning... we didn't honour these requests but they remained open for debate for a while, and our reasons for not honouring them were publicly given and can still be challenged at any time:

• (new) CIP-0001 & CIP-9999: Cardano Problem Statements #366 (comment)
• CIP-0030 | Upgrade to latest format & propose version / extension scheme #446 (review)

[rphair]

@NetWalker108 since we don't have an identified need for this taxonomy, can you either rebase this proposal on a current version of CIP-0001 or close this PR? Without at least an update relative to the current document & the evolving process it represents, we would have to close this if it remains inactive and incompatible.