EIPIP Meeting 75

Transcript

thank you everyone for joining EAP IP meeting 75 I have shared agenda in the chat we are going to discuss uh open issues and pull requests we will continue some discussions from the past meeting followed by EIP insight and EIP editing office hour updates but before we get into the agenda item we are joined by um one new EAP editor who has recently joined the team so I would open the floor for him to provide an introduction if that's okay

thank you Buddha so basically I am a CL that I've involved with load star primarily and as well as I also work for ethereum.js so I have a little bit I have deeper understanding of Cl clients and I'm getting a little bit more understanding of the Year client so I'm sort of able to see a little bit more picture of the entire landscape and hopefully I can contribute awesome we're happy to have you likewise all right uh so we can go ahead and

start with the the discussion and issues listed on the agenda we have collected it from the EAP GitHub repository as well as from the Discord channel uh the points for discussion number one here is allow including both an email and a GitHub username I think this was proposed by Panda peep so Panda if you would like to explain and we can collect editors feedback on this one I mean there was someone that tried to do it it seems like a somewhat reasonable request so I just created an issue for it all right in that case if anyone has any objection if not then the only issue would be that it would that all the CI

that parses the author field would have to be updated but that shouldn't be too hard to update your reg access yeah just a little bit of work in upw not too bad so if we want to do it we can um so what's the advantage of doing it just makes it like easier well so that there could be a link to the authentication which is GitHub and also a link for contact which is email right I mean the current recommendation is just to repeat uh from your example here my name once with email and once with GitHub so I guess the advantage is what you would have a single author

entry with both as opposed to two yeah it shows up in the meta twice yeah and so the meta tags and um well I guess just the meta tags um and RSS could benefit from it being one author item correct okay yeah I guess I'm in favor of this um we can make that change seems minor enough that we can probably merge it without uh do it without my client here yeah yeah I don't think there's any reason why one would object we are the two people that would be most impacted by it and we just said yes

um do you want to do a username then email email then username or both uh what is the order the eip1 has it in right now I think we are adding email first one sure yeah sure that works yeah we can keep it in the order that's specified here okay I'll make the changes to Eep w ow um that would be awesome and it is going to also make my life easier because I sometimes have hard time reaching out to authors with just the GitHub name uh so this would be optional right so yeah so right now yeah okay very well and

has any different thought or if fine we can move on with the next item okay I think the next item is also proposed by Panda pip it is about replace requires with a bibliography section I see there are some comment by Sam Panda or Sam anyone would like to provide overview which issue is this again 6509 oh yeah that um basically in order to get listed on Google Scholar you need to have a proper bibliography and I think what what we can do pretty easily without much effort

especially now that we're switching to the new build system or hopefully we'll end up switching to the new build system uh we we can then have a new entry in the Preamble that basically it's like requires in fact it could literally be a yaml list of Erp names but that also accepts external Banks such as dois etc etc etc and then it would generate a bibliography at the bottom before the uh before uh right after the uh or perhaps before the copyright section yes I think generating a bibliography is

um the correct thing to do I mean we need to do it anyways because of the CSL Jason stuff um my only complaint here is I don't think we should get rid of requires um because it's like 90 of references are going to be uh to other eips I'm suggesting we use a Wiki data like thing for eips yeah lets you just use a string identifier in fact it could be like literally EIP colon Erp number here okay and then for like uh dois and other stuff it would be like a full Json thing and then for doing I'm pretty sure for Di's you can just do DOI equivalent okay

yeah and for Wicked data Wiki WD colon Wiki data yes I guess for me if we want to go ahead with this I'd like to see a couple examples of what a preamble would look like following this format uh okay yeah just throw them in the issue and we can we can talk about them all right I'm not sure I'll think of earlier we were using a bibliograph before at least for EIP one I don't know if anyone has any background on this okay never mind we can go ahead with the present proposal so um I think the suggestion here is to add the specs

there in the issue section and it would be discussed further sounds about right thank you moving on the third item here that is also proposed by Panda Peep and it is about draft background image to draft EIP uh the issue number is 6479 I think that we are flying through this I think the consensus was that yes this is fine yep yeah I think it's just take like draft or last call or whatever and just make a watermark out of it all right I thought that it is important

