EIPIP Meeting 99

Transcript

welcome to EIP IP meeting 99 this is issue number 310 on eat cat hles EIP IP giup repository this seems to be pretty short agenda in fact uh we have a few items to be discussed with respect to process then we will discuss any open issues in PR call for input and any other discussion continued from the past meetings we'll quickly take a look at the eaps insight for the report of uh January 2024 and uh we'll get to know about editing office hour to begin with the first item and I see a comment here in the

chat by Sam no Sam we did not hear you maybe if you would like to rejoin or check your microphone very well so the first item listed here is RP process documentation um it was on the suggestion of rip working group but I don't see any of the member on the call today I wonder if anyone has any update to be shared but I have got one update there is one rip which is Rip number 7212 has now been moved to final so it will be really interesting to learn

about the process they would like to follow and what are the type categories they would like to consider because I can see here the category mention is cool yeah if anyone has any in any update or yeah any thought about RP process feel free to share uh I I briefly talked to um uh Doan uh sorry

ulash um who is the uh guy who opened this one uh and he um made it sound like uh the rollup like a lot of the decisions it it sort of in you know synchronous like meeting based uh and that they're doing something sort of on the a allore dev's model uh but it sounded like um he couldn't tell me who to talk to about the more horrible stuff I I didn't I couldn't understand if it was

who who was the person who wanted to be harassed about Pro per se like maybe maybe black client knows oh sorry I was putting them on the spot maybe we should start over all right um just for some context here we were discussing the RP process documentation and it seems we won't get an opportunity to talk to the author of rp7 to want to but we are still unclear about the decision making and process part we were hoping to have someone from

the working group to join this EIP meeting to maybe share about the process but yeah anyone else on the call if you have thoughts ideas or any information collected please feel free to share I have also left a few comments on one of the all codev agenda after that we were reached out by the team but I will try to follow up with the team again and try to get them in the next meeting if possible so if there's nothing further

on this one perhaps we can move on to a web page ing to include eips erc's and rips I am not sure what is the progress on that side but yeah if there are any hey yes I'm working now okay cool uh so I've been making a little bit of progress on the um Eeps working group um stuff so e review bot is now running on my uh repositories and the rendering is is done um for that uh also I'm not sure if anybody else is aware but Panda pip has stepped down as an editor for the time being um just wanted to make an announcement about

that uh but yeah so uh I'm working on E viewbot for working groups and um yeah you can follow along my development over at github.com DWG that is wonderful thank you Sam for that Sam whenever you think we in a position to maybe have a small demo and we can publicly announce that that would be really nice to have yeah I mean eventually we're going to have to decide if we want to adopt um that structure so I think that's probably something we should do before uh we announce publicly um how how do people feel about that in general do we

want to go down the working groups Ro yeah I feel like this could be a good time to discuss that we because we do not have a ton of items on the agenda and we probably have most of the editors on the call um can you put a link in the chat to any document that I can skim quickly uh yeah it's the same one that we've been discussing um with the uh working groups having their own like members and everything I'll I'll find the hackmd thank

you I have a question here if I understand correctly the present eips ethereum.org also um render the ercs I mean I had someone working on rendering of RPS but I do not see any success over there I'm wondering if people still want to go that route or if you want to switch and move all together to the working group part so I'm in favor of having RPS be a working group so they'd inherit the same rendering stack but uh I I don't know how everybody else feels how do they feel about

it I've talked briefly to ancar about it and he's pretty pretty interested in making it a a working group which case I'm all for it yeah ulash aash seemed to like the general idea but it seemed like I was he was hearing about it for the first time I don't think he had like a clear uh definition of what what being a working group meant and didn't know how to you know check if I was asking him to commit to more than he he was already committing to in other conversations so

I think my action item was to uh send him links to what becoming a working group meant uh maybe I don't know if that's similar to the vibe you got from ancar um Lush is I think just an active member I don't think you signed up for any sort of formal duties he's just the guy who wrote the RP mentioned as far as like formal responsibilities for like like what is like quick summary of what it means to be a working group it means you're you're kind of subject to the similar rules that we have for eips now so like

