CIP-0001 | Small suggestions for multi node world

[Ryun1]

• some small comments and suggestions to better suit the CIP process for a multi-node world

[rphair]

thanks @Ryun1 — I believe these are consistent with what we've been asking for from "core" CIP authors this year.

Generally it seems reasonable to me but I would hope first for the opinion of some others from the "node diversity" working groups: to see if any more (or less) detail would help CIP contributors (just tagging a best-guess list of these who are also CIP stakeholders).

cc @Crypto2099 @WhatisRT @abailly @yHSJ @jpraynaud @coot @KtorZ @michele-nuzzi @Quantumplation @ch1bo

[rphair]

@Ryun1 p.s. to #1070 (review): @fallen-icarus had (in PM) some questions about how this applies to the mandated consistency between nodes & enquired about the next meeting (where this is now marked for Triage): https://hackmd.io/@cip-editors/117

[rphair]

@Ryun1, my attempt to summarise the resolutions from yesterday's CIP meeting:

• As @Crypto2099 pointed out, this includes a subjective assumption of what an "important" node is to put on the implementation checklist (e.g. what's a minimum node "market share" / implementation status to be included on this list... and is that consideration really consistent with the principles of the multi-node environment?);
• It seems to convey an impression that CIP implementations — if tick-boxes are created for them like this — might be cherry-pickable by "alternative" node development teams & therefore another source of divergence between CIP feature support across a multi-node environment.

So this is technically Unconfirmed pending a rethink & rewrite of how we can do this without conveying inappropriate impressions to CIP authors and/or node development teams.

However the establishment of the 4 "Core" categories that you have enumerated has stood up unanimously in expert review at the meeting... so at least these can be addressed that way & in any case CIP-0001 can be updated with these official "core" classifications as already included in the PR.

[ch1bo]

I'd prefer if we state what we care about (implementation available to most of the stake pools) over enshrining specific project names.

Also, a bit biased as an ambassador of the cardano-blueprint, I'd love to see "implementation-independent documentation" and "conformance tests" as a template acceptance criteria. For example, like I wrote in the Leios CIP

[ch1bo]

How about Implementation in block producers used by 80%+ of stake?

[yHSJ]

I agree that we don't want to enshrine specific projects into CIPs. I like the Leios CIP you drafted where you require that changes are represented in the conformance tests. Ideally, we'd then write a standard that maintains a version of those conformance tests which corresponds to a ledger version.

In order to be a Cardano node, you have to pass those tests.