EIPIP Meeting 29

Transcript

welcome to eipip meeting 29. the first item on the agenda is network upgrade process review and some proposed changes to the status of core eip uh this item we discussed in the previous meeting and um with the present model uh i'm trying to propose some changes in the status of core eip so in the last meeting i shared this diagram that is uh that is a link is provided in the agenda itself that suggests that if we can have

the change of the status for mainnet phase and make the testing green light or public test net to be in review or the last call status so basically just to make sure i understand when something is being tested that it absolutely has to be in review or last call right right so the last uh meeting we discussed that generally the last call is suggested to be for 14 days only so there were one con there was one correction that i recommended that instead of having the last call for 14 days

we can mention it as a minimum of 14 days that was point number one and the point number two when we are sending it on public test net then we mention it to be on the last call and until uh it reaches on the public test net let it be in review status i think that makes a lot of sense and um and eip will be considered final only if it is deployed on mainnet for the proposals which are actually being considered to be deployed on the mainnet via network upgrade because the standardization process for eip and network are different now so there can be some core proposals

who would be reaching to the final status but may not be ever being deployed on the main net so we wanted to keep this on agenda for this meeting as well so that people should know about it and if anyone has any other thought feel free to share just to reiterate again this is not not an eip issue this is a core dev issue right but what uh i'm suggesting here is like if we are

planning something and document it we can at least reach out to the code or maybe the author of the eip uh suggesting that this is this is the process and if we go by this that would be like really helpful for everybody nobody can say that we went away aware that the proposal is in this status and it is going in the upgrade and something like that that happened for one particular proposal yeah i i do think that taking off my eip editor hat putting on a wannabe core dev hat i think that anything that is um proposed for like for mainnet should be in review by the time it gets there

like we don't want eips that are still under active development by their authors to be proposed like you should be confident enough in your your ap that you think you're done at least you might not actually be done but you think you're done before you bring it to the core devs and waste their time with it right so uh by bringing it to the codex do you mean the consider for inclusion phase because uh my understanding is even if it is in draft for computer consider for inclusion it must be in review when it is approved if a coder says that okay this is general consensus we can think about it then it should be in review or i mean it's fine i'm okay i'm personally okay with cfi

being in draft because mainly just because we don't want people to waste a huge amount of time before they get just like a general consensus from the dev core devs saying yes this is an interesting thing to us and to me cfi is basically the core dev saying yes this this is interesting to us go go finish it now and come back to us when it's ready for us to look at for implementation right and so for cfi i'm okay with draft personally just again like if the court of saying no we're not interested i don't want people to waste a huge amount of time getting something to review which requires getting past micah which is a huge pain in the ass

um if this is going to be immediately rejected by the core devs it would be nice if people get just like uh like there's a bunch of core aps you know where people craft them and then they go through a huge amount of effort to get it past me and then they finally get it past me and then they take the core devs and the core devs immediately just shoot it down and say no we're never doing that and this is just a big waste of time for that that author right and tim has suggested here in the chat cfi for draft network upgrade for review and test net block chosen for the last call yes that is exactly what we are planning here that sounds good to me uh by the way sorry about that i actually can be here today everyone was very quick

so i can make it thank you for joining hudson okay uh so uh let's let's keep it uh for the notes taker uh uh the suggestions here uh cfi for draft network upgrade for review and test net block chosen that is actually the main net phase um in the last call and it will be marked as final only on um when it is deployed on the main net and we will share this information with the coder as well hope there should not be any objection okay moving on the next item on the

agenda is should erc's be moved to a separate repo so there has been this discussion around eips and ercs should be in different repos we discussed it briefly in the previous meeting and i saw some conversation on the ethereum discord channel as well so uh maybe like client or mica if anyone would like to take a lead and talk more about it i can say something briefly hold on i'm having an echo uh you're joined twice somehow oh there you go you're going to hear me yeah we can hear you

hello hi we can hear you ah okay i was still connected on my other device okay so i posted on the discord channel uh based on the conversation for the last eip ip meeting we kind of talked about how ercs just don't fit very well within the eip repository and there's a lot of disjoint responsibilities over there those eeps you know i personally feel like i'm not a very good person to to be editing and reviewing a lot of the ercs and i think there's people in the community who would be really great at that but they're really not suited very well for you know review core aps you know for that reason in other