to make a mention in this meeting because this is kind of you know a public awareness as well also if people aren't following issues um diligently then they would be at least aware of it and if there are any concern they can definitely go back and add their thoughts in the issue that we are discussing here okay uh moving on to the next one is discus policy to add a champion or co-authors to an EIP so this item has been added from ech Discord so uh latest discussion on adding Champion EIP editors and others other users have already shared their thought um and we do have some text added in eip1

defining the role of champion however it will be a good idea to revisit and possibly make changes if needed so yeah if any editor would like to share thoughts and share again like what should be the criteria for adding as a champion or as a water here I really want the adoptable thing to get merged likes it's like the easiest thing ever it's a flag others can say yeah if it exaggerates then anyone can just take it off up where we left it off with and if authors don't want it they can just say no we'd rather it just stay segment that was the idea initially that's

other resist that they wanted to be stagnant the alternative is someone can start a new PR with almost a similar proposal and mention it that it is you know kind of unstagnanting that particular proposal there but I was specifically suggesting adding a preamble entry so that the EIP number gets kept oh Well yeah if you want to pull out any um EIP from statement status I'm just sharing the information that I am carrying from the past the idea was it should include author's permission uh to keep the number if they are willing to

understand it then only the same number will be kept on the proposal otherwise if author decides not to unstagnant that and someone else decide to come up uh with a new proposal with the entire like a copying pasting the entire content the EIP number would not be the same it has to be a new one that's what I'm suggesting the adoptable field would literally be authors saying basically giving their approval in advance of its stagnating like we give our approval to whoever wants to pick this up it's not something that's by default it requires an authority authors to give approval but it's just that the

approval is given at the beginning of the process when the authors are reachable rather than at the end of the process where the authors will are clearly unreachable since the proposals of disagnant yeah that make a lot of sense so do we want to add any field there or any specific comment what is the proposal so I think that was fairly against this one so I don't think we can discuss it without him here yeah okay we can bend it um I wonder if anyone else has any thoughts on it so definitely We're not gonna make any decision in absence of math so uh we can at least collect thoughts if people have any different um I don't have a problem with what you

were doing um Panda like adding yourself as an author to Eeps that you want to see pushed through like as long as you can yeah I think that uses existing process but which requires author approval oh yeah yeah we're just like Matt was complaining about it and I I don't see a problem with it I think it's fine if you want to do that especially considering I'm straight up rewriting all the EIP like taking taking their paragraph basically removing all of it and inserting a new one yes please go ahead oh yeah I was just saying like yeah I think what you're

doing is fine um I I think that is the best we can do today without adoptable and I don't think we need to but I don't think we can discuss adoptable without Matt so all right fair enough I'm gonna bring this in the next meeting I hope Matt joins then and um yeah now we can move on to the next item which is kind of information it's more of an announcement that probably invite a Viewpoint though it is really not that of a concern of community at large because mainly it is related to Dev worker which is going behind the scene

and the one who is doing most of the thing has proposed this so it is about moving away from Jekyll um as many of us know that the present EIP tooling requires Ruby and at present we don't have much contributors of Ruby or Ruby expert to support the infrastructure so Pana Peep and EIP editors um who are mainly maintaining this has a suggestion to move out of this so Panda if you would like to give more background to this and what where we are at the at the moment so I've got a completely working website we could switch literally right now so I'm gonna put the link in the chat to my

so this is using the entire workflow so the GitHub the GitHub actions thing that that will automatically build it and I have it sending it to this website right now um since it's on my Fork of the repo so the things that would need to be happen is first the pr that adds this need needs to be merged and then secondly uh secondly in the settings GitHub Pages needs to be switched to uh the action based workflow instead of the branch based works though and then this and then the and then the URL needs to be set to vips.etherium.org but as you can see

I have a working website here I think it looks pretty good so far all the feedback I've received after says it looks pretty good um it has all the features of the previous website plus this nice little search feature I added um it's in JavaScript script so we can add so and in fact the actual code will be on the eip's repository so changes to the website can be even managed by straight up using the EIP review bot um additionally actually I think that's it

