EIPIP Meeting 32

Transcript

welcome everyone to eibip meeting 32 um so uh we are trying to skip the first agenda item that is um progress on erc's repo i do not see lifeline on the call so maybe we can come back to this item later on number two item listed here should we care about people making statements uh regarding the trademark in informational eips i i found that in a comment left by you michael michael you would want to speak more to it sure let me pull up the eip real quick

sorry i thought i was going to be at the end of the agenda so i wasn't prepared i mean it fine if you want to bring it up at the end of the agenda it's fine it's fine i just need to reopen it it's all right closed um so the someone's writing an informational eip that talks about the proposing the appropriate way to use the term ethereum mainnet right now it's pretty used in a bunch of different contexts a bunch of different ways they're basically trying to clean up the language around ethereum when you're like speaking or when you're present presenting or writing a blog post or whatever just this is kind of the official way we talk about the

ethereum main primary network um and that's all all fine it's informational ap so not particularly stringent on the requirements however there's one section in there that uh has a note about the trademark um apparently ethereum the word ethereum is trademarked by the ethereum foundation and so it mentions that trademark and references it and indicates that uh it just it it makes me a little uncomfortable to start having like legal stuff in eips and so i wanted to get other editor opinions on that or other i guess not just editors other

people's thoughts on eips making statements about like how trademarks are supposed to be used for example yeah sounds like a big red flag like i guess to add more cutter there you know i think the ef has tried as i understand it to not use the trademark um except to defend against scam so one of the big i think probably the biggest use case for the trademark um is when there's like a scam youtube account that's like an imposter for the ethereum foundation or for ethereum the ef needs to own the trademark so that youtube takes down that account

um but i think you know beyond that like saying you know yeah it is very weird to try to like impart how the ef would use their trademark in an eip that's not written by the ef yeah it just seems very weird in a lot of ways yeah so so just to make sure that we're all on the same page context-wise i don't want to miss misrepresent this person um the let me just read the text here even though the name of the network is ethereum mainnet which is what the cip is about it will be necessary for your application it may that may be critical here it may be necessary for your application to show this as ethereum like a little r circled mainnet and

include a note like ethereum as a registered trademark of ethereum foundation elsewhere for more information on your obligations on mentioned ethereum trademark c and then it references the uh uspto registration number and the note at the bottom of the terms of use page so they're not making strong recommendations like they're not saying you must use the trademark or anything like that they're just making people aware of it i guess um it still feels it feels weird because no single project you know no project says we're using ethereum tm right like yeah yeah it just seems like like i don't

yeah i i would not include it but that's right so i guess the follow-up question so it's the follow-up question then if if no one wants to uh argue for it um i'm weakly against it i express this to the author they seem pretty adamant about keeping it included um so my normal strategy here would be i don't merge it and leave it some other author or some other editor to merge it unfortunately i don't think there's any other editors in the room right now so that means this will be one of those eips that sits forever unmerged and that feels like a really bad way of doing governance but it's the current way we do things i don't know if anyone has any thoughts on that aspect of it

if this is helpful i can ask the es what they think about it and if they can leave a public comment but i'm not sure and they will want to do that um you know i don't and just to see if they're interested in commenting um like if they are that might help settle things and just move things forward um if not all we'll probably do is sorry go ahead oh go yeah go ahead yeah i'll ask all right so what i'll probably do then if um we don't hear anything is i'll tell the author

i'm not comfortable merging this unless that trademark section is removed uh however um you might have luck contacting the other eip editors and seeing if they want to merge it i believe this particular author has run this problem before so they know who the other author the other editors are and so maybe one of them will merge that sounds good to me oh yeah yeah i have seen that the author has made quite a few pull requests for a few eips and have been an author for uh yeah because that has been you know in in the final stage as well so yeah i'm expecting that he may have some visibility so let's wait for that moving on uh the next item on the agenda is

progress on json rpc api spec in each one dot or repository um i see elite on the call i believe someone from the team also joined but i can't see him anymore alita if you have any updates or if you would like to share something on that yeah so there's progress on it i recently finished east call or i got to draft um i spoke with tomas about kind of my involvement and stuff and tomas appears to be like um recommending me to be doing the project but it's not super clear about like um like there's no like official like oh