reasons you know we talked in the last meeting about what if we had what if we took the ercs and we put them in their own separate repository and i had just posted on discord asking like what does it take who whose approval do we need to get to make that happen i'm happy to do the work i i don't think it's gonna be too difficult uh to me the biggest question mark would be there's a lot of permalinks out there that point to the you know the github pages we can redirect the eeps.ethereum.org website all the ercs can be redirected to their correct page but we can't redirect the github page my proposal to resolve that is just replace every erc

with uh a stub that just says this has been moved to the years he requested here's the new link and so that would just add an extra uh level of indirection for anyone trying to access it directly on github i don't think that's like a showstopper what's the proposed numbering system i think the numbering system would you know we'd have to have some way of and you know my look the lowest tech that i can think of is just a google sheet that we share with editors and that's going to increase the burden a little bit because instead of just looking at the pr number we would have to go look at the sheet to see the next available number but i think that i don't want to do something where we like multiply ercs by

10. i think that that's that that that's just asking for problems in the future but uh i think it's worth it in the long run just to make it a little bit harder to assign a number because it's going to be a lot less work for core editors uh who don't have to review ercs and then we can really bring on more people to edit ercs and actually build you know kind of a community around just that aspect because there's a lot of people who are only interested in the application level of ethereum and they have no interest in eaps at all i suppose once we create the if we migrate the ips into a similar

file structure then if someone tries to create a pr and create a file with a matching name it'll immediately get flagged and blocked so we don't even need to keep a separate document i think right if the bot had a like an overview of both repos no i mean like if if we take erc20 for example and just copy it or cut it out of the eaps repo paste it in the erc's repo sure there is now an erc20 in that repo and so if someone tries to create erc20 it'll just immediately show up as they're deleting the old one which is very obvious sure i'm more worried about assigning new numbers though because there's no way to know if you know 3502 has been assigned as an erc yet

uh right so as soon as they um as soon as someone like editor comes in and says oh your pr number is 20. so use erc20 the user will then try to create erc20 realize conflict send a message to the auth the editor saying hey there's a conflict what should i do no the editor then just says i'll use 19 instead or whatever if it's but if it's published in the erc repo there would be no corresponding file on eip repo yeah can we just add like some padding can we just say i don't know you add like 5 000 to the number so if it's pr 20 then you're erc or i don't know 5 000 might be too low but i just feel like we're not gonna you

know leave the eip system in five thousand i mean that's yeah i mean that's only five thousand eips away that's are you are you worried about there being an eip 5000 and an erc 5000 to me that seems fine um you don't need them to be actually exclusive i mean if we don't need to be mutually exclusive why not start erc's over is that where you're playing yeah because but then you're going to conflict with the current ercs i think if you take a number that's bigger than the last eip right now then you you make sure that there's no conflict right yeah yes but the the total number of ercs

that are actually like draft or higher is on the order of maybe hundreds i think i'll check while i talk but i think that long term you're going to end up with more simplicity if you just continue to use the pr number numbering scheme and you just deal with those 100 or so conflicts if they come up and keep in mind that there's a very good chance they won't come up because you know every single pr increments that number but only a small handful of those are actually new ercs and so um i think that you'll just end up with a small number of conflicts like so when someone comes along and does pr20 if pr20 happens to be a new erc not someone updating an

existing rc then they'd have a conflict and then we'd do a one-off fix for that one say i'll use 19 instead 19 is free i have a suggestion i don't know how much it will be helpful but i was wondering like not all pr number is an eip so um what if we add an additional step for the ercs just asking them to create a pull request stating that i have requested for i have created a full request in erc repository for whatever proposal he or she has and just refer the pull request number here and use that as erc number there so in that

way there is never going to be a conflict and it will not disturb any of the process other than it will be an additional step for an author to just create one issue for request here at the eip github repository i would prefer that the eap like if we were going to separate him i would rather have it truly separated but i i do kind of like the idea where i mean we can artificially bump a a repository up to a specific you know issue or request number and you know theoretically we could have a repo ethereum slash um numbers i don't know what you would

