EIPIP Meeting 69

Transcript

welcome to eipip meeting 69. we have agenda and chat so we have listed a few items to discuss which are coming from issues and pull requests pull requests in which we can make some decision and move forward with the decision in terms of merging or not merging and then we will have a few other issues related to bot may be discussed so maybe we can start with the first item here that is update EAB 721 um

the pull request number here is 5887 so this particular item was also discussed yesterday in the EIP editing office hour uh it is created by Panda peep one of the editors and I believe Sam Wilson also left some comments we were hoping to get more comments and feedback uh to move forward with this um I believe that's what the last comments Sam left on this whole request wondering if anyone have any thoughts to add here I I generally uh think that the history

on EIT 7.1 including what was adopted what was Prior Arts were very useful uh and being left as a record how that EIT was incorporated and finalized through morning links did that we're being talked about FL reduces the value of the original documents okay so this is about your latest solidity and removed that's right kind of I I kind of want to kind of prefer my uh keeping it as as is because you can't

like you can have a newer version but I I kind of feel that the EIP itself was not meant to be updated over time um we don't do that for the id220 and I don't know if that is higher value to do it for you I think 21. so that would be my perspective just to avoid touching it if it's finalized and has been widely adopted even though I had like for another 97.12 I have a lot of complaints about how it's broken but now this finalized I wouldn't challenge it much open

that would be my position yeah looking forward to either to other people's thoughts right um yeah lately we have been receiving a lot of edits for final eids so I wouldn't visit project that comes later on with someone um however yeah if any other people have any thoughts we are currently discussing pull request number five eight eight seven I have shared link here in the chat I'm relatively against updating the CIP

oh mostly indifference but lean towards not a dating okay so um one editor has proposed it and we can hear two voices in against uh and I think Victor is also not very much in favor of changing so maybe we can leave that as a comment over here and yeah it's gonna be passed for the arguments we can have it in the next meeting I feel like we should just close it

like I think we have a lot of people who have already said that don't necessarily think it changes best and there's no reason you can't reopen if she wants to but I would rather like our default be more towards action rather than in action because we tend to just like reiterate over arguments many times before something happens and so if we whenever there's strong consensus just enact the consensus I think we'll spend less time reiterating the dates I would love that I was worried a couple of days ago pull request number of open pull request

but lately we have been potted and the number exploded so yes as much as we can close pull request that will provide us clarity thank you so that's about it the next item here is a EIT status change um so this is a question that we are receiving generally in EIP editors office hour and on many other forums like uh new EIP authors are generally confused about how and when we should move though we try to put more information on eip1 however there is one special case that uh came

into light yesterday it was about EAP 3651 which is a core proposal um the general understanding is for core proposal we do not exactly follow the process of standardization although we have these similar nuances except for we try to sync it with the mainnet upgrade because that is supposed to be updated VM Network upgrade um so yeah if any editor would like to reiterate on the process about their status change just for clarity and I was wondering if we can have this special

case mentioned in eip1 as well like I have added the blog post that was published by cat headers over a year ago in which we mentioned that a core proposal should be moved into last call during the public test net period like when it is into the main net phase but that I believe is not clearly mentioned in eip1 so yeah any thoughts and yeah I don't think it's necessary to really document too much like we're talking on the order of five to eight eips a year that go through this and most the authors of those Eeps know and we like just had an instance of

the author of 3651 worm coinbase triangle with his last call and I just mentioned hey we usually only move these last call whenever the test Nets are happening just in case there were cement needed to be changed and he was fine with that close to PR so I don't I don't think it's something that's necessary to really document beyond that uh just to add on on that I mean I'm really grateful that you left that comment just to add on there uh this full request was a reaction to an action that was performed by bar so the author reached out to me saying that I really do not know when to move to a different status and my EIP is getting this

support comment that it will be still and he then went ahead and created this board request to change the status though I mentioned it to him that this is a special case of core EIT and you should be expecting some something from EIP Adidas thanks to math you did mention the same thing so it made it very clear to him um if we are open for taking it Case by case basis I'm fine by that because as you said that we do not have a big number of uh core eids getting into status change form from last quarter to final or review to last call so I'm I'm fine I just wanted to share here sounds good