well I mean obviously it's JavaScript and we have at the very least I know JavaScript and I also know Sam knows a little bit of JavaScript I can either confirm nor deny that that is a recently done by an editor who basically worked in ethereum JavaScript so I'm hoping that we would have a bit more extended support on JavaScript side yeah guys I can support wherever I can okay great

so um can you please uh once again um like summarize what is uh needed here do we need uh consensus on switching from all the editors and yeah I think we just need consensus from all the editors so this is a radar okay awesome I was just about to ask that do we have a PR so the pr number here is six five one eight I don't see Matt on the call I don't see Victor on the call so we'll keep it open for some time and let's try to collect more support there yeah no this looks amazing besides not being able to click on the search bar oh

I was able to click on it that time it's really weird um but yeah I know it's great like good job on this thank you really nice looking website thank you so much all right so now that we have the pull request as well let's move on to the next item which is uh agenda request okay so this is uh from the issue that was added on eipip GitHub repository and uh the number here is 215. so the proposal requested this

issue to be considered for this call but I know that uh it was being blocked by one of the editor yeah and I think he would like to mention Panda why uh you think it should be blocked at the present state uh which issue number is this again what is the issue number again all right it's in chat so 6483 is the

pull request and uh e-i-p-i-p215 is wrong repository yeah it's the filter again search one that four percent uh the only thing I was blocking was that I would like to have uh seen that split into two different PRS Additionally the website rewrite just does all of that already maybe the the correct approach here is to ask full descent to take a look at your rewrite and um see if it solves the same problems and just explicitly ask them to take a look

at it um that would probably solve any kind of like um I don't know frustration with the process yeah so I would just pick him and be like hey you know what do you think like we've been working on a rewrite over here um would love to get your feedback on it see if it solves the same problems and we'll just see what happens after that I mean I can even do that if you want I would definitely uh like it's like you to at least review the website yes I know hey I've taken a look I've left comments and I've changed up the files since then and also modified about 550 EIP now I'll I will take another look

don't worry and to address the kind of frustration that can bring to anyone with the present process or with the dynamic process that we are trying to follow here is um we have uh we are sharing this feedback form for EIP authors that is our next agenda item uh so far we have received responses from only ERC category authors so please uh core interface networking informational or meta authors if if you have documented a proposal for ethereum repository consider responding to the survey this

is um just a feedback form less than five question I believe uh it is just to collect your present thought in the process and also if you have any suggestions that we could probably bring up in future eipa meeting for consideration of changes I'm not sure that networking eips are a thing anymore I know I know they're technically still a thing but it is I can say it for one for sure that is clwp okay fair enough but I'm not sure who's reviewing that yeah mostly because that is neither a part of um

um upgrade and also that is not a like very popular ERC category but they are still into existence at least for now but yeah uh we do have common authors authors who are contributing into core EIP are generally authors who are contributing to networking and interface category of proposals and apart from that we do have a lot of ERC authors so please uh take out time less than two minutes it would take and respond to this let us know what you think is not right thing for you and you would like that to be changed okay um moving on to item number two that is

discussion continued from the earlier meetings um the first one here is adding CL devs as EAP editor and a new ERC editor um we met our new core EIP editor we are recently joined by another ERC editor uh who is Victor um people have seen him raving ERC category proposals on EIP repository for over six months I believe now so yeah he is very much familiar with the process but unfortunately he is not here um today uh had some power issues or so but we hope to have him in future meeting thank you both of you for joining us and helping out with the EIP

process um the next item listed here is thoughts on Asia Pacific APAC friendly times on infrequent recurring period yeah any thoughts if people may have on this one I'm down like I was so I probably probably wouldn't even notice yeah I I don't think we get 100 participation on this call anyways so I think it'd be totally fine to add another one that uh is at a different time slot we might get different editors showing up so I mean it is I feel like it is useful or

helpful when people know that what time that meeting is going to happen so instead of having having it at different time can we try to move it uh um like to the Asia Pacific obviously friendly time zone which is not that bad and that could be like the time when we have other client meetings will that be a good idea obviously it depends on what time itself is uh that is 1400 UTC I'm so sorry so my question here is like does 1400 UTC sounds like a perfect timing because