uh you know formal external link policy you have to use mark down a few other things and uh you'll have to use our repository structure um and then then on the governance side you have to like write a document describing your policies but other than that there's not too much overhead yeah the the first thing told me was I said hey do you guys want to be a working group The Way allord Dev says and and he was like Oh you mean like getting a repo like they have yeah I think we're planning to do that so on that level I don't think there's any conflict I think they're okay with that yeah I guess reviewing uh PRS would be the other thing people would have to

review PR they'd have to review PRS but they already have their regular uh calls so I think it's very it's sort of logical to be like at each call we just review you know check in on our repo seems like they they are fine with it it's the same compatible with their structure I can predict that there'll be conflicts over external link policy yeah I I think that's probably true and you know obviously working groups can Define their own kind

of exceptions and however they want to approach it there's a lot of freedom so okay so pretty much if an author of an R rip wants to do a link that we wouldn't like um it's more up to the working group um is that what you yeah I think I I I think so yeah um like our goal like our mission as thep editors is to make sure things are you know durable for the lifetime of ethereum um and yeah I think we can probably come to reasonable compromises with work groups on the specific Like rules they want to

use okay an easy one is is simply to um push it as far down the pipeline as we can um so it doesn't prevent drafts from going in but by the time you get the final these things have been resolved it also gives the author time to find a better source for the link but still have something to link to now so that people reading the proposal yeah um have something that they can read BG you might you might have a link that's only to the author's web page and

it might take some doing uh to find a better link um but during graph phase even review the author could want the link there because that's the only link that he has to explain the the concept that needs explaining or to back up the motivation or anything like that yeah that makes sense absolutely and I would really appreciate the users and whoever are involved with the RP process right now like definitely it's being discussed in the meeting and being purged PR are

being merged one of one or more of the members May either document those things so a community may be able to refer to or maybe join our meeting and share their thoughts and we can be aware of it and kind of help whoever are new and would like to document a new R you can definitely send them to watchs the RP Discord Channel that is available on E R&D but generally speaking it will be a good idea to have proper documentation around because I know at this point the GitHub repository is also like in very very early stages and we do not even have the name of theil just listed over

there so it will be really nice to have something documented there all right um Sam um just to be sure like would it be possible for you to maybe provide a demo by the next meeting even if we are not formally announcing that um that will perhaps give people to have better look of it and maybe compare and see um if we would like to so to to be clear um everything is working except for E review bot and ew you can actually see it all live right now like the web page rendering and and all of that would it be possible for you to

maybe sure yeah on your screen yeah thank you oh yeah I can do [Music] that there we go so it's pretty much the same as before um yeah um I don't have RPS just because they don't have a a repo yet but um you know web page is here and it's all rendered from separate repositories um it's rendered using Zola instead of um Jacko basically exactly the same yeah

what is this governance mean here like I can understand core ERC wallet and yeah yeah so this is uh the working group for um defining the eips process itself so this has things like our external links um the EIP ERC repository split uh our handbook um yes so this is kind of like the meta category right but if I understand correctly it's not collecting all meta but some of them so how do we pick it like is there any um code defined for it or do we need to select these proposals manually uh so all all of all meta eips

that exist today are moved into core except for um a handwritten list uh because most surprisingly most meta eips are uh hard Fork descriptions and not uh governance documents that's right and I'm wondering why we are seeing ERC EIP repo split here and not in the core oh cuz this is a govern related like splitting the repositories is a governance thing hard Fork sort of project management coordination documents be informational technically or or was meta the right way to designate those in the

first place So Meta was originally like a category describing other eips and it was meta because it was just a list of the other eips that were in the hard Fork um but now now there is no meta because it's kind of ambiguous so there's there's um governance which is for the EIP process itself and then there's um core uh for um you know hard Fork organization and stuff so yeah so just to understand it better we are not going by the type and category

but we are going by selecting which will be the best suited for the working group exactly so instead of it being like a type and category uh you'll have a working group and then each working group if they want can have categories like uh core there's more in here if I go all the way down yeah so um so for example the core um working group has both core eips and networking eips as subcategories but that that would be up to the working groups to Define how they want to organize stuff and maybe one other related question I'm sorry I'm asking so many

questions one other related question here like uh do we have a list of or should we maintain this list somewhere that who are the participants of respective working group can we maybe uh provide some placeholder in this website so people can know that if I have question with respect to this particular working group I can perhaps reach out to these editors or users um uh until we officially launch it like this is just my playground uh there's nothing here that's permanent I I regularly erase it and start over um so I don't know if it would be worthwhile but there are um there are um if you go into the