yeah I also mentioned there is wording in the EIP one not much but we can talk about the core EIP has different requirement that requires implementations to be considered flying out so I think that level of quality is enough I would be we don't need to add more but I think that any new even if it's a new yet the author by reading everyone they should understand that this is a requirement for coordinate he's already documented in here if you want version okay and one other point that I wanted

to mention uh related to this status change only I understand we generally do not have any fixed duration mentioned anywhere except for the last call duration where we specify that the proposal should be there for at least 14 days while looking into the eips inside for the month of November it came to my attention that uh there are a few proposals which moved fast of moving fast is not a bad thing um I just want to highlight that that uh it was observed that there were a few proposals which were into draft status and is in final status

in less than two months for some reason my feeling is like less than two months could be relatively faster and we may not be providing enough time for Community to learn about the proposal and add valuable feedback so that we do not have iterations of changes post it is finalized like when a proposal is done we want to keep it done no more changes there wonder if there are any thoughts the ones that I remember going to final very quickly were like single method uh ervs were there were there more

complicated ones that went through quickly or I can list the number I have it is five seven three two five six seven nine five seven five zero so these are like uh the proposal is started somewhere in September and they are in the 5750 is not on a final it has started on October 15 and it is in last call which is ending November 19. so if the author chooses to make a pulled request to merge it as final it will be less than two months actually within a month it will be and similarly for five six seven nine it started on September 19 and on November 10th it went into the final starter so I

feel like it is relatively faster so if there is any recommendation to keep proposal in review for about a month or so if there is no rush like if there is no particularly need to move it faster than that yeah we can we can do that we don't see a problem with it naturally a way of making that happen most likely I mean it's not I feel like the longer time in review is a trailing indicator where we really want what we really want is we wanted to know that people are reviewing or people are happy with the standard and so I think like if we make an active criteria more than

just time because having some time on it to me doesn't necessarily mean whether or not that someone's actually looked at it and we talked about this in the past I think that if we just made this requirements for you know especially erc's a little bit more stringent like we have this requirements as before you open a draft you need to like have discuss this with the community and have to you know have some sort of support from the community so if we had that as like part of the draft stage like Smooth review or move from review to last call you need to like show like three independent people who've shared thoughts and are approving of this change and like I don't really know the best way to like encode that within the EAP process but I think having something like that where

we put the work on to the community rather than having some arbitrary time limit could be a lot more valuable yeah I agree with that like Ryan that um maybe adding obviously time period is not the best way I kind of in favor of a particular way to like uh kind of based on the community interests so one thing that I have been thinking of is that um for like I authored a lot of VIPs um I think the RC uh should generally also apply similar um standards to get final for example like how about having multiple at least

two of the Independent implementations to get final I think it's okay to have something be on drugs and on on review and on last call but I I kind of generally feel that there is really an explosion of the RCs and some of them were kind of really rapid repetitive and hard to put them for debates the worthiness of them and showing that there's uh adoptions or showing their set implementations just like core could help on one side really start the further iterations of of of um of the specification patient like you already have adoptions it's hard for you

to any actually make automated change but also for clients is that their time and energy in invested into building and implementations shows that it's not just support you can easily buy support by and pay on on foreign [Music] Yankees one thing I remember

discussing with the few eib authors actually of ERC category um like having a prototype even if not fully implementation is ready for a proposal to be a standard that could be a good place where we can realize okay this is being implemented and here's the Prototype maybe it can be moved towards a standard if that is something you should consider no I don't think you prototype is sufficient um actually working in deployed a small contract or actually life our clients I think should be kind of I am more leaning towards that level of of clarity

because you can easily create some prototype that doesn't get tested it doesn't get like I I'm not sure if categories for people who contribute that is uh editorially would be able to test just by looking into um look just by looking into that asset file for solidity and it's it's it takes a lot of other things uh for uh the reference orientation to be kind of you actually testable and so seeing a real deployment and a real life one is much stronger much much more solid as a proof of this is being adopted and functional

functioning well that'll be my thought yeah I'm not sure we want adoption as a criteria for publishing an Erp is final um don't worry that that would kind of stop people who may not be technically minded um or or as technically minded from writing an EIP and I think the process should be open to as many people as possible that said I think um maybe the approach that I'd prefer is um actually having a uh like a resource list that we can send to authors and say

