EIPIP Meeting 36

Transcript

all right welcome to eipip meeting 36. i have shared the agenda in the chat and the first item on the agenda is evolving eip process so we have been discussing this from the past few meetings and i wanted to bring it up to this meeting particularly as an agenda item so we can discuss how we are looking into the changes that that can be expected with the merge and like future upgrades so uh yeah i like that if you would like to go ahead and share your thoughts on it sure um so we originally like got this idea from kind of how east 2 has been handling discussing core changes and

it feels like the way you know the way they do it they're able to kind of create just a diff against their specs since they have this executable pi spec it's easy to write some code that actually implements a feature that's being discussed and then people can focus on discussing like the actual mechanics of that whereas for each one right now if we want to propose a core change we need to write a full eip and that eip almost always has to redefine a lot of things in the system just to build the scene and be a complete spec i think 1559 is a good example of something that basically implements uh not in working ethereum clients just

to show the things that it's trying to change and that's kind of like where our motivation came from just seeing how things are not working as well for either one and how they've been successful in these two so we've been working on this pi spec for about a month now and the goal of that is to be a complete implementation of ethereum in python and be of a format that's very readable very modifiable something that's not doesn't require a lot you know over engineering it's not um very pythonic it's just focused on being incredibly clear and

concise and it's not really clear to us how to go from having that spec to like enforcing it as this thing that drives forward core changes so i'm curious if what if people have thoughts around that i don't think that eips or like the concept of them will go away because i think that there is a lot of value in a lot of the pros that goes into an eip just defining like why do we want to make this change what's the rationale for these things to me this is you know really replacing the specification part because to me the specification part is where we're

creating like a lot of duplication so if anyone has thoughts on paths to requiring eips have diffs against this spec be curious my personal preference for those that are new or just tuning in for the first time i'll repeat it my personal impressions is that we just have prs against the spec and those pr's would include the motivation rationale stuff like that i know a lot of people disagree with me on this i believe that motivation rationale etc is transient for like a better word like it does it's not something that needs to

survive forever like we don't need to you know have a permanent record of why it was decided that we added chain id to uh specification four years ago or whatever it was um that being said i have no problem with storing that information somewhere but i don't think it needs to be like in version control i think it's fine if that's just like on a doc site or inside a hackmd article or in a blog or something like that like i feel like we're in a youtube video where a peep and eat type video or someone talks about it like i think those are all very reasonable places to store motivation and reasoning for things i think the spec is the piece that must be stored in version control system and have history and like be easy to diff be easy to see the

change set stuff like that so so yeah so i'd my preference just put all the other stuff that's not the spec itself into the pr and then it's okay if that kind of goes away over time i think like one interesting model that we could learn from is how rust does rfcs against the language they seem to be similar to eaps in a lot of ways they have these things like summary and motivation and talk a little bit about how did they come up with this idea and then they link to github prs and issues the top that either like implement these or

places that a lot of discussion happens on those so i you know i tend to agree that i don't think eips necessarily like the text around it or things that have to be version controlled and live forever but i do appreciate the ease at which you can find the stuff like i'm curious about uh some certain feature and rust it's really simple for me to pull up the rfc and then i can immediately just read like a brief summary and these are things that are like kind of informal they're not really really long things they're generally just really quick summaries and like motivating reasonings and then it links out to these places these github places where i can see okay here's where like a lot of

discussion happened these are kind of the entry points and so that might be an interesting way i think it like kind of removes it it avoids fully removing this idea of eips like i'm not sure how a lot of people feel about that i'm afraid that a lot of people will say oh well we like eips that's what ethereum is and here at least we get to keep those exactly what they'll say yeah so yeah i'd be curious to um unfortunately the problem is it's just a different format than we have eaps already like

it's a little more informal it really just focus on linking to these github things and so yeah anytime we make a big change to the eeps repo it's not clear how to retroactively apply stuff or if they should be retroactively applied at all so on the um thought of removing the idea of eip like completely um i mean maybe i am in the cam that i would say that let it be there for some more time it's really helpful for new people like i'll consider myself to be relatively very new who is trying to understand the process and read about these proposals while doing my research like earlier

