EIPIP Meeting 30

Transcript

all right welcome to eipip meeting i'm puchar ranchan and i have shared the agenda on the chat so the first item is splitting out eip reports into eips and erc um there is a link which we can follow this item was discussed in the previous meeting and hudson created an issue for this where he kind of summarized discussion so far uh michael further added gold and potential solutions and major road blocker for today's discussion that we would like to resolve so uh the goal mentioned there is a separate notification system for erc editors and subscribers and eip

editors potential solutions separate github repositories that we discussed in the earlier meeting so people can watch on the only one repository or both if they would like to uh the problem that we discussed was a numbering system so i'm trying to open the floor for any other comment or suggestion uh can we just start from the goal like how to separate or do we actually want to you know is there any other way for a separating notification system so if we take a like uh yeah please go ahead micah i was going to say my preference still

is weekly and just allowing for duplicate numbers across the systems i think um my preference i think i'm sorry let me meet my phone my preference is um so when you say duplicate numbers you mean like having an erc1 like starting there yeah so start with the rc1 and we might very unlikely but we might end up with an erc that has the same number as new ap so what about people who do naming conventions where because like erc20 is technically eip20

um and like there's some eips that are erc's but are not referred to as ercs but they are ercs um so we don't have to worry about collisions the other direction because the eip started out way ahead well we don't have to worry about collisions the other direction anytime soon because eip is already up to like what is it three thousand five hundred or something and it'll be a while before yet ercs catch up assuming they do um i don't and by and when they do catch up they will be called ercs not eips because we'll have super repo and also ever process whatever and so not too worried about that particular problem i think the counter argument against just allowing

for duplicates was people are worried that there will be user confusion yeah that was something with the whole like early numbers are considered older and so erc five people will give undo weight too because oh it's got a low number it must be really old yeah that's kind of where i'm at i think we should start we should just pick a mid number um or starting at a certain like 3000 whatever and just go up from there where there's ercs and eips separate and they can overlap i think that'd be my my solution if we want to do that i think we would need to either come up with a new mechanism for choosing numbers which is fine or uh someone write a

script that will burn through issue number one through 3500 in the erc repo yeah that's that's a good point i don't really have an answer to how to do the numbering system across both could too hard to run through all the numbers i don't think uh i don't think i get rate limited it's like a day or two on a script so i was wondering like in the last meeting we also discussed about uh you know having a separate repo for erc but uh opening you know just issue uh section in the eip report so that we do not have the overlap

and we do not have to go back to number one um i was wondering do we find any uh any issue with this proposal like maybe uh to implement this my recommendation would be to discourage people from using the issues of eip repo to open it for eip discussion and like as we were also encouraging people to open an issue in the fellowship of ethereum magician so we will going forward maybe we will keep the issues section only for erc's to grab a number that way we will never be in

conflict with the eip number and we will not disturb whatever has been done uh till date like whatever ercs or eips were there we will not be disturbing that do people understand that would not resolve it would not resolve our problem of subscriptions because you didn't generally subscribe to a whole github repo or at least i do uh i don't think you can subscribe to just issues or just prs like you described subscribe to the repo or not ah i got it i think the easiest is if we're so if

we're okay with eventually having duplicate numbers at some point but we just want to not have low numbered ercs for historic reasons i think just writing a script that burns through issue number one through 3500 on the erc's repo is probably the easiest and it sounds like it satisfies most people the biggest problem there is is finding someone to write it maybe we can get elita to do it she sounds interested in picking up some work pretty easy script right and it would require some of the new numbering can't know okay sorry about mike wasn't working um i i still really feel like we should not have conflicts

between the ips and ercs and i'm not you know tied to one certain way of doing that i think the two ways that we talked about are a a spreadsheet or something some central source or we could do it have another repository where you create an issue to get a a number and then that way that always is happening sequentially and then they just post a link to say hey i request my number here this is my number can you give a short reminder on why you don't want duplicates across i think that people generally use um