like oh you're writing a soul bound token out of D here are 10 people who deal with sold-bound token nfts who you should talk to about your EIP and I think that like that and then some kind of ensuring that we have a reasonable amount of discussion on the discussion thread would be sufficient um I I just think that an actual implementation or even a reference implementation is is making it like too onerous for EIP authors that's a fair point maybe um obviously we can leave it at the description of editor so like when they would like to move but uh having a fair

discussion in discussion to Third and some implementation could be right set of information that we can pass along to new Waters when they are preparing to move their proposal into different status I'm saying I if I heard you you correctly uh you referring to you like you you don't think you want to require it how about we said if you recognize it I am I I hurt you and then I totally agree with you that was me too that as many people contribute to the IV as possible and that's one of the reasons I really want to be flexible on Main Kings links um I do feel that uh there's some way to show strong community supports if

there's any way to show strong community supports adoptions would be a good one like if we didn't say hey can we adopted I can be seen as community support but if you haven't also have multiple implementations that's definitely helped that's definitely helpful um so make it an optional suggestions uh I think that's what we are today right so yeah I don't think we we mentioned that yeah I don't think I think that you can provide this meditation but we don't say okay so I may need to be like uh it's

recommended to even understand reference policy uh that you were advocating if I understand exactly people should actually remove them um the new dimension of adoptions yeah I think we can we can we can put that into context when we talk about 1191 and put an agenda and I think that can be tested our policy discussion can be tested in real yeah if you're reviewing uh right and I think that is the next item

listed here about eap1191 um better I believe this was added by you if you would like to provide some context here yeah so just yeah q191 has been moved to last call since back in 2019. with minimum change or minimal nomadic change um and there's a big list of adoption table which makes me feel um this would there will not be my change in in the future as well but staying in last call for multiple years I think undermines our sense as a community forward lost parties

um so I kind of pose this question to editors should we move it to find out or should we move to stagnance um I gain towards moving to final but there's a strong push from Etheridge author uh we attract more more um so I kind of like to get a gallon of Andrew saying thoughts about how she was like how what their ass injury goes here and what their policy thinking process is um I think it's like our policies that if an author

wants to open a PR and push it through they can otherwise we don't touch it right so just to add some more context here this proposal um was also under discussion about um about uh six months ago and that point also we were stuck at a place where Arthur uh where are the etherges are the requested some changes and the proposal author is not willing to maybe comply with that or is is there only so the other option is if author wants to maybe withdraw the

proposal or someone else wants to come up with a competitive Proposal with whatever changes they are suggesting like I believe it is a a note on backward compatibility so if they would do other proposal will be moved forward otherwise bot will definitely move it into standard status if nothing happens there for a longer time I do know that uh if untouched for six months but we'll do that I think my question is uh given the current status at some of the community has stopped in some of the community being towards and so I came back with compatibility

are they if author ones are they allowed to move this is final given this current status foreign so sorry uh am I oh no I think we can hear you yes I think we will differ there on EAB editors um decision and it looks like the

decision is if there is no pull request by the author uh yeah to move it to the funnel and unless all the issues mentioned in the discussion thread are addressed it should not be moved into the funnel is if I'm reading correct well like I don't think we'll stop it from moving to file um if the author wants to move it to final but like there are a lot of concerns and either like somebody should open any IP that addresses them at some point but yeah I am not sure if this is the resolution

we were hoping to get for this particular item later but uh yeah if you have anything more to add or yeah yeah I agree um I I need to work that author I'll allows you to move it to final um I do also agree that they can also just resolve any from any concerns that would be even better but uh my stands our personal opinion here is that once they get larger number of adoptions um that the ID's hours were enough to uh to finalize

foreign there would be cases of getting it merged to fire all right moving ahead we thank you moving ahead we have item number two which is discussion continued from earlier meeting first one is a EAP

one clarify when to use requests I think we discussed this and Sam Wilson opened a pulled request for that so I believe this is to decide on merging uh they could request number is five six one four any thoughts comments or maybe decision I mean if it hasn't been merged at this point I'm I'm okay with just closing this I mean we have two approvals and and Victor as well I don't think anybody's opposed um I'll merge it unless somebody objects right now here