actual repositories um so there is like the um same kind of emo file that lists the members of the working group and EIP editors um so that that's going to be very similar to what we have today all right yeah I mean I find it good I mean I I feel like it is really good if we can add perhaps a little bit more information about the people whom we should be reaching out to for example to understand what are their thoughts about just they want to categorize core networking and how they want to put it otherwise it looks good and it would be

a good way to share proposals with respect to working group I wonder if anyone else has any other question I I was just going to plus one and say that the uh the working group breakdown as opposed to category or type breakdown like it like adds another category that Loosely maps to category and type but like there's very good reasons for needing a third category it would it would be more legible if it was part of a bigger socialization of the concept of the working group and one way of doing that like bja mentioned like

if when you click on a working group the color of the site changes or you know a contact name appears or like it's sort of uh some sort of ux feature flagging that you're like entering a different zone of authority and there's like a different contact person right like that could be that could be at the level of display that could be hidden from the level of display but obvious in other context maybe when you go to the repo it's in the the top of the first read me in the root directory maybe wherever like I wherever it happens I do think it's good to have some sort of nudge that like you know this is a this is a a a different Zone a different

something okay so um You' like to see more of an indication of like that you're in a different part of the website or kind of yeah like I I do think I mean I I uh I think P's uh instincts are right here that the average user won't care much about differences of governance but they'll be very thankful if they know there's a different person to tag on GitHub or a different sort of C you know uh contact endpoint whether whether that's an email or a GitHub name or what but um something that sort of signals it's a

different department or a different workflow something like that um okay I'm trying to agree but also generalize at the same time like maybe uh first idea probably best idea but but thinking more generally the the working group as a concept is sort of only known to the people on this call and the people involved with moving repos so it might be good to think of the socialization of the concept accept as a project worth coordinating like pin pin a message on E magicians maybe I was thinking about maybe working groups could each have categories on eath magicians and whoever curates that

category might be the same person you contact if they're you see what I'm saying like like a front door for each working group might be good or I mean there is another way one can sort of allow them the freedom to render any way they want while adhering to the checks that we would want is in terms of Social Web tags so they can basically uh right now uh our uh lters expect a certain format and we can basically throw all away all of that and allow them to have

any rent ing format they want and then basically with the social tags they would have to match the categories that we have in our lter rules and using that maybe you know it is possible to give the freedom to work in groups to render in any way they want is that something um potential working groups want like they they said they don't want to necessarily use markdown and they don't want to use like are po request bought they want to do their own thing entirely I'm not sure I'm just thinking if this is a real issue that they want their own rendering formats and maybe

this is a way to allow them yeah that makes sense yeah I um I think at first we should probably provide just like an outof the boox solution and if somebody wants to do something crazy then I I don't see why we couldn't let them yeah makes sense cool just with the intent of allowing them the freedom to do that will solve away a lot of the edges that people get uh when they are restricted so if you just say that you you're allowed and we will be able to uh again we will be able to assess your

page based upon for example social tags then I mean most of the issues that they would have for fitting into a certain format we want them to those would go away I mean even if they don't end up doing anything but still the illusion of the freedom basically takes away lot of resistance I find this generally is a very good idea to be very honest from my side I would love to see no change in header or maybe a unified header across all working groups data analytics could

be easier for individual projects uh infrastructure projects around EIP but obviously it would depend on working groups so yeah that could still happen Puja in the sense that when we process their markdowns and we look for our uh s social tags then we can basically process and format those tags on the top of the page so it would still be possible uh and we still can sort of allow them the rendering format they want that would be awesome great uh well thank you Sam this

seems like a good progress uh towards uh including all proposals including RPS as well along with ercs and other working group uh that we can see here hopefully uh we'll get to collect some input from other editors as well who are not here on the call today to maybe decide on if we want to go ahead with the uh this format and merge it as a part of e. ethereum.org um any final comments before we move on

to the next one my only my only my only thought would be could we ask ancar or ulash or someone involved with rips uh to come to the next meeting I mean we can definitely tag uh members um on EIP editors channel on E R&D and let them know about the next meeting date in advance and perhaps hope