i'm the one doing this um so it has me a little bit not sure if i should be putting in too much time um into it or whatever because i don't want to you know waste time um but yeah so we're kind of in a bit of a of a place that is sort of blocking progress in a sense because i kind of need assurance that i'm gonna be the one working on this um but to follow up as well like we are in the process of drafting up all of the json rpcs um and prioritizing the ones that should be done first

i know i mentioned on a each magician's post about this um like about which ones are the most important and pertaining to eip1559 um so i guess just just to kind of like summarize a bit um it's going okay but it's challenging i think at times to put too much time into it just because i'm not like the official person working on it um i'd like to be but there could also be other people that would like to so i spoke with pujo about this as well and were we hopefully posting something soon some sort of um thing

on github or ech medium to invite comment or proposal um i think that pretty much covers it in my experience in this space if you just uh start doing some work that no one else is doing and do it well no one will challenge you i let go to that yeah i have shared the appears that have been submitted by alita in the chat uh it's for jason rpc api if i remember correctly in one of the earlier meetings we decided that we should be providing access of each one or specs to

maybe to mass to kind of have the you know permissions to merge these pull requests after review and when they uh they believe that this is ready to be merged in the repository i am yet to uh no work on that i have received his email uh sorry github uh id yesterday and maybe i'll be doing it today and uh yeah if anybody has any comments on that on the pull request uh it is there one thing that i would like to get more clarity on and i have mentioned it to anita and tomas earlier like the part where alita is mentioning that she is getting the urge like not clarity on what to do when to

do it how to look i mean obviously she's having some pictures but if we kind of create issues for whatever task she's working on and we keep on closing the issues i think that will give us the visibility that uh she is working on these particular tasks and if there are tasks that she may not have time to do and if you would like to invite people to do from like from the community uh we can do that so i believe the post so that we discussed uh could be helpful i think it's also worth um a plan on my end which is like if there isn't clarity on if i'm gonna be the one officially doing it like i don't know say like by friday because that's like a week after

um i submitted each call i think i'm just gonna kind of start doing it just cuz um i mean i know that it's an important thing i like to you know make progress on it so um yeah i think that we can we can definitely follow up with all of that with the issues and stuff and actually one thing that's important is puja do you mind giving me access right access to the um jason rpc repo that would help me a lot um but that's it uh yeah i i mean i'm not sure like uh if i understand correctly one of in one of the meetings when we had to manage on the call

we discussed that you would be making full requests and creating issues and that would be reviewed by a group of people maybe from client teams or micah or whatever the group you have created on discord maybe and then only one person from the team would be having the access to uh so i mean i'm okay i do not have any uh problem doing that but yeah i i think uh getting some clarity on that would be helpful so the reason that i want um the right access is so that way i can create branches um off of the repo itself and because it makes life a lot easier for me um as far as emerging is concerned i mean i think that you can trust that i'm not gonna merge something without approval

um i don't think it's a major concern especially considering the fact that jason rpc spec hasn't been written yet so there's not really anything to mess up um and github also hurting yeah i don't forget that uh please bring me your github id um i think that should be fine that is written okay anything more on this topic okay moving on the uh next item is progress on canonical source

of eips uh i have added the link for wip document that is uh created and maintained by brent alpha i believe that you have some progress on that yeah i basically wanted to uh so i i missed the first item where we talked about progress on creating a new erc repository so and so do we have some people that are going to make that er a separate erp repository or what was the decision on that actually we'll skip that uh we are going to come back later because we received a message from lifeline that he would be late i mean okay okay but but anyway i guess the same issue has to do with the meta eips do we want to um

and and so i guess the core issue there is just we need to decide where where we want a home for everything and so i'm just trying to figure out what would work best for everyone or find out what it wants my personal recommendation is for now we keep we just focus on getting your seeds out and see how that goes and then if it goes smoothly and well then we can talk about moving other things out but we should probably plan for the kind of medium-term future that only ercs will be extracted until such time as we actually succeeded that so does that mean we want to leave the like eip1 and the med eips in there or do we want to because i know that was proposed pulling those out or do we

so what would you like to do with that so for for the general meta informational ip eips i think leaving them is fine uh eap one i feel like is very special and so if we believe that there's a better place for eip1 to live right right i'm not against that i'm also fine with it staying with the other meta eips for now first again is all personal opinion so in other words it sounds to me like then so on the eip eips.ethereum.org we have um tabs for all and for core and meta and all that but there's also one for erc so do we want to leave that tab there