call that but you know you could just say if you're going to open an erc or vip you have to go open an issue to you know claim a number that kind of removes the burden from the editors i don't really like the idea of going allowing people to you know start claiming like single and double-digit erc numbers that were eips and i just i don't really like the idea of having a erc conflict with an eip number that to me just seems like we're asking for it you know especially because this is this is something that's going to be changed and it's already difficult enough to convey changes in the eip process to the broader community and so people start seeing oh wow there is you know eip

3102 and there's erc 3102 i think that's just asking for confusion yeah and like the the precedent we've set is that ercs are eips up to now so changing that precedent would be a task it's not impossible but like maybe taking this in steps so like the first step would be finding someone who even wants to be an erc editor and then have them start doing erc editing in the main repo and then getting the resources meaning funding and people's time to split out the repo that would be a whole different discussion so i think i guess all that to say we're kind of getting into the weeds today when really

the main decisions to be made are maybe if it's worth it to split it out in the first place like from the repo because i'm not convinced that they shouldn't all be in one repo um but i guess what's the benefit of splitting it out into two repos just like clarity one additional thought i had in since we're talking about splitting ercs from core dev uh eips um is there's all my understanding is that mica and light client get harassed with a bunch of people trying to do stuff that isn't related to either one of those

and if we it and the key is we need an editor for erc's and we and and and maybe we could have a miscellaneous so we have three different locations we have a miscellaneous for all the other stuff and we have and and maybe we could just say we want to push in that direction and we want to find an editor for miscellaneous stuff and we want to find the editor for ercs but eips are just for cores anyway just a thought because if i i believe you instead of telling people what not to do tell them a better thing to do so if people that there's a lot of people that want to do that if they had a place where they could put stuff that would take some pressure off the editors i would think yeah a lot of this is about taking

pressure off the editors who aren't like either aren't equipped or don't want to handle ercs like they'd rather do eips and so if that's one of the main goals and sorry about the background noise by the way if that's one of the main goals i don't know if we should split it out at all right now or maybe just decide that later i think that it's it is more than just making things easier for editors i also really think that it can help increase community participation there's so few people in the ethereum community who have the overview where they can understand both ercs and core eips it didn't generally tens of people

you know are at dap level developers or they're kind of core level developers and there's a lot of noise in the eep repository with both of these things and being an editor having notifications on seeing the noise it's hot can be tough for me to keep up even though this is like a responsibility that i signed up for if i was just a community member who wanted to follow the latest and greatest core developments the latest and greatest you know erc developments that would be hard and i think that if we split it up that would generally just allow this kind of natural boundary that already exists for people to like really begin to be more involved in that process without actually having a role just you know tracking what's happening and uh you know

being a part of the um the governance process on both of those sides um oh michael you just asked what point you got cut off i i didn't hear you from the beginning so if someone interrupted you mid-center because you haven't talked oh okay i think you're on now this i got connected like five minutes ago ah so i was going to say yeah so i was waiting for you to respond to something but i didn't hear you talking i'll say it again it sounds like you guys move past it but i'll say just get it out there so there's only a few hundred i would say total eips and a portion of that is erc's and so when it comes to numbering schemes

if we just use the pr number like we do with the erps that use it for ercs as well except for be the erc repo it will be very rare that we actually run into a conflict and when we do we can just handle that conflict individually and i think overall that will be the least amount of work for erc editors in general um just because conflicts are rare and when they happen they're very easy to resolve and that way the numbering scheme for the common case is very simple let's just use the pr number like we do now so you're saying there we will they will start with erc one and then skip 20. yeah so we'll start with the erc1 and there's like a 99 chance we'll skip 20 naturally

because that's just how the numbering system works it is not uh incrementally increasing like eip you know 20 exists and 55 exists and nothing in between the two exists um as yeah we start with erc one and then there would be an erc you know maybe 35 and maybe in year c 72 i'm assuming the pattern is similar to eips and every now and then there'll be a conflict but it'll be very rare i'm guessing one or two total i think it's going to be confusing because generally people will associate lower number with earlier in the history of ethereum so if there's erc 5 they're going to think it came before erc20 etc so like if there's a standard that like improves

