EIPIP Meeting 107
EIPIP Meetings · 17 Jul 2024 · 34:27
Meeting 107 of EIPIP, held on 17 July 2024. EIP editors and community members go over the EIP process and the editorial issues currently open. This meeting covers edits to Final proposals, updates to EIP-1, a working group update, security considerations and disclosures in EIPs, open calls for input and the monthly status report.
Topics
From EIPIP Meetings, hosted by ECH Institute.
Transcript
welcome to EIP IP meeting 107 this is issue number 346 on ecat herders EIP IP GitHub repository on agenda we have some open issues and P requests to be discussed we'll take a look at some miscellanous issues as well as PRS and we'll collect editor feedback thoughts whether we should keep it or close it we'll take a look at call for inputs added here and then discussions from earlier meetings I see uh there is a reques uh for discussion that happened in the last meeting we can um hear about that and we'll get some updates on working group discussion that
happened in the middle of the week so starting from the very first item we do have a list of uh P requests the first one is 1363 it seems that it has uh been already approved earlier um but the author has added some new changes I wonder what the editors think uh is it good to be merged or do we want to get some more clarification from the um this is editing a final proposal and I think it's editing it too much IMO anyone else has any thoughts on that
that yeah I remember 1363 had a bunch of PR for editing a final proposal okay let's try to uh get something on this one um just considering this open be number 403 do we want to Marge it or do you want to give a push back I don't know how significant change they are trying to push here um it it's not too too bad but it is just changes in general so Matt gajender is there any objection
on merging on this one or do we want to not merge this and just close I don't think we should merge it um I I don't think yeah we should merge it because seems like overing changes in the Tex all right I'll close the pr right moving on to the next item which is uh PR on ERC 342 it's uh updating ERC 2098 it seems like we have already
received one input from REO and seems okay for him not sure he ever got a chance to get into it again do we still want to wait for any more updates we can perhaps give him another ping or anyone else from the EOS system another ping to take a look if not are we in a position to merge it I mean I think we need to verify that it's correct or someone needs to so we want to wait a little bit more on
that I don't think it's a waiting thing it's like somebody needs to tell us if this is correct or not is it a fin one I mean he does have an example here that I'm trying to understand it seems Richard is one of the authors and uh he says that at first look it looks like they are correct I mean I guess we could plug this into like a signature Checker and see I mean he does have this solidity example so if I could run this
quickly we could know all right well we'll leave that to you to verify and get back to us sounds good Matt whatever comment you have for that please add it on on this PR and we'll take it from there moving on uh for some open issues and P there is an update to 1175 it seems like it's not only for 1175 they have pinged a bunch of es and ercs so what do we want to do about it is I
don't know if it is a potential spam I could not even go through the entire no no it's it's correct it's just it's not spam it's just um uh because of our weird build system um they have to be EIP um I'll I'll make a comment and close it okay perfect thank you so much the next one is the update EIP 4788 PR number 8590 um it seems that it has been approved by one and uh not many and we were waiting on math comment here it uh
Matt I mean is there any way to change your mind or you are still on it and we need to close this because it seems we did not get any consensus on this one I mean I think there's other final eaps that have TBD in their Forge so I don't really see why we should updated this here I'm not sure that was a field earlier that is a new practice I guess that started from past a year or
so I feel like that's been since 2016 yeah like the the earliest eips include a fork block and then later eips don't for exactly this reason um I I don't care if you want to like if you you don't want us to merge this I'm okay just closing it I mean I guess I don't really care either okay I think in that case we should add that because that is the right thing to do here and it's because it's a core proposal it will give I mean it will add value it'll look better if we merge it yeah I'm if you're okay with it I'll merge it then mat yeah it's fine
all right very well the next one here is uh EIP 3712 multiple fungible token it seems like uh this is a wrong repository for this PR we already have mentioned it to the author but author hasn't taken any step to move it to the ER see how do we want to move about it should we move like just move as merge or I just close the pr uh so we want to move it because it's interface or it's ERC on 30 uh uh EIP prop uh GitHub repository no no I'm
looking at it but so it is not an ERC it's an interface proposal so um we're saying shouldn't be an interface proposal no my bad so I think I looked on the earlier version where it was mentioned as category ERC now I see an update on category interface so this can be here because now it is a core proposal I just think it's still an interface and they saw that there was an error and we're like wow we need we need to fix that but they didn't read the text that says the erc's go to a different repo yeah this is definitely talking like it has solidity code in it so yeah this is definitely um yeah I I'll close this and redirect
them um yeah but we might want to consider that because so far we are still having interface category proposal on core I mean like EIP GitHub repository so it will depend if they want to pursue this as an interface one then it has to it is not an interface though then perfect yeah this is definite like it's a solidity contract this is a clearcut like this is an ERC okay and the number suggest that this is pretty old one and yeah by now it should have received at least category classification very well we can then perhaps close this one yeah I'll take care of
that perfect uh there are couple of more and the first one here is an update to a stagnant proposal 1078 so stagnant definitely can be brought back to life if someone wants to and sees value in that proposal I am not very sure though with this pull request they are trying to do that or just U um fix typo and make a commit in the VIP deposit Tre so maybe editor can take a look the number is 540 and this is to fix two proposals 1078 and 1129
though we discussed earlier that we should not welcome any PR to stagnant proposal because um sorry it was for withdrawn yeah it was for withdrawn I guess we should not welcome any changes to withdrawn proposal we can definitely welcome for stat okay okay any thoughts on like merging both of
these I'm just looking through it um announcements yeah I'm okay with this it's fixing spelling mistakes okay maybe you can perhaps yeah I'm just going to first Force merge this like it's not contentious all right cool all right the next one here it seems like spam PR number 8734 correct yeah I'll close
it okay and the last one here is PR 8724 it seems like um it is not merging and it may require Force merge people try to open and close but it oh it's merg now sorry my bad I don't know why it was showing to me still open or was it forth much right now okay perfect very well that covers all the open issues and PS we have few call for inputs the first one here is 343 which is to fix ERC 3448 okay with change okay with change I don't know Matt if you have any thoughts you would like to add the last date is
still July 28 but it seems like two people are I mean two editors are already in favor of it so your vote will definitely make a difference here we'll get three or more if you are in favor if not then we'll wait till the end of of the deadline the next one is uh issue 345 on EIP I GitHub repository this is to Mark EIP 7212 has moved because this proposal has moved into rip repository and now we have RP 7212 because we follow the same uh number system for all three repositories
it generally makes sense to me that we have only one number in one repository and it could be moved the way we have moved the ERC proposals out of the EIP GitHub repository however uh this this is open for cord input it seems like m u it seems like Sam is already in favor and the author of The Proposal is also in favor I have added a note from the last all codev execution meeting where um one of the rip editors also shared the same interest of having a new proposal instead of continuing with the same name but I think input from other
editors may add value and we will be able to make decision on this PLL request anyone has any quick thought to add right over here I want to take time and look into it Asing sounds like it's going to be asynchronously any just delete we should just delete from the EIP repo yeah so all the ercs were marked as moved and then we are not like counting it over there
so not marked as moved was it why do we mention it as an unusual status how did we deal with erc's yeah they're all marked as moved yeah so we we can they're not Mar moved aren't they they're just no they're just hyperlink to the RC's repo I mean it's not a status like they're like this has been moved to right I that's what you're referring to but it's not like a status for the E my preference would be to treat uh this as very much as like ERC the way we have treated ERC and do not create any new
and special status for this particular proposal if that makes sense yes we do mark them as as status moved that might be me that did that but uh okay that I didn't do that so yeah I had to add a a little header to each one to get the the bot to work again I see I still feel like we should just delete it yeah I mean deleting it would be fine
too I don't really care I didn't remember hearing about like breaking of eips inside when this Fork happened like when we moved everything from uh EIP get up to ESC GitHub maybe because of this status moved I do not have clear recollection of that uh but if right now we are in a stage when we have a copy of all of these proposals everywhere unless we want to save the history this can be deleted however we can definitely refer to older history by keeping it but the status moved is not being reflected on like anywhere order history will always be in
the git repository so that is not an issue okay so just to uh clarify it for notes taker are we deciding on deleting all erc's which has been marked as move and EIP which has been marked on move to the RP report um I can try deleting everything and make sure it doesn't cause any problems and if it doesn't I'll open up P deleting the erc's deleting everything with status moved and rip or EIP 7212 I mean I don't know if we should
delete everything with status moved because there are a lot of like lingering hyperlinks to the GI post I mean that to me is the reason why that link is there and why it wasn't deleted in the first place okay then in that case for this PR it is the resolution is this can be marked as Mo I think we're just going to delete this one um yeah we'll delete this one and everything else stays as moo okay
perfect moving on the next one here is a call for input for um merge update eap1 152 um just to provide some background here there is a small update to a final proposal 152 it seems that author is not around to approve the pull request however this has been already approved by editors as it seems like trival change and people are generally fine so I have created this call for input just today sorry for the delay here uh but the idea is to collect consensus on can this be a process there are so many proposals for which authors are not around can we merge hold request um if
editors are on board with merging the PRS in case auths are not around we can definitely Define a timeline that we want to keep the pr open for so everybody get to see that proposal and if needed create a call for input for even um more eyes on it because I have just created it um I do not see many people have added their comment I will definitely add but any editor here on the call if you have any thoughts on that so I'm against creating a general policy for this because um I think that leads to like not potentials for abuse but um
like it kind of limits in Us in how we can consider each proposal so for this one I'm okay merging it because it's it's like a very trivial obvious change but for other changes to final proposals I might not feel so confident merging it without an author approval so I don't think we should make a general policy but I am in favor of merging this one proposal sounds good yeah we can definitely take it Case by case as it was mentioned earlier as well we'll try to bring up here and call for input if needed but for this one people please add your thoughts and yeah we will take it from
there that's all about item number one moving on to the next item it is discussions from the earlier meeting um there was a meet to discuss about working group update I think Sam you would be the best person to maybe summarize that and say where we are on that sure so I think the current plan is to abandon a formal approach to working groups um so we will not be adding separate repositories for each working group we won't be uh creating working group Charters or anything like that um but some of the I did will be used I'm going to um open up PO request to convert away from Jackal and switch to a
different rendering uh engine uh called Zola and uh so that'll be a little bit different and then uh we were also planning on introducing um a like formal recognition for non-editors who have PR approval rights uh or permissions rather uh and we would call them probably EIP reviewers um and uh uh yeah so that that's kind of the approach we're we're having that would let us delegate some Powers uh and enable people to make informal working groups uh with their own reviewers if they want to um yeah so I think that's that's kind of the plan moving forward thank you for summarizing that I
do not see Victor on the call I think he was one of the person very much interested in learning more about what is the decision on that I hope the some of the call will be able to help him and I don't know maybe um poor editors can uh find out some people who can be good reviewers maybe we can reach out to individual teams to volunteer people similarly for ERC group there is all ERC Dev meeting happening we can share this information in that meeting and try to um have some volunteers to be added as rers and I see there is a wallet Dev meeting plan today
maybe it can be mentioned over there to get some more reviewers for wallet proposals I sincerely hope this will be helpful anyone has any other thought to add to it very well the next item here is security consideration and security disclosure in eips we discussed some of it in the past meeting and de has added a detailed comment about what does he want to say here what is his proposal and things like that so let me invite de to yeah share his
thought and what do we want to get as a resolution from this particular meeting today hopefully to be there yes so basically on the previous meeting I was uh requested to provide some links and uh here is my comment uh no discussion followed my comment so I'm here to bring it back again and uh in general I think that uh final means no change rule is uh is simply wrong because it doesn't allow us to disclose security considerations and problems in final eips and uh this is the stage at which most of the problems
will be dis discovered uh because it is a normal life cycle of a software uh most of the software has back bouncy programs for this and uh I was proposing to uh make security considerations an exception from this Rule and modify the EAP D1 uh to make a new rle that uh if there is some verifiable loss of funds which can be verified through the blockchain history uh then this can be added to the security considerations uh we don't want to uh focus on some small issues our goal is to inform the implementors about the most critical stuff that they need
to worry about and uh here is the proposal all right I will open a formal call for input um and we will get our thoughts out on there and we'll let you know and 30 days I think call for call for input will give this proposal even more visibility and we should try to collect thoughts not only from editors but also from the community I think when
the link is available we should share it on other social media as well if people want to chime in and um share their thoughts although the decision made on call for inputs are basically from editors um but that would be good to see what is a general recommendation coming up from the community and if they would want to bring up any changes in future so just to make sure I understand your suggestion correctly here Dex um you wanted to make it so that you can modify everything or you can modify only the security consideration section only by appending to it and only if there is a financial loss is that a re SEC only
security consideration only aend okay I'll I'll make a a formal request for that okay uh I remember the comment regarding the contraction contracts do I need to address it once again or we can just skip it uh it's fine like once we once we decide um how to handle security considerations we'll apply the same rule to 223 as erc20 okay I want to follow this discussion and provide some maybe comments uh where can it be shared and followed Which social media uh yeah so we it'll be in our um
EIP editor Discord Channel probably um or here on this call okay perfect thank you moving on to the next item I have just added total number of issues and PR open numbers are reasonable not going not blowing up absurdly but yeah we are in process of trying to decrease the number of open issues and poll request so we really appreciate any thought feedbacks and people who would want to add review comments that would help editors to may be able to close this
poll request or merge these sooner rather than later on eips Insight I'm just taking a quick look at the website and it seems like we have received three new draft proposal on EIP GitHub repository as well as three I'm so sorry we have received five new proposal on EIP GitHub repository and three new draft on the ERC side we have one proposal in the last call section that is an interface proposal 5792 wallet call Api and the deadline is 24th July so if people have any thoughts comments with respect to wallet call Api proposal please uh make
sure to add your comment on Fellowship of ethereum magician page the discussion tool link page for this particular proposal and it could be addressed by the authors for details uh the link is added here on the agenda we did have EAP editing office hour I have added the recording for meeting 40 and agenda for meeting 41 for people who aren't aware EIP editing office hour is 1 hour dedicated for EIP editing and you can come up with your open p request number if you have any questions you did not understand the comment of reviewers or editors or you
don't know what to do next I think this is the best place even if you are someone who is trying to make the First full request to create the first EIP for the ethereum ecosystem and you do not know the process this is the place for you to come so if you are the one or you know someone who is looking for any help or support in documentation of proposal moving proposal from one status to another status please let people know about EIP editing office hour that happens every other Tuesday on 1400 UTC and we always try to add agenda in advance so people can come and add their P request the next one is review action
items from the earlier meetings I think there was one open action item for uh call for input for e152 that we have already created today one last thing that we wanted to discuss was about the next meeting date and time I think Matt has already dropped but he was suggesting that we can decrease the frequency of eapap meeting right now the Cadence is once in two week do we want to keep it the same or do we want to decrease it in make and make it once a month I wonder what editors thinks about it I'm okay with once a
month all right in that case uh yeah please go ahead yeah same here perfect in that case um we will try to create an agenda in advance and that would be for July 31st oh sorry for August 21st and we can keep it as a Cadence just for people to easily remember on third Wednesday of a month we will have the EIP meeting at 1400 UTC my bad the agenda reflects 1730 but it will be 1400 UTC is it generally good with people okay
perfect that brings us to the conclusion of items listed on the agenda I wonder if anyone one else has anything to share add or maybe propose for the next EAP meeting just a side question uh I've seen that you are publishing the records of these uh meetings on your YouTube channel but this doesn't have a lot of uh reviews uh do you want to attract some attention so uh I have some telegram channels like with 57k members and I have a Twitter account I'm found of one of the ethereum classic teams I can share something on ethereum classic Discord uh is it a good idea or do you
just want to keep it small and free from site participants I think it is always good to get the visibility the reason we organize this public call is we want people to get engaged any support in creating awareness about EIP AP meeting or EIP editing office our meeting will be highly appreciated feel free to share the link and we will also try to start sharing this on Twitter and webcast so people know more about these kind of meetings happening okay got it thank you perfect thank you so much anyone else has anything to share
and propose very well thank you everyone for joining us today and I hope to see you all in the next call which is scheduled for August 21st at 1400 UTC have a great rest of the day everyone thanks p take care thank you everyone