when i learned about eips and proposals there were different categories i got it from eip1 and started reading about it doing my research but while my research i i came to know that there was eip4 which was actually superseded by eip1 and there we get all these types and categories so if we find the history that would help us connect the dot so maybe we can keep the history but the template how we store it could be different maybe in the if we say for example if we want to keep it in hack md let it be like it's dot md file is also not bad maybe we can change in the uh template of eips and move the technical part directly as a pull request and keep the

other content the relevant or the text part in this hackmd or maybe dot md file that could be something that we can think of another idea if we want to do a slow transition like we don't want to just go all in we could just keep the eips as they are and just change so that the specification section now just needs to link to a pr against the specs repo and that's it and anything else in specification section is invalid and that's just the entire specification section everything else stays the same that would be a very easy transition it would vary i don't think anyone really disagree with that strongly um it's nice and simple and

make sure that we're getting keeping the specs repo up to date and it gets people used to doing stuff um to the specs repo but it's uh non-contentious i'm not a huge fan of it just because like i would like to do a bigger change but i understand value in taking the wins we can get and that might be the only one we can get yeah sorry go ahead yeah micah mentioned that that takes away the contention but that just pushes it over to whoever accepts that pull request into the spec right

sorry i meant it takes away the contention about of changing the ip process is all like it's a small change to the the process itself which is unlikely to get a lot of negative pushback whereas if we try to do what i would like um i suspect like matt indicated everybody's gonna disagree with it and we might gain nothing um by trying to do too much of one that's right uh yeah i mean uh i am in very much agreement with michael's proposal about uh having the spec section uh submitted as a pull request and that's how we make changes so like this idea looks good to me but yeah obviously i'll be curious to

know what other people think so that would be a pull request against a python a spec running python spec which doesn't exist that would depend on that existing right is that what you're talking about yeah like client is already working on that right now and i have shared the full request that is submitted to eth1.ospac repository okay so there was this another idea of like when we are talking about network upgrade and network upgrade process there was another thought around uh kind of for differentiating the

the category of the proposals right so there are proposals for protocol changes and there are some for future changes is there any particular thought on like how to deal with that because uh it was brought into attention like it sometimes it's it's take time for any any change that is dependent upon an upgrade to come and include that improvement proposal and by the time we are on the upgrade that proposal may have been superseded by something else or may not be valid or something else came up so is there a way we can deal with this kind of situation what do people think generally are you referring to

like the debate on eap 3074 and yeah and accountability yeah yeah i mean i still like very much in the camp that there just needs to be a little bit more leadership in at the core layer in terms of um i know that's crazy thing to say but and i'm not asking for like a dictator or something to say this is what ethereum is because i say it is i'm just i think that there are already like informal leaders who have ideas of things that you know we should be

doing and working for i think like vitalik is a has been a great leader of ethereum he generally has a list of things that he thinks is important for the protocol to do and we kind of like see those things manifest as time goes on like we are seeing him talk about these things like extending the address space to 32 bytes uh state expert these are all things that are kind of on his list and i think it would be would be good if we had people a working group who spent time and tried to like build out saying this is like kind of informal path for ethereum and here is like how we kind of like want this road map to happen because otherwise you end up with teams like quilt working on this

idea eip3074 which is a very useful change to make to protocol right now and then we i don't want to say blindsided but we didn't really take into account these things that were like theoretically on the roadmap five to ten years in the future like quantum resistance and fully removing eoas and so now we're kind of in this deadlock where until someone actually does some research and thinks about well how can we move away from eoas and actually have smart contracts in the protocol maybe how could we move away from this sec p256k1 curve there's nothing that we can really do because people can always just kind of like sit back and say oh there's these changes in the future

that may not be compatible so i think that if we had a little bit more leadership and have a little bit more responsibility delegated to people for like certain areas as in you know you are kind of the people who are in charge of looking into these types of things improving the ux of ethereum improving state of ethereum and we like informally have a lot of this stuff but it's not nothing is defined there's no there's zero structure around these things yeah i think that is what uh uh what we can do as a group here in this eipip meeting like can define a structure i

was looking into like older proposals and i found that the abstraction of transaction that was originally you know written by vitalik that is also still in draft uh status right now so there are these are important uh proposals these are good proposals but they get lost maybe because we do not have a process defined for how to deal with these kind of proposals similar similar thing was also there for some of the networking layer proposals proposals are implemented they are being you know deployed in a client and they are being used but they are still in like older status i mean maybe because of author forgot to create a pull request but