you know refer to their eeps and ercs by their number and there are many famous numbers and it would be bad to have an erc 1559 or you know an erc 2718 and you know as editor sure we can kind of try to avoid those things from happening but i just don't think that that's you know a really good solution for for what we want i think like long term even i i this may be crazy but i kind of think we could really move away from eips i actually thought about this last couple weeks i don't even i don't think eips themselves actually make much sense and so then we would just kind of be stuck with erc's and then that we wouldn't have this um issue of numbering as as much

i like the idea of just getting rid of vips that'll solve all of our problems i i've talked to some of you about this and to me you know we we kind of like you know model off how bitcoin did it bitcoin kind of modeled it around like you know how pep and rfcs did it and the thing is is that you know for pep and rfcs there kind of isn't like you know rc's especially there isn't one canonical internet there's lots of different implementations of many different protocols and it's not a requirement to have to implement you know this certain version of http there's many versions that you can support and there's you know different things you can do but for ethereum there's one ethereum and so it doesn't you know in my mind make a lot of sense to have lots

of lots of eips that you kind of like understand in a piecewise fashion there should just be a single specification that you understand as one unit and i think like on the longer term that would be a much better way of going about proposing network changes if we're putting prs against the specification i think this is exactly what eth2 is kind of doing yeah you have my vote um the hard thing i think is going to be convincing like migrating everything to that and getting the initial specification up like i mean that's probably half a year to a year of work just to get the initial spec yeah i think yeah i mean it's something just to kind of keep in mind um there's someone who i believe is going to be working on a spec in the not

too distant future for some other reasons and i think it's going to be you know as you know the most comprehensive speculative ethereum more comprehensive maybe even the yellow paper and i think that and that's gonna be written in like a python or something simple like language and i think that's something that we could use as the you know canonical spec at some point but yeah it's not something that we had to do today so if i understand this correctly you're saying that the decisions we make here don't matter long term so it's okay if we take on some short-term technical debt because your belief is is that technical debt will just kind of be deleted when we move to that is that correct

yeah and explicitly you know the technical data is that we are coordinating two numbering schemes to make sure they're sequential and i think that long term that we're going to go back to having one scheme anyways and so in the interim i don't think that is a huge issue to deal with if anything it might catalyze the effort to get away from eips all together so if i understand this correct like uh the suggestion of uh separating the reaper we want to keep it on hold for some time and as you're expecting somebody to

start working on it and then we'll have a better picture of it i don't think we want to keep it on hold i think lakeland is just saying that eventually the eip's current eap process will probably change if we don't get our way but until that happens we would still like to have erc's and efp's split apart i believe at least that would so do we do we think that alicia's help could be useful to deal with them in the meantime uh yeah so from given engineering resources there are a number of solutions to this

so uh one is just to make a if there's a bot on both repos it just checks for collisions like as part of the merge process just to make sure we don't merge collisions that's one way another way is a little tiny little web app that runs somewhere um did we lose micah did i lose anymore yeah no i can't remember if he's talking i hope he's he's back yeah he's cutting it out you guys can't

hear me now okay uh did you guys get uh unfortunately not if you can repeat like yeah none of it and you're supposed to sorry about that can you guys hear me now i can hear you now before you've missed anything before now yeah i am so basically saying given engineering resources there are a

number of solutions this problem one would be to have a merge bot sitting on both the rfc repo and the ip repo that just make sure anytime there's like you sign a number just like normal and if there's a conflict it'll adjust the bot will tell you and you can give another one so that's a simple solution that if if we have engineering resources to spend another one little tiny web app it just gives out numbers and we can just ask it for a number um via some mechanism maybe only uh editors of the two repos can do so so that way someone just doesn't click the button over and over again um so i think the problem is easier if we have engineering resources allocated to it it usually is yeah that's really how the