for one of the representative to join cool yeah I think it it might just help because then it would double as the the it the the walkthrough on the next meeting would also double as on boarding if they want to do it right like it would be a absolutely like sort of a subtle way of nudging them tricking them into say yes on the call I right all right moving ahead to the next item which is about discuss open issues and

PR and other topics I see in the chat Sam has already given a thumbs up to the pr number 213 which is about ER updating an ERC 1363 this was also requested by one of the users in the comment I wonder any editor has any different thoughts or if all of them are okay to get it more so I see one more thumbs up very well

um we can perhaps merge this here um unless that any editor may add any further comment suggesting they are not open to merge this one the next one here is the call for inputs I have listed two uh new call for input number is 306 and 308 Sam if you would like to maybe take a few minutes and talk about these uh call for inputs the deadlines for both of them are February 7th and February 8th respectively sure I can talk a little

bit about them um so 306 um is a backlink kind of proposal so um let's say I'm working on an extension for erc20 um in my document I'd be able to say extends 20 in the Preamble uh kind of giving an official symbol or or um like back link to the the thing I'm extending and then on erc20 there would be a list of um all of the proposals that claim to extend rc20 and that would be handled by the rendering infrastructure so there'd be no change

to the actual text of rc20 to make that work editors if you have not added your input for this particular issue please feel free to add it on or before uh February 7th so we can have a decision and yeah may be able to move forward or just close it I have ADD input and my apprehension is the same that I it over there that it can become as a Spam vector or another the vector where we have to judge whether we can allow a new EIP to say

that it supersedes or updates a particular old maybe maybe the 6,000 erc's for erc20 extensions is a good concrete case for discussing that because without having a way to without marking each as an extension of erc20 we still get a lot of them do do you think there would be more of them if they could Mark themselves as an extension of erc20 I mean if on that particular EIP or ERC page we show that it extends for

example erc20 then it's fine I mean because those tags are not getting into erc20 EIP page and a person who is looking at that particular EIP page for that it is a relevant information and a back backlink to rc20 is useful uh but yeah I I would basically hesitate to sort of Pop these links on erc20 page I mean I H I mean I guess my my thought was in

the case of extension later documents extending it it uh that's a pretty good argument against forward lengths but in the case of informational updates hey I want to rewrite the security considerations same author updating a final EIP with a new X section or more examples or something there a forward link is really helpful because you want everyone who sees the original to see the update um and for me the utility of having update eips being more satisfactory to the cranky people trying

to update their final eips uh is uh a good that outweighs the bad of erc20 having a spammy forward link section you know like I think I think it's a pretty minor nuisance to have erc20 have a you know 200 forward links um whereas I think it's a pretty major benefit to have updates be seen more I think I in all the threads where people are trying to um patch final eips uh the recommendation is we'll just open a new informational and every time they're like but no one sees it

in the structured in the structured groups like you know uh Cavs right where the Cavs adopt an EIP which supersedes the previous EIP it's very easy to make a decision right that yes this has been adopted but for example for ERC where the standard is more decentralized and there is no Community which is basically saying that you know also a community can't definitively say that that okay this ERC is interface is better right so in that manner how will you do that maybe you can just have a link that says that okay you know this there are

extensions to this particular ERC and you click and then it does a search kind of a thing shows you a list maybe that can work right I think listing everything that claims to supersede isn't that harmful a harm like if there's too many links in that section oh well there's too many links in that section uh so maybe we need to move this forward is like showing a UI of what it might look like to have these forward links in the case that they're very spammy so

like how bad would it look to have 400 forward links off ERC yes and that's also an argument for um you know the the precedent from ITF a is structured working groups like you're saying so that applies better in some categories in others because there's some external curation uh and B there's two categories there's replaces supersedes and there's extends um here uh the extension category of erc20 would have 400 in it because the all all the erc's with NFC NF in the title are

assuming the basic erc20 interface and adding more functions or whatever um so that's kind of like our requires header now yeah even just displaying requires if people are using requires properly already if if the Corpus of documents already has a lot of them filling out requires then you could just uh maybe to your point that it might help to have a sort of preview you could just do this with requires uh because requires and requires extends is sort of the permissionless version already um the super session part is

probably the Spicer part uh and there I was trying to think of the permissionless semantics and all it could come up with was like Forks because a fork is assumed to be a permissionless upgrade like you can join us or not join us but there's no sort of authority calling this the one upgrade um maybe that's a an interesting choice of words um inflammatory choice of words perhaps but like the hard Fork schedules right like they're it's an upgrade cycle I don't know super super session only really works in like an ITF case where there's