i believe sometimes it is included in upgrade and sometimes it is not so that's a lot of confusion around these proposals that's fine but as a group i'm thinking if we can do something about it or maybe can define because we have like great minds here all the eip editors and people who are actually involved into processes are here so can we think of something it's a very hard problem this has been solved in traditional business but the way it's solved is a way that kind of goes against the spirit of ethereum which is why it that same solution doesn't work um like you know traditional company you would just have when i say it solve this business you mean hierarchical business the guy at the top makes a decision and everyone goes in line right

um yes like in a very simplified version usually there's a lot more delegation involved so you have someone at the top who is doing very broad strokes directions yeah it's definitely hierarchical and then you know there's disagreement people go to the next level and the next level solves the disagreement yeah so if you get into a deadlock specifically you can escalate up and have somebody call and even if that person doesn't have actual authority like the structure is flat just having a tiebreaker like having someone who just makes a call often is very valuable um doesn't even matter what the call is more often than not like you just have a business decision that needs to be made

it doesn't actually matter what's decision is made it just a decision needs to be made and ethereum struggles with making decisions we saw this with product proof of work it's like the canonical example of not being able to make a decision and resulting in massive amounts of engineering waste because just because we couldn't actually decide on what to do um whereas in a traditional company you know you'd have someone would have made a call like you know long before you spend thousands of engineering hours on both sides someone would have just been like we're doing this or we're not doing this yep that's it doesn't even matter like again it doesn't actually matter whether you do it or not what matters is that a decision is made that is more important so i think the uh

to cut myself off i think the solution we need is a way to make decisions on contentious topics um that isn't just like do nothing like do nothing is currently the strategy for resolving contention so if you had a petition system say we want to let's pick something controversial like recover some funds hundreds of millions of dollars of funds lost in the wallet and and you build up a petition that describes the change that's going to happen and then you start getting people signing vitalik says yes i support this and other people start supporting that and then we have diff of course a ton of people that dislike that and so they create a competing camp and people also sign

and support and but anyway the bottom line you guys recognize i'm just talking about it i tried this all decided yeah we tried this before in the past with like the the dow fork for example people tried all sorts of polls and just like sentiment analysis the poll is completely opposite of what canonizer all a poll does is measure disagreement and canonizer is completely different than that so yeah so yes so the the issue it often is that we we get we get into a stalemate where everybody knows what everybody else's position is like at least within the courthouse like there's definitely within the

community there is lots of misinformation and lots of uncertainty and lots of understanding within the core devs at least we can usually get to a place where everybody understands everybody else's position there's just like there's some core premise that people just fundamentally agree on like some like kind of root belief system sometimes it's a belief system um sometimes it's just like a disagreement in style like just i was raised this way and this was more comfortable for me versus i was raised this way and this is more comfortable for me and those are the ones that i think we really struggle with is when the it's not that we don't understand each other's positions it's that we find where we disagree and then we just get stuck and we we don't have like

both sides and i say this all the time in the corridors call where both sides recognize each other's position and it's just someone just needs to make a call like that that's all like there's there's no like we we can eventually get to that under point of mercedes we just can't actually get past it right but there's no formal way to track both sides claim there's so many people that are good gonna do this we're gonna fork but that's obviously they have no clue how many people are really on that side oh yeah so rigorous measure of and you can never track all that needs to be seriously measured so if you can see that 75

of all of the core devs and everyone are clearly on board and the noisy people that are that are against it and saying there's going to be a fork if you can see that then making those decisions become it can become a decision if you see 75 percent people are on board and 25 percent people aren't versus everyone just polarizing says there's going to be a fork and yelling and there's going to be four can you do this i don't think the core devs actually listen that much to people who yell and scream fork um i think there are a few core devs who do but the impression i get is that most of them are pretty uh ambivalent like most of them seem to be in the general camp of um forks are an acceptable form of governance if two