on erc20 or replaces the rc20 but it was erc 7 i i just can see most people getting confused how did agree to that so if we have to start this like we should be starting from this point onwards not going to the back number that would be my first suggestion and uh using the same like you know getting the pr number would be a better idea it would not ever let us to any kind of conflict because it's just an request that is there an empty kind of just mentioning that there is a relevant erc that people can go and refer to if they want to so the other option is we could just

write a little bot that just turns through the first 5 000 issue numbers and do github repo the problem is then you still have this issue where you you can end up with er eips and ercs with duplicate numbers and so i really feel like they should be mutually exclusive uh why i i just think that we've already said this precedent that ercs and eaps are kind of very similar they're in the same repos they have different numbers and it's going to be hard enough to try and tell everyone hey this is a totally different thing now ercs are their own thing there's you know maybe in the future they can have the numbers could conflict

but i i just think in the in the beginning i i really don't think it's that much extra work there's you know i think there's two good ways to do it we can either have a spreadsheet where an editor you know spends 30 seconds and goes and puts the number in when they assign it or we can have a canonical repo ethereum slash numbers where people can create an issue and they post the link to the issue and say this is my eip number because i went and this was the next number i got in the repository and and so i think there are good ways to solve this issue of you know making them mutually exclusive it just only puts a small amount of extra burden on the process and it creates it makes things so much simpler for people who are trying to

follow it without knowing every detail so could maybe a way to do that be like you split the repo but within the same actual github repository so you create two different top level folders one for eip and one for ercs and then at the top level you maintain a list of numbers so like at least this way yeah they're always in sync the problem with that is you don't solve the one of the bigger problems which is email notifications like i i'm currently subscribed to all the heal eips repo so that way anytime someone comes in with a new um pr i notice it

and if we add them in one then i still get all the erc ones and on the escalator it still gets all the ip ones is there a way we could automate this list that like keep tracks of the different it's almost like whenever there's a merged pr you want to update the list with that number or something i mean you can set up like a github um github action that fires web hook anytime a pr is made and you can even set it up to automatically do the numbering so get the humans out of the numbering system of course that requires engineering effort and that is something we are very short on in this group yeah i mean definitely we can have bots do this this is a very simple thing to have written obviously it has

to be written i don't think we have the time to specifically do it at this exact moment but that's what i'm saying i think that you know starting with a spreadsheet and then eventually having someone go in and turn that into a part of the merge bot that would be back to the same level of effort required or less today i don't know if github repository supports uh with the help of label i mean like if we start labeling it as erc in the beginning if somebody is creating a pull request and that helps like um with the notification that you're receiving i'm not sure that by the way it doesn't help with the notification unfortunately

yeah so just to go over what we've kind of decided we definitely want to split editorship into eip versus erc um we are heavily leaning if not pretty much decided they should be split out by repo what we're stuck on is once they're split out by repo how to do the numbering is that is that kind of a good summary i think so okay so i think a better option would be for people to come up with proposals when we make an issue in the eipip repo or like uh where's the stuff discussed there's an eipip repo

yeah so um i can make an issue for that and put it in in here uh it's like ethereum dash cat dash herder slash e-i-p-i-p and github um i think that's good and then we can move on to other stuff unless someone wants has like a final thoughts on this only final thought is if we're going to do this for erc should we also do it for interface and network or not ercs are the biggest problem but the same basically the essentially the exact same problem exists for all the different categories it's just much more muted for the other ones that was there in my mind thanks for putting it

um i think it's we should try out with erc's and learn from that and then split it out further if well i don't know maybe doing it all at once would work but i don't think there's very many how many interface and networking eips are there i don't think there's that many that it would we yeah and i think we want to keep the networking alongside the core eaps because it is like the same set of folks who end up reviewing and implementing both yeah i agree i tend to agree with that core networking are very tightly related interface is a different set of people so like metamask and basically all the wallet providers care a whole lot about the interface section

as do core developers as do dab developers and so um interface is like it's a very appropriate name it is the interface between all three layers and they care about all three very much um so maybe that one pulling it out just again so we can have people can don't have to get the core eips if they just care about interface stuff sure i think erc's is a good place to start the number of non-erc or core apes is incredibly small i'm good with starting with your c and see how it goes

