Table of Contents:
- Summary
- Editors Meeting Flow
- November 23 2021 notes
- Extra
Rough writeup of 11/23/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, Robert Phair.
PR147 - adding metadata labels (to CIP-0010)
Frederic - It seems we gathered all the green ticks (approvals) for this to be merged
Matthias - This raised an internal consideration here - should we be requiring more information from people adding labels to this? Because a lot of those are modifying this registry, but giving no actual justification or rationale for it. While at the moment there is no abuse, everyone appears to have an actual project behind the request, but should we start thinking of something a bit more standardized, asking what the project, background or reasoning, including some way of verifying they are indeed related to a particular project and so on.
F - I think this is an issue we have with the Cardano Foundation's Token Registry, where there is leniency but likely a need for enhanced verification. A Registree registring with a Registror (in this case the CIP repo) has an expectation that there is some criteria of acceptance/validation that was passed: a modicum of validation?
M - Yes. Not asking for a KYC or extended thing - but maybe ask the Author to provide some background behind that specific label and why it is being added, to filter out a bit.... So far no abuse so not a big deal
F - Defining a threshold of Validation: Checking that the site exists or something like that?
M - Yes, that's what I did for CardanoHub, Looked around, checked the Github and the user account seems legit. A weak verification still?
F - As long as it gathers the approval of 3 editors this should be fine: we serve as the filtering mechanism. Hopefully flags get raised for dubious projects.
M - OK
=> Merge NOW PR147
[PR152 - moving CIP 7 to 'Proposed']
F - This was proposed by Shawn as a CIP and he has pushed to move it to 'Proposed'. This prompted a concurrent conversation, the need for a "Path to Proposed" to be added in CIP 1. I would be inclined to merge this one as-is. We've had a conversation with Shawn and he agreed that a way towards active would be to have IOHK or whatever implemented have this, still in the current setup it would formally be better if there was a defined section in there as "Path to Active".
M - I agree. It might also be a good time to do a second round of calls within IOG asking people to look again at this CIP and maybe give a clear answer on wether or not this will be implemented. It's fine to merge. That's part of the conversations we had a few meetings ago. I do think any CIP merged in the repository should have a status 'Proposed' (rather than 'Draft') as that's close to what the merge is conveying in a way, as "accepted by the editors". Maybe not in a final state. But it should have a "Path to Active" that clearly describes how that CIP would be considered active. There might be some exceptions such as CIP 30, where there are still points under discussion in new PRs, which would still have it be a 'Draft', because there are additions and people know they still want to make modifications. Short story: I agree to move this one to 'Proposed'.
=> Merge NOW PR152
PR112 - "Cardano Offchain Metadata"
F - Needs one more review for this to be merged.
M - Duncan has approved, we set it up to two mandatory so we could go ahead as I am the author.
=> Merge NOW PR112
PR137 - "On-Chain Token Metadata Standard"
M - This is a follow on from the prior meetings discussions, by Matt Ho from SundaeSwap.
F - Seems we're all new to this.
Sebastien - I think it's fairly straightforward, it's just the registry but onchain instead. The core concept is nothing difficult.
M - It's more almost a philosophical concept at this point: "Should you put metadata onchain or not?" We discussed it previously, the pros is that it's readily accessible if you're monitoring the chain, and the dev experience is a bit easier. The cons is that you make the whole blockchain bigger for storing data that in the end has no reason to be there (The blockchain making for a very poor database) So instead of storing the metadata onchain, it might be considered better to push a hash of the metadata onchain to precisely avoid putting metadata onchain. At the same time we don't prevent people from doing it - and if they really want to do that - at least it's good that they have comments turned off for doing it. It's also very similar to that other proposal for NFT - CIP-0025. And this one looks like an interation on top of that one, which makes it slightly more generic, to expand beyond NFTs, for broader metadata and at the same time still covering things like names, image, url... etc.
S - This is also similar to the pool, which also had. This CIP tries to referate a website for authentication, making an effort to tie the metadata to the person that authored it.
F - Regarding the Structure of this CIP, do you see anything wrong - should we push it out to next meeting to review?
M - One thing that is actually missing is the rationale, which is esssential. Why is this a good idea and why would you do that? I can understand it and imagine, but maybe I would like to have a rebuttal for the cons (why it's ok to put all this data onchain.. etc)
F - The motivation can serve as rationale if you look at it that way, It's similar.
M - Similar but not the same thing. Motivation is why you write the CIP and the rationale is why the way that it is solved is ok (and why the decisions make sense in here). It could also be worth discussing CIP-0025 since they come ater, should it be reconciliated as one, coexist..?
F - CIP-0025 is the NFT Standard they weren't aligned with a few meetings ago.
M - And we've more or less already had that discussion about the on-chain or not conversation. If we take back the last comments from the CIP-0025 we can see all the suggestions we made at that time that are still likely applicable for this new PR. We had quite a few remarks on how to structure things, WHy putting things onchain was good or bad, and some suggestions such as "as for the schema" maybe use something more standard like a json schema (as could be found on schema.org) and how this references many things as schema, such as if you were an organization, here are all the fields and or references or semantics, types... Everything we said in there still applies to this one as well. If this is going to become a thing to have metadata onchain, let's try to have a very general approach and say "you have to pick one of the schemas that is in there" and have clear rules on what should and shouldn't be onchain. At the same time, you can also just hash it, put the hash onchain and a URL to that Hash and that's it... Then you avoid having to store onchain all of that data and you can still have the benefits. More complicated to update it, but that was the same problem with stakepool metadata. That was the spirit.Maybe someone else can comment.
F - I see your point about not trying to store things on the chain but I feel it might be fine to have those as concurrent (yet opposed) CIPs and have that conversation on wether to merge or distinguish them at a later time: Enable people to see that there are different options and maybe speak up about that discussion.
S - Personally I am in favor of making it easier of using Cardano as a Data Dump, and not have to jump through hoops to dump data on Cardano. And therefore am in favor of this CIP. I would prefer if we had an easier way to do this rather than Tx metadata, but it's what we have.
M - For this PR, I'll comment in there asking for a clear rationale, I don't mind per say if this is merged, just "slightly" opposed. If folks are going to dump data on the blockchain let's make it in an organized way. Still I want a clear note that people have acknowledged the problems (and it mentionned in this CIP) that this is maybe not the best way to approach it and have it compered or noted that it differentiates itself from CIP-0025 and that we also will likely need to have this as a separate json schema that can be referenced and used.
S - Makes sense.
F - Moving this to Last Check and should be merged next meeting hopefully.
=> To 'Last Check' PR137
PR148 - CIP-30 signData API
F - This is the continuation of CIP-0030 focusing on the specific section around the signData API, to help focus the comments without having to regress through the 100+ ones on the prior PR. Is this ready for review?
S - This is kind of a tough one, there are many ways we could go about this. It depends on what people/authors prefer. It kindof runs into some issues with the rust lib as well. Created an issue to address this on the rust side as well. I would not merge this yet, and get people who are using the message signing spec and give feedback on the library and the implememtation and what they think should be changed.
F - Looks like there has been an extended convo between Rob and Alex. If someone can step in the conversation to give perspective otherwise it will be part of the notes for this meeting and will be tableed towards a review next meeting.
=> To 'Review' PR148
PR150 - CIP-0019 readability update
M - I had a small discussion with Heinrich and he said he would make a few updates on CIP-0019 to clarify the distinction that exists between human-readable addresses and the binary representations of addresses that are one and one thing but two different views of the same thing which wasn't clear from a potential newcomer perspective. ALl those are actually encoding of a binary representation that is simply described by this CIP. He moved one section, the user-facing encoding and clarified a bit that addresses can be encoded by bech32 or base58 depending if they are Shelley or Byron addresses , and that this represents a binary format behind the scene that is described by this CIP. I reviewed the changes and it's good to go for me.
S - I'm okay with it too.
=> Merged NOW PR150
PR130 - Updates to CIP 13
F - Robert who has been vocal about this has raised some considerations in this PR regarding the approach. He was pushing a URI framework CIP, unclear if he has pushed it yet, but the conversation has kept going regarding why we need Deadalus-specific approach.
M - I think this draft is pretty old now, so we shouldn't spend too much time on this one and I know the team (including myself) are working on a new version for this one that isn't Deadalus-specific that basically extends the URL scheme with some new capabilities which would allow services like Deadalus to work with the PAB and for example partially pass Txs with payloads accross services to another services. I know the update is for "soon" so at this stage, this PR can probably be disregarded until that happens.
F - This is two months old, and isn't a CIP by itself, just an update to CIP 13?
M - Yes, but it adds a completely new capability to the link format. Still two months not that old but still old. It's being worked on weekly if not daily, and the team is also working on making it sure and usable within Daedalus. Maybe I can ask Nicolas to comment on the latest update on this one? But this PR is more or less outdated in that respect. I don't know if they will try a new PR or update this one but it will be significantly different.
=> Likely deprecated in its current form
PR140 - Alonzo Protocol Parameters
F - CIP 9 was specifically the Shelley Protocol Parameters and that was the conversation of changing this to "Shelley Protocol Parameters" and effectively have a separate CIP for "Alonzo Protocol Parameters".
M - Name it won't work and it might be worth it as having it as CIP32 (or 28).
F - Might be worthwhile to reference it in CIP-0009.
M - Definately cross-reference them.
F - I think specifically we should make a separate CIP for the protocol parameters for the NetworkIds? We don't have that yet for the specific deployment places for Cardano, it would be good to have that kind of registry available.
M - a few minor edits to do - change folder, add number, rename as readme... could just push changes on top really (Kevin has given go ahead).
=> Moved to 'Last Check' for next meeting (pending Edits)
F - CIP-0010
M - Should be moved to Active, the registry speaks for itself.
S - Fine to move to 'Active'
F - CIP-0011
S - Fine to move to 'Active'
M - Definately, being used by most of the tools.
F - CIP-0012
S - I think this was added by blockfrost and I believe Emurgo also added this
F - can setup as a Triage item for next meeting
=> Moved to 'Triage' for next meeting
F - CIP-0013 - 'Active'?
M - I would say yes, because some of those links are used I've seem that being used in Yoroi as well for sure
F - when we were discussed the Proposed status, it might be worth setting it as 'Proposed' with a "path to Active" of (a few services implementing the proposal)
M - Agree, we are doing that post-fact really
=> Tabling for now, to triage or 'Last Check' for next meeting
S - Active is fine, depends on what the Daedalus team thinks.
=> Minor Merges (such as PR147, PR150 )
=> Merged as CIP-0026 (Draft) - PR112 / CIP 26 - "Cardano Offchain Metadata"
=> PR137 - tentative CIP 31 - "On-Chain Token Metadata Standard" to 'Last Check' (should be merged in two weeks pending it receives appropriate approvals and structure reworked)
=> PR148 / Update to CIP 30 (signData API) to 'Review' (will be discussed more intently next meeting)
=> PR140 - tentative CIP 28 - Alonzo Protocol Parameters to 'Last Check' (should be merged in two weeks pending it receives appropriate approvals and structure reworked)
CIP Statuses changes:
CIP-0007 'Draft' -> 'Proposed' PR152
& trying to advance existing CIP statuses
💡 - For more details about Statuses, refer to CIP1.
"Alice has a Cardano idea she'd like to build more formally":