groups disagree strongly enough forking is the appropriate way to deal with that situation and that's okay um there's definitely people in the community that disagree very strongly with this like they do not think fortunately yeah we'll never accomplish anything for constantly forking into smaller fiefdoms um so so yeah so i think the idea the idea is is that in in most cases people aren't willing to fork over a thing like you have to be pretty big and significant like the dao was an example of a significant enough disagreement that caused an actual fork for pretty much everything else it's not enough to fork over like prague pow as an again as an example i don't think whichever way it went we people would have actually forked over it like i think people complained and

claimed they would but i think in the end like as we saw at least with the way it went people didn't fork despite threatening to and vice versa i think if we would have implemented it i i don't think it would have actually forked are we going to fail because mechanic also because contentious forks that involve something that's perceived as an economic blow to minors further incentivizes a fork so even if like the community at large might not support it the mining community might i wouldn't say arbitrarily but i would say uh our i would say the mining community is capable of making a decision that's largely independent of the rest of the ecosystem sentiment if they feel like they're defending

their own uh that their own holdings so i know and prague gets a bit funny that way i'm trying to predict exactly what would have happened uh but i i i do agree with all of your points there when i say fork i specifically mean a a fork where there are actual users on both sides of the chain um a fork where it's just a bunch of miners um who just go off and do their own thing and no one actually uses it that happens every single time we have okay every hard fork there are miners who forget to upgrade and they just keep mining the old chain for quite a while sometimes um like that is very normal and what specifically a contentious fork i think of like etc

is the only one that ethereums have i understand you actually have a significant user base that exits with i'm not just you know miners trying to sell their tokens or whatever yeah i i understand so that also brings me to a point where i wanted to bring it up about the fork identifier right that is this proposal is a network layer proposal and i know that is already implemented in get so someone please help me uh understand that so i'm i have not complete understanding of it is if it is implemented in all the clients or just get only i know for sure that is there in the gap but is it helping uh miners like getting

on the right chain if that is included with the latest version of geth when it is ready for any network upgrade uh which do you have a link to what you're referring to yeah i'm just gonna [Music] share them here it's eip2124 and i'm sure so uh the proposal is in the last call um we had invited the author to explain about the proposal and uh there is a very good video on peep and eve

about this proposal explaining how it is going to help identify the right chain because they they don't have just chain id they also provide identifier for every upgrade so that may be very helpful for miners to you know find the correct one oh yeah i see uh no so this wouldn't help with uh miners forking off uh during every hard fork this is basically just to the way the gossip network works you basically just kind of broadcast out and talk to everybody and you try to find people that are on the same chain as you um it would be i think if i understand it correctly they're basically just trying to make it so you can segregate and so when you open up a channel to talk to somebody you can very quickly identify oh you're

not the person i'm interested in talking to i want to talk to uh because i'm you know following this other fork than you are um so that way if something like ath dtc happens um you don't have people you know still gossiping with each other it's just basically it's a network bandwidth saving thing more or less performance improvement i don't think it'll have any visible effect on the ecosystem if i'm understanding it correctly also this simple summary is too long yeah yeah so yeah i was wondering like if there is any such proposal which are there for improvement of network layer they are generally i have not seen most

of them in in upgrades i was going through the history of upgrades and looking into the proposals i found one i think there was one eip8 that was accepted in homestead but other than that uh no other proposals are there okay if uh i followed all of them then so uh so i think there's i think there's two reasons for that one network network changes are actually pretty rare we don't change the network protocol very often and two they um they can kind of have because they're versions and you could the clients can be on different versions it's not actually critically necessary for everybody to like come to agreement

like it is for core eips and so like usually it's felix and the guest team who you know talks about something they propose an eip and then you'll see they actually are a handful of network network eips it's just like because they don't need to go to final they usually just get forgotten once they get close and so um i suspect a number of these are actually maybe not maybe these are all really new yeah i mean like it would be good to have them as finals as well like i know there are uh quite a few version of like 64 then we went to 65 and at present we are at

66. so we have different we know that one is superseded by the other right so i i think sorting them out would be no um i wouldn't say superseded like you you can have a client that speaks only 64. talk to a client speak 64 and 65. uh geth i believe is actually going to drop 63 and lower soon um and then they won't be able to talk to people who are not on 64 or higher if they remember correctly um so yeah so we definitely should get 864 needs 65 out of draft like they should be final i think because i think they're in production

now right and same for 66 that is there in the uh review for a while it's i don't know does anyone know 66 has been deployed i'm pretty sure yeah yeah i'm pretty sure geth has it released okay and there's slowly deprecating uh 64 and 65. all right they've announced sometime this year when they're going to stop supporting it or removing it oh is it 64 or 65 they're dropping yeah okay i believe that's yeah so we should definitely get all those merged and moved up um talk to felix is probably the best

person to talk to they definitely understand the protocol and like if you wanted to just rope someone in and say hey can just here's a list of vips can you tell me which of these should we move to final uh felix is probably the one to be able to answer that easily yeah right right i will i will reach out to him on this week and we'll create pull requests for at least which are in like draft and they need to be moved but for the review one i will request author to move it all right so bottom line is like i was just trying to understand for this proposals like there are three questions three open questions as per um my understanding like one um are we planning to have like code proposals going the same way as it is

going for now for the network upgrade uh irrespective of if it is a protocol change or a feature change let's let's come with the same process and um the next one was for net network upgrade uh proposals network layer proposals can we do anything about it or it's just that we will be reaching out to author because these are not very frequent we shouldn't be worried or bothered much about it i'm fine with network just following this same process as core um i think it's just a matter of they're just infrequent and so that and they don't need to follow the process like there's nothing forcing them to

like with all core devs and so um i think it's just a matter of you know just we need to be proactive in and and their inclusion and their inclusion in any upgrade uh does it have any significance should we or should we not uh they're disassociated with hard forks so they can be released by clients independent of any sort of hard fork makes sense so we don't need to track it for hard fork coordination or anything right right yeah yeah i just found only one network layer proposal which went into the first upgrade i believe and after that it was never there cool i'll make a note of that thank you i think that one is actually

you're talking about ep8 right right eight i think it was needed before homestead so i don't think it was actually included with homestead it was just every client needs to implement this before homestead goes live i know i think i saw it in the list of properties did it actually you know did it actually go live with homestead it is there in the meta eat for homestead okay that was before my time so i'll take your word for it all right i think this topic might need more discussion so we'll get back on

this uh maybe in the next meeting we'll have some more thoughts around it and try to document whatever we have discussed in this meeting and we'll take it from there any question or last comment before we move on to the next item okay uh moving on the next item is a new eip erc editors in training progress um i know we have william here on the call and there was some discussion uh in the discord channel as well anyone would like to give any update on how we are doing on it or like is there any challenge people are facing that might need attention

my largest issue is the lack of more hours in the day currently okay we need to fix that yeah if we could hard fork today and increase the hours all right that being said i guess on a more serious note i have not put in very many hours this last month uh i am hoping that the future does yield me a bit more time for that there were a few things sort of extended waiting for me this month that being said it is something i'm keeping an eye on and if i see that consistently that i don't have the time to dedicate to it i'll probably withdraw from the from the position

and just to allow someone more productive than me uh it's actually uh like um i i would suggest that do not withdraw it yet we need people it doesn't matter that like you know you're giving one hour or like five months yeah just to be clear i am still trying right if i see that it's just like you know i would not have pretty much anything concrete i could point to from the last month for instance so look if i see that that is consistently the case so i'd probably put some effort in trying to find someone else to to try and come in i can do that anyway truth does right in the meanwhile i was just

talking to light client and we were thinking of having a recording on like how editing works maybe i i can have my lifeline both on a call maybe in uh an episode of people where we can record how the process work and explain it that might be helpful for new people like what all tiny details that they might have to look into yeah any other suggestion that that we can create some resources for new people getting on board to be honest as weird as this sounds um like client if you are open to have i guess i don't have a better

term for this than like a ride-along or something like that if you're about to do some eiping or anything like that that actually doesn't sound very good uh and you'd be willing to have me kind of tag along or something like that i think i think that's the perfect term if you know what right means it's like one of those where i said it and then i was like well maybe maybe better context really would be pair programming yeah yeah uh i think i mentioned something like that that would probably be a good thing to do i just need to figure out uh yeah maybe we can huddle together after this call and figure out like a good time to do maybe one hour every week or two

i'd love to join that too actually since some of you weren't invited i'm sorry is a very private thing trent yeah all these all these open source repos yeah we can let's let's talk after this and find a time that works for us just to do an hour or so a little less a little more every week or so and then yeah should get our feet wet right yeah we were thinking about it like maybe meanwhile if we can record something on like ama kind of this frequently asked questions that people have around or get in touch with all these people i know trent you have also volunteered to

do that and william is there and there was another guy i don't know he's not in the meeting today so we'll uh check with him too and anyone else interested to generally learn how does this process work because we would want more and more people to join this is something that needs attention because more like proposals are stuck because it's not being reviewed not like a core proposal they are moving faster but for erc's definitely we need some more help maybe we can come up with something more concrete in the next meeting all right uh moving on to the next item is

jason rpc api spec progress update i believe alita you mentioned in the last meeting that you would like to go ahead and provide update every uh meeting about what's going on in there yeah so basically um in the past week we have gotten through most of what i mentioned in the last issue i guess i didn't i was too busy to fill it out for um for this time but like are there any endpoints that are particularly particularly important for us to focus on over the next two weeks uh the eip15591s if they're not done yet okay uh do you know offhand what those

ones are i wouldn't actually say the 15 59 ones because right now we are we've kept two separate implementations of the spec and the one that's in the eth1 specs repo has the 1559 ones and is kind of the coordination point and i'm just like keeping those updated for now until the fork passes but um yeah we'll we'll transition away from that after the fork passes so it's not there's not like a strong need at this exact moment to get them why do you think we should not use this process for london uh it was just talking with ted i

mean we are using this process it's just which specs are we using and i'm would rather them not like focus on the one that's apache 2 from ethereum classic and focus on the cco version it's just that like the apache 2 version is you know not as complete as what we're going to want eventually but good enough for client like we're still using it as the coordination point for clients to figure out what is going into london but long term like the work that all of our work should be going towards the cco version speaking of which um that's going to be delayed probably until this weekend um because i have been very busy

so yeah uh but i did promise that for for today so um that's a bit of an update but yeah i will have um pr finished and i mean i'm probably just gonna merge it if that's okay with you all uh i mean i guess you know you all can review it but i don't know it's gonna be a long pr so i guess michael likes to read long pr's but just let me know go on trade adopt a popular belief i do not actually like reading long vr's um but anyway so yeah there's like essentially if there if anything comes up where there's like specific endpoints that need to be doing that need doing um let me know but otherwise based off what like clients said and micah said

um i'm probably just gonna kind of prioritize based off of you know what is best for myself and for the person working who's actually doing the work here um which is to me that like they don't have or jared doesn't have a lot of experience yet and so i'm trying to keep it somewhat simple um to to kind of like guide that learning curve but um there's a lot of progress we've been doing things and there's also a major discussion right now about format which is like kind of blocking us actually um which is a little bit frustrating because like i think it's less important than getting things out you know what i mean like i think it's easier to to go back and like reformat than it is to get somebody else

on to to do this so it makes more sense to me to just kind of like bite the bullet until we can figure this out as far as formatting and just go with whatever we have right now um but what do you all think about that momentum is hard to change and so if we pick pick a format it's and we want to change it later i worry that it will be difficult to actually make that change as we've seen with the ip process we struggle to change it because people are used to one way and then it's very hard to convince them that something else will improve their experience if they just get over the

hump of adjusting okay so maybe we'll do it internally then um i just i really don't want to slow down anything i want to keep things moving as fast as they possibly can because otherwise you're not going to make um august deadline we're already very much so um i mean i already am pretty confident that we're not going to make it but um if we slow down because of the formatting thing that we are definitely not going to and so um i mean what's this why are things slowing down why can't we just figure out the formatting and then continue on well it's because until the formatting is figured out we can't open any more pr's

and so we can't get client people we can't get clients reviewing um and stuff so in other words my point is that like the formatting is like a very high priority right now um i'm going to schedule a call with my client and um tomas for this weekend to figure this out if any uh if anybody else is interested in being on that please let me know and i will add you um but yeah it's like it is essentially it's saying like we have like the raw information but we can't deliver and if you can't deliver then you just have a bunch of work in progress and then we just get to like i don't know i mean it's just it's not it's not not a very efficient like pipeline that we have going on right now so i

think the it sounds like the solution is we need to resolve the formatting thing quickly is there anything we can do to expedite the solution the the best thing i can think of is just this weekend um we schedule a call and get through it on that call like basically we just call until we figure it out um so yeah i it was supposed to be this past weekend but i had a crisis at work and that's resolved now so i will follow up with it but i mean tomos not available asynchronously at all i guess he is yeah i can also um message in his mind if you just ask him to chat in the jason rpc

specs uh um discord channel then yeah i think he's a little i think he tends to be a little bit unresponsive because he's very busy um i i'm not totally sure uh but he tends to be a little bit slow at times and so i don't know um i think a call would be more productive um but what we could what i'll do is i'll do an async as well as schedule a call just so that we hit both avenues um and then we can just cancel the call if the async works sounds good feel free to send me a link to the

meeting and time cool so the next item is a canonical source for eips so i don't know uh brent if you may have any update on yeah that's a time issue for me i need to fork myself but i haven't got it's still on my list of things to do but haven't done anything recently so gotta push it again right uh like uh do you want me to keep it on recording meeting or should we take it off and one you have yeah let's try it at least one more one more meeting and i'll try and get something before the next meeting all right no boys

okay uh so now we are on the last item it's review action items from the previous meeting um there are a couple of uh tasks that were like coming on from this meeting um i just want to quickly have a like if there is any update the one is eip draft banner um are we done with that task or how is it going oh yeah this one i have um unfortunately not finish this one i don't know maybe i'm gonna see if somebody else wants to just because i'm like i mean i can do it uh like i will get to it

it's kind of like how what's the priority of this item um but maybe jerry could do it i don't know i does anyone else know css because i do have like a kind of like a rough framework for it i think if if we can open it for community i mean if we have like a bandwidth issue we should create an like issue and share it in our discord we have so many people from like you know uh developers community as well who are looking to contribute so if there is a way they can also contribute that would help us like speed up the

task and yeah i mean i know you have worked on it so if you're around they can always reach out to you if that's okay with you yeah of course that would be great i think um i think just posting a thing saying hey are you interested in this and then just reach out to elita if you are and then i can give them what i have right now um i'm sure that there is not i'm sure it won't take that long for whoever ends up picking it up but i am very bandwidth constrained right now and so that's resulting in um unreasonable delays all right so i'll take on it i will create an issue and share it with people on discord and everywhere else uh the next uh task that we discussed

sometimes ago uh was a boat tracking inactivity period uh that is issue 73 i saw jared responding on that but unfortunately he's not there wondering uh if you have if you may have any update on that uh what is this again sorry but are you talking to me yeah yeah uh it is issue number 73 i see your comment uh like you would be able to help jared working on this staff it's about bot tracking inactivity period for eips.ethereum.org so they can move the proposals to the appropriate

status if they are no more like you know in activity for a very long time and that withdrawn status or so uh so in this case i don't know too much about what's happening right now i do know that jared is working on it and i do know that he can reach out to me with questions um but i do not have a status i think jared has been working very hard on the jason rpc stuff and so it's feasible that he and he's also been moving recently and so that's feasible that he's been unable to get to it um depending on the like on the priority of this i might recommend

handing off to someone else um i can you know guide and train whoever honestly um but yeah i i i mean i'm not totally sure uh i think maybe follow up with chair asynchronously to see if he's done any work on it cool no worries i can follow up with him too all right um i am now looking into the last meeting notes to see if we have any action items uh there and this stations uh number one anything that wants to be on ethereum standard needs to go through if

you can github repository i believe that is related to erc process that we discussed in the last meeting alita to investigate a bot exclusion to eip1 um my understanding is this is done alita can you confirm that please yeah that's done thank you eip1 changes to only require two editors to approve but this is also completed correct i believe both are interrelated that both are related to eip1 only month the json rpc api is back in either one o as duplicated internally until after

london i believe we discussed this today lifeline brought it up there are some changes and the last one is change the name of each 1.0 api's repo after london is shipped that's a decision no action item on anyone all right so that's all from the uh agenda item anyone has anything else to share with us or maybe bring it up we made it on time nice all right thank you everyone for joining today i hope to see you all in two weeks on

july 14th have a good day evening everyone cheers