but when you click on it go to the other repository or something like that or in a perfect world it would so in a perfect world i think we would still have the same page the same page layout and everything it would just pull from two different sources i suspect that the engineering effort required to achieve that is significantly higher than just making that yeah just link out yeah have someone maintain a whole uh erc repository and stuff like that so any i guess that's my question is where do is there any way we can expect someone to do all of that extra work i guess is my question because if we can get someone probably not realistically

right like historically we've struggled to get engineering work on this sort of stuff and so i think that we should probably plan on not getting that engineering work done in which case if we pull extract out or if and when we extract out the ercs into a separate repo we'll probably lose them from the all list so they'll no longer show up in the all section of the eips page and then that erc tab we can keep the tab but the tab will just now link out to a separate page right so erc's not ethereum.org or whatever it's just and that'll be like a link and we just put it like at the end we rearrange it so it's at the end of the list instead of the middle um just make a little more clear that it's external maybe put a little uh external link icons next to it or

something i don't know okay great sounds good so um there's also the other talk of moving towards a model that the ether two has where we um just we it sounds like we wanna the talk there was completely get away from ercs and just have pull requests against the um the the python uh script and stuff like that is do we want to worry about any of that right now or or is that future stuff or i think that's sufficiently far in the future that's probably not worth worrying about right now i think it sounds like most of the people involved in the ap process would prefer that um and in fact the feedback i've gotten from just core devs and whatnot also

seems kind of generally positive and so i think it's one of those things that like everybody kind of agrees yeah that would be nice that's a good idea but the effort involved in getting to like mvp for it's like the very first version that we can launch is relatively huge relative compared to our manpower and so i would not plan on that or build around that at the moment i think it's too far in the future to really plan for at this point okay so so let me see if i've got it all right then so so we are gonna continue on as planned and we're going to leave room for if we can find some resources to split out erc's we will hopefully do that but for the time being we'll just keep on working with what we got and

and i'll keep working in that direction this sounds about right yeah ercs i'm pretty sure at this point are going to be extracted it's just a question of when um the rest of it is is very much uh more in the air and questionable but that being said the extraction of ercs should be from the point of view of the organizational work that you're doing i think the extraction of eric sees is going to be a relatively small change to that like it's literally just like it'll the eip's list will shrink a little bit because it will no longer include the rcs and that link at the top of the page will be an external inconsistent internal link that's okay i think basically we should also make it

pretty clear on like the actual ethereum network page that this has changed right because one big problem we had when we moved say like the hard fork mellows out of the eips is now nobody can find the specs for the hard forks so i think we want to be pretty like explicit where this stuff is moving to um even you know like i agree like having the link there is is good but also just having probably a note or like a warning at the top of eepson ethereum.org that says hey if you're looking for ercs this is the right place um yeah great yeah that's brilliant i'll take the notes down and make sure we include that so yeah thanks for all that and yeah just one note also on the idea of like

changing uh to match you know the e2 spec um i suspect if we do that we probably still will keep core eips as like the way to define those changes maybe because basically what what the python spec would be is you know the current spec as is but when you propose an idea it's not gonna be part of the spec right it'll be something that's like separate from it um and you know there'll still be debates about what gets included and what not and it's probably very messy to have those live and just like open pr's to this bank and that are not merged so i would not be surprised to have something where like

you have the python and then once an eip is accepted you just open a pr against the spec and actually update it or you only open a pr per hard fork or something and you say you know this is like the changes for london which is kind of what etude does um right yeah so so it doesn't mean that like the eips will go away it just means that it's almost closer to the yellow paper going away than the eip repo okay that makes sense so so basically it sounds like then um so there's still we there will still be some kind of proposal for eips but but there'll be a clear um gate so that's all ahead of of a decision being made and then once it's

accepted then the pull request is done and then it's officially pulled into the spec is that something like that right which is roughly what i think we should good i think we should probably talk about this more because i think everybody else that i've been talking to is assuming the opposite of what you just said which is that we would just submit pr's against the spec correctly and there would not be anything it's like a very naive assumption given the amount of given the ratio between the proposed eips and the merged vips right like we have more proposals than we have things that go into hard forks so yeah and to be clear i don't think that's been decided but yeah it feels like it would be very weird to have like

100 open pr's against the spec and then we picked the top five of those and then the rest just like i don't know gets closed or something it seems odd but yeah it's not like that out of curiosity what makes that odd to you um like whatever the fact that so the fact that there's no like um i guess artifact after right like take trunk pal just to you know take something that didn't get in that's important what do you do with like the frog pal pr after you know it's not in london exactly um whereas now you know the eip is still there um and i think that's kind of good that there's