an external Authority saying this definitively supersedes this but a foric is sort of like it could be superseding or it could not it depends on the it's decentralized the yeah I think the prime example here is like 223 and erc20 um Dax ran who wants to like rip out approvals um I think you know he considers that to be a superseding EIP where I would consider it not to be superseding and it to be like comping I guess um so I'm not exactly sure what yeah we we have a word for that already it's a hard

work I mean I would suggest that we should not complicate things any further than it is actually required at if we give a look at the present list of eips even on the simplest website eats. ethereum.org it is not difficult to find erc20 related proposal if people want to have extension they can go ahead and do that but is it really necessary to the new proposal could be considered as super seeding do we really think there is there is any advance Wantage of doing it yeah suped could be useful for example in COD I I mean because there yes does there is some superseding that

does happen and it is very uh you know clear that okay this proposal supersedes and has been accepted and has moved into final so well I agree totally makes sense over there yeah maybe we can by working group have these tags whether it supers seed is acceptable in this working group or not I mean maybe we can do that I feel like in the case of application standard it it is not for um like the governance member to decide on that because application Pro proposals are for different different applications

some may need the older version and some may need the newer version of them it could be on their organization if they want to have like a upgrade their proposal and they can say okay fine we have upgraded and now new proposal is sueding that in my mind it is not adding too much value to the list of a standards especially for application I can totally understand it makes sense for the core proposals I think I mean proposals are the ones that need it the least though because core proposals don't go final until they're on mainnet so you can just

update the proposal until it's published whereas erc's somebody will finalize it and then like in the case of what is it 12 1271 they find a security problem and then they want to update their EIP well like they don't want to come up with a new number because it's going to be mostly compatible except for a little note they want to add so I think core eips don't need supersedes nearly as much as erc's do in certain cases we have seen examples of like you know one proposal I think uh which was in the past upgrade now get a better version I mean like the better proposal and we move on that on the Cod we just know by the latest list

of proposal for the latest upgrade and we move forward from there yeah but the but we just know is exactly the the thing that's a problem for casual observers or first timers or it's there's sort of an information aemet there I I think that the uh distinction here is like all cordev just know because they're there's an external authority to marking things as archived elsewhere and once an ERC goes final there's no way to know or notice that that it's archived like you can only withdraw something if it didn't go to final once something goes to final

it can only be forked uh permissionless Le because there is no main net runtime to tell you that a final ERC is no longer relevant or that the momentum has moved to another Fork I don't know I I feel like I feel like that I feel like the arguments I'm hearing actually sort of cut both ways and in a way the the just linking to things that claim to Fork something permissionless is almost like the most you can do without changing the rules for final status like if you don't want to change status but you do want to give

final ercs a way to be somehow marked as archival externally I don't know it's just my thought I mean we so sueding is something that for example can be part of the base uh ERC which is being superseded I mean if that author is agreeing that this is being superseded by some particular other standard then we can actually allow a superseding tag directly in the that particular ES which basically author is agreeing to so there is a

definitive Authority who has earlier authored a particular ERC and is now coning that this is being superseded or it has security issues or whatever and should be superseded by this particular ERC I actually proposed that earlier but I was told that front matter can't change after something goes final yeah that's my my position so once once the document goes final you can't change it um well it's not that you you can't change it it's that I mean we don't want to defer to the author as the authority of deciding whether or not we can change it no instead of allowing basically uh the author to change segments to it he

can just add that this is superseded by this particular ERC for example I mean that is only change we can allow so my my problem with that is once once a proposal becomes final it's kind of gifted to the community right so the the entire ecosystem decides whether or not it's been superseded not just the author like sure the author has you know permission to change it all the way up until final uh well I guess last call technically but um then once it goes final it's like this is done anybody can use it um and then uh okay maybe an example's better it's kind of hard to explain my feelings on

this so um imagine you know a a a malicious author writes um an EIP that contains a uh security vulnerability and they they write it all out they know about the security vulnerability or or maybe even not a security vulnerability let's say a a inefficiency or a bad API design and you know they convince the rest of the ecosystem to implement their standard um while secretly they're implementing the next version of their standard that's significantly better um and then they release that after everybody's wasted a whole bunch of time implementing the first version of their standard so they have this leg up on the rest of the the competition