world works right i agree though yeah i think uh for this uh if if there is a solution and uh i know alita is available and she showed her interest in working towards it so if this is something that we think of like a priority amp i think the cat had us would be happy to fund this thing and get it fixed for the solution we need for the time being i mean like maybe before march uh whatever the eip process we are following so is it something that we should consider now yeah i don't actually care that much about how the numbers are picked um i have like like i said my preference is very weak i would rather just get things moving then spend another two weeks debating it

so whatever people want whatever gets the ball rolling um uh how comfortable light client and micah you both would be if we have alita allocated for this job and she can get in touch with you get the requirement and try to resolve the situation same sounds good so uh um unfortunately she is not here she mentioned in the discard that she may not be able to make the call but she also mentioned that she would be interested to help out with so i'll be having a word with her and maybe then we can start looking into it anything more on this topic before we

will move on to the next item yeah i think one last thing i have um i just want to make a quick mention of that um that we are working on securing funding for eip and erc's adidas as well like we mentioned earlier that uh it would be helpful to hire more people but funding was an issue now we are looking into that respect may if not in this meeting maybe in the next meeting if we could discuss an estimate of how much funds would be needed for three to six months that would be helpful for us the cat hurdlers to talk to sponsor censor arrange that i think it depends on how high quality of editors you want

and i'm expecting uh the present editor's input for this because i think those people can give us a fair idea and we would be just people to arrange resources and funds um quick quick note before we close out this topic uh the someone should probably look at the rc's i've been auto archiving them for our last conversation and uh they're starting i have noticed they're starting to pile up yeah i'm planning to do that soon okay i fractured my thumb about two weeks ago and unfortunately that has caused you know delays and reviewing eeps are you one-handed right now i've got a full range of motion in my fingers but

i've had to like buy a split keyboard and tilt it so that i can type for more than a couple hours at a time it's not good you could just uh get it get a saw and cut off half your space bar and then lay your thumb in this in the gap there we go okay so if that's it on this item i will discuss further in the next meeting about the next steps that we kind of agreed upon in this meeting moving on to the next item it's a json rpc api spec support needed for coordination and funding a couple of weeks ago we organized

peep and e for ap 147 for json rpc spec there we realized that such spec need not to be following the standard eip standardization process and should not live on eip repo necessarily in the last meeting we came up that we should have a placeholder for these kind of spec maybe on each one spec or somewhere else tomas has been leading the json rpc spec calls where all parties joined to discuss this standard spec and in the last meeting as well as in the json rpc's last meeting it was discussed to make e1.0 repository the placeholder for these specs uh thanks to mass for

joining us today uh to discuss how we can provide support that is needed for this chance to move forward unfortunately i don't see eric and sam richards the other two participants who we have contacted for this issue um the mask can you would you like to go ahead with the summary that you have mentioned in the comment for reference hi yeah uh thanks for invitation and i'll be happy to share some summary of the last two or three months of calls with the various teams including the client developers they

library implementers like the libraries integration libraries implementers the tooling implementers and so on um so we started by analyzing whether json or pc api should be more of a change in suggestion of changes or simply a spec of existing thing and there is a very clear agreement that what we care about is the spec and to deliver the very detailed information about all the mostly used json rpc items and one important outcome of this course was that we no longer would like to approach it

from the perspective of the entire json rpc or modules because that's the level of view where the most differences appear that are not necessarily differences that cause trouble to the user so like if you think of the entire module that has 20 or in some cases 30 different endpoints it might be that not all of those endpoints are critical or standardized and they don't have to be but if we look at single endpoints like eth block number or eth call those are widely used implemented in all the clients and this is where on the low level the specification is missing

and our initial view was that some way of specifying each of those endpoints separately in a most formal and ethereum style way would be good and we picked eip processes the the way to go however recently i was suggested on those calls uh that's within eip ip goals you had the vision of moving things to the spec repositories for ethereum one and potentially ethereum two and uh this is totally fine and if you're asking about the support i think that all these people that are willing to work on actual spec preparing the details of endpoints