like a long-term artifact to it um and that's i guess that's like a political one but there's also the case where like uh eip was at 2200 which supersedes in other eips and whatnot so when eips start building off of each other it feels also cleaner to link like an actual thing than to link like this pr supersedes this pr and whatnot like it's not this would be for it'd be for core eips only so we don't have to worry too much about these supersedes because we'll just be updating the spec to now say you know before this blocks like the spec would say prior to some eip the spike would say this is the rule and then you the ip would make a change to the spec that says if fork block less than x this is the

rule else yeah this rule kind of thing um and so we would still retain the history aspect um for the the prague pow and similar i mean there's a lot of programs one example there are many here right uh vips that are proposed and they're reasonable and they're generally good ideas they're well thought out and they deserve to exist but they're not part of ethereum i think that's the class that i think we're talking about here um for those ones my personal view is i'm not opposed to just leaving them open pr's um there is from a management standpoint we have to make sure we don't get the position where we're we can't manage all the opr's but i think with github labels we can handle that pretty easily

and just say like this this eip is like considered for inclusion label would make it so you can filter and see okay what's actually being considered right now instead of all the things and then things that are like um explicitly like were considered but rejected would have maybe another label so you can filter those out easily and so i feel like my gut tells me which my gut here is very weak on this but my i weekly feel like we can make it so having hundreds or thousands of open pr's is not unmanageable as long as we have a good system in place for managing that oh okay so yeah i'm guess i'm having troubles

uh understanding the difference between what mike and tim are saying it sounds like micah both micah and tim want to split apart there's the governance part where things are being proposed and people are trying to get people on board and then there's the bridge when someone something finally gets accepted then a pull request is done and officially makes it into the spec so the difference is is uh what i'm proposing is that we as soon as someone has an idea for a change to the spec they can open a pr and make that proposal as an official spec change so like that is the first step in the official process like you can there's idea steps before that where you like just uh you know chat on forums or discord or whatever but once you want to make it official

that you want to propose a change you open a pr that actually changes the specification and then that pr may sit open for months or years depending on how long it takes before it actually goes into hard fork and the act of merging is like okay hard fork launched kind of thing and so that the merging into the spec means this is what ethereum mainnet is now whereas tim is suggesting that we have some other process for iterating on spec changes that is separate from those prs and the pr step is very close to the end of the process and so you submit a pr perhaps when we decide on fork blocks or when it goes onto a test net or something along those lines oh okay so you're at the very end so you're saying include the proposal and governance part in the pr

process it's just you tag them it's not accepted yet or whatever yeah they'd have a label that indicates this isn't uh this isn't considered for inclusion yet or this isn't um and like part of this is you know matt has oh matt that's your good so um is that like client matter is that a different matt i don't actually know your last name uh so matt has argued with me in the past that the eips repo or the ethereum specs repo should specify ethereum maintenance like that's the thing that it should be specified not ethereum like things and so if we went down this route i think we would be moving towards that world view where

eips are not a general thing or this i guess ethereum specs repo it's not a general purpose thing this is specifically the definition for maintenance it is not the definition for things that are like mainnet or even the test networks this is specifically the definition for maintenance um okay it does create complexity um for testnets that's actually didn't really think about until now but like if we're doing prs to a specifications repo um then and they don't get merged to the specs repo until main net then defining what is rinkaby is no longer trivial like it's no longer just oh it's eip155 but if you have

like branches i mean it's not super nice but like you could have branches with like the full spec for the test net and then you could have like a tracker where it's like these are the pr's because like they're still going to be kind of like eeps but it's like these are the pr's that we're adding just so it's like an easy place that someone can look and see these are kind of the chains that are being discussed so so actually this this is what we're discussing so do you believe there should still be core eeps or should there only be pr's against the spec i think they should only be pr's against the spec i think that you know what i've felt after trying to write several eeps is that you end up writing the same thing over and over again for like you know

half of the eep like you're trying to describe the situation and you're trying to set up like what is mainnet when in reality like if they were just pr's against the spec you don't have to do that anymore you just have to say here's the difficult spec and then you can just focus on the rationale and the rationale would that be integrated into the spec like maybe some sort of commenting system or would that be just like the pr description kind of thing is where the rationale lives um i mean that's a that's a good question um i think like in the pr is okay because that's how a lot of other governance systems sort of work as far as i'm aware like if you look at