because uh you know they they convince everybody badly and then they release you know the the better version later on um and I mean you know supersedes and and labeling it in the EIP doesn't really stop them from doing that but I'd rather not give author the ultimate power to modify their EIP in the uh internet standards superseded makes sense um because it basically means this is the way we did it in the past and you should stop doing it that way because if

you do you're going to fall off the network of everyone's going to do it this new way now um for the typical ERC that doesn't make any sense um people can do whatever they want so in the absence I think in the absence of a working group um that's actually taking responsibility for these things so that they can make such recommendations um no there's no one thing can't supersede another except that the community can recognize that oh erc20 is broken in certain ways and here's a new proposal that's better and

so the community sort of on its own either keeps using erc20 anyway or uses the better one but but sorry but I I completely agree but the distinction there is between a centralized protocol and a decentralized protocol because if I if you can only be on one version or the other like you say if you fall off the network doing it the other way then that's a fork yes it can't it can't be a super session because there isn't one network that decided unilaterally that we're all going to Fork so there can only be a sort of opt-in opt out Fork but if you want to Signal you either do the older way or the new way we need some semantic other than super session and I I I lead

more and more towards Fork because the new EIP is telling someone do it this way instead of that way to switch from that Network to this network another term is deprecated in in the case of core um the criteria um the CR the criteria used to be that it's it's basically final once it's on the main net um and the core developers are they can set up their workflow however they like and they're even when they didn't have their own workflow they were we can't prevent the core developers from grabbing something

from any stage of the EIP process or even something that's not an EIP and deciding that they are going to include it in an upgrade um and then then exp poost facto it would be really good to have an EIP describing what happened um but typically there is an EIP um and it will need need to describe what's actually on Main net and that becomes the final EIP and if any discrepancies show up um um the discrepancies are that the EIP does not uh describe the main net because the

main Net's running the main net is the source of Truth not the EIP and at that point at that point I think you need aat to the original rather than New Way confusing to have a new EIP that supersedes the old thep uh that people uh implemented onto the main net this would happen if everybody made the same if everybody they it differently than EIP and it's running on the network and it's you know there's consensus uh and I'll stop talking um because I'm trying to say something

simple and I'm going on and on um actually it's slide number 21 uh so I have just shared a presentation that we had few years ago I wanted to let people know here that superseded was actually a status a few years ago but when we try to kind of simplify the process or unify the process for all core and non core proposal this was dropped I am aware that there was at least one proposal which was into final and in the next upgrade it was superseded by another core proposal so

we used this status but it was dropped and we decided to move on with final only so if we want to bring it back like considering there are use cases of that that can be definitely be under consideration and we can start discussing that but about this particular um call for input do we really have a case to back it up why are we proposing this at this point of time except 1271 okay so there's a security problem in it and it is a like inarguable legitimate security problem and uh they want to um update it with

that security consideration I mean I'm just trying to understand why are we treating it different than erc20 the author of erc223 also claimed that there was some issue with erc20 that led to a lot of hacks then uh the author potentially went ahead and wrote another proposal can't we do the similar thing with 1271 sorry could you ask the question again so my question here is like the solution that we shared uh with respect

to ERC 20 and the author went ahead with the new proposal and kind of educating the community that this new proposal is going to overcome the issue which were there with erc2 that may have led to certain loss of funds oh yeah okay you're talking about like 22 three right yeah yes so can't we suggest the same thing for 1271 I mean if an organization if a project found that this this particular uh proposal has some security issue they can perhaps come up with a new proposal and upgrade their project to that proposal is there any specific reason that we need to stick with 1271

as the number that has been implemented in that project uh it's not that they want to stick with 1271 I mean they do want to stick with 1271 their preferred solution is updating it but I think what they're willing to accept as like a compromise is if we have a link on 1271 to the replacement I mean that is an additional ask and that's really kind of them that they want the community to know about it but I understand there are other ways that can help that particular project and perhaps the community without making a lot of changes in the current process oh I I think we already

have one or two call for input on 1271 K specifically or do we want to have maybe one final round of call for input to this side on this this particular issue that can or cannot we include the superseded part in a final proposal I think at this point we can definitely wait till 7th of February to see what other people think about it and