and finding out those such cases and describing them uh would benefit from from some help on just just arranging that properly and organizing that within repository that would um that would follow the style of specification that you picked for all the other items within ethereum so like the the exact form is not the most important for us uh what we would like to achieve is ensuring that it's complete on each endpoint level and it's every single endpoint is separate so so that's we do not have the spec which is a single document for all the end points that is not a spec that is

separate document for each module but it's actually a spec where you can clearly separate and independently edit every single endpoint within json rpc again explaining that by endpoint we mean here i think like a single method eth block number with different potential parameter setups the of the modules that are in question so the eth module is the one for which the end points are mostly used and most important and where we can get some immediate gains by just simply specifying one by one uh some of those like block number like call

estimate gas the ones that are used over and over um that's called because of their complexity and wide usage and many different users asking for additional functionality improvements changes they ended up being slightly different in different clients and what else so one more outcome of those conversations was that uh we do want to have the uh some technical way of describing formal way of describing the cips is well something that would at least defined interfaces in a way that alice for automatic code generation or automatic verification of the

api being implemented by the given client or not and that's that's where there was wide agreement that open rpc format can be reused this is something that was initially created within the domain of ethereum classic and i believe that zachary belford is ready to help here with writing this part of the spec so we think that every single endpoint will be the description that will define what clients do now and if there are any discrepancies it will suggest how they should be resolved but also there will be a technical part which we say oh this is the uh this is the formal spec following the open or pc standard that you can use to write tools to

generate tools um then also i know that ethereum.org wanted to be hosting that information so that would be great if that's uh automated in some way so this info is not um over time it's not being updated on any of the sites whether it's spec or ethereum.org [Music] and also when think about eip1474 which was like the the first probably the most successful attempt so far to do json rpc specification that one is approaching json rpc as the whole but but it also provides all those basics of explaining what the types like

quantity or block number block graph and so on data are so we we still need the basis uh so we'll still need to explain those basic r repeatedly used types and we think that maybe something like that can be introduced almost like a both as a basis that those uh endpoint specific documents can refer to but also something that in the end can actually gather the links to all of those endpoints and create a way to navigate between them so while we say this we don't want to create a single document but we actually after creating many

documents we want to create one one list of like references links to to all of those and i think that's it really so i was looking into some conversation on the discord channel and there was this mention of creating a folder and they eat one respect people so uh how do you guys uh want to you know proceed in that direction like getting access to that is okay or is there a defined group who would be reviewing the pr and we can manage it on our end do you have any thoughts on that part i think this part we don't have uh very formally specified so i think that there should be reviewers

for each of those and then it should include at least all the uh client developers saying developers from all the clients represented saying oh yeah this is correct as for the current state of things whether they should be formally having access to that repo or just simply submitting prs and making comments via standard github interfaces it's an open question i think you might be in a better place to make those decisions and suggest us the something that would work best based on your experience i think having a finite number of editors who are just familiar with the process

is valuable um it keeps people from accidentally merging or thinking they've gone through the process correctly and then they just merge and it's too soon or there was an agreement so my recommendation is have a core group who are most familiar with the intended process that have merged rights and everybody else just operates on prs yes i think that we would like to suggest on one or two people that would be actually writing the spec if you think that you can um that you have someone that you can suggest for that role so eric eric suggested zachary's i'm not sure if that's uh i assume that's with zachary's knowledge

that's how it sounded in the email and if if there can be one more person involved in actual writing and writing the spec and contacting people then i'll be very happily helping to to just get connected to all the client teams all the tooling teams for these reviews um and i can be in that process like on on decision making on when it's ready to merge just because i think that i remain the person that that's actually connecting all those teams and deciding what is what is the common agreement around bertie gerstberg and everyone else can be just reviewer