receive comment from Greg also but it does not seem to be in negative Direction so it should be fine yeah okay I'll just merge this in and the other one also we have already discussed this and I believe uh the eipw bot sorry eapw bot has also been updated according to it the code request number is 5273 uh Matt uh I believe this issue was brought up by you you have to add

anything I'm in this since we were in agreement like the majority were in agreement I am still against it but majority were in agreement so yeah let's go ahead with that yeah I just want to press the green button and so I was gonna make sure that that was okay I'm still against merging it but I can press the green button I mean you have that privilege on GitHub yes good thing I don't have any privilege on that side I mean right now basically Panda pep and I are the only people who are

Pro you win Sam I think Sam also yes okay yeah sorry what kind of pet is like marginally Pro I think the question is whether Sam are against it to the level that Sam wanted to block it or saying just waiting oh I know I I keep I keep saying I'm opposed because I I like no offense to you guys I think it's a dumb idea and I don't think we should do this the problem is that this is already the way that everybody does it and

we're just confused like every week I see another person ask why why is this the case and this week it's the guy who's working on the warm coinbase he says I'm trying to move my EIP last call why is he getting mad at me saying I have to refer to ERC 20 as EA P20 like I'm really tired of seeing all these authors confused and the community getting confused if we flip it we're going to have others confused the other way we will not all the authors understand that we refer to EA erc's erc's why do I have to call this an ERC every author understands this but I

consistently because we've never had a rule that enforces calling an ERC ERC like there's there's never been a place where an author would be confused by that like when we add the ew implementation that forces ERC then we're going to start to see authors confused the other way I'm almost certain we won't because I've almost never seen an ERC referred to as VIP in the like broader context of eifs anytime you see an ERC discussed on another form or thread is always ERC except for this more recent time where eipw has been enforcing EIP I witnessing the same for speaking of uh yeah the author

I would like to add a small Point here people who are referring ERC as ERC um they are generally people who are here in the ecosystem for very long time and that time ERC was having a special case like okay they were not considered to be I don't know people did not even consider it to be a part of EIP standardization but we spent a decent amount of time in making this thing and the good news that I want to share here is new Authors who are documenting eib of ERC category they generally do not have this kind of hesitation and they have a better understanding like if we want to document our EIP and ERC category they have it has to follow the

EIT standardization process because it is a standard track EIP of ERC category so that yeah that is there with older authors but obviously we do not want to lose them they have been a great contract so I mean it's with all of the EA ERC eaps up until four thousand like we're not going to get away from this there's too much too many ERC references out there we can't just change it in the middle of flight now even if you're a new you know ERC author coming in and you're like naming your things EIP you still have to

like live in this world where all the implementation is called erc20 all of the reference is called erc21 721 like no one is calling these things the AP 721 foreign [Music] I didn't catch what the council was

the principle is that you call Erik or EIP based on what people call it if we ignore it if we don't care what outside people are about it then I like Matt and I we we agree on we want to call you guys but if we don't uh agree on that put it to the poll at all uh then we don't make a case but if we if as in this venue everyone agrees that uh we should call your EIP based on what people call them then the next debate is what do people call them right people already jumped into the next everybody but they're going to test out whether the first one is actually the principle is actually uh

agreed upon by the group I mean how like to borrow one of Micah's old arguments um how how long do you expect ethereum to last whatever uh that's what I think is like internet so the small amount of time that we call them ercs versus erps is insignificant in their very very long

term so we should probably try to correct the naming now what was so early that sounds convincing like it's pretty marginal see the fact that in the community calls it ERC and there's no um to see phrases when they own board Apes into random websites like we can't use the community as an indicator of quote like quality decisions so we also shouldn't just like hey invasive policy just because we think it's like marginally better like if

there was you know substantial Improvement of calling it like this like the naming change at least two to the consensus layer and stuff I felt like was a big and important change and it's the thing that we did it but we're seeing people would call it eips rather than ercs that's like much less necessary ah yeah I mean the benefits are mostly just for consistency like internally with an EIP repository right like we don't need the files erc20 we don't like we don't do any of that stuff um repository by naming it you're seeing like working towards that but right now