based on the response that we collect it uh it can be decided all right is there any other final comment or thought that people would like to add add for this particular call for input I think we're good to move on I think yeah so there's another one 308 uh sure so uh this is um a final EIP

where the existing authors want to add a new author to the author list after it's been finalized which they would sorry they would probably do that if that person was an author all along but uh wasn't their authorship was not acknowledged what it should have been is that is that what you mean yes exactly orata I mean as I have commented on that issue as well I mean authorship is not

same as uh the credits for the EIP so I don't see why we should allow any change over there now since it doesn't need any maintenance I'm not understanding for us I think authorship is just literally that you you contributed you contributed to the EIP um um so it's both permission to modify the EIP and a list of people who contributed so in my understanding it is does not reflect credits to the e in the sense that the people who contributed to

the EIP because I mean I don't know the crediting and saying that okay you know we picked our idea from here these are The Inspirations all that is a messy stuff I think I see author of The EIP as of people who would want to make edits to it or edit it or basically maintain it but since it's final and it doesn't need any maintenance I don't see whether why should there be another author to it in the sense that it is also a retrospective step right if uh the contribution was meaningful at that particular time at which the EIP was written we would defin they would defin

itely be a mention so in retrospect uh editing of the authorship I actually don't see what uh basically the benefit to the community is and why it should be allowed because it doesn't serve any purpose if nothing else it it serves a purpose in the resume of the person who should have been recognized as an author and wasn't but it opens a Pandora box to other people who will say that okay you know uh people who might bribe author of wellknown eips to get their name inside

and to pump up the resume I mean we are not there for people to pump their resume right so uh I I actually feel that I I me I strongly feel but I think that we shouldn't do it of course we're worrying about something that's never happened what what has happened I think this is the first first case where we have received this request to maybe update an author after it is being finalized otherwise historically we have seen authors being added whoever may have implemented those proposals in

respective client or may have have contributed significantly as co-author of The Proposal what what has happened is proposals um where one of the authors no longer supports the proposal um and currently that that person remains an author um because of their contribution and in in one case um um did not want to be removed as an author even though they were very much against the proposal so um very well and any other editor who

may not have added their comment if you would like to maybe add your comment towards this issue it would be really helpful making decision by the end of the uh deadline here and we are 4 minutes past time I quickly wanted to maybe mention about issue number 291 and 293 I think the deadline for these two call for inputs have already passed um do we plan to extend the deadline or are we good to close them I think they've been open long enough okay

perfect and um I think I have repeated item number three my bad so we can perhaps skip that part quickly getting into the eips inside because today is also the 31st of January which is the last day for this month so if we uh take a quick look at the eips inside we have two final proposals on uh eips repository one in RS ERC and one in rip so this is the first proposal which move to the final status for rip and uh we have nine proposal added to ERC repository in the month of January and uh two proposal on eaps

repository have been moved to the Stant status the detail list can be found on the links added to the agenda and people can also refer to eips insite.com one other question that I want to ask this group quickly before concluding the meeting for today is the time for the next meeting it seems in the another group chat uh the Discord channel that there could be further discussion of the alternate time do we want to stick with this 1730 UTC or we want to go back to 14 and 1500 because USF and ejs team meeting are at 1600 till 1730

okay ask Matt what is prefer time slots are Sam I think I overs spoke you uh you were saying something uh I was just going to ask um my audio cut out for second I didn't hear the times okay uh I was mentioning about going back to the original time, 1400 or 1500 because uh the later half is like filled with other meetings one is EF meeting at 1600 and U ejs meeting is there from 16 to 17:30 so we can can either start at 1730

or we can go back to 14 or 1500 think I'm okay with any of those it seems most of the participant of this call are definitely okay with 1730 UTC um but as I have mentioned in the Discord channel of e R&D let's hear from people if they would like to maybe change it to 14 or500 but if we do not receive much of the response in support of either of times lot then we will continue to have it at 17:30 UTC all right I think uh we have covered

to most of the agenda item today is there anything else people would like to quickly mention in that case um thank you everyone for joining us today and thank you Sam and gajender for running the last meeting it was a quick one I really hope that you guys run the meeting so it becomes way quicker all right um hope to see you all in two weeks have a good rest of the day thank you byebye yeah byebye