EIPIP Meeting 94

Transcript

welcome to EIP I meeting 94 this is issue number 292 on ethereum cat herders GitHub repository so we have items uh to be discussed which are some of them are open issues and PLL request a handful of open call for inputs that we would like to know where we are on that and then we will take a look at eips Insight plus ercs ins side for the month of November a few updates from EIP editing office hour and we'll take a look at review action items from the earlier meeting so um starting with the first one discuss open issues PRS and other

topics I believe the burning topic here is the update on EIP ERC repost split and we are joined by gav so Gavin if you have any update on that to be shared please feel free yep okay so recently upgraded my SSD and also switched from winners to Linux so I am still kind of getting my new development environment set up but I will be able to resume work on the toolings soon that is awesome I believe a few of the authors have uh uh shared some concern with respect to HTML proofer uh

is it resolved where we are on that uh so the issues have primarily been that users are doing the or rather authors are doing the expected thing and updating their links to the new files the problem is they can't do that yet because the tooling isn't smart enough to be able to rewrite the links yet and this is also because the system we have currently is a very temporary solution and we are planning on kind of taking out all the website code from both of the both of the projects and putting it in the new

repository uh but yeah to all EIP or ER well specifically to all ERC authors uh don't update your links use EIP hyphen EIP number or ERC number even for ERC even for erc's and I guess also for EIP authors if you're linking to an ERC use EIP number that is helpful I believe there were some authors with this kind of concern in yesterday's EIP editing office hour so it's a good piece of advice that all ERC authors even if you are creating a new pull request at ERC

repository please keep uh the name of the file which you are refering within your document as EIP Dash whatever the number was very well I see there is yes pleas also your the link Checker will complain so and unfortunately that's one that gets kind of priority for check annotations because HTML doesn't have check annotations so I'm considering just remove Ming the link or disabling the link check C for the time being because I think it might be misleading authors right I believe as of now on ERC

repository Issue Number Eight is kind of guideline for ERC authors to follow and make their PRS on the ERC repository do you believe if we add any additional information with respect to uh this HTML proofer or what they are supposed to do specifically here would be helpful if it is not there okay we should absolutely do that okay you mind taking care of that uh I cannot it's a like client uh issue oh wait no I can edit other people's issues sorry yes I can do that okay perfect I hope this temporary solution will be answering the burning question

from ERC authors as of now but in case you guys feel any other question feel free to U drop by ethereum caters Discord Channel we have EIP editors Channel especially for all these sort of discussion if you have any questions there next uh item here is web page rendering for EIP and ERC I believe we could not get to any solution last time in your absence well light client was on the call and he was in the favor of having a separate web page but unfortunately you weren't there sorry I'm referring to gav here gav wasn't there so we were not able to make any decision wondering again if you have any

new stance that you would like to share where we are on that sorry I was kind of busy editing the uh the issue I'm repeating my question is with respect to web page rendering for EIP and ERC do we consider two different pages or is it going to be the one page so I think it's probably going to be still be one website but with two very different like basically I my plan is one website but each repository gets to control how it its portion of the website is kind of rendered and all that stuff so the eips

can have EIP specific dat information on their Pages like for like B basically I want it all to be one website so that users don't have to worry about which website do I go on to and also so that IPS can all kind of just share one place uh but I also agree that each kind of I guess it's working groups now each working group kind of should get to decide what stuff is displayed on the E IP page and what kind of stuff is searchable it allows ANP to be searched for right um so I believe we are going

to maybe talk about the working group if this is something that we should decide after getting Clarity on working group perhaps we'll come back at it and I don't see M on the call today so um yeah it would be fine when we have some more clarity and then we come back to that issue very well uh the next topic is um topic group and I see Sam joining the call Sam if you would like to maybe share a high level structure of topic group or working group or what is the plan to take it Forward uh sure um so I'm kind of working on like a prototype of how I

think it should work uh essentially there's one repo per group and uh yeah that's pretty much the only change it looks very similar to the ERC EIP split um but I'm going to get all the tooling working ahead of time and then um I'll shop it around for people's approval um nothing's hugely different from today um biggest changes are removing the EIP Das prefix and the ERC - prefix so it's just number numbers um I've already sent it to Panda pip and to like client um and yeah I'll I'll keep you updated as I uh as I work