like the rust language like how they do rfcs it's like all just prs into the rfc repo and the discussions are kind of there i don't know if they have i mean it's like different obviously like our again rfcs are not quite the same as a consensus definition of what mainnet is i don't think i have like a really strong opinion on whether it should be in the pr in a separate document it should wherever it is it should be accessible pretty quickly and it should be documented historically okay i think i've got that i'm going to try and write

some of this awesome go ahead just for you brent uh everything is up in the air no one's decided on anything right so that's what i'm struggling with it's i i appreciate your your struggle and frustration um like i said i would folk work under the assumption that we still have core eips we still are doing the aap process as it is today maybe at some point in the future the doubt process will change but for i think your work you can kind of just ignore that the only thing i think that matters for your work is just the ercs are almost certainly going to be split out from the eips okay that part i'm pretty sure is going

to happen and hopefully in the very near future okay great yeah that puts a bounding box around what i need to do so okay i'll move forward to that thanks so much for the help yep thanks everyone um yeah so i have i also wanted to give a small suggestion or proposal i don't know that is something coming up in my mind like whatever we have been discussing about like that may happen in future about like uh managing it through um specs using pull requests for updating the specs of the main net uh i find that very similar to um each tool process right so i was wondering like we are working on london upgrade right now i know this is not the right audience to kind of

decide on anything but i just want to share my thoughts uh like right now we are working on london and we are following the process that we came up uh um last year during like a long conversation in this eipip meeting itself but for the next update maybe shanghai before the merchant if you are expecting that i think it it's worth giving a shout out that we should try this um pr stuff i mean i don't know i do not have any clear picture right now but my my thought would be like feature baseball request if somebody wants to add something so yeah we can't do that if we're doing shanghai because there is no spec of ethereum one um it's something that's possibly being worked on but it's definitely a prerequisite like we don't

have something to do prs against right now um maybe for the merge we could do it um and actually that's what they're doing on the e2 side but if shanghai is just like a feature for um the odds of having like a stack is very low and i wouldn't want to put that as a blocker yeah i think unless we hire someone full-time who already has experience with ethereum um realistic timeline for getting a full spec written is probably like a year even if we hire someone full time i think realistic timeline is probably a year yeah and we're basically saying someone needs to write a python client that is specifically written to be

readable not to be fast like the currently is pi ethereum but it's designed to actually execute relatively quickly and therefore it's harder to read this is a a rewrite of a entire ethereum client that is explicitly designed to be readable yeah and i think there's a few different people or groups that are somewhat interested on it but i'm not sure they've made that interest public and you know that they're it's more than a hobby so like yeah i it's something i i've been spending a bit of time looking on and talking with folks who might be interested but i i doubt yeah i think at the in the best of best cases like we would get something

six ish months from now but that would be too late for you know shanghai if it's a feature fork and possibly for the merge too so yeah yeah okay i mean yeah that would have been a nice to have feature i mean obviously nice to have process in place but never mind we also have to consider a lot of other constraints along with this process okay so one last thing that i wanted to uh discuss in this topic particularly about my types i don't want to bring like the entire thing here like moving off eip1 and all just one thing like for this past two upgrades we are having a dot mda file for berliner taught md file for um

london so uh what do people in general think about if we create uh like not create if we like kind of uh move the uh meta files which were for earlier upgrades here or maybe a copy of that no copy wouldn't make sense but yeah i'm moving sorry move move them where uh to the eat one spec like we have like network uh upgrade section in which we are keeping all upgrades we are keeping it for london we are keeping it for berlin and even if we we have i believe uh there is a file created for us as well so we can move it there are you talking about moving

the old hard fork meta eips there is that correct yeah yeah i'm a big fan of that i would love it if someone just sat down and just kind of transcribed the hard fork metas over to eth1 specs and then my preference and this is a weak preference not as strong as that i have in the past my preference would be then we actually remove the them from the ips repository and just replace them with a pointer um similar to what we did i believe for i think we did this actually for berlin so if you look at the hard fork the berlin right meta eap it just points at ether1 specs repo if we were to move the like retroactively move the other ones there