uh right yeah the same day just the time at 1400 UTC so um you know most of the CL Dev the Elder meeting most of them are at 1400 UTC and we know that we have participants throughout the globe so they are participating at that time didn't we used to have it at that time and then we moved it so yes this is so that would be 9 A.M Eastern that is right and that would be 9 A.M for for a couple of weeks only uh just a reminder like March is right there I think that would be fine for me and I ended up being a few minutes late

but I don't think that will derail things too much I mean I'm okay moving around we can we can try it if it doesn't work for us or we get less less participation we can move it back so and if maybe we can also do the rotation rotation is something that I'm a little carry off but uh I don't know because you know when we when we go out and spread the message that join the meeting we generally try to give them a sense of time like when we are doing it earlier it was 1500 UTC since we started then we moved to 14 then uh people suggested

1600 and here we are going back again to 1400 which I think is a good idea but when it comes to rotation what is the alternate time suggested here 1400 UTC is fine awesome because that would also work for uh um the newly joined editor because he is also from Asia Pacific and what about you Craig yeah awesome Greg is that fine with you too I just wanted to come up with a

yeah no problem awesome thank you uh then I'm gonna add that in the summary of meeting today so we are trying to switch it to 1400 UTC and I'll make the changes on protocol calendars so people who aren't in available in this meeting today may be able to notice it through the calendar wait wait wait uh 1400 that's 10 a.m Eastern it's going to 9am right now it is nine but it's going to be 10 a.m in like a week's time or so because we are close to March so we are going to have DST gone call not going to be

the people is so UTC does not care about daylight savings okay yeah good okay that'll be completely fine I will not actually be late then I'm confused so right now eipip is after the eof implementers call we want to move it to an hour before EOS yeah okay and then they'll both shift the same amount when during daylight savings that's fine perfect awesome yeah okay yeah please go ahead

nothing all right uh so I will try to have the next meeting at 1400 UTC I'll try to make announcement as much as possible update the calendar and also update the agenda for the next meeting moving on to the next item here that is a it's a pull request number that is 6269 for pull evm equivalence so I think the issue here comes down to what building meta versus information will mean because I interpret meta to be literally basically definitions

like because in my opinion you can't ignore a definition you have to choose one but at the same time you're not beholden to any specific definition so it could be informational basically we need to have a fine line between meta and informational so a meta EIP would be something like in this specific instance If This Were A meta EIP it would be an EIP changing the process to not allow people to use this term um unless it conform conforms with the definition so it's a meta EIP describing the EIP process um informational is just here is a definition for a term feel free to use it if you want vip1 never says that meta actually has to deal with the EIP

process itself that's what I'm saying things you can't ignore yeah in this case it would effectively be a change to the the list of things editors have to check oh then absolutely it should be informational but like then at the same time wouldn't that mean that the deprecated self-destruct tip should also be information or not matter yes I agree okay then should we change that no it's final so yeah I mean it's going it's already in the announcement both now irregular State cases are things that editors can do yeah no I'd rather not I don't I don't think it's a problem that it's meta

um I think the another Advantage with that being in meta right now could be like you know we are going to see a lot of changes coming up with respect to self-destruct this is just an announcement I agree that it looks more like an informational at this point of time but there are chances that it could serve as a matter of and we should see some you know some more proposals coming down the line for the support of that absolutely I I think the base issue with this EIP is that I don't think we should put definitions in the Eeps repository unless they're also associated with a technical specification I think that what you're describing is exactly what informational is is now

what I believe the informational eips were meant to be right and I I don't think we should have them why not is it where where would they be standardized they wouldn't be it's not something that needs to be standardized like the Eeps repository is not a dictionary it's not an encyclopedia it's a list of standards and changes to improve ethereum right like that's that's in the name what is the standard if it's not a definition for something yes but it's not a technical definite like it's not a standard for a like a piece of technology you can build a a proposal it's just exactly here's it is a definition for a piece of technology

you can build it is but it's not it's a definition for a term that you can use to describe a particular type of Technology same thing with a lot of erc's not you can think of token as perhaps an adjective that can describe the smart contract there's right but there's no definition for a token we we have a like Eep 20 defines a standard that uses the word token but we don't have a separate informational EIP that just defines the word token okay fair enough like I I would have no problem if you know uh forget it was a full descent that was doing this one um I don't remember who was doing this