on that very well thank you for the update Sam so there was this question with respect to EAP editors and Associates about uh who are Associates or is the role associate defined anywhere just to make it clear editor associate is not a formal position and it is not listed on EIP 1 this is just to indicate whoever are interested in contributing as reviewer and may aspire to become an EIP ERC editor one day and this is also being used as a tag on EC Discord so uh they get the required permission and if editors have to make

any announcement which may engage uh uh Associates as well like they should be informed they can perhaps make use of it and the sheet that we have added here on the agenda is uh just an official documentation of who all are available here so we get a good hang of how many uh people are with us for this purpose and people may be able to tag if they know whom to be tagged here for reviewing of their respective eips and erc's um with that perhaps we can move on to the call for input I see five inputs call for inputs are there out of which

one should be closed um Sam if you would like to maybe take on each one of them yeah I can run through these um just open all these up [Music] here all right so starting off with The Accidental function in erc223 three um right now it looks like everybody's who's commented is in favor of this uh this ends tomorrow um and this will merge poor request removing an accidential function uh then we have ratify editors listed in ep one uh the deadline for this one is November 19th and this is basically to formally welcome uh vender

and Ben as um or Victor sorry as um uh official editors so there's no more question about that um so far it looks like we have two votes in favor uh then we have remove external implementations from erc20 the deadline is November 19th um there's been quite a bit of discussion on here um my preferred option I think at this point would be to move the reference implementations into the assets directory and otherwise make no change um well that's that might be a bit tricky with I'm I'm not sure I'm pretty sure one of them is unlicensed uh they're they're both in

repositories with an MIT license file at that commit oh okay good then there's no issue with that well I mean except for the fact that I would rather everything in the eips OR RC's repository be cc0 but I guess that's hard to do even when even ipw isn't CC Z yeah um so would you be okay with um moving them in or that would be that would be I would that would be vastly preferable to what we have right now all right okay um yeah okay so I'll make a note uh for

that uh so we have the withdraw EP 719 99 um and we have two votes in favor of that and that ended yesterday so that looks like we will be merging that pull request uh we have November 30th deadline for add security consideration to ERC 1271 um so if anybody listening can go and leave your comments on there um it's kind of an important one and then we have an informational EIP that is created describing apparent flaws in the erc20 standard again um kind of an important one to leave comments on so please go and do so uh and yeah I think that's it for

calls for input awesome I am confident that this will help us get to a decision sooner rather than later and uh with the deadline we must have a decision by the end of the deadline so yeah this is helpful thank you Sam well the deadline very specifically anyone that hasn't responded by them basically then doesn't get to have a say that's what the deadline means ideally everything should be a we should have input from everyone by the deadlines but that has well even Alex just I'm pretty sure Alex actually hasn't responded to I

think there's one or two that he's responded to but yeah so far that's not what the deadline has turned out to me whenever we are creating this call for input I know uh the link is always shared on respective Discord for editors to follow and maybe leave a comment whenever they get a chance do we think if we add them in in the call for input may be helpful to grab their attention sooner rather than later um I think that right now the problem is just that Alex is currently working on

other stuff and well for example I'm also working on other stuff specifically getting my development environment ready on this new operating system uh but that also means that oftentimes there's a few like there's a few of us that just aren't keeping track of everything that's going on so I'm wondering if it might make sense to reduce the amount of time needed before the B basically I'm wondering if it might make sense to reduce the four weeks down to three weeks oh just like making them faster um

making them slightly faster I I like the the long period period um and I kind of picked it long to encourage people to remove inactive editors but that that didn't go very well so yeah I think this four-week period also give us the opportunity of that particular call for input being mentioned at least twice in EIP IP meeting that is true um The Annoying Thing right now is that this basically anytime a anytime a somewhat major decision needs to get made it the current system means that it

has that it can't actually happen on a single call if if if it's like if there is a clear consensus because we actually have to well I guess we don't have to I guess Sam can just decide okay consensus has been met um but like like no there's a line that says every editor is entitled to be heard before the cons the keeper um makes the determination except that hasn't happened happened for several of them now because Alex just hasn't shown up yeah yeah it's so it goes like you have 30 days and you can't make the decision until everybody's expressed their