we're just like upsetting Google okay so like the consensus or the executions facts are coming along and you know they're going to be a thing that might be the best time to revisit this discussion because we're going to be changing everything anyways so if we do it all at once and we fix the naming we we pick whatever system we want because that like once we have the execution layer specifications then there's a very clear difference between an ERC and the IP and I'm totally fine at that point calling them ER seats foreign in the core

do you want to have wireless headphones yeah sorry I'm like losing connection a little bit yeah what have you talked for a second hello I also have a crappy uh at my iPod just be great it's very badly many many years it's so important it's just every once in a while like we get a burst of static from someone I think mine is just like having trouble touch the internet okay yeah so no not a huge deal it's just one dimension um unfortunately no nobody said anything it wasn't you

okay I just respond to one big one comment from Victor Victor generally we speaking of the process of the standardization is not very different we are also looking for implementation for even core proposal though this implementation is going via a client team and similarly the expectation is with the ERC also there should be some kind of implementation or adoption there so maybe uh like in real life there could be a little bit of difference the process of the standardization Remains the Same and that is not only for this ERC category that is for any other standard track eib foreign foreign

we should consider that a factor into our decisions I mean I would love to just move erc's farther and farther away from eip's and honestly I am like getting tired of waiting like I don't know when that's gonna happen but I would love to do it more but I think that like we're just seeing over and over again that people are confused with this we have years used in the wild and now we're like you know calling them in an automated way that that's wrong all right I will get I I will you know withdraw my block um but let's have a discussion on Discord about it and let's get everybody except

um access to weigh in on it because I think even Greg might have an opinion on it and then as long as if I'm the only one that's holding up the process then we'll we'll make the change okay that sounds amazing sorry Victor if you were trying to say something uh your voice went robotic we could not casually then thank you

yeah but it's no matter so maybe you can type it so I I will ultimately definitely client or do you want to press the green button right here or continue discussing on this corner let's discuss on Discord and wants to hear everyone's opinion I I just don't want like if I'm the only one against it I don't want to be the other person blocking it but I also want to make sure that everybody else has a say hey yep thanks I think um the voice of editors count here uh and that's why my voice is not counting here but yeah I'm also against of it and one point I also want to mention in your sorry for coming back on this topic again and again math uh but

here's the thing like when we decide something for core proposals there is a lot of things that is coming up for a community but I believe that as a client developers and people who are in the ALCO day meeting they take this responsibility they own this responsibility to communicate it to the community like what is the right thing to do just like you mentioned about in the case of each two similarly on the ERC side if if the EIP editors are trying to make a decision on that I think it is on them to own this responsibility of communicating the right thing to the community so I don't think we should be feeling bad about

making decisions meeting this is open people can join and share their thoughts yeah but let's continue discussing this and not the discard side I like them the next one is AP bot I believe this is an issue created by math uh for sale review dismissal Loop if someone would like to provide an overview of the issue and where we are at it um yeah I mean I'm just having a Crusades do not have the blind post a bunch of meaningless comments on the yeah he said because there's nothing worse yeah there's like 30 40 comments but they're all just like

opening and closing the TR or sale reviews bugs and the bot whatever and there's gonna see a new one Panda Pop says that this is just due to GitHub I don't know maybe it's true it's just annoying to like I don't know why or how it happens but for some reason like you leave review and the thought we'll just dismiss it sometimes or someone else's interview they'll just dismiss your review and it doesn't look very nice on the um foreign understands the situation my knowledge ends at the command line interface for

Eep W so I'm sorry I wonder how that if you have any thoughts on that I'm not sure if you are completely familiar with the code which is working behind the scene here but since you have been looking into the repository if you may have any thoughts or if you would be willing to maybe look into this issue foreign I believe what is annoying is all that leads

an action of style reviews means and whatever so I'm gonna take a look I I feel positive that we can set the kind of filter on on that One Direction sounds good so maybe you can update it on the issue created by Matia 5 8 6 8 is the issue number so if you have any finding you can probably add here that would be good any other thing on EIP bot site that you would like to share or mention today uh indeed I choose three more issues to