so uh [Music] yes sorry oh tim were you talking i think i'd say i think i think that was background noise i think uh um we have to create an issue on eipip get our repository stating that we would like to start with erc to be in a separate repository and then maybe i don't know if elite i just mentioned in the chat if we can have some documentation of the requirement for both bot that we discussed if that has to be done with the help of bot

and um oh did we did anyone discuss about losing like historical hit like history between behind like the older eips and stuff would we just close all the previous prs and issues and they'd still be in the eip repo or would they be deleted they would definitely still be there i assume that the discussion threads for old ercs if they're pointed to issues will probably just you know stay as issues in the eip repository and then you know over time there'll just be so few that are actually actively discussed got it okay okay so does it make sense to bring it

back in the next meeting to discuss further on this topic do we keep it yeah yeah i think so cool so moving ahead uh the next item on the agenda is progress on the eip github ripple action part uh i believe alita is working on that and there is an issue uh for collecting some uh you know requirements for debate that is issue number 59 in the same repository anytime you would like to provide some more update on it sure so right now um the bot is waiting on i forget who exactly but basically we're waiting on transferring the exact bot to a ethereum controlled repo um it's currently in a private repo

um the actual merge bot like where it's used um on the main eip repo is not merged yet um i think that there's a small change that needs to be made um and we're still trying to figure out like manual stuff um for the eip bot itself the from stuff we discussed last week um our last meeting um i have implemented like the testing framework for it um and then i have created a new issue for okay so i have interfaced like

the eip merge bought its own repo so that way we can more easily managed it i have built the test framework and i have created a issue for collecting information on more features um required for the bot i think that sums it up does anybody have any other comments or uh great job and um did we i don't see it written anywhere how much the cad herders are paying for this and i want that like down somewhere so we know how much to pay you for your work uh is that somewhere yeah 200 000. yeah it was like a million [Laughter]

no no i i actually created a funding um request in the cat herders and that references the video that um like got me started on it which was seven thousand usd um so and then for future funding um like because because i'm considering getting it up and running with like the features that were initially requested and like transferring over including the testing included in the 7000 um just because i don't know i want to make sure it's good um but any future uh like features and stuff i will make um like the idea behind the requirements document is to get everything in one place so then we can create a

like a thorough proposal for funding um to get those in place as well uh not issue actually it was a response somewhere in the eip github repository itself uh in which we kind of calculated like how much the work is required and how much should be the funding maybe i would share that link but yes that was somewhere around 7 000 so yeah that's fine um other than that um do you need help

getting it into a neutral repo like ethereum yeah you could transfer over and then um well actually i have two requests can i please be made a um contributor to the eips repo because it would be nice to be able to branch off of that because i'm probably making changes to the um bot once once it's put in um like if i want to change the version or something on it um and then but yeah so then we also need to transfer the current bot which is a lead or a leader dash more um eip bot which i can link um that one needs to be moved to an ethereum control repo which i would like to be made an admin

on so that way i can have some like ease of editing stuff that all sounds good to me um so just to be clear we don't have contributor access on the eips repo the three roles we have are read write and admin um because we are on an old github plan that's cheaper for us so would you need write permissions to read clone and push to the repository and manage issues in pull requests or would you need admin to also change settings i don't know if i need admin just right yeah just right okay put your username in the zoom chat if

you're not on mobile and i'll make you write permissions right now and then message me on discord and we'll in the next few days uh get that transferred sure all right awesome thank you just one last comment from the camera side like uh uh do let us know whenever everything is done like when bot is merged and when we have to make the payments so just uh gives us a heads-up um i mean i submitted the funding request um the bot is like i guess mostly done i have some like polishing to do

i don't know if we want to wait for that to be done um i know i'm waiting on a final review from micah um like essentially it's kind of a continuous process so i don't know if there's if there's a clear line in the sand um like in my opinion it feels like the initial task was done and i'm just polishing right now um what do you think or you all think my opinion would be after micah's final review if that if he says it's all good and there's no last-minute fixes that were part of the initial set of either requirements or expectations then i'd say we can pay out then

with the expectation that for we don't pay anymore for you actually installing it because i think that was part of the initial stuff right oh yeah for sure um yeah okay then yeah that sounds good after micah gives the okay i say we can we can fund it what do you think micah the last i looked i think i was we were waiting on that manual trigger that we found getting that set up and there is something else i think it was mentioned in the issue um are those two things set up now like we have the ability to manually trigger and what was the other one speaking of which the manual trigger