opinion and then after that it's the the Quorum is reduced to the people who have responded oh yeah that I remember now yeah no I I made it to be very very annoying um because I I think it would be much better if everybody would answer as soon as the call for input went went up or as soon as we were on the call but you know that's not how this works so yeah I think I it really does seem like there should probably be some system well I guess we do have a system that makes lots of smaller changes faster and that's uh like like I guess eips are just an example of that but like we I think we

need kind of more Pathways to make more minor changes faster yeah I think that's fair all right um we can perhaps update The Proposal of the EIP as we get to a point where we need to have a smaller duration for call for input maybe specifying that under a criteria that that is time sensitive it could be done in future if needed maybe like for example change

that can be easily reverted only requires two weeks and then there's an additional four weeks after it's merged where any editor can object and then bring it back to a call for input yeah I like that um it it it could even be like by the next EIP I meeting or something as long as there's a couple days of grace if it's something really so reversible or small um just an idea like for example say up like a rather during a final EIP like that's pretty minor change in Grand SCH of things and can be easily reverted and so I think that would be a

good category for like we only need two weeks of deadline and then an an additional four weeks after that where basically an editor can object and bring it back to a call from ma'am uh my only concern with that is like for things like assigning an EIP number or or or like irre irreparable irrevocable changes like that uh that's what I'm saying this would only be applicable for easily revertible changes and changes that don't leave a side effect yeah I I think that'd be okay um I think we could work something out like

that and put it in the E sounds good by the way uh I think it will be a little bit in line in what what we are what we will try to say later in the call so this is great great direction right and I think we are almost there uh I just wanted to make one final comment before we move on to the next topic given if you have any specific example of this use case that you are talking about it would be really helpful to be added in the EIP I mean like for some event to maybe come up with the idea and we will have a reference like why we want to have this

thing included in the EIP thing so for example there's a few of them like one the creating of the informational describing the issues with the erc20 uh the create uh the withdrawing of one of those IPS these are things that can be easily reversed and also there and also don't leave a side effect and therefore I think can be merged a bit quicker and then if it turn and then if and then that kind of I forces editors to actually pay like forces editors that don't agree with it to then say that but it also means that we

can make the changes faster sounds good well thank you and with that I think we are good for call for input uh topic today and the next one is security related EIP modifications um there is this comment by Dex run and um I have added uh the link to the comment as well as a a response by another user Andrew I know that we are joined by team to maybe talk about this particular topic so if someone from the team maybe like to summarize what they are proposing and then we can get it for

discussion for EIP editors here okay um so I'm Vladimir uh I will most likely represent the the let's say business or like main overall direction position and uh Ure and and xran can be more let's say from technical perspective so um the the main idea is um uh basically coming from experience and from where we see everything is heading this is more security uh and more U definitely more kyber security uh implementation so from from this perspective uh I come from the country that is part of European union and it's visible that there is um

basically uh movement for every company in Europe uh to start Implement more and more uh security U implementation to be in line with um guidelines that are provided by EU or uh the the state where you are based so why I'm saying that is that there is possibility and we can see it more often a good example is for example Microsoft uh imagine that eum is in a position as Microsoft I think it's not farfetched because uh you are providing a platform um to uh developers the developers are uh doing their products

on top of your platform and are also working in line of your um let's say um guidelin lines or um your processes um right now we don't see a reasonable way how to affect um already known security issues in the Apes uh because they are final if they are final there is basically no way how to reopen them or it's extremely uh hard to show to the users that this a um has known security um vulnerabilities so the the main idea is uh basically be able to have this

information to be shown to uh end users or other developers because from what we saw quite often is if you have final AP or eight um um people usually will take it as a template and they will use it in the their projects later on um and if there is no information on um revealed already known security issues with uh with the code that is in AP um then uh basically nobody knows um and um and the actual developers will use the already

known security issue and they will continue basically spreading the already known problem U because for what we can say quite certain is that always there is a good analysis of all these hacks or issues security issues so we know what are the issues is we cannot say like we don't know or who who can know that like it's known that the ab has security issue the problem is nobody kind of like knows about it or it's extremely uh hard for people to to see it so so the so this is the main let's say um Direction why we are trying to to propose it it has many possible benefits

and it has also some risk involved if uh the platform will not do it one of the main risks just a sec what is the solution you are proposing sorry what uh you were talking about what kind benefits the solution would propose uh would you mind actually going into what your solution is first so so um okay I can go into the solution so I I thought it's quite clear so um if I understand it correctly uh after ape is final there is basically limited way or almost no way how to uh adjust or put yeah so this is process that is