or if you suggest that there should be more people that will actually uh reach out to every single client as i uh please suggest this one person that would be familiar with this and would be ready to add documentation photos back and be responsible for communication within the team so i think to begin with creating a folder in each one or spec repo should not be a challenge we can go ahead and create that folder and uh if you would want to you know write the first initial documentation for this that would be great and on the development part as we mentioned that maybe resource is needed actually i was

approached by someone to kind of fund these kind of uh activities so i'm wondering if we have some someone in mind already who is the developer for this or maybe the funding needed for this particular uh development and documentation part so i'd like to underline that funding actually is not not an issue here uh it's more about finding the people that are ready to work specifically on writing with all the support of actual resolving the the questions finding answers to the questions of how the things uh what should be described so it's this like uh maybe a bit more entry-level

uh task there's a person that's that is exploring this rpc or works more like with json or pc but not exactly as a developer of the of the implementation and it's ready to work with developers and ask questions for for clarification work with me and ask where some additional input is needed sounds good uh we will try to spread word around this for the requirement and if we have someone we'll send it to you uh what what are the thoughts of other people here uh unless like having the access and a folder on each one inspect ripple

who is that of 1.0 specs oh i'm an admin of youth 1.0 specs okay so we do have someone here that can actually make these changes yes same here oh yeah tim can do it too either one of us or pooja too pooja is an admin so uh yeah for uh the next steps we i'm gonna go ahead and create the folder for json rpc spec and we can start working on it uh tomas if you would like to start uh you know kind of the first thing they read me or the documentation that is needed we can start from there and see uh how uh different clients collaborate and try to add

stuff there does that sound okay to everyone sure yeah i've prepared the eipp version of it so i'll try to move it one two one to this folder if you have any preference for the actual format then let me know otherwise i just follow the format of vip even as it's formally will not be in the ipa but i'll just use the template eap template sounds fine to me because it is not living on the eap repository i don't think it should be an issue here it can be in any way that is preferred and easy to maintain obviously we are expecting it to be updated with the help of pull requests so whatever template we

may decide on the first should be okay right so if it was if it was me um which is not um i would actually model it off of these 2.0 specs repo rather than eaps i believe if you take a look at their repository they basically have markdown files which are just specifications like they don't have you know motivation sections and rationale and security considerations they just have a spec and it makes it a lot less wordy a lot faster to iterate on and generally just easier on everybody i think also worth noting that uh

when the merge happens or before the merge happens we're gonna want to merge those actual um those actual repos so doing stuff that's you know in line with the e2 specs repo is probably future proof as i suspect you know the e2 specs repo is much more fleshed out than the e1 specs repo so that's probably the one that will will model everything off of yeah i think from from my perspective this is one thing that i would need the most support with like just be very very clear on when it should land

um this feels very vague um since that last meeting when we were said that when we were told that eap is not a good place it feels like we are suggested not to use the ap but there is no clear information maybe or where to go so if it's if 1.0 is back then i would love to see also the roadmap of how exactly it will be transitioning to if20.0 and when we can expect some decisions here that roadmap does not exist yet so i guess well yeah i i would not uh block your efforts on that i think the ethernet specs probably make sense to use right now adopting you know a format that's

similar to e2 is you know likely a good idea but there's not like an official i don't know road map or plan about when we transition that yet i see a comment from micah about the folder it's like eat one dot oh dash specs slash interfaces slash application slash jason rpc so if we want to have these many subfolders in that it's fine the idea there is just that over time we

have the beacon client which will have its own set of public facing interfaces we'll have the application client which has instead of public facing interfaces some of those are json rpc some of those are rest i think it would be good to just kind of from an organizational standpoint of course we can move things later so if someone just wants to throw in the route for now we can always move it later not a huge deal just trying to future proof a little bit there yeah i think anyways you know when we merge the repos we're gonna have a bunch of like wrangling to do so i think it's fine to have jason rpc as a top level folder for now there's no sure i definitely wouldn't block that yeah so it's a fine like eat one dot oh dash specs slash json rpc