i would be in favor of also having them just have a similar pointer just to kind of encourage people and reinforce that each one specs repo is the place to go for hard fork meta information so the challenge is each one specs repo might not exist in a year so because if we merge so i i'm fine doing that but i would wait basically a year until we have actually harmonized the e1 specs any two specs repo before doing it because then you'll just end up with a bunch of broken links um but i don't mind taking that on once like i guess the first thing i feel like i need to figure out is how do we merge each one specs any two specs and it's not the most urgent thing right now but i think after london it will it will kind of

climb on that list um and once we have that like you know ethereum specs or whatever then uh yeah i i wouldn't mind putting a bunch of pointers and adding the past hard forks um but right now yeah the links will just be out of date in six to twelve months sure so are you arguing that we should not back port the uh hard forks at all or just we do back then but we don't back link to them i i think we should back link to them um but once we have a backlink that we're fairly comfortable will be stable right like so i don't mind so if we have you know each one or if we link them if we battling them to each one specs and the each one specs repo goes away in six months

then we have a bunch of broken backlinks we've forgotten about um so if we merge each one any two specs repo into like ethereum specs post merge um then we'll have like one repo we know is going to stay around and and we can backlink them there and i think that's fine if i understand correct we are ultimately planning to move out everything uh out of mata i mean meta eat right so anyway we are going to move it out of eips i mean like it is repository at the end of the day so if we bring it to the ethernet repo right now maybe it will be pulled to the e2 or wherever we decide to move like merging things it will be pulled together but the link from so in the if we do that right now

you basically go to all the meta eeps and you say this keep is not not uh accurate go to these one specs but all those links will break when we do the transition and people are already complaining to me a lot that like they don't know where to find the hard fork specs and whatnot so i'd rather everybody knows that the hard fork meta eeps are a thing right now and i'd rather just do this transition once than do it twice um because now it feels like it's messy and nobody knows where to find the london spec or the burning spec and so i feel like there's there's three three options here one we do keep all um hard fork eips in the aip's repository until

we're ready to fully move them all to ethereum specs or ether specs or whatever or we have all of them in each specs asap and so that is the canonical source or we have what we have right now which is legacy ones are in ethereum.org meta and the new ones are in each specs i feel like the way we have now is kind of the worst of both worlds because there is no con canonical place to go to look uh my i do have a preference that we move the canonical place not to be eaps and we start training people on that sooner rather than later but it sounds like tim you would rather go back on our decision to drop eips

from meta or sorry drop hard fork eaps no so i guess yeah what i what i was advocating for is your third option which when you put it like that does sound pretty terrible um so yeah um in that case yeah i feel like the way you framed it i would probably rather move all the yeah all the meta eips to the e1 specs repo but if we were to do that i think we should give we should bring it up on all corners and give people the chance to chime in and whatnot like i don't want to just do it overnight and and then you know people are like where the hell yeah so these these historical eips are a little bit easier i think than london shanghai and berlin because

those are new the historical ones aren't changing so it would not be terrible if we had them duplicated at least for a period so we can leave them in the eaps repo as they are now don't touch them and then also have someone go through and transcribe them over to one specs and then we can tell people you know the right place to look for uh hard fork changes is the ethospex repo um but people who are still going to the old place will still see the old stuff so you'll still see yeah i like that what we could also do is add a line at the top of every one of those saying you know like this like mela eaves are no longer being maintained here you can see this

you know in the east one specs repo um sure and then if the uh if that link breaks it's not uh critical because we still have the spec right yeah and we gave we gave you know like advanced warning like say that that link breaks in a year then there's been advanced warning for a year that you know this is not the right place um right i mean uh yeah this is uh this is very similar to what i was having in my mind like like we have berlin.nbc and in that we will be having everything that was there for homestead meta eat whatever it was uh uh just that even like my type number would not be there but the content will be there and in that uh we are going to just add a liner

that this is now available on um homestead md eat one dot or spec repo so yeah if you have if you have someone in mind who wants to go through uh those hard fork metas and just kind of port them to ethon specs repo i think i can do it yeah yeah i'll be happy to help him yeah i was also wondering if i can look into that yes they're relatively easy to port i don't think it requires any specialized like ethereum core dev knowledge um it's pretty straightforward process just kind of time consuming yeah sure cool so at least we are good on this part uh so going back to point number four where we

are discussing about canonical source of eips ah just to summarize this uh for brent brent he has to continue working on ignoring this fact which will be coming in future uh just work on the erc part and extraction of that for new destination of meta eats not all um except eip1 we would be moving uh meta eats a copy of it to the ether dot or spec repository and for other uh proposals core interface and network uh we are like kind of tabling it maybe we will discuss that in future that helps a lot thanks okay so moving on uh the next item on the agenda is a progress on