simply either incorrect or or wrongly designed because it doesn't respect the fact that the Apes and any program or anything will change in in the time and if we know already that the code is faulty and is simply wrong because we know that it is as I said then there is there needs to be a way how to reopen it and possibly comment it so I would say that I what I the solution I prefer to see uh so first of all I need to establish what IPS for aips are basically a way of making sure that thing that basically once you implement something then it's almost like a label

as long as your smart contract implements an EIP correctly then other contracts can expect that that well that contract will implement the EIP so in terms of actually modifying final EIP eips I don't quite like that in term but I do agree that there are there are now multiple instances where an EIP has had flaws that mean that it shouldn't be used so I'm I'm so I'm wondering if what we want to do is make another working group but the that working group is is unlike any other working group in that

it is explicitly like it it does issue recommendations so as a whole the EIP project does not issue recommendations the existence of an EIP does not mean that basically it's a good idea to use it the existence of an EIP is just a way that you can ensure in our operability however people have been I will fully admit people have been using eips as almost a way of oh if this is published then it's safe and so we need we I think at this point we do need a way to communicate to readers that there

are probably better options available and so possibly an opinionated working group might be a good idea so uh as as you said there are many uh quite complex how to to do it obviously what we are trying to to achieve is to start this discussion and most likely the the impementation can be U more complex because as you said either we can put a label there so this doesn't touch actual uh AP finalization but there is information provided to the people hey there is something wrong here maybe you should take a look on the updated ver version of the um AP or RC

um and um so there are many ways how to tackle it uh I don't think we we can give give you straight away all the possible solutions but one of the solutions is obviously ability to reopen I do understand why this is not um let's say liked idea because obviously if you can reopen something you can change it then you need to have then you are basically ending with the question who is guarding the police yeah so uh I know it's a really difficult discussion but there are many solutions one of the solution is B basically being able to put uh some let's say label or some some note that is on top of let's say this uh

apes or or or things basically to say uh we in this in this particular ape we know that is this security vulnerability um and uh Please be aware of that um the the the the reason why I said the example with Microsoft is that that it's actually quite good um comparison because because you are providing the platform and in the end who if the users are damaged and and the the money is lost or or stolen um in the end who will be responsible um obviously what we think right now is that the responsibility

lies solely on the developers and they are responsible for they what they write uh but in the end the platform needs also to to be able to explain why and how they did everything possible to to help the people to at least take in consideration that these risks are there so again the purpose of VIPs is not to endorse specific standards it's simply to provide labels that allow things to interact with each other no matter how bad those interactions like like no matter how like not like no matter how flawed those

interactions are yeah you're you're kind of saying like if you implement erc20 even if erc20 turns out to be completely broken and horrible somebody can come along and know how to use your erc20 you know 30 years so that is what the goal that is kind of what the IP project is in ter but I will not deny that people have been arguably Miss using it as an endorsement of a specific standard um and in that regards I think that we can do better to communicate to readers that something is flawed and a few things that I can think of doing off the top of

my head that would require almost no effort on our part is make the security considerations Ed always editable postf final any modifications to the security considerations are are Rob no matter what they are as long as they are true second thing is move those security considerations way up if they are important so if if there is like a really glaring issue then we should be a to move the security considerations above even the abstract so those are kind of two things that I can think of that wouldn't require much work at all and I think would definitely be a good benefit so

so uh so I'm defin starting to come around and I think that we do need something um you you you and DX San have convinced me for sure um but is just how to implement it and I think in a way that keeps the Eeps process you know true to its goals um and I I think right now my my um my concern with what you suggested panda is that if we edit the security considerations like who is supposed to decide whether an edit is allowable or not like if it's the author and the author doesn't want to reveal the security vulnerability because it will you know hurt their nft Marketplace like stock um and they they keep blocking the PO request uh are they

allowed to do that do EIP editors need to make that choice um say let the EIP editors make that choice make it clear that EIP editors are making that choice like then that puts us in a place where we have to make decisions that we could like we some of our credible neutrality if we do that so so I think I think I I don't agree that you will lose any credibility obviously that you need to have a little bit credibility credible neutrality it's slightly different basically the pro the process is designed so that eips again are just a label that can effectively be applied to compliant smart contracts something is

