Table of Contents:
Rough writeup of 01/25/22 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. + guests (MPJ, Mark Stopka)
Matthias - (On Process) Michael Peyton-Jones (MPJ) is saying CIP 32 requires attention, but it's already on the agenda. Mark is also suggesting we discuss “delegated voting” instead of particular PR with that. And also the onboarding of new editors… (answering to MPJ chat ask) “Proposed” if there is a ‘past to active’, which is clearly outlined. It should be the case in this.
Michael Peyton-Jones - So, in that case I should put them as ‘Proposed’? Not clear on what is needed, what to do in terms of the process.. The changes we think we need to CIP 30, 32 are sort of details (how are we going to represent it on the ledger etc… )? My understanding is that you merge things(CIPs) and then add edits to them? I am not really sure what the process is, happy to leave it open…
M - If you still anticipate few (substantial) updates, probably best to merge it as ‘Draft’ to indicate that it's still being worked on. If rather updates are anticipated to only be simple rewords, merge it as ‘Proposed’.
MPJ - For 32, Hopefully we can address the comments that came out just straight out. The other two, I think are fine. I'll do a last pass today.
M In principle once it is ‘Proposed’ you do not really anticipate changes to it, the final design before ‘Active’.Why you are implementing it, you discover new things and then from propose to active there are still changes.
MPJ - That is basically what's happening. So it's just a question of how we want to represent the current state.
PR148 - Update to CIP 30 (signData API)
Frederic - Jumping into the triage items: First one is PR148, the signData() API. Has that conversation continued?
M - A bit, Yeah, I saw a few updates and Alessandro also commented on the issue… but it's also now in a state where it needs to be updated. Not much more than last weekend. In terms of progresses. So, the discussion made some progress, but not the CIP per se.
F - Um, Yeah. PR148 adding signData() API to CPI 30, i.e. “how a DApp would connect to the chain”. If you have strong opinions on this, please do weigh-in on PR148 directly.
M - Yeah. There was also a discovery by Alesandro last week. I think, regarding the codes assigned to one of the signing methods, they were not matching, between the stake and the library. I think he opened a PR.. Not completely related to CIPs but …
Sebastien - Yes, We are aware and are looking into this, the repo belongs to Emurgo FYI.
=> PR148 being looked into and to be followed on for next meeting (should it be moved to 'Last Check')
PR159 - tentative CIP 31 - "Reference inputs"
F - Do we want to extend this? Is the conversation still going on?
MPJ - I didn't even spend much in the way of substantial additional conversation. Recently. There's one point of contention: The scope of this could be expanded to include an additional feature (which it doesn't currently include). I made some attempt to check community sentiment on that. I think it is something that people care about, but I don't think it's feasible to do the design work and implementation in the timeframe that we'd like to do this in. So I decided to revisit that in future. I don't think there's actually been any discussion that changed the substance of the proposal in a while: fairly settled now.
=> PR159 On hold for now, revisit later
M - (now that we are over with Triage) some peripheral CIP bookkeeping: There were just minor changes and corrections to the existing CIPs: PR195 is adding another reference implementation for the CIP 3 (the master key generation algorithm) from seed to wallet BitBox02 key format. Which also uses this format that is specific to ledger. if we added it to the CIP which is very much welcomed. So we both approved Sebastien, I guess we can merge that. Small update to CIP 30. It's pretty minor change. Also PR193 re: CIP 25 (on NFT metadata): a precision by the author about the asset naming, coding which has to be UTF-8 which does not make me happy yet is approved, because it reflects what it is. I think we can merge this as well. Additionally, we did discuss another small one two meetings ago requesting a clearer “path to active” section in PRs, so we know what the author has planned in order to move their CIPs ‘Active’. (also relevant to MPJ’s earlier Q).
F - Again, the CIP’s “Proposed” state is intent for when the author (or authors) deem the CIP PR complete and there is a community-verifiable explicit (Editor-approved) path to “Active”: This could be a working implementation (where applicable), or a set of observable metrics on the network, but it should be clearly worded out in the CIP as its own section for all to refer to.
M - PR182 could be merged also, it is fixing links.
PR160 - tentative CIP 32: "Inline Datums"
MPJ - That is the one we discussed earlier. We need to see a bit more activity: it just needs a bit of attention, but I think that's resolvable. Inline Datum is about allowing you to put datums directly in outputs instead of datum hashes. A lot of things are fairly uncontroversial, the only question at the moment, is about how this is represented in the script. So I think there's fairly good reasons to make this distinction visible to scripts because then scripts can assert inline datums to be used. But then the questions become “How exactly do we do that?” in the representation, which is really a detail, and “What do we do for Plutus V1?”. We could do a sort of “backwards-compatible thing” where we pretend that it is in the witness map (which I'm somewhat partial to) or (what we really shouldn't do) just “Omit the information”. To just silently drop the information would be a bad approach. A realistic option would be to effectively ban transactions which contain inline datums. We just do on-script. This wouldn't be so bad, except we create a new way you might make things unspendable, by creating an output via Plutus V1 script and inline datum, because you wouldn't be able to reference that output to itself.. There are already a lot of ways to make things unspendable, better not to add more…
M - This is something the ledger would catch very easily right?
MPJ - Not really, you can not catch that. When you create an output, you only have a hash, which does not tell you a version, or a language tag: At output-creation we do not know those.. I think Alex summarized most of that pretty clearly in the PR comments. It's not clear what the best resolution is from here.
M - Would it be out of the question to introduce new address types for that?
MPJ - If we are going to change the address types, adding an address type that generically included a language tag, would be reasonable. But I don't really know how much work that would be. It's also somewhat orthogonal to this: We could in principle do that separately. I think you're probably more likely to know the answer to how difficult that might be.
M - It wouldn't be too complicated probably.
MPJ - Okay. He doesn't think that solves the problem. The ledger forbids your transaction and transaction creation time. So you wouldn't make a spendable output.
M - It doesn't completely solve the problem in the sense that you would still have the old addresses available to use. You could migrate to this new addresses and recommend deprecating the old ones into new ones…
MPJ - I suspect this won't be a problem, but feel bad about introducing a new way to make things unspendable. Not the end of the world, but a better option would be nice.
F - Ok, that’s setup as a ‘Last Check’ item, tabled for now TBA until the conversation evolves from there. CIP 32 / PR160 moved off from ‘Last Check’ and back on hold depending on the state of conversation. a Triage item for next meeting, depending on the state of conversation.
M - Let’s not put PR160 on the agenda until we have an update (from MPJ). The discussion might take time, So we can just put that PR on hold and put it back on the agenda when there is an update.
=> PR160 Moved off the agenda (and off from 'Last Check') until we have update from MPJ on the conversation (check in on it in a few meetings)
PR161 - tentative CIP 33: "Reference Scripts"
MPJ - That's the one we were just talking about. Shouldn’t have substantial changes
M - Let's merge that one. I suggest moving its status to ‘Proposed’ as soon as we have fleshed out the CDDL (and surfaced the details / path to ‘Active’)
MPJ - I think for some of these, we could merge them as ‘Proposed’. Stuff like the CDDL, will ultimately come out of the real implementation. I will defer to the Ledger team on what is the right way to do this CDDL..
=> Merge NOW (PR161 as CIP 33: "Reference Scripts")
PR188 - Update to CIP 15 / Multi-Delegation
S - Last time I talked about this was mostly around backwards compatibility. I haven’t had the chance to check their edits for this yet. There is also a question whether if people are actually going to implement this? Because we're modifying an existing CIP - So we need to know who actually wants to implement this thing. This is something that the Catalyst team is supporting: If nobody wants to support this, it might not be worth changing the CIP. So far, I haven't heard of anybody that wants this change. I think that the voting purpose it's fine. It is not a backwards-compatible change any wallet needs to take care of. Again, It can be used by random folks.. But a change to allow delegating your vote would also be something that should be taken care of, but not sure there are any wallets that signaled that they want this. Maybe someone from the community wants this. Nobody from IOHK will submit this proposal. We need to figure out if they really want this feature. This is my main concern. Obviously from the CIP perspective, It's a valid CIP and it can be varied from that. But the fact that is modifying an existing CIP, it makes it slightly different from merging a new CIP.
M - Perhaps it's really better to be a separate CIP. Because indeed it seems like a fair extension of an existing one. But it modifies it quite substantially, which could fit better as a separate one.. And it would make it clearer for wallets (or clients) who could then implements CIP 15 “and CIP X”
Mark Stopka - As far as CIP 15 / Multidelegation goes, I think it is a long awaited feature. If it's going to be a separate CIP or the same CIP, I don't care. The community has been calling for the ability to get Cardano whales who are too lazy to download/vote in the app via Catalyst for quite some time. It is critical. And we would like to have it asap. Maybe by Fund eight (about three months from now). I know it’s suboptimal. When thinking about governance and delegation we've been expecting something completely different… I don't know if there is a plan to use this as a temporary solution, and later implement something more cryptographically sound and less traceable - using some zero snarks, or zero-knowledge proofs or something…
M - The idea here would be to let people register the set of keys they are delegating their votes to.
Mark - I have friends that have about 10 million ADA, none of them votes, except for me. So they would be happy to give me their voting power and let me decide, and I buy them yours and I will have much more voting influence to support technical proposals that make sense as opposed to some that don't for example.
S - From a technical perspective, I have no opposition to the CIP after the modifications. After I read over it, I think it's fine. Still, I think he is probably right. I believe it's better if this is a separate CIP, because it requires explicit support from wallets and backwards compatibility. Make this as a separate CIP and then wallets can choose to support this change.
Mark - Happy to propose a new CIP. I will setup a CIP to complement this one, add authors, and submit it by the next editor's meeting so we can push it through.
M - Yeah, that would be better. As for delegation currently, It also changes: there are like two changes in one. Before that there was a single delegation / a single vote. Now it is a list. So in terms of tooling - or for the Catalyst process by itself...
Mark - Not sure how IO does it, but if I were doing it, I would just scan the chain for all the voting registration certificates. Then make a new genesis for the Jormagandr sidechain that would reflect the respective voting power.
M - That is exactly what happens. There is a snapshot on a given date that takes all the registrations..
Mark - So in this case, you would look for the registration certificates that has multiple staking keys and you would pull those together. That would be a temporary solution. As we roll out Voltaire, I think there would be lots of changes to such a CIP overtime
M - That sounds fair. Given that Jormagandr supports “multi delegation” in the first place. There is also something to be done there.
Mark - Multidelegation has been thrown around for about a year: Is it something that is actually coming? As a community we sort of develop the work around with enabling wallets so we'll have multiple accounts. People who want to multi delegate currently split their wallet into multiple accounts and allocates each to different pool…
M - I don't think there is any plan right now to support that “natively” in the protocol. There is a clear willingness to have (delegated) voting supported by more clients on the line: that's exactly the way this has been done. I think there are at least two other CIPs that are also approaching this question..
Mark - I don't think that there are bad intentions, just limited available resources or prioritization, with things like script preferences or other more important things.
M - Also about complexity: there are features that would add so much complexity as to make the feature itself undesired. Here, the consensus has been that the complexity compared to what it gives, is best handled in the wallet rather than the node.
Mark - In the ledger rules in the repository. The guys started to update the foremost pack. I think they are expecting this CIP to be approved soon so they can roll on to the chain quite soon. There is a difference between LaTex specs, executable specs and actual code in the HASKELL node but I think that they are at least expecting an early merge…
S - We are getting off topic right now. We're trying to finalize what to do about updating CIP 15.
Mark - We agreed that I would submit a new CIP, which would be more specific... I will do it today, tomorrow, and we can then merge it. I will copy the CIP 15, removing what doesn't make sense and refocusing on multi delegation. That way wallets can signal support, for CIP 15 it itself or “15 plus (new one)”. Also I've been hearing from colleagues in American time zones they feel it is difficult for them to participate. So what I was thinking since we have CIP meetings at the every two weeks, what we could do is that we could have one that we'll be better suited for Asia. And one that will be better suited for America. And both of them will be suited for Europe.
F - Let’s add to the discussion section: We have one more item first though.
=> Re: PR188 - Update to CIP 15 / Multi-Delegation requesting a resubmit as its own CIP (rather than modifying existing one) - to review as appropriate
PR183 - Update to CIP30 - Experimental tag
S - Right now there are multiple wallets implementing CIP 30: Flint, CCVault, Nami, and others. Now that multiple wallets try to implement this CIP, they are trying to stay aligned on a standard. It makes it hard for DApp authors to know what is supported by “all the wallets” and what is something that's supported by single wallets. At dcSpark, we want to create a website that explicitly lists what can be used for browsers, and which wallets supports what. To effectively do this, we want to be able to mark APIs as “experimental”. That would allow devs to know an API is “experimental”, and devs writing code could focus as needed. We could have a set of stable functions and then the experimental flavors: this PR basically just explicitly adds this experimental field inside the CIP30 data structure.
M - The difference between the global and the per-wallet namespaces would be exact ‘X’. For features that are “experimental” but agreed upon globally, they would go under “experimental” but a feature for a particular wallet would go under the wallet namespace.
S - The global and the wallet namespaces are for different reasons: for registration purposes. One of the goals of the dApp connector, was to prevent monopolies ala metamask - basically nobody can compete with metamask because metamask overrides everything: There's no way to specify which wallet you want to connect, It is a mess. So we want to make it easy for wallets to list themselves as supporting CIP 30. The Cardano object at the start has no functions in it, only a list of wallets. Then whenever you use a dApp, if you call ‘enable()’ on a specific wallet, then it injects it into the space. These are two valid separate things. The wallet namespace being experimental is just for meta-information about the wallets. And then the global namespace is for actual functions...
M - This could be the next version or the extensions of CIP 30, for instance, that are still being worked on as CIPs? (S - “yes”)
F - So, could this be a standalone CIP, or what is the reason for riding this on top of Rob’s CIP 30?
S - This is fully backwards-compatible and is currently experimental. It's currently supported by CCvault, Nami and Flint.
F - Should Rob (PR Author) be pushing this? Is he on board with those changes already?
S - I will ask him. (Rob works for dcSpark)
M - It sounds good to me. I've approved. Alessandro seems to be positive about it.
F - Considering PR183 as ‘Last Check’. Rob is working on this, for experimental APIs.
=> PR183 moved to 'Last Check'
F - Next discussion item is as per Mark: “can we move this meeting so US-based folks can attend more?”
Mark - We keep seeing bigger and bigger changes coming in: In order to facilitate a global community, as well as enable a bandwidth enabling the amount of changes coming in, and have a proper debate over all of it, I propose that instead of having the (CIP Editor) meeting every two weeks, we have it every week and one be catered more towards Europe and America. And the other one towards Asia and Europe. (Let's set up a mailing list + onboard more editors too..)
M - The current problem with doing that is that we as editors would have no bandwidth to do it. Scaling the number of editors and people would definitely make the communication harder. Sometimes synchronizing things takes much longer. Re: mailing list, we already have the notes published after each meeting and the actual recorded meetings. Maybe it's more about advertising the notes more than we do?
Mark - There is a magazine called ADA pools.io... I'm going to try running a monthly retrospective of the CIP process: that would help drive community engagement that way. As far as the coordination for the actual CIP editors, I feel Github is too messy unless we make like one issue where we can have a discussion, I think Github supports discussions, right? So we could move it into the discussion part or in a Wiki part, or somewhere where we can have threads, which won't be cluttered with both technical stuff and the process operational stuff.
M - That's something we mentioned in the past, indeed. I would really like to give a try to github discussions. I think they are well suited for the CIPs. Especially for discussions that are not necessarily technical, but more like political debates or changing the process, or onboarding new people etc. We discussed that in the past. About onboarding of new people. We have Robert now, but he's also US-based so often halfway to join meetings. Um, but we still haven't defined the formal process for candidating for the editors (currently a majority vote)
Mark - I see several gaps around the process and I think we should update/review it. The process we currently has just three tracks for the CIPs.
F - We are very aware that many process areas could be improved.. Can we focus on the timeframe for the meetings (Conversations will get lost a bit otherwise)
M - Probably why we’d want to have this “GitHub discussion” open. We also have been in the past meetings where we had á list of ideas of things we wanted to change probably in this API. I mean, the process. So one we discussed today was this little thing “path-to-active”. It's still minor thing but something we want to change for others. We don't have enough time in a crowdcast meeting to discuss all, so might be better to have proper discussions written down to discuss and bring them into an actual synchronized conversation.
F - Every 10 meetings there is an actual retrospective that happens behind the scene. For the sake of making sure that we go through these discussion items as put out in the agenda during regular meetings, it is very condensed. But for the sake of conversation, regarding potential US meetings. It is more a problem of time availability. Matthias and Sebastien have been pulling most of the editorial work. Finding a time that works for Mathias (FR), Sebastien(JP) and myself (TW) with US is really hard..
Mark - The question is how big of a quorum do we need to make decisions on CIP meetings? Matthias is in France, so he can cater to US as well. I am in Europe, so I think I can cater to US. And then you have one more person, you mentioned one more who is the new CIP editor based out in the US. So that makes three people.
M - I don't mind alternating. We can do two things. The thing I just want to confirm is if we want to double the amount of CIP meetings..
S - If we want to double the CIP meetings it does not seem reasonable to me at this point of time
M - And although we do not need to double them. Lets do one meeting in Asia, US and. Europe time zone We can alternate them.. One was a meeting in the US and Europe. And we'd have two meeting amounts. So that means once a month, um, every, everyone goes at least able to speak in a friendly time zone… Otherwise they got to wake up early or wake up late. I think that's a good step in the right direction maybe.
F - For the sake of consistency, prefer to have the meetings at the same time. It's difficult to juggle.
M - In a way that would be “at the same time every month”. Maybe we can run a poll to see, and have proposed times, then take the time that has the most votes? And if we see there is clearly a pattern of “two times”, adjust new times..
S - I am not sure a mailing lists adds more value, in terms of enabling email notifications from github and considering we are low on resources for managing CIP stuff. I would rather not add what we can not manage.
Mark - We can tap into the catalyst resources I believe: they have an entire team dedicated to admin stuffcalled QADAO:we should use them. We pay them, we should use them. They have all sorts of different fancy names for doing different stuff… I can reach out to them and we can ask them to provide us with that for doing meeting minutes for example. They already do meeting minutes for the catalyst circle. Circle. Things that are recorded and so on and so forth, so we should be able to tap into these resources. And they already have some automated AI based tools for transcription.
M - I would actually do nothing more than publication of weekly notes. If someone wants to build a mailing list on top of the CIPs, or adding things to ADAPools as you suggested, that would bel welcome, but adding this to our busy schedule is too much.
F - At this point, we're also looking at adding more people to the editorial board. If you are interested please reach out to either Sebastien, myself or Matthias via email or social media.
=> Merged as CIP-0033 (Draft) - PR161 - CIP 33: "Reference Scripts"
=> Merged minor changes to CIP 15 - PR183 - Updates to CIP 15 / Experimental Tag
=> Hold on PR159 - tentative CIP 31: "Reference Inputs" as conversation continues
=> Hold on PR160 - Potential CIP 32: "Inline Datums" - will be revisited as needed
=> Hold on PR148 - update to CIP 30 / api.signData() (to Triage again!)
💡 - For more details about Statuses, refer to CIP1.
"Alice has a Cardano idea she'd like to build more formally":
