Table of Contents:
Rough writeup of 10/19/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. guest: HuthS0lo.
N/A
PR88 - "DApp Connector"
Frederic - This was discussed at length during Editors meeting #30 and #31. It has a lengthy 130+ comments conversation - but we felt it was good enough to merge in, have there been further updates since?
Matthias - I think we suggested to remove the section about 'events' that was introduced recently with discussion, for the sake of merging what has been discussed and have the conversation about events be brought up in a separate PR/CIP.
Duncan - I agree - let's merge the bits that are stable and carry on ongoing discussions in their own threads.
F - About steering: Do we want to override authors in PRs or do we leave it up to the Author?
D - In the first instance the author aught to decide - but Matthias Recommendation is very sensible: "Guys, get the main part in there, it's fine, and separate off that other piece and we can declare the main part cannon.."
M - The author is very active/responsive. This was my last message in there because he asked precisely that.
F - In that case, is this still another 'Last Check', awaiting Rooooob, the PR author to move that section out?
M - It's on Rooooob indeed, we can make it a bit clearer, but he had a Q about that.
F - So flagged as 'Last Check' or actually 'Triage', ready to be merged once removal of section, if Rooooob is ok with it merged. Would it be wrong/inappropriate if merged with Events section in however?
M - No, given that it is a draft, but it would need a disclaimer that it (event bit) hasn't been fully discussed as much as core ideas maybe.
S - I can ask Roooob to change that section so we can get it merged. If that's all people have problems with we can even have people approve the PR now so that when Rooooob makes his changes I can merge sooner...
D - Were there any other major changes or things or was this all about the events API?
S - I don't think so
M - There was one change that was proposed recently but it was very minor, which can go through a different PR. It was more an additive change. Beyond that, no, pretty stable.
=> Moved PR88 to 'Triage'
PR116 - "Standardization of Royalties"
F - This tentative CIP is by HuthS0lo
HuthS0lo - 45 days ago, there was a meeting with several community leaders, folks in the CNFT space and the goal was to create a community standard for royalties because the challenges with smartcontracts, they really didn't seem an effective method of creating royalties for the resale of NFTs. We all met and agreed on a standard, which is straightforward, with the goal to make it so that people cannot change out their royalty structure down the line. So we request that their very first token created of of a policy essentially identifies the royalty they are expecting from any asset created out of the same policy - that is functionally it.
D - For clarity, what can you express in these policies: are they fixed, relative... and they are only 'voluntarily enforced' things by actors correct?
H - Correct, this is not enforced at the blockchain level, and really meant to be enforced by the various marketplaces like cnft.io, token.io, artano ... Anyone who is active in that space. We expect they will align with the standard. As far as what goes in a policy is really two key things: the percentage expected from a resale and the address it should be sent out to. One of the things that was decided was that we only wanted one single address to prevent undue burden on the marketplaces. ALso there is a minimum ADA per Tx, so subvdivision and such was inconvenient.
D - So it works as metadata and has to be attached to the very first minting with that policyID...
H - Correct, your very first mint has to be this token. And the reason for that is so that people can't change it down the road. If we make sure they make it on the very first transaction, then it is very much identifiyable for any transaction that comes after that - plus it's not a major rist on creators: If they mess up their initial minting, then they can just do a brand new mint.
S - This feels like there is overlap with Matthias's CIP proposed (CIP-0028)
H - I have to look at it
S - Besically a way to add to the metadata associated with a mint. They are associating an arbitrary keys so that you can refer to it in the future. My train of thought is that you could use this instead of tying the royalty information to the first mint, you could tie the royalty information to any transaction associated with a specific key...
D - But the purpose here is to NOT have it modifiyable over time
H - Correct, there were multiple proposals - the meeting held was by users influential in the CNFT space. One proposal wanted to setup an offnet repository and you could have a metadata tag pointing to that, like a SPO putting his pool info up in the cloud. But that was exactly it, we didn't want ANYBODY to have the ability to change it. You could bad actors that might sell at 0 royalty and later change to 100%... The goal was to protect buyers on the same token and create the ability to have royalties without requiring the extra layer of a smart contract. As long as there is a standard that any marketplace can enforce.
F - The state of the conversation as understood is as a 'Last Check' are there requested changes?
D - The extra metadata label as '777' has to be registered with CIP-0010's registry.json and should be done in this PR.
H - I think someone had asked previously, but I can do that.
M - We typically bundle those changes together so it is also reflected rightaway in CIP-0010. You had it as a separate PR, this should be in a singular PR.
D - Change the existing PR so that instead of touching one file it changes multiple files: just add another commit that changes that registry file (CIP-0010)
F - Also, the file should be in its own subdirectory, and the header is missing from the main markdown file itself, where number/type and such are defined.
H - Happy to add header + move and touch the other file as needed.
M - There is a template in the repo you can refer to (or existing CIP)
=> Moved PR116 to 'Triage' for next meeting
PR117 - "CIP-0029 | Monetary Scripts Serialization format"
F - That was setup as a 'Last Check' and was ready to go.
S - Good to go.
M - Hasn't changed in a while, good to go. Maybe one thing we could change is the status from 'Draft' and maybe to 'Active'? It's capturing what exist. I don't mind making a second PR but we could also merge it directly (as Active).
F - Partial to it but it might be worthwhile to have the status transition as a separate conversation.
D - We have that general issue that we want to move a lot of the 'Draft' ones, so it might be better to deal with that all in one go.
=> Merge NOW PR117
PR112 - "Cardano Offchain Metadata"
M - I had an extensive chat with Michael, he cowrote most of this CIP and we mostly discussed the changes and additions. I made a couple of edits this morning based on his feedback and this was all discussed with Polina. But not much different from her on the PR. Generally it's pretty much in a state that is ready for 'Last Check': It's completed. I added this morning another 'Well Known' Property (the preimage) which is a very common usecase for the metadata, removed some sections that weren't relevant to that CIP and some rewording. It's a pretty large CIP.
=> Moved to 'Last Check' PR112
F - Other items that we might want to cover - some CRC conversations, and the advancing of the CIP statuses.
M - Let's go over the CIPs statuses: It's a question we could solve rapidly.
F - I'm inclined to take more time to go through them, maybe we can see how far we can go
M - What was said last time was we could go over a few of the propposals and see if we could advance them - maybe it is faster than anticipated and we can do them all.
M - OK. CIP-0002 the coin selection - this one is implemented at least in the cardano wallet and the NAMI wallet. As far as I've seen they have provided their code opensource which is a javascript implementation of that one and the Cardano wallet has a Haskell implementation of it. It would deserve to be extended with the multiasset concerns which was introduced with Mary. Coin selection approach is very much the same but had to be tweaked a bit because there is no strategy for how to handle the multiassets. At least for the spirit of it (the self-organizing approach) still very much applicable. I think it could be set to 'Active' - I will chat with Jonathan, and maybe see if it is worth doing another new CIP making this one obsolete - it would cover multiassets additionally. I think this would be a good usecase for that - move this one as 'Obsolete' and have a new one that takes over. But in the meantime, it should be 'Active'.
S - Agree. 'Active' is fine.
F - Will reach out to Jonathan - Next is CIP-0003.
M - CIP-0003 - "Wallet key generation" is definately active - the CIP was done retroactively and so is exactly what all wallets use today on Cardano to generate keys from recovery phrases and that includes Trezor, Ledger,Yoroi, Cardano wallet, NAMI, daedalus, probably CC wallet, Exodus ... every possible wallet is following that. 100% 'Active'.
F - While all those changes are proposed directly to the statuses of those CIP it might be worthwhile to have that 2 week lag so folks can weigh in on the change to 'Active' - Pending any objection, 0003 is 'Active'
M - What do you think about a PR changing the Status to 'Active' and pinging the respective Authors to react/aggree/give feedback? I think that's fair.
S - That sounds like the faster option.
F - There will be a PR to change the status, notifying the Author. I'll bundle something when I make the notes and go from that unless someone wants to jump in and change that.
S - CIP-0004 - "Wallet Checksums". For the Wallet checksums, it is active. It's used by Yoroi, CC wallet, and also Flynt.
M - 'Active'
S - CIP-0005 - "Common Bech32 Prefixes". It's used by everybody.
M - And is geting extended from time to time with new prefixes and units. Used by CLI and APIs as reference if only for the address prefix.
F - CIP-0006 - "Stake pool extended metadata".
M - I think it is used?
S - Adapools uses it.
M - I think it was at the time of the ITN and people wanted to have this ITN special 'tag' - I think it's still in use, have seen the pools using extra metadata that isn't part of the initial set? It would be good to confirm with the author maybe - unless 100% sure Sebastien?
S - I know adapools is using a share model to modify things internally - I don't know if others explorers are using this still. I would assume that pooltool is using it since they contributed to this spec as well. Not sure.
F - CIP-0007 - "Curve Pledge Benefit' was setup as a 'Draft' to discuss, there has been no change I assume on IO's part.
M - I think it should be 'Proposed' and not 'Draft'
F - What is the path towards active for this PR?
M - I get your point and I don't expect much will happen (to try defining a "path to active"), mostly because this deals with the Core team on the Ledger
F - Can we suggest to the Author to add to the PR with the proposed path to Active "to have the Core team's implementation"?
M - But he has no control over the core implementation. It's fair enough to propose it. Maybe a good time to change the status if other things have changed?
S - CIP-0008 - "Message Signing" - it's implemented by NAMI and Flint. There are quite a few dApps and users using this. Good to change to 'Active'
F - CIP-0009 - "Protocol parameters" this is the initial Shelley Parameters changes and the changes since. I don't know if this was updated since.
M - There is one PR updating it with the Alonzo parameters and the new parameters introduced in Alonzo genesis. I don't think the parameters are updated that often: There is the d parameter that gets updated each epochs. Kevin is updating and keepingthis up to date aas far as I know.
F - I thought there would be a CIP for Shelley, one for Alonzo, has this changed since or will we have one giant CIP with all the parameters
M - I think we said we would have one per era (if relevant). There haven't been new parameters in Mary or Allegra so there was no need for new CIPs. At the same time it's good to have everything in one place, we should look back in the meeting notes.
F - I believe the PR from Kevin is only for the Alonzo parameters, and last I checked with Keving there were 160+..
M - The thing about the Alonzo parameters, you have a dozen main ones or so and then you have the cost models params for Plutus. You could see them as one giant param, as values for individual parameters for each operation, so that takes some space, you don't have the give an extensive description for all of them, they refere to specific machine operations.
F - Maybe reach back to Kevin on this one wether this should be setup or updated.
M - For the Shelley one, it's definately 'Active'. Then we have to see what we do with the other PR.
F - Maybe we should request the Title be properly bounded (and change the title to "Shelley Parameters").
M - But then it would be a bit confusing to have two CIPs describing the same thing on different Eras, but at the same time it would be clear. Ideally they would push a CIP BEFORE the HF to discuss the values upfront.. So yea, this one renamed as "Shelley Protocol Parameters" and for the next one have a third CIP.
S - I agree with the title change but I think the content is fine.
F - What about the status?
S - I think Active is fine, as was mentioned, the next CIP would be a new CIP, so fine to leave this one active.
=> PR88 / CIP30 - "Cardano dApp-Wallet Web Bridge" to 'Triage'
=> PR116 / CIP27 - "CNFT Community Royalties Standard" to 'Triage'
=> PR112 / CIP26 - "Cardano Off-Chain Metadata" to 'Last Check'
=> Merged as CIP-0029 (Draft) - PR117 - "Phase-1 Monetary Scripts Serialization Formats"
- We went over the 9 first CIPs to review and advance status, will out to Authors regarding to changing the status to either 'Proposed' or 'Active' (If agreed)
💡 - For more details about Statuses, refer to CIP1.
"Alice has a Cardano idea she'd like to build more formally":