compliant or it is not um what what the problem is is that this kind of is that what I'm suggesting does admittedly go outside of the scope of what the project is for the project is not for kind of determining what is good practices no matter how obvious those good practices may appear to be I do think that we can so again what I've suggested is making another working group that is explicitly not credibly neutral yeah and I think that'd be that'd be acceptable I will just give give you

some notes from let's say outside perspective because I'm a little bit let's say less involved with the ongoing process but from my perspective like I see Apes as a template basically to be used um obviously what you are saying makes sense I am I don't know if anyone is actually aware of what you are saying uh it makes sense it's basically repository that needs to basically track so in 10 years you know how it was done uh but the question is if basically everybody sees it differently uh if it's better to basically adjust and do what what is let's say expected uh how to do it as you said is uh is I think uh the

options that you can do obviously you can see I think a little bit better than than for example me um but I think that there needs to be done something how it's done I think you are right it's extremely difficult to uh have a process where basically you only store information how things were done and that's it uh and uh something that is let's say uh updatable or commentable where you need to have some some judge basically to decide if I push this button and then announce that this nft Marketplace has a security issue therefore possibly damaging the the the the and if it if it will happen that

this Marketplace didn't have security issue and it was just false alarm then this can be quite big issue obviously so yes there are many uh things that uh you that needs to be considered um I think the the main thing was to basically bring up the topic uh and open it discussion uh because we do believe we have experience to um basically be part of the discussion and possibly give you some some um good proposal that obviously you will adjust as you as see f it so I think we can probably model a bit of this on what the ITF does so the itf's working groups are literally

working groups so kind of there is a working group responsible for for example the ACT specification part of The Proposal one for the Securities uh uh security considerations part of part of The Proposal Etc um I think we can start doing that and taking effectively the security considerations out of the EIP and into its own working group and I think the the security considerations working group should not be explicitly credibly neutral I think the security considerations the working groups don't necessarily need to be credibly neutral right just the editors do so I think

that works yeah so so if we create a secur a working group with the only goal of determining what should be done with any given EIP security consideration whether or not it should be moved to the top or left its current situation what changes should be made to it post final and let's be perfectly honest I don't think that the process should for adding is or or editing the security considerations uh like editing the security consideration section should not depend like the process should not depend on what stage the

proposal is at except maybe in draft so so because if it's if there's a security consideration it doesn't matter if it's in review last call fin or even a living it should have the same process except maybe other should have an easier time disclosing vulnerabilities maybe we can add a section like security reference it not will be so strictly like consideration we will public uh in the reference uh links to the security company or Security Experts who describe issue in some AP if they found or insecurity reference can be public uh audit uh

information that thisp was checked by security company and uh was confirmed that this AP is have no big issues for example so so something like that would probably go on a Wiki like um I think that kind of a format would be great for collecting security considerations so I'm wondering if what we want to do is basically take make eips literally like the actual EIP part of the EIP literally just the abstract and the security considerations and maybe also the test cases so we take so that is what the EIP itself is and then we take

all the other sections the security considerations motivation rationale uh reference implementation against copyright section goes in the regular IP bit and then we take all of that and we make that also uh like if you will consider the the actual solution I think it's extremely good if there will be a place where different um in like I I will give you good example um something was hacked we know usually one day after why it was hacked and we usually know what vulnerability was used maximum in a few days there is no doubt about that about

that because there are many companies working on eum doing different analysis of these hex Etc so that is uh definitely a good thing in this but the question is um how this information will be provided to users uh or specially developers um so for example if I used ERC uh 20 um and uh I know it's a part of my code how I will receive notification or how I will receive the information that something uh uh changed and that uh because in if if it's part of a then obvious if the AP status will change I will receive notification

straight away from the GitHub no so this is basically kind of semi-automatic so I think what the easiest solution to that would be is have an RSS feed that is updates to security consideration sections what do you think Sam um I I'm think think what we should probably do is uh time box this conversation for now uh make maybe a Discord Channel or a thread or something to keep our our thoughts on or or we'll use the discussion thread that um we already have and we list out like what the possible solutions to this are like whether we have a Wiki whether we allow modifications to the security consideration section uh and we kind of sketch out all the different like

