Table of Contents:
Rough writeup of 10/5/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations.
Notes might contain errors or miss pieces - call out issues as needed
Editors meetings are public, recorded and summarized: do join and participate for discussions/PRs of significances to you.
- Triage/Review: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions..
- Last Check: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period)
- New CIPs Review: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)
PR -> ‘Draft’: Needs format + approval.
‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.
‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing. - Current Discussions: What the current CIPs discussions are on social media / forums / Discord.
- Close: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list.
Attending Editors: Matthias Benkort, Duncan Coutts, Sebastien Guillemot, Frederic Johnson. Community Editor Robert Phair.
PR136 - UPDATE / adding js impl. for CIP-0014
Frederic - This is a minor update to an existing CIP (CIP-0014 - "Asset fingerprinting") that provides a javascript implementation. Describing how to do asset fingerprinting in Js.
Matthias - Approved. Also good to move towards Active when feasible (but separate conversation).
Duncan - Where is this located?
M - NPM link through the NPM site.
Sebstien - Some background: We originally wrote this reference implementation between me (representing Yoroi) and Ishish (?) from CardanoScan. That is why Yoroi and CardanoScan implement this but most other wallets do not at this point.
D - OK
=> Merged PR136
PR132 - CORRECTION - adjusting CIP-0003 text
S - I think the two changes in this PR are independant: The first is a typo. The second change I have to double check, need to double check the work. It could be indeed correct and needs to be verified.
F - Tabling this, added to 'Triage' for next meeting, Sebastien or Matthias to look at this to confirm.
=> Tabled, to 'Triage' (if it gets correctness confirm) PR132
N/A
PR88 - "DApp Connector"
F - This was discussed at the last Editors meeting (#30). Discussion can be reviewed in the notes from last meeting. This is the 130+ comments conversation - there was an ask about who might be able to summarize the conversation and how we might be able to move this forward. Has there been some support from IO? Should we go over this PR more carefully right now?
M - Partly. Most of this CIP has been implemented by the NAMI wallet I think and the CC wallet is also working on it. As far as I am concerned, it might not be finished/perfect and there might be more changes to this CIP, but I also don't see any reason why we couldn't merge it in as a 'Draft' right now while not finalized. It is mainly about the pre-Alonzo era, and now that Alonzo is here and there are more things with the scripts, those updates will come. I don't feel we need to reach them before this gets merged. Rather I think we should have new conversations about such modifications (in new PRs).
F - Agree - I think this is a good example of the (Process) conversation we have had previously regarding statuses of CIPs (and here a good use of the 'Draft' Status). PArticularly with the background of a DApp connector concept that would benefit the greater ecosystem when out.
D - Who is currently implementing this?
M - At least NANI and CC wallets - so the two lightwallets out there. There is also plan within IO such as with the wallet announced at the summit to also integrate with that CIP and make it sort of ecosystem out of that.
D - Do those two groups broadly agree with eachothers?
M - On things that have already been implemented in this CIP, Yes. The discussions ongoing really are about addition of new features or elements, such as event APIs, or to react to a changing network or to a disconnected wallet. Maybe therefore the structure of the CIP could be split a bit and have a core part as the API and extensions that could be supported by this event API, the Alonzo Update... A bit like we did for CIP-1854 with one common foundation and extensions on top, which can be discussed independantly.
D - If the people who have the current implementations of this agree on it, then it would be fair to set it as a 'Draft' standard.
M - Maybe we can bring it to the spotlight again, and if people are happy with the current state, then merge and have the conversation on the event API on a separate PR.
D - Yes, drawing a line would help. Let's add some comments to that effect in this PR.
M - On it, need to ping the right parties involved, will look into the varied Github handles. I will draft a comment - just gathering the github handles.
S - I think it's fine.
=> Moved to 'Last Check' PR88
PR116 - "Royalty Standard"
F - This tentative CIP looks at establishing a standard for Royalties. This is also an active conversation, and can also be flagged early as an item for the next meeting.
D - I am unclear as to wether this is a ledger change or if that is built on top of the existing one and is built as a convention.
S - Convention - Just using Transaction metadata to let people know that "if you are operating an NFT marketplace, please reserve some of this sale to the author of the NFT"
D - so purely Opt-In? I see.
S - I think the CIP is fine as-is. There was one comment where I mention that the address is saved and reserved but they could decide to use binary address to save space (in the metadata itself). They were not sure wether or not to do this and haven't responded either way. There is another issue where the percentage field is a decimal value so 0.2 is 20% and I am not sure wether or not 0.2 should be 0.2%. They are suggesting renaming it.
D - Probably should not be called percent
S - Suggestion is to rename to make it clear. These are the two issues I see in here. Neither of those have been addressed yet. My understanding is that people have already implemented this. Unless they modify the CIP or respond to the comments soon, we should just merge it because it is already implemented and if they want to change things they can add to the backwards-compatibility. By the same logic we could just merge now and if they want to change the points brought up, can be done post-merge.
=> Moved to 'Last Check' PR116
PR117 - "CIP-0029 | Monetary Scripts Serialization format"
M - This is intent to put in the same place the CBOR serialization format that is used by Scripts. Phase 1 scripts are the ones that were introduced in the Shelley Era and later extended in Allegra. The binary format is already kinda fixed and documented in the ledger spec repository in a CDDL but there was no documentation of the JSON format. The idea was to document that, but also to make a recap of the rest, and locate in a singular place the CDDL for the binary format. There was an ongoing discussion with Duncan on one of the naming conventions.. I replied to the comment in there: there are visibly two different conventions used between the Cardano API and the ledger specs. I stick with the Cardano API as the most user-facing and what people will likely see, and also used for the JSON format. So i changed (retroactively) the CDDL. It really depends on how you look at the script - Either invalid or valid after (Semantically equivalent)
D - I would suggest getting the CDDL changes upstream.
M - Yeah, also, in the repo.. I did double-check the sourcecode and compared... It is a bit confusing in the end.
S - We want to implement this. We have an implementation already, it just isn't public. We'd like to know if this might be the final piece before we push anything.
M - The thing is this is one of those PRs that is specifying something that already exists. In retrospect. Something that could have been a CIP first, but now requires synchronization / a coordination spot for the varied implementations out there. It doesn't really change things, it's really a matter of putting on paper what is. It might be the Cardano API has also changed on those regards - I don't think so but maybe it has. Something we could do before merging if we want to move forward. Or actually merge it and do the changes in the Cardano API and bring it back to what they were.. I wrote that PR some months ago, I don't know if the Cardano API has changed in the meantime, I have seen a lot of work being done on the JSON format recently but I think it was mostly on the other parts (UTXOS..)
D - I don't think it touched the scripts at all.
M - It would be good to control if this is still the same.
D - Ask Jordan to Review to make sure it is accurate - I am not aware of any changes in the JSON format. The other stuff cannot change because it is onchain (CBOR, hashing, ..)
M - If this is fine for everyone I would prefer to move this to 'Last-Check' for next meeting, if it is still capturing the current state of things (will check with Jordan)
D - Fine with it.
=> Moved to 'Last Check' PR117
M - Actually dependant on PR112. If PR112 (tentative CIP 26) doesn't make it there isn't much ground for PR118 (tentative CIP 28)..
M - This was touched to in some previous discussion CIP 26 is for finding a way to have offchain metadata that can be verifiable and can have some form of ownership attached to them and still be midly decentralized or not fully centralized. The idea is to have metadata that contains information themselves that makes them verifiable provided the user has some knowledge of some existing keys. Metadata in this context is just an object, which maps fields to values and all values are signed independantly with a set of signature by a set of public keys. The keys by themselves have no particular meaning. So there is a need for another mechanism to identify the owner of the metadata with those keys. This could be an offband communication mechanism (ex: advertizing your keys through your twitter or other, just as ppl do for GPG keys). There are also other mechanisms proposed such as CIP 28 which explains how to link keys and owners: through an onchain publishing which can then be discovered automatically. CIP 26 doesn't go that far, it stops at having metadata assigned by keys (where the keys come from is off-topic). It therefore decribes the structure and signing process: how to generate the signatures, hashes and how to verify. Also to give recommendations on how clients could be consuming this data and how servers could also be implementing this offchain. The idea is not to have one central server but rather multiple registries that could be maintained by the community to share all that metadata. One server does not actually provide any authority on the metadata, they are simply access points for the registries, which can then be replicated on any of the other registries in some way. So arguably more decentralized so. It is derived from an original abandoned CIP draft that was written by Michael and Polina some time ago. We made quite a lot of edits along the way as we actually started to implement that and that is the final version that we feel is currently quite complete and also implemented in the Cardano Foundation Registry at the moment.
D - This is currently accurate with respect to the current Cardano Token Registry?
M - Yes, and it covers both the phase 1 monetary script approach that we used before, where the keys used for verification were actually the keys from the policy, which isn't the case for plutus scripts as you don't have the same. For the Plutus scripts, the association between the scripts and the keys needs to happen via some other mechanisms. This CIP puts out some ideas of how that might be achieved, while PR118 / tentative CIP 28 shows a concrete approach of one such usecase. (Publishing onchain this mapping as part of the minting transaction, which is really just for mentary policy scripts, it doesn't cover a wide variety of Plutus scripts, rather just for the ones that would be minting policies..). I also asked Michael and Polina to have a look at that some time ago: they were happy with the results but only commented on Slack. I will ask them to weigh in directly on the repo to have a record of that.
D - Sounds good. How long has it been hanging around for / have others had a chance to comment much?
M - A bit - it was advertised on some platforms. We also discussed it in the Summit actually, with people asking about that and how we would do Plutus metadata. General reactions and comments were mostly emojis.
D - "so non-controversial"
M - More hearts, therefore positive.
D - Let's get more technical architects to comment on this.
=> Requesting public reviews from MPJ/Polina - moving PR112 to 'Review'
F - There have been discussions about possibly bringing in 'CRC' (Cardano Requests for Comments) as a category, do you feel this would be worth discussing, do you feel strongly about this? It was previously lightly discussed at the beginning of the CIP Process and at the time dismissed as non-urgent & non-necessary (as CIP as Standard is more or less what people mean by 'CRC'). Ethereum has that system of improvement proposals and request for comments - the most famous being the ERC-20 standard. This is an aspect of the general Cardano Ecosystem that we have put off as non-essential. We have standards, but nothing yet specified as "Cardano REquest for Comments.
S - This came up many times in the past and confuses folks. Especially now that we have Plutus, people want to standardize their Plutus Smart contracts. This is a possible excuse for this. This is was folks do with Ethereum and ERCs, they standardize smart contracts interfaces.
D - How is that different from a CIP?
S - Basically there is no real difference, it's just a different track.
M - I think it makes sense.
D - What makes it require a different track, what qualitatively makes it 'needed' rather than having even more new tracks for things like wallets, or ... (Just want to elaborate). WHy should we treat it differently?
S - The main benefit would be that if you are a Plutus developer you have a specific track to look at, and so when we are reviewing a CIP, you know that you can focus on that area. I think that is the main reason, because the expertise to look at it is different.
M - It's not that we have been using tracks differently, we don't have a separate process for them. To me they are more like tags or categories. It makes sense for filtering and it makes sense to have another category for this one if we anticipate it to be the home of many future CIPs. I think that in itself justifies the creation of a new track.
D - But if in practice all that is reflected in / has a different tag and one entry in the metadata and the PR it has a tag on github so you can filter..?
M - In that sense then we could have one singular track and have varied tags as tracks.
D - I understand it as a Tag. Searching by what's in flight, is good through Github Tags - I think I am agreeing with you that it's good to have in multiple places.
F - There will be other meetings to discuss bringing it on this platform, This was lightly touched so people are aware the consideration is taking place, and likely added to next meeting's agenda.
(PR136 merged)
PR132 to 'Triage' (correctness to be reviewed and merged next meeting if adequate)
=> "Last Check" - PR88 - “DApp Connector” - potential 'CIP-0030’ - reasoning is that it is better to have it merged as 'Draft', and have newer conversations from there rather than rtying to summarize from here
=> "Last Check" - PR116 - “Royalty Standard” - potential 'CIP-0027’ - There are format issues to be addressed in the PR
=> "Last Check" - PR117 - “Phase-1 Monetary Scripts Serialization”
=> "Review" - PR112 - “Cardano Off-Chain Metadata” - potential 'CIP-0026’ - to be discussed with Polina and Michael.
💡 - For more details about Statuses, refer to CIP1.
"Alice has a Cardano idea she'd like to build more formally":