yeah okay cool um and the only small thing uh so right now i'm looking at the east one specs repo and it's really focused around network upgrades and whatnot like the main readme so i can i can update that like once once we have the pr for json rpc i can update the readme to just make it a bit more general and mention that you know network upgrades are only one of the things that's being tracked here yeah that was another point i was about to mention that we might have to update the readme because initially when we started we only thought of network upgrades so we wrote accordingly but now we are including more stuff we'll

may have to add some stuff there thanks okay um i think if we are good on this part uh we can go ahead for the next topic um and uh obviously i'm gonna connect with you to mass offline and see if there is anything needed more on this thank you so much perfect moving on the next topic on the agenda is eips and network upgrade process requirement um there is an issue uh linked to this item so we discussed this item

in the last meeting and people seem to be in agreement offer the format that that i proposed in the comment section um like when it is cfi it is in draft when it is dotnet it would be for review and the mainnet phase uh it will be last call eaps will be marked as final only if it is deployed on the main net um jim has left a couple of comments um so on that part um he mentioned about removal of the testing green light thing and instead of that he suggested to add i mean reword it differently i'm

trying to find out my issue so yeah if people have thoughts on that yeah i'm looking for the issue right now but basically the testing green light phase does not exist like so there is no testing green light so i don't think it makes sense to have that um and then yeah i think the time to move eips the last call is when we agree on a list of eips for a hard fork like we don't want them to be already on the test net we want to say like look this is the london art fork it's eeps one two three four clients are gonna put out a release with block numbers for this then the eep should absolutely go into

the last call so that would mean the devnet phase uh here i'll post the issue um the devnet could be review devnet would go into public test net then yes exactly i like that yeah so yeah i'm also in total agreement that the eip green light doesn't does not make much more sense here so we can simply remove that section and yeah i'm fine with that so what basically we are saying is like when it when it is in cfi then only it will be in uh drafter review when it moves to uh devnet

it has to be in review or last call no it has to be in review okay and then we move it to last call when we decide basically the the fork block numbers and when we're when we're sure that it's going into a fork on mainnet um tim we had a long conversation i think either one or two eipip meetings ago about what last call means by definition and what the like what the colloquial like definition of last call is how do you define last call people should look at this right now because it's about to go on my net which can changes happen during last call i mean they can happen but they're i

guess the burden to change is pretty high right okay okay um i was under the impression that last call meant changes can go in because usually people don't look at it until last call but if enough people want to if the definition is different than how i'm thinking about it i'm i'm cool with that and um we can go ahead and make last call like uh really this is the final time to look at it instead of changes can go in and i guess the reason why i'd be i i i would agree with you in theory but in practice we don't even move stuff like we didn't move the eaps for berlin the last call until two of the test nets had already

forked right like so it's still a net improvement if we agree to move at the last call when when we set the fork blocks as long as the definition on eip1 um starts to say that last call means only only the most urgent of changes such as security can do things so not like nominal changes um and then i guess the other piece is should the last call mean the same thing for ercs as well because i know we're talking about you know just mainnet eips but so i think the definition of the rc uh last

i think the definition in eip1 is pretty good like it says this is the final review window for an eip before moving to final and the ip editor will assign last call status and set a review end date typically 14 days later if this period results in necessary normative changes it will revert the eip to review which i mean it's general enough that like it works for magnet and ercs okay and what's normative mean in in the uh or what do you what do we think normative means because to me that means like any changes so it just means um once it's somebody's final you cannot do changes that change the uh the meaning of the document so in the case best technical specifications you

cannot change the like protocol that you're working on however you could make an edit to fix a typo or you can make an edit to improve some wording or something like that you just can't change the the content itself like it still has to say the same message unless there's a security vulnerability that we need to then you know throw a hail mary and revert things or if there's a typo got it okay once something's final the security vulnerabilities require a new erp like let's say last call yeah oh last call you could do non-normative changes unless call yeah and but that's the thing yeah it says they have to be like necessary and necessary is a very vague term like i think we can i think we all have like an agreement