options and we we try to decide on that um because I think right now we're we're kind of just brainstorming on a on a an hourong call and I think that's yeah I think not efficient yeah you you are correct I think uh what what we wanted to do is mainly to open the discussion if you are open to the discussion I think it's exactly what you said the solution most likely can be completely different from what we discuss right now um and need needs to be discussed in some open format so if if we can join the the the group and put the ideas there we be happy to do so you guys are in the etherum capitals Discord right okay

great all right so I see here in the chat Dex has also shared the link to the fellowship of ethereum magician uh where this proposal is active people may uh find the link in the agenda today and may perhaps leave their comment and thoughts on this on any possible solution uh to this proposal for security consideration with that I think uh we can perhaps move on to some of the open PRS which are with respect to final proposals I see a bunch of proposals added here and most of them are from the earlier call um so I wonder if uh any

editor has any thought on any like any proposals to be allowed or not the number one is ERC number number 49 which is for ERC 223 remove standard function uh I'm pretty sure the deadline for that is tomorrow um if that if and so far I think we've got two approvals and let's see yeah yeah this is an example of where I would like that two week deadline that can Beed okay so um just for the summary of this call do we want to keep it on hold because

there is one more day left or is there anything that we can answer it as a solution to this Pi or maybe next St we should Sam are you willing to merge this tomorrow if nobody objects yeah I'll do that meret tomorrow if nobody objects okay okay the next one here is is update ERC 2612 which is which seems to be like a small typo and the pr number is ERC 57 yeah this is this is I'm pretty sure this is

correct so we can allow merging yes so an so annoyingly this is in the spec but this is fine I think um actually hold on so I'm pretty sure that there's so it first of all I think it's pretty clear what the original intent was uh second I actually you know what I think that this is actually incorrect wait is it hold on I need to

actually check the when he's back here I think Joey is on the call who is the author of this uh Joy if you have to add anything here yeah sorry what was the question for ERC 262 I'm just double check I'm just double checking that the function name is correct yeah I I believe the function name is called um allowance not approval um for the mapping that I mean it's not even it's kind of weird because in ERC um in erc20 it's defined as a function not a mapping so the fact that yeah so the fact that it's um so the a m

become functions with two parameters I'm pretty sure right yeah but it was just like you know the way that he wrote style choice but you yes this can be mered this is a very obvious cool yeah thanks

okay NE do we have any more uh yeah the next one is ERC 1363 fix created date um sorry I was on mute yeah that's right s yeah guys I I think from from my perspective if it's all and if anything I will be obviously on Discord or Forum to be reached something it's needed thank you for consideration and bye-bye thank

you all right so the next one is a 1363 which is uh which has actually 1 2 3 four open PRS number are 66 7475 and 76 all with respect to one proposal which is ERC 1363 I'm I'm not sure about the Creator date I I don't think there's any precedent for what the Creator date is and therefore I don't think it should be changed since it's FAL oh I mean they created date like it was it was an issue before so yes I know it's issue we don't I will fully admit here the created date in E1 is just completely underspecified since EIP 1363 is final I don't think we

should be changing it the Crea date so it's a field it's a field in Preamble we should use that right why do we want to change it oh so the created date was set to when it was upgraded to an a markdown file as opposed to like it was a draft issue uh created long before that so I guess you can see what 223 didc 223 okay they they used 20 the issue created date okay yeah sure this is good yeah erc20 is you know 2015 which is well before

the using markdown so sure I'm I'm still not a fan of of updating finals just to change the creat date to something different but you know what since this is what most of them are doing I'm fine with it so I'm just trying to understand here like a created date is a field which is added when the draft was added why was that not updated at the time of making draft it could have been easily updated so the draft was created as an issue that's in 2018 why I mean there must have been there must have been a draft in markdown and

in that they can add any date um if they want to keep the issue date as they they just put the wrong date when they made the the the markdown file okay I don't see any um as of now I don't see any advantage of changing that date any significance why they want to change it except for history purposes if they want to keep it there I think it's just a um like it was one of many modifications they're making to the EIP and this is the only one I thought was reasonable um but yeah so I think also this kind of ties into that that create a date it's just

like completely arbitrary like like ip1 says it's the date at which the proposal was created like this is this this is like unclear is it the date at which it was merged when it was first conceived when it became an original issue or a PLL request like it it's just arbitrary and I think yeah it most of them have been the issue creation date yeah yeah it's the the earliest date a relatively complete document has appeared on the Eeps repository I think is the rule we go with about