collaborate I'm gonna I'm gonna share in the report in the repo so the the editors can confuse they are working on it and then or not I mean yourself very well thank you for that um the next one here is eaps inside for the month of November um I have not added the format how can we over here but uh I was trying to collect the information with the new eapsinsite.com website that we are working towards it and we do have a tab of the latest Monday uh from that uh report I can say that we have six

proposals which reached to final status in the month of November those proposals are EAP 5732-5679-5528-5375-2612-5484 so it's kind of good progress that we have so many proposals moving into final that means they are not waiting in the pull request form for a longer period to be moved forward we do have received eight drafts and there are four proposals in review status there are three proposals in last call um one is five seven five zero general

extensibility for methods Behavior four five one nine non-fungible token tied to physical asset and the last one is five seven five seven that is process for approving external resources so uh Matt I was wondering like we have this proposal in last call do we want to move it to final or do we want to leave it with the status of living what is the next step here It's the final which one uh the process for approving external resources so we want to have it as a final not a living yeah I think it's final yeah fair enough uh so yeah these are the

three proposals uh on uh last call so people if you have thoughts comments come forward and uh share it either on the discussion toolkit or on the respective request better on discussion to thread we don't want to create any confusion okay um that's all on eits inside um the next item here is EIP editing office hour yesterday we had editing office hour meeting number six recording is updated on ethereum cat photos YouTube and uh this has been going great I have been receiving a lot of positive feedbacks thanks uh Samuelson for having this meeting it has helped a lot of new

Authors uh to understand how they can move forward and people if you have any um questions or any pull requests and anything that you would like to check with editors I believe this is the best meeting where you can have one-to-one interaction so yeah agenda for meeting number seven is already added you can also uh leave your code request number in the agenda so we can include it in the next meetings discussion that's all I think and now we are at the last item which is a review action item from the earlier meeting and

okay so there is one action item for Sam I think he already have worked towards it it is related to EAP 5750 which is at now in the last call so that is taken care of and we have Revisited issues which were pending from the last discussion I think that's all from the items added to the agenda for today's discussion um we have approximately five to seven minutes if anyone has anything to share discuss yeah please um I think the other one that we should discuss is

5874 so it's five eight seven four that's the two external Origins um I think we just need to come up with the weather I just need to come up with a way to um add a Json to a footnote um see if anybody has any suggestions on how to do that please add it to their PR and then um we can merge it um same uh I wonder I it it seems like uh these uh jsons are very highly structured structural I wonder if it's better to be in a separate file for a structural or is that intended like you have a citation file or

something in your assets directory oh no not necessary I thought that the CSL the dash Json file was meant to be used in a in afew as a way to allow uh yes yes and in that way I'm kind of think that um has a strong purpose but uh I felt more in markdown it's very hard to test whether a structural data is legit and has been validated so I wonder what's your thought on making that separate file like exactly like from the from the validation point of view it's not a problem like either you can just grab

that block and and validate it but um from like a human readable perspective I can definitely understand why you can put it into another file um but that would require more work on the Jekyll side to get it to render correctly um but maybe that's worth it I don't know um because like what I have like so the concerned has here is that the indented code block that I'm using uh doesn't render correctly in common mark so um that's a problem sorry I have to just figure out yeah dude putting in a different file is probably a reasonable solution I hadn't really even thought of that cool okay uh so if this is resolved before

the next meeting it's fine I mean if it is much or not uh so if we want to bring it up in the next meeting considering it is still open um we can probably add it to the agenda there okay Sam I also mentioned that I want to propose a few other things into this uh into our first uh accepted uh external Origins such as ethereum Dev po P2P um do you have a father to adding those like I I'm hoping this is probably the easiest time to get um origins in so yeah yeah so I think um just just because I didn't separate the like my PR

into like a um two parts like one about the the rules text and one to add the um the actual Origins so if you could make a PR after this one gets merged I'd appreciate it but um if you also want to make one before just copy the same like introduction text that'd be fine I I'm I'm I love to I don't know where to put that for a particular file so yeah once you either merge this one or you create a separate API I'm going to add uh or the list I want to be allows listed to be in with okay perfect yeah foreign thank you

so I believe that concludes and that is the time we have for today's discussion thank you everyone for joining us today hope to see you in two weeks I'll