that you mentioned i don't necessarily know that's gonna work i'm trying to find a workaround for it um but what's the problem what's the gist of the problem like the one sentence version you can only run it on a branch not a pr i think oh but this particular bot needs to know the pr because it's gonna merge i see well that's annoying um okay and the do you remember what the other one was um let me read your message here i thought there i thought there was one

other thing oh yeah that the other one's done it was talking about not referencing master so um yeah the the the bot on its own separate repo has a versioning system and um it's using the version so that's easy uh just send at mention me in the pr so i can it gets added to my inbox which will cause me to then look at it and i can do it final review done um and then as far as the the manual thing goes i mean there are definitely solutions it's kind of hard to do that async so maybe we can have a call or something like today or tomorrow

and what i'd what i ultimately really like is a way that we can um dip our feet in with it and migrate to it slowly and so we can basically test to make sure it's doing what we think it should do and then once we've validated that it's doing everything we think it should do in the production environment then we flip it flip the switch and turn the old one off the new one on i'm just a bit hesitant to have them both running specifically because my current process is if i see the bot auto merge something i completely ignore the email from github and so if the bot goes crazy and just auto merges everything just as a pathological example it may be a very long time before anyone

notices okay um i will implement some way of do manual like the one okay maybe what if we just what if we just have the bot set up to always run but take away its ability to merge and then just have it when it runs it will just do like a green red or yellow in the ci section like you know how the ci at the bottom says green green red or yellow if we can just have it go green or red then i'll at least see did the the bot think it wanted to merge or to think that it shouldn't merge then we can do run that for like a week or two and then if it looks like it's correctly going green and correctly going red at the appropriate times

then we'll flip the switch and if and actually enable merges and if not we can fix whatever bugs that sounds great to me do we need any kind of conclusion for this any kind of what documentation i mean documentation is always nice but at the same time um i would rather elita spend her time on more useful tasks given there's like maybe three people that actually ever use it yeah that's fine i i was just wondering like if it if it is needed at all um so there is some documentation on the bot like the code itself um i mean it's well commented and

everything i fully intend on doing um like a full test suite for it just because i mean i want it to be scalable but um like essentially what kind of documentation are you referencing i know i was just mentioning that if any kind of documentation is needed for people to refer um maybe in future if they have to fix anything or something like that yeah the bot itself is written in a way that's readable um with clear documentation on con contributing so i think that's good oh cool okay uh so in the sense of time should we move ahead with next agenda if everyone is funnier

okay uh the next item is the the eip standardization process uh so we had this um meeting for eib1474 or that that was basically for rpc standards for ethereum um jason rpc standards and two things uh were proposed in the meeting one like this standard this proposal particularly is never going to achieve a final status because there is always going to be room for some improvement so should it follow the normal eip standardization process or should it be granted some kind of special uh access or maybe you know um going with a special status maybe living

or there was another proposal of converting it to a meta eip because it would be kind of template for every client to implement in the way they want to because not every client's implementation for json rpg standards are exactly the same so it's difficult to document that in the proposal as an implementation section and people were looking for thought of ap editors on this like how do they want to proceed with this particular proposal my personal preference is take this opportunity to try out um a specification system closer to like what eth2 has where we have a repository that defines a specification and then pr's to that repository is the change

control process and then when a pr is merged the repository just shows the latest version um i feel like that works really well for documents that tend to live over time that being said i don't actually think the json rpc should be a living document at all like i very much think that when you deploy or when you standardize on something you should really not be changing that standard on people like that's how you end up with the browser hell of circa year 2000 to 2015. like standards should stick around and be very very rigid because that's what makes them useful is the um so i have two minds on it one i think there are much better systems for living

documents than the ap process and i encourage people to try them and two i don't actually think this is necessarily a good use case for a living document and i know those two things conflict like 100 so the meta question here is like this proposal or proposals like this should it be a part of erp at all so json rpc specifically definitely needs to be specced out somewhere like it needs to be documented currently it's documented in five different places and is documented poorly and the people who own the documentation are not necessarily the people who care about