github repo action bot uh i believe that's going to be really quick elite on my car if anyone would like to um yeah i can hop in here so it's nearly all right they can make you just check right now um to see how it's doing but i think it's fine um we want to make one change potentially to it but this is like small things but overall progress is good i'm hopeful that we can do a murder like kind of activate it soon um mike and maybe you can fill in on his plan for that but overall going good it's uh currently more reliable than our existing bot

like our existing blot hasn't merged like four or five eips this week whereas the uh elitist spot has flagged them to be merged i don't know if it would have actually merged but it's at least gone green right so i mean now if i understand this whatever it has bought is working right now it is working from her deposit right it's not like actually been merged here right um so the bot is active on the eips repo or just not like essentially it's a stubbed version so it doesn't it doesn't have the capacity to merge anything yet but it will in the future um and it's so it's basically running in production

but just not um actually merging things is it still part of your personal github org or is it part of the ethereum organization oh yeah it's still my own github so we do need to move that over to ethereum one right uh so i believe uh to mark this action like you know completed and this thing is done uh we would want to move that to etm github repo because i don't know it appeared to me like it's coming from her personality when i saw that comments from bot that was really good every time i see editor on every proposal yeah so we need to we need two things one we need to meet an actual repo in the ethereum organization and

two we need a execution key that has a nice spot name not alita so when you say that repo on ethereum [Music] do you mean a bat repo wasn't there such a thing earlier like there was bought earlier uh i don't think anyone's created a bot repo in ethereum organization but maybe they have and i don't know about it okay maybe i'll make a note of that we might want to get into it so i'll try to get into that yes just uh whoever i don't know who actually has rights in the ethereum organization to create new repositories so i don't know who to ask yeah so um it's the ef devops team so you know i

don't even have the right um if somebody can send me just like a quick note just giving some context about the bot and whatnot i can get it created right so with that note i was going to come back on uh agenda item one that was progress on erc and i believe we need help there i'm not sure if we have this ercd book created yet do it doesn't even have any information on that i think it's the same problem we just need the right people to go and create right new repository i don't again i don't know who those people are say i was trying to reach a couple of people but i had no luck or maybe uh tim if you can help us on that we are looking for someone to

create uh yes repo and get access to micah and lifeline at least so that they can start the initial work and then yeah so i guess yeah so it's the ef devops team so um the only thing i would need for both repo is just kind you know some background and summary like they want to understand why they you know we're creating the repo so if somebody can just send me kind of a quick paragraph that i can copy-paste and give to them um that'll that'll help along with the who should be like uh admin on the repo i'll i'll get in touch with you and i'll provide you the details perfect thanks yeah for erc i'm very clear on that path for bot my club would you want to add anything um i can let uh elita probably can

describe the bot better than i can so i'll leave that to her yeah i'm gonna reach out right now with the description um i don't know that so sounds good uh we probably need to bike shed for an hour or two on the name of the bot as well i think i can bring it up in the next meeting as like first item i discussed okay okay um that's all about it i i'm not sure if we have anything more to discuss on erc it is created oh is that the thing we're waiting for lake client to show up for the first agenda item that we delayed to the end yeah right so yeah i was wondering if he has any more updates

or he's aware of anything sorry updates on which one uh erc repo but i i understand oh no yeah i haven't just waiting to get it created okay okay so i mean like if i understand uh right after it is created we will start moving and we will have to publish a like kind of announcement blog like mentioning what all changes we are doing with that process and um maybe i was wondering if we we should start adding questions and concerns with erc i have been receiving quite a few comments when um with nfts and all they they are having some discussion around

this versus business standard and also these kind of stuff may be added in future eip record okay so uh that's all on the item i i think we can go ahead with the action item and summary from the last meeting the first one is create erc repo we are still working on it and i will probably piper oh thank you details how's it going you're mike's life yes oh sorry guys i was just mentioning this medium they

just told me why mike is live your mic's still alive matt okay uh so the next item is update eips.etm.org with changes to eip and erc repo i believe we are going to see this like in our next one or two meetings so i mean we have to work on that create a boundary for json rpc api spec i'm not sure if we are going to create a bounty right away but i am expecting some kind of write-up on that maybe from a later uh that would be helpful and complete eip report we discussed this today determine pay rates for eip editors i don't know i'm gonna talk to uh

mala people for that uh uh i have a meeting uh this week uh so after the conversation maybe if we can get some kind of clear picture in that one funding part i will be happy to share that in the next meeting um the next item is 31.6 it's add an erc dictated editor for now i'm considering like client for the editor of erc uh as he has shown interest on working on that but in future if we need more and more people we'll try to reach out to community so that's all about it and anyone wants to bring up anything um so there is one thing which is that there is

more work to be done with the bot and moving forward um i'm kind of awaiting like uh funding for that so that would be one thing to look into i don't know if that's more of an ech meeting thing to talk about though bot funding uh yeah for continued work beyond the initial merge so like the stuff we talked about today that's all gonna be done that's included in the initial um implementation but then there's other work like transferring over the circle integration to github actions um adding some more features to the bot more considerations along those lines um i think i could use help here from

the eid editor so eap additives like whatever we have uh decided for the first task i believe we have decided on a fixed amount to be uh for that work to be done and whenever we come up with any kind of enhancement work or nice to have feature that has to be added on eip bar if we can just create an issue maybe in this eipid repo or the ethereum dot eip github wherever and give an estimate of time or like you know work needed the feature that has to be added that would be easier for cathedrals to follow up and you know kind of provide funding funding should not be a problem that is something that we would like to cover from the edm cathode side but getting an estimate of work and how

much funding is required would be helpful so i think it would be it would be easier for everyone except for the cat herders if it was if we were able to hire someone to kind of work somewhat unboundedly at an hourly rate or something like that or salary just because there's a number of kind of small tasks and often in engineering the cost of estimating how long they will take ends up taking more effort than just doing the task and so i'm worried that we would end up wasting more time and money on just doing estimates than we would on just having someone that we could kind of like a regular person who would go back to and say hey you got some more work

start clocking hours or whatever the process is so yeah i'm planning to have a request shared this time for like next quarter maybe for an on-call engineer one hour per day kind of like 20 20 hours a month or something like that so i hope yeah something like that i think would uh work much better than trying to figure out like how much each project costs just because there's like lots of little things that i think we could really benefit from having just an engineer who was somewhat familiar with our process and who we can kind of go back to is this specifically related to eip editing or a different set of tasks yeah yeah eip stuff uh it's um like yeah bots that help us

do editing easier make make the bots better improve them uh there are also things like we talked about this whole thing with the ercs or cips we want them to kind of share a numbering system and so someone could write like some tooling that makes it so we have a mechanism for getting shared numbers so they don't conflict don't overlap um there's miscellaneous stuff like that yeah would definitely be probably the number one then my next question is is this work that's already happening um like micah are you would you consider yourself as a person to do this kind of stuff or are you trying to get other people to it is work that is not happening um because we don't have we don't currently have anyone like we have everyone who does eip

editing uh is an engineer but none of them actually do engineering for the ap editing the last person who did a significant amount i think was nick johnson and that was like two or three years ago i'm here with the original bots and since then we basically have you know we have again we have engineers who are editors but not acting as engineers if that makes sense okay so but are you proposing like that you would be doing this work or you're saying oh you know very much because there should be something i'm suggesting yeah there should be someone elita has uh done workforce previously on the bot she recently wrote and so i would be fine with her being that person or someone else like i'm not particularly attached to

any one person like more care but that there's somebody that was another point of consideration like i'm i'm requesting this funding for but i may not be able to understand to whom it has to be disposed or uh like you know when and how much if it is just on a monthly basis we are requesting for like 20 hours a month or so uh we i cannot say for sure that it is uh secured until it is actually secure uh but uh when when a job comes if we keep on posting that this is this is supposed to be done and this has been done in this month that would be really helpful for a lot of us yeah i think having an after the fact

just like what was worked on shouldn't be too big of a problem that's much easier than trying to do estimates of future work yeah just submitting invoice sounds good sounds good to me um okay these are all good conversation i'm very happy that we made some good progress today i mean like every meeting we do but uh yes uh there was a lot of clarity i was i personally was looking for so thank you everyone for joining us today and i hope to see you all in two weeks please keep sharing any thoughts any comments any concern that you would want to bring it up related to process improvement of ethereum like ecosystem um make a comment on agenda or you can

reach out to us all the members of eipab have a good day evening everyone see you all into thank fuji thanks thanks