based on you know the core devs process like what's necessary and what's not um and it's quite murky to define beyond that so i'm finding it pretty general okay i'm okay with that too then if everyone else is okay with that um yeah that sounds good to me so we're getting rid of testing green light main net phase will literally just be main net and everything else will be devnet phase unless it's cfi applied um no i mean like are we moving the public test net to generate maybe not so public testnet should be in last call because we have to set yeah we have to set

the fork blocks you know before we we do the public test notes i'm talking about the black box phases that are under the thing so we just i think we just removed testing green light basically okay yeah so test net will be on the main net phase it just that the review status would be last call and for mainnet it is already final so everything is fine if we just need to get rid of the testing green light box here right yes and then you remove the review as well right because yeah um yeah that review part was basically because of the existing of this testing green line yeah exactly okay fine i'll update that sheet

yeah i think that looks fine everyone if you can update that and post a comment in the issue i'll i'll just bring it up pretty quickly on awkward devs at the next call so people are just aware that we did the change sure so one also one important change that we discussed in one of the earlier meetings that last call which was for 14 days only this is not going to be 14 days only it is minimum of 14 days so that is one change and the other change is resting green light has to be removed and status should be last call sounds good cool so if we are good on this we can go

ahead on the next item but probably we can skip on that because alita is not here and she already left it yeah like client um so i was wondering is the is the purpose of um considered is cfi kind of meaning that cordov expect that to go into a hard fork or is it something good going into a hard fork like is that distinction makes sense so i just put up an issue for that uh yesterday on this connected

oh looks like it's machine talking connected every time so all right so it just wants to keep connecting to my phone can you hear me yes no we can hear you yeah do you want to go again we kind of missed the second half of what you were saying uh yeah no i think i got most of it out i'm just trying to understand like the what is the true meaning of cfi or is it something that quarters to eventually so my point of view on this is so much context changes during forks that the stylus should probably reset every

fork um because like otherwise we end up carrying a bunch of old eeps as cfi and it kind of doesn't mean anything anymore i was looking and i was looking yesterday at the ones that got basically cfied before berlin that didn't make it into berlin and frankly you know they're all irrelevant the only one that's relevant is at 2537 and that got brought back into berlin so you know i yeah just like cfi it again so that's kind of my i guess my my read of it would be it's like you know generally positive towards having this in the upcoming hard fork um and um you know that doesn't guarantee

inclusion and i think by default it should reset uh between forks and you know the bar for for it the unreached you know to become cfi again it's just somebody stepping up and saying i want to champion this for this fork um so it doesn't have to be like a huge bar but at least we know there's still some interest we know that the proposal is still relevant um because like for example you had 2711 which was sponsored transactions which is basically superseded by 3074 right and it makes sense for you know 27 and 11 to just like not be cfi anymore and like you know for 30 74 to be because that's the new one you're championing um yeah that that all makes sense i think like the

main reason for asking this is that you know my experience here with 3074 has kind of been and i think this is like something that's going to be general eeps that aren't brought by you know basically by like a core team is that you know you it's really important to have people look at it but it's really hard to get people to look at it without a stamp of approval that's going to a hard fork or like some sort of something that says it's beyond just a spec that someone came up with last week right and so to me it felt like maybe cfi is that thing and i'm trying to understand if that is the case where you bring it into all court devs and you say here's a change that i want to make i want to champion it for the sport and cordev say yeah that makes sense

we could see it go into this fork maybe here are some things that need to be done to make it happen like you need to have some support you need to do an audit whatever but we'll move it to cfi that way it has the stamp of approval that you can go to the community and say look is this something that court does like are are amenable to having in the fork i need support from the community that makes sense yeah i i think yeah i think that's the agreement if i approved so when it is like approved by the coders they said that okay this and this changes we can expect and then it will be included in the book that is the the net phase when we say it's cfi approved right yeah i mean yeah it's approved by the court of cb cfi