the the specification and so um it's not great the current situation 1474 if i remember correctly tries to move all of it into an eip kind of wholesale at once which i have spoken out weekly on uh like loosely against that saying that it should really be multiple eips let me verify that one four seven four isn't back to one thing enough what's the canonical place for the rpc standard right now yeah so i think if you're gonna use the eips repo i think the proper way to use the aps repo for this sort of thing would be to have each endpoint each method be a separate

eip and then maybe any iap for the overarching this is how ethereum json rpc is defined i don't think trying to have this one monolithic eip that then just mutates over time does anybody any good because then you have immutable standard and mutable standards are not standards so therefore they're not useful as a standard um again i would this is a good up i i still think this is a good opportunity though to try other things besides eaps like there are currently there's basically other than this eip there's no work that's been done historically or very little on standardizing interfaces there's some but not a whole lot and so unlike core eips moving out of

the earpiece repo i don't think would be hard and so i'm going you know trying something new like a like eth2 is doing with a github repo that it just has prs against it maybe is a better solution so we are now joined by eric swan so eric we were discussing about the proposal excellent yeah um yeah uh hello yes that sounds uh like an interesting proposal how much of it did you catch i i caught the i i caught the very tail end i think so uh the suggestion that uh we may want to do something like h2

is doing and having a pr dedicated to the json rpc interface that accepts prs yeah so basically have a github repo that contains the specification and then the change control process would just be prs against that repository and the entire that is the entire change control process so pr would want to submit if they want to submit a change gets reviewed by however many people that pr lives for a reason amount of time to make sure there's time for people to get feedback on it and then when the pr is merged that's when it's final or that's when it's standardized uh well i'll be damned if that's not the most pragmatic thing i've heard it's almost like we should do that for

core development too i agree they are used for everything so while you're talking about having it in form of pr and a repository what are the thoughts on having it on eth1.org repository i'm fine with that i think that's a great place for it to live and this would be a good opportunity to try to kind of start using eth10 specs repository for this exact sort of thing and then maybe one day we can enter then if this works successfully i can dream at night about how one day the uh core dev change control process goes through the same system and these will know specs just imagine we'll be putting prs into

the yellow paper for hard fork changes well hopefully it's worded better than the yellow paper so about the ethanol specs i was talking with danny i think yesterday or today before when the merge happens those repos should merge too um and the e2 specs repo is like much i guess more uh much bigger it has more content than the eth1 specs repo so i suspect in the next like i don't know six months or maybe a year the ethonospex repo will probably get merged

into the e2 specs repo and and given like the scope of both uh the east one would be this one that moves over um yeah so i just want to point that out it might be kind of on its way out and i mean most things would still be useful in the like i guess it would be called the eat specs repo at that point or whatever but like the the merged version of the eth1 and e2 specs repos so perhaps if we do this do it in the e3 specs repo and just deal with the fact that it's kind of a misnomer for six to 12 months yeah and then maybe we removed it yeah and moving the ethospex repo is not long

uh you know i could probably do it in a day but i think it's you know yeah the moving the pr is the hard part like if we do do this pr change control process um then like it's nice to have the pr's living in the right place from the beginning yeah yeah yeah sorry yeah that's what i meant it's like almost we should move the eth1 specs repo before we do this right um but then yeah out of curiosity how would how do the e2 devs feel about just renaming that repo like this week to east specs and we just move everything over there over the next months um they feel very possessive of it right now so i guess my fear is like or

my perception of their fear is maybe i i don't know i think danny ryan is the one who would want to ask about it like i'm curious i'm just looking at the commit history right now and it's like danny ryan and and xiaowei are like 80 of the commits and i guess proto is like you know number three a distant third but like yeah shawway and daddy ryan are really like the biggest committers so i think just asking the two of them is probably yeah good approach um okay anyone want to volunteer to yeah i don't mind asking i don't mind asking i guess what um what i would would be useful to know

along with the ask is like what are the specific changes we'd want to do you know um because that'll be the hard part if i tell them can i move five markdown files over i suspect they'll say yes if i tell them can we change how you handle pr's uh i suspect they'll say maybe and this is the hard conversation right right and that's a that's why you just you know you show up and say oh do you mind if i can cut in front of you and then you're holding like one thing and so as they say yes you're like okay bring over the cards so i you know i think it yeah maybe the best way to go is like for us to and us i feel like i'm putting