magicians I think that would conf create a lot of confusion we should be clear here and created a date is a field which is to be filled by the author they if they want to keep the created date as the initial date of when it comes to their mind they can add that date we should not go ahead and change it like let's keep what author propose it when they are creating the markdown for the first time and whatever date they enter we respect that that is is what I'm thinking it would be the right thing to do here is because I know the confusion about the created date because I was trying to create a chart where we are trying to find how much time did it take from one proposal to move from draft to

final and there are two created date here one is the date what what is added in the Preble field and one is the date when it was actually merged and there could be a month of difference between these two but what we are trying to do here is like whatever created date they have added as in the field of Preamble should be considered as a created date okay um how about first first like the date at which the the IP editors were first made aware of it that's making the pr date well except it also is work works for things where there's not actually a

PR which was the kind of previous way of doings but that could be very confusing many editors could not get notification of that right so first time they get notific specifically like like when when a notification is kind of the date at which the notification was send basically like so this this doesn't whether or not the editors actually check it does not have an effect on when it was actually sent so um if we try to collect this piece of information with respect to GitHub I think GitHub action BS provides US history when the is merged yeah when it is mered or when it is

created I also think we should try to avoid depending too much on actually GitHub as the flow for what we do I think that whatever we have in the ip1 should not depend on there actually being such a thing as a poll request that is is required to submit any IP I think it should be I think P requests and all this should just be implementation details right and while creating pull request this is the opportunity with author they can input whatever created date they want to add their I don't I have never noticed any EIP editor creating an objection on the date of creation based on like why is it

different from the completely arbitrary yeah they can did arbitrary like I'm pretty sure that my that my first VIP 4834 um H has a created date that it's two days before the actual date I submitted it because I made a typo all right let's get back to the uh this paer here um do we want to add it update it I see there are bunch of other updates considered for this particular EIP so if you want to make it a part of it it can be done but I Just Want To Be

watchful of creating this as an example that anybody in the future can come back and say that my issue was originally created this whether it was not with respect to the pr you know what I'm I'm I'm in favor of changing the Creed dat on this proposal and I also think that the authors if they strongly agree with it should be a to change it back because I think the authors were the ones who originally proposes change so oh okay then yeah this is a no-brainer then right yeah if the author himself wants to do it we can perhaps allow it but yeah we should be mindful of this kind of situation yeah the the authors

approve the port request okay then yeah absolutely let's do it yeah I I don't yeah I'm just going to pretend this is not controversial and we're going to go for a merge on that all right there are I think there are two or three other open PRS with respect to this EIP so if we can make decision on that perhaps we can mark this item as completed so the next PR is 74 this is how much of this is actually Rewritten I'd say that the Rewritten

version is actually just way better stylistically but unfortunately it is also Rewritten yeah um yeah like the description and the simple summary don't actually match up although that's partially because you can't have markdown and because the simple summary was just bad oh gosh what was their former abstract okay I'm in favor of this just because how just because of how poor the original content is that's appalling and being hyperbolic but like

yeah this is just better writing anyway yeah but that that's kind of goes against the spirit of changing a final EIP right like H this one's Tough All right so you know what I don't think it actually leg I don't think it I don't think it creates any incompatibilities here is just a rather larger R it f it fixes some bad style choices what do you

think um it's final so I'm generally against editing it and if they want to publish a new version with um you know updated text they absolutely can okay um how about we recommend to the authors uh to the uh uh to the author of uh PR number 74 that they split this into first of all split it into things that are actually necessary like moving the simple summary to the description updating the discussions to URL these are things that I think are good and

should be merged do you agree Sam um I don't know if changing the discussions too is necessary um but I mean it's just not the correct link any anymore that if people want to see the historical discussion for this EP it is the correct link well except the historical discussion oh is there actually anything on the updated magicians link or is it just stub well that that's what I mean like I think the old no there's there's actual go there's actual historical discussion that's uh of is there no there's not okay considering there's not actually any discussion on the new link

that's not on the original link so I'm I am against updating it to the new ethereum magicians link because that that wasn't actually where the discussion took place in terms of moving the simple summary to the description as long as no changes are made apart from removing the markdown because there is no mark down in Preamble that I think is okay in terms of any other obvious fixes as long as it's an obvious fix that's fine I would also like them to submit another PR that actually not does of this changing and ideally section by