what is the what's the stage for we agree it's going in the hard fork i think that's after right it's like and this is kind of the murky one where like you know we have the devnets and whatnot then we at the end yeah have a feel for what do we want to put in the actual fork okay and it's kind of london has been weird in that regard like for berlin we had everything cfi then we did the devnets and then we kind of picked and choose what we wanted in the fork london we kind of went the other way around because we kind of knew 1559 was going to drive the fort we and 1559 had been cfied like you know two years ago or something so like 1559 went right in and the difficulty bombed as well and

now we have like other stuff that we're looking to you know also add in the devnets but we haven't made a decision about whether they're in the fork or not um so it's yeah it's a bit murky yeah okay i mean it seems like it's it's how i was understanding it maybe in the future we can have like a little bit more process around but you know see if like when something is cfi like i think that it should be okay for something to be cfi if it's contingent on something being done like 3074 is kind of contingent on this audit and i think that it's okay for things like that to be cfi but there would need to be a place to say like this is cfi and it's contingent on x y and z

i agree yeah and we don't have a good place to track that right now like we don't have a good place to track what's the what's the decision criteria right um yeah yeah and we we can come up with that at some point uh just bring it up now doesn't this have to be done this week yeah but yeah i i generally agree cool that's some good session here on cfi so yeah we can come back on the criteria that we would try to document somewhere maybe to define which proposals can be considered for it or not okay so we are very close to the uh time um uh we have

one last item that we quickly want to check on that is progress on canonical source for eips um i'm not sure a brent do you have yeah we've got a uh staging site up now i'm gonna paste that url in the chat thing and we made a slight change we're still um and so you can go to there and and and and it's a mirror a staging mirror and um and so we're learning how to modify and keep that up to date but other than that icon up on the top of the page we haven't made any changes yet but anyway making progress that's kind of slow and also i had the question how are changes made to the ethereum.org

because some of this i think we're going to want to get some changes into ethereum.org is that something we contact yeah how does that manage or um with ethereum.org it's an open source repo in github um so you just do a pull request there and then get one to review it oh okay cool that's right and do you guys have the uh repository for that uh i can find it and send it to you but i think it's just a theory a morgue okay i'll look forward and channel okay okay cool thanks so much that's all i had okay that sounds good uh the last item is discussing about

earlier decision items and action items so i'm just gonna quickly run over it so see if if we missed on anything cfi uh draft defnet review those were the decision we already discussed it today split editorship between ercs and eips without this separate repos we haven't covered the editorship part yet but we did some uh discussion on the splitting of the area pose allow what to fail if it was going too much to be turned on at a later date i am not sure if it is related to eip but uh so on that one we need um in order to turn the bot on we need

someone with admin access to be around when we do that and so we've been struggling to coordinate with the admin of the ips repo to get that enabled that's the number one hold up right now okay do you have i mean like any leads on that or if we may look into it i think hudson's an admin and james is an admin i don't know who else uh twitch repo the efp yeah uh oh no uh micah you are now an admin so is elita so am i oh okay uh then we'll take care of that then i didn't know we got powers yeah i forgot to text it or i might have typed it and then didn't hit enter uh i forgot cool so we got it solved

uh the next decision was around for json rpc so we we discussed it today create a new repository that's just for interface instead of migrating to e2 specs repo uh i think we are moving in a different direction so that's fine and action items uh deciding on number system between erc and eaps i am not sure if we have made a decision on that but i'm sure alita light client and mica can be working on that and we'll see i mean like we'll see uh how this number system has to be considered action two create an issue in the api

people to separate erc and eip's repo yeah hudson has already created an issue maybe whatever decision we did take on numbering system or moving ahead with this process we can keep on adding that doesn't comment so that's all from this meeting today doesn't even have anything else to bring it up well thank you everyone for joining today see you all in two weeks have a great day evening bye thanks all right thanks thank you