one but if if they were making like a standard that's like this is you know the interfaces you need to Define this is the architecture for an L2 that is fully evm equivalent this is the definition of fully evm equivalent and that would be a perfect place to Define it but on its own without some kind of a technical system that it's describing it's it's pointless to standardize the term because like the reason they're doing this as far as I can tell is so that marketing teams can point to it and be like hey my evm is fully evm equivalent according to this particular EIP and like that's just going to turn into like a war that I don't want to touch with the EIP process I don't want to get into like is this you know L2 actually fully evm equivalent or not

yeah okay how about it if it describes something that was eat X evm compliant or something like that like specific head and each number on the term I mean I I guess if you if you were to do that then you could say like okay reading that Eep does it provide enough information for an implementer to create a like an interoperable implementation of a fully evm equivalent lab L2 with the links it provides yes it does yeah then maybe okay

it's just defining terms is not something I want to get into but if it's if it has enough technical information that you could implement it then maybe I could be convinced it links to the things that actually need to be satisfied in order for the term to apply okay well maybe I'll give I'll give it another read um yeah maybe it deserves more of a chance than I've been giving it and maybe uh just to uh I think if I'm getting it to write on Sam's Point even I would be more happy to have it added when it is supported by one of the or technical specification I

mean not a technical specification in general but I meant by like proposal which is like um 29.82 the serenity phase zero when it went into the informational category it was blocked in the beginning for so many reasons I don't want to get there but it actually defines many things that people would be interested to learn about and there are proposals which are using these terms and this proposal is ultimately getting referred to um if the present Proposal with a 6269 uh the full evium equivalence contains this kind of element then it would make more sense to have it added it in the ethereum repository rather than a

promotional tool for any other project to say that we are fully evm equivalent okay so um we do have this um item added in the pull request form that is 6269 I think we'll try to say if we get any uh consensus on the pull request and if it is merged if not then we'll bring it up in the next meeting sounds good

all right moving ahead the next one is a issue number is five six eight two new contract interface and EIP should require to include a privacy consideration section again I think we should just replace it with a consideration consideration section and privacy and security subsections okay all right I think we had some discussion in the last meeting it's because we did not have any consensus on this it was supposed to be brought back here again yeah I mean I'm in favor of including privacy

considerations I just think that if we are going to have a bunch of consideration sections then they should be organized into considerations in the different types of considerations okay if I get it right and if I'm not missing this point I think Matt was not in favor of this proposal and we did not have enough time to discuss it last time I'm also not in favor of it uh okay so we have a tie here I can see uh um Victor left some comment uh

he seems to be in favor of it with certain options and Matt is unavailable and given sensitive in favor so what like to be clear I think including privacy like privacy concerns in the EIP is great I just don't think they necessitate or deserve their own section like if somebody wants their subsection no yeah well yeah of course like if like right now that's not allowed so why isn't privacy a subsection of security maybe I'm not understanding that part because you can have something that's

not a security issue that but that is that leaks privacy right then that makes it it's meant not necessary is not necessary like if somehow like take injecting windows ethereum it's not a suggestion it's not it's not a security issue to do that but it allows for fingerprinting right and then by being fingerprinted that's a security issue like all privacy issues are Subs like a subset of security sorry all privacy issues are in like a subsection of security issues like there I don't think there are any privacy issues that aren't security issues

nonetheless I think we can definitely distinguish them into two categories based on the leads information about the user and can be used and does not leak information about the user like I think that that is definitely something that could be like done yeah I don't know I guess if this is going to keep coming up over and over again on the eipip meetings uh I guess I'd be okay with a

optional privacy consideration section at the same level as security considerations um if people want to include it what do you think of making a subsection well I I just don't like having a section called considerations because I know people are going to abuse the out of it so well except I there are good reasons to abuse it like if it's like hey you shouldn't use this effects y z that that's not related to security or privacy then that deserves to be in there oh no no I know but what what people are actually going to do is they're going to take like motivation content and put it in there they're going to take rationale

content and they're going to put it in there like it's people are just going to put in the wrong section like they already do and it's just gonna be worse um maybe if we update the EIP template to yeah I like if it's if it's clear what the section is about I think that that issue can be mitigated um maybe like maybe it's something like implementation considerations I feel like that's what it used to be called a long time ago but I might be wrong or at least that this discussions come up before