section so updating the abstract and updating the modation because I do think that the writing of IRC 1363 is not the strongest and I would like to see it changed especially since it look let's be again I'd say the purpose of the EIP project is to kind of create specifications that can be applied to different programs to enable interoperability if modifying a final EIP does not conflict with this Mission and in fact makes it easier for imp for potential implement to kind of understand what the proposal is all

about I think we should be allowed to modify a final EIP that's kind of vague statement like people can interpret it differently we need to be explicit about what are the conditions under which it can be allowed because if the like you know if the potential user should understand it better then we may have to end up updating a lot of fies I do agree here so we do need to be explicit about it I'm just throwing this out here should we be allowed to modify final eips to make the content easier to read because it will help implementers in the

primary objective of the EIP project which is to enable operability no I don't think we should I think if somebody wants to take the spirit of this EIP like the same like if somebody wants to specify the same thing as this EIP with different words they can just make a new EIP for it so arguably it's just the same label though right because I'd say allp is is just a label that can be kind of applied to something that's compli yeah I'd like to understand the thought process Sam behind your no just so that we understand the the principles that we're discussing this under oh sure

so um the EIP is supposed to be immutable and whether the wording is exactly the same understanding quickly why you feel like the entire e should be immutable I IM mutable of content or immutable like immutable of text or immutable of the actual spiritual content right it's like of the law yeah so absolutely immutable sorry go ahead panda because again I do agree that the actual EIP the like the main part of the EIP itself what the EIP is and even it's like the the details in the specification the specification not the text itself but the spe specification

should be immutable what should not be immutable is the actual text itself because the EIP can still be the same EIP but with different text and one of these ways is kind of just the EIP in my mind is what is trying to be conveyed by the document itself not the actual document itself well I think uh we should try to wrap this up here I am sure we are not going to get a solution until we have uh some more thoughts collected from editors who may not be able to make it today would it be okay to have it added to the next meeting agenda and like a

specify conditions under which a final EIP can be considered for changing uh yes and I think we should also kind of create almost like a more General thing of like what is kind of like what constitutes the EIP itself because I think we should all agree that eips themselves once they are final are mutable but what the actual EIP like what are the parts of the EIP that are essentially the EIP and what are the parts that are just kind of helping the reader to understand the EIP and by the way Sam I would I at some point I'd actually like to just have

like a one-on-one conversation so that we can try to find some consensus here yeah sure very well um so I will go ahead and add that for discussion in the next next meeting and I would request e editors to maybe take a look at the other open um final proposals if they have any thoughts they can perhaps add it if we get a consensus on the pull request itself we can make a decision on merging it on the next call otherwise we can definitely bring it up for further discussion I'm trying to just uh look over other items if there is anything of higher importance that we might want to

discuss I think there are a couple of other items uh with respect to renaming of ERC office hour and things but we don't have time how about we decide on the next meeting time this was not our usual meeting time our usual meeting is 14400 UTC but this day for today we made it 1530 UTC as I can uh look into the uh time for the ne next meeting which would which could be on November 29th I see it is in conflict with execution layer P2P breakout what is a our stand on that where do we want to have it do we want to have it after that meeting ends or yeah any suggestion here so uh in terms of moving it forward that would be less

convenient for me but I could do it in terms of moving it backward I cannot actually I can't do it any earlier than the normal time I'm not attending the execution l or P2P meeting so I don't really care if it I'm not attending it either but I imagine that Pro if there is a person here that we do need to have on the meeting it's light client and I imagine that light client will likely be attending that meeting yeah I don't want to assume but and I see that after that there is UF meeting uh so both, 1400 and 1500 slots are booked by other calls so if you want to make it, 1600 I can perhaps do that if it is not inconvenient for anyone

present today hold on let me check time zone 16600 works fine for me I was concerned for you specifically G sing but thanks for giving a green shade there so this is600 UTC yeah 1600 UTC will be 11:00 a.m. eastern time I uh I am no longer Eastern time I'm central time but yes I'm that is good for me perfect Sam does that work for you also yeah um that is pretty open for me so okay so let's try to avoid the

conflict hopefully we get to join by Matt as well so we can decide future meetings but for the meeting scheduled on 29th let's keep it at 1600 UTC sounds good to me thank you everyone for joining us today and staying a bit longer I know this is not the usual of the call but yeah thanks everyone see you around have a good one thank you very much have a good day thanks everyone