work on other people than myself right now but like um yeah till i kind of write down what we want and then bring all of that to them um rather than just like can we merge the two repos which is a bit disingenuous so short term i think what i would imagining is the hard-fought coordination for the application layer would move over so london berlin shanghai etc and then potentially if everybody's in agreement on jason rpc we'd try to talk to the jason rpc group to make sure they're also on board with something like this and if so then the other thing would move over would be like basically the interface layer so the application layer interface which probably will also

include the application consensus layer interfaces like the ones that communicate back and forth from each other um some of those are already in the two specs repo so however they have it laid out maybe we could kind of merge in with that again assuming everybody is on board with this general idea um eric does this general idea sound good to you not quite sure how much sarcasm there was in your statement earlier uh none whatsoever i think i think this will be well received because one of the main concerns uh that have been raised during the um uh like json rpc groups uh meetings is that like like it particularly from the client teams they're like wait you're saying that like we're going to be held up by the eip

process to like create or change methods they're like forget it so i think they will be very receptive to this idea okay and i guess the downside wants to go uh we talked a bit earlier about splitting up the eip repo for notification spam i feel like if we merge the eth1 specs e2 specs and json rpc all together then we are back you know xiaowei doesn't want to hear about new json rpc calls and people in yeah working group don't want to hear about yeah deposit contract changes yeah that's very valid it's a good point

yeah so uh fallback suggestion then would be um i don't know ethereum interface specs repo or something yeah i think i feel like there's i don't know maybe it makes sense to actually keep them separate for now and have yeah one for the json rpc which is like the interface e1 and e2 and then after the merge we can merge each one into e2 and then and and then you know there won't be any more changes to each one after right like or whatever changes they'll be they'll be across the merged clients right they won't be just across each one um only minor note on that is i would name it interface not json rpc

um at some point we might bring in other other protocols like grpc if once an artem gets his way or we have rest for the consensus application layer i think they use rest for their communication and it feels like all those things should go in this repo like this is the repo for how various pieces of the system talk to each other essentially yeah that's what i'm imagining at least yeah so are we are we thinking that rpc methods that are implemented by say just wallets like wallet ad ethereum chain and so on would also go in this repo that is in my head that's what i'm imagining um because that that still is an interface which is between dap and wallet right and you've got the interface between

wallet and client you've got the interface between application client and consensus client you have the interfacing condenser client and wallets like each we could split each of those connections out but i worry that we'll end up with people being confused especially since there's some overlap like the um dap wallet and wallet clients application client interfaces are very similar like they share a lot and so splitting it apart into like one repo per like pair of things um feels like that's not quite the right solution and so that's why i'm thinking one one repo for all of it open to other radios though yeah now i think uh i think that makes sense

okay to conclude for this uh particular item like we have to wait for some time and maybe when we are getting more clarity on how to merge with the each one and e2 spec as the ethereum spec repository then we will uh proceed with uh like creating a pull request there and having that living there on that repository itself uh you're talking about the for the eth1 specs merge uh yeah because i understand that we are not planning to have the json rpc spec on the eat one spec repository so uh it will be created on the each two only directly there uh no no so the the current thinking for tim's

feedback long ago we've pivoted very rapidly uh the current thinking is now have a new repository that is just for interfaces basically oh sorry sorry uh yeah i got it no i i just messed with yeah okay uh so we have just a few more minutes left eric uh do you have any more questions or uh i i don't uh at this point i really appreciate that uh you guys decided to talk about this and uh i think the solution sounds good great thank you for joining us and we have just couple of minutes left here for this particular call i wanted to

quickly check with brent if he has any update on canonical source of erp that he has been working on okay yeah yeah we have made a little bit of progress we got one of our engineers got the jekyll system running on his personal system and now we're moving that to a public system and once we get that up and running then we'll have a staging area where we can stage proposed changes so don't have a lot of time but we're making some progress sounds good um so i know many people have to drop now to join the other call and we have almost had the time so thank you everyone for joining us today see you all in next uh two week on april 7th and the timing

will be 15 1500 utc will be back on our uh usual timing thank you everyone for joining thanks see you later thanks