um our privacy considerations really implementation well yeah I mean there might be considerations that aren't necessarily for implementers they might be on the user side or or something like that I don't know when using the CIP okay I think here are two things we are trying to discuss when we are trying to move an EAP into uh like you know final status we are trying to provide a standard that could be used by any other application developer or project a developer to have it uh implemented so the implementation or the consideration that we should like to have it over there should be for the implementers only not for the end users for end users

the project could be providing the take consideration or any other consideration that they may have for implementers if there are any consideration they are generally provided in security concentration if that is related to security um otherwise uh like privacy concentration um they might want to uh give it a um you know thought on how many that kind of proposals do we receive and do we really need to have privacy consideration a room in the EIP Repository I don't think we do but that's just me I think it would be

okay at the very least I would be in favor of adding an OP I I if if the compromise is adding an optional second level privacy consideration section then yeah we can go ahead and do it I'm open not to bring it up again because we have brought it for two weeks uh I mean like two meetings consecutively but uh um maybe we can take it from the pull request and try to collect more consensus from editors and people over there because this is something which is sounding

um like we don't have a consensus and we do have to do additional editors missing on the meeting is that okay I think I think it is definitely the case that we do not have consensus on that bus entry to collect more feedback and we'll see what is the final decision and go there moving on to the um next sub item which is a change requested for final eibs though we know that we do not encourage making any changes to any eaps which are into final status uh the way

are still getting some request I have added two pull requests here the first one is six three three zero which is to update 5192 and the other one is six three one four so yeah let's uh talk about 6330 what do people think I mean it doesn't well it changes the spec but it doesn't like significantly change this back there are some wording things and it changes the title I'm I don't want to encourage it but this seems like a really minor change to me it's a final EIP it shouldn't

change if it helps it is coming from the author I think it makes sense for clarity purposes to try to get rid of the word soulbound the argument here is that these aren't really soul-bound tokens or the argument here is that literally the soul bound doesn't make case to make much sense to use anymore because people have stopped using the term foreign I just noticed this my back so here the

proposal is to change the name of the proposal all together when it turned out to be a funnel proposal yeah exactly oh that's not a good idea yeah I think like I said I think this is final we shouldn't change it and the thing I'm told about is the fact that it would actually change the citation so it would actually change the name and basically any citations to it would disappear but I don't think people cite eips anyway not yet um yeah I don't know like I said I this isn't a soul-bound nft as far as

I'm like my understanding of soulbound goes and um but it's also finally IP so I I personally I just think it's it's final it doesn't change we move on yeah I'd say as per the current criteria it probably shouldn't be merged but at the same time I think that the current criteria are flawed this is clearly a backwards compatible change like this is changing only the name and removing the word soulbound I don't think that it's gonna be liked

by many other people that after an EIP getting into final status we are changing the name because that is something which is highly noticeable and it may not leave a good impression that if that was not supposed to be a soul bound we should not have allowed it to move to the final status in the first place so I think the best that's fair enough but at the same time I as as previously mentioned I feel like final uh status altogether should be there to demonstrate how how much the standard can change

animal and I also would like standards to be able to change a little bit more while they're in final not not the actual like specification that should never change but clarification should always be something that can be done yeah had it been some sentences that is changing in the uh you know documentation could have been fine but changing the title altogether is not gonna reflect good on us as my heart I mean like if there are implementers for this particular eib there could be one or two or a d Max five projects implementing this so we are restricting a damage for five projects instead of

like re-announcing to the world that this is something that is possible even after an EIP getting into final status they can request for the name change there the final is final if there's an error there can be an Errata otherwise there's no reason to touch it does this fall under errata I don't know okay well I think that's what we're discussing it doesn't sound like it does but the author is not present I don't think so no no the author is the one making the

change though we we can discuss it with the author on on the on the pr or elsewhere sounds good okay um we can probably uh discuss about the next PR which is PR number six three one four and it is to uh request changes to one of the most popular EIP eib 1559 and it's about remove empty test cases so yeah there is literally a test cases section with the word to do in it

Capital all caps that's literally the uh that's literally the content of the test cases section uh yeah one five five nine so I think what happened is that Cascades are mandatory for core eibs and they just forgot to do them but I would argue that it's probably worth just removing them just because it looks bad to have to do written on it I mean we cannot deny that there were cases because we are talking about eip1559 however we would not have added the link because the at that time there

was this policy of not adding link to outside the repository so yeah I'm kind of okay I don't know what other people think of removing this to-do section this seems like enough it's a rather right this is an error there should not be a to-do in a final EIP if we can link to the actual tests that'd be better but I'm also okay with removing that but now we should just remove it yeah I'm fine with that okay so uh do we need any author's permission here I don't think so okay so we are agreeing to merge six three

one four all right uh we have five minutes more um we already have yeah please go ahead I guess we could discuss uh uh seven four seven twelve uh final change oh I'm sorry uh it is not listed can you please help us with the number pull request number let's see five four five seven this thing so this was one where I think oh and it said this this PR is update so what

happened was that uh 712 uh due to an Erp W bug got actually merged with two specification sections without anyone knowing uh merged as final with no with two specification sections that are mutually incompatible wait I thought we merged the one that fixed that or did we not oh God we didn't so what is the proposal here are we uh

suggesting to merge it because I heard uh you're mentioning it's out of date yeah if the current pull request good to be merged or should we just simply close it I'm just gonna I'm just gonna actually manually go into the pr and fix it for the authors of this PR um if I can find where the second specification section begins there we are okay so now I believe it is up to date so there were two errors one there were

two specification sections the that should not have been that there were there's an additional specification section that shouldn't have been there and some stuff left over from the forking of the original uh ethereum design messages at uip I argue that this is backwards compatible because no there's no thing nothing that could have claimed to implement 712 could have because there's nothing that could have implemented it so it's backwards compatible because there is nothing to be backwards compatible with so I don't think backwards compatibility is

the gold standard for this like if someone were to write uh e1559 let's say and completely had the wrong calculation in it from what all the clients made the Eep would have to be updated to match what the clients implemented um it's not backwards compatibility is nice and but it is not necessary so we should just take whatever the correct 712 is and put it in there I believe I have updated that PR to do the correct 7110 all right and that was uh five four five seven yes all right so all the needs is author

approval now right uh it has been needing author approval for months now I think it is safe to say that all the authors have gone AWOL all right so I don't know what to do in that it's it's it's uh uh uh just a minute I think I have some background here uh there was one cat heard us William Schwab who has been working with ramco for some time to push this proposal towards the final status I think um uh we can probably have uh reached out to him to reach to Remco to uh like if we need any kind of permission there because uh I think this proposal

um was in stagnant for a very long time I mean if that's okay otherwise if people agree that it should be merged right away I'm open to that as well I'm not a hard stopper here actually I from the looks of it it looks like there's even some more stuff that needs changing uh yeah this is it's hard to it's hard to know what's correct here and what's not correct because I'm seeing some I'm still seeing even though I removed the duplicate specification section I'm still seeing some ethereum signed message stuff which should not be in there I think the either one would be like to

close this one and the changes that you think is and bought and then should be getting in come up with a new proposal or new pull request for that okay uh we are at times so I think um this could be um like uh left here we can leave this uh conversation and we'll try to look into this pull request number five four five seven maybe it can be reviewed again and see if we get response from

authors and if uh a writers are confident that this is in good shape to be merged we'll take it from there sounds good okay yep thank you all right um we are at a time I just quickly wanted to uh share about the month's update for eips inside link is added to the agenda we have vipsinsite.com February 20023 this provides us the information with all the proposals which we have moved from one status to another statuses and in the month of February we have

received three final eips and a lot more changes going on in the EAP repositories you uh you may check out the link added here and we have added recording to EIP editing office hour people who are interested in learning about EIP documentation process or or if they have any question and related to their pull requests they are always invited to join this so they can have a conversation directly with the EAP editor and we will try to help more proposal towards the Final Destination having said that that's all include from the agenda item for today we hope to see

everyone in two weeks but the meeting time would be at 1400 UTC and the date would be March 8 2023. thank you everyone for joining us today have a good one everyone take care yeah all right