EIPIP Meeting 27

Transcript

okay so hello everyone and welcome to eipip meeting number 27. um the first item on the agenda is the eip github repo action bot um and um pj you said you have a small update because i don't think elite is here yeah considering the issue with the present efp bot the eipip group discussed to address this by possibly having another bond and ethereum cathedrals are funding the effort and elite moved from the team is working on it i guess she made some progress as far as i know she had some questions related to testing but unfortunately i don't see her on the call today

so maybe i would ask her to get in touch with the micah if that is fine and uh yes we can get it done like often okay sounds good all right uh the next item is progress on the content for the eth 1.0 spec repo including json rpc and network upgrade pages so uh the atm we are trying to add some useful resources to ethereum one dot or spec repo uh and uh i believe james uh is uh taking care of that um maybe adding

the previous network upgrades and some effects i have just one small update on gsn rtc side that ech is organizing a peak meeting for eip 1474 remote procedure call specification on march 17th with eric marks and maurice one we are where we are trying to provide the overview of the proposal and how the implementation is done because many people have questions on that particular proposal helping out with this uh just not respect so if people are interested please feel free to join us on march 17th all right great um item number three is the relationship between the eighth one

and eth2 specs um i think that's something that danny put on the agenda and wanted to talk about today with the merge coming up and things like that so um danny if you want to kind of talk about what you had in mind for the discussion today and we can uh chime in so as you know largely we've done specification writing in an independent repo called the eqo spectrum though um and moving forward we are beginning to write specs that have a tighter relationship to existing specifications um things that we normally call each one specifications um and just for some context the way that we're currently writing specifications and currently protecting things is

uh essentially take each one subtract out proof of work addie's two as consensus layer um and you have specifications um obviously we did 2982 at the end of last year which was met with some contention from eip editors as to whether that actually made sense to tie like the 20 specs repo into the eips that way in an informational spec and i just want to pick your brains get some advice get some thoughts on how best to do this because the specifications moving forward look like modifications to the consensus layer proof of statements layer specifications in the e2o repo

and linking somehow into the application layer specifications which is largely like what we call ease one largely exists in eips uh i know there's also the yellow paper i know there's also this one of specs repo on releases um and there's a lot of moving parts and it's not clear how to it's clear in my mind how to link them together technically uh but not necessarily practically from like a specification and maintenance standpoint so i just wanted to see if y'all had any ideas and i don't suspect we'd necessarily decide today but i just wanted to put it out there so i guess my first thought is

what is the way that we can do this that best signifies that this is a single etherium um because i think that's really important to make sure that we don't frame this well it's already kind of a i think misnomer might be the right word that eth2 is like totally separate from each one or like is a whole new thing and each one's deprecated more so than this merge that we're kind of developing a new narrative for um so i think that's an important aspect i also think that it might be hard to answer how it should come together until we

figure out how best to organize eth1 stuff and get that complete because from last i heard and someone might be able to answer me the yellow paper is not updated the eips repo is still looking for more editors and the ethos spec repo still doesn't have all of the things it wants in it yet including previous network upgrade information and some other stuff like the json rpc spec help me understand the eth1o spec repo is that primarily what it does is it takes like a bundling of eips and says like this is essentially a release and specifies them as such that is part of it yes so it used to be when you go to the eip repo

you would have um different you would have meta eips for like homestead and all those other ones and that would really conflate a standards process with a release process including stuff like having final and eips mean it's enough work uh when you're talking about quarry ips so we've changed up some of the terminology um and also tried to separate out the standards from the non-standard stuff including network upgrades to make it a little bit easier um i think mica was a big driver of that so he might be able to give him a little more color as to why that why that happened great um

interesting so in my mind and maybe not in the mind of everyone but what we call each one is more like in this and in a merged world each one minus proof of work is like the application layer and ease two is the kind of consensus layer the cradle for the application layer um and maybe maybe the linkage is actually between these two spec repos in that when there's a once there's a merge there's kind of things are released in tandem where the application layer is at this point and the consensus layers at this point um and they're they're tied together through um essentially on the on the on the consensus layer there's like a function

call under the application layer but in it it might be very clean um it also might there might be more than one tie and it might be it might be dirty and we might just kind of see how it how it lands um so that's one possibility um and to so tie them through these two repos instead of through the eips like i tried at the end of last year but i'm definitely open to thoughts and ideas here so my initial thought with the process that would result in the least change to the process would be that anything that needs to happen for the merge that would go into an eth1

client would go through the ap process so any changes that each one clients need to make prior to the merge and then once the merge happens at that point any changes to either eth1 clients or e2 clients would go through the eip process so basically the e2 clients would join the eip process as of the merge until the merge then yeah right i see that so in that sense the east 20 specs become something like the yellow paper as in like the foundation before it started and it can still be maintained in tandem but iterative stuff needs should probably go through the iep process i see that does these two have an

improvement proposal process no it's quick and dirty um kind of by design things move very quickly and rapidly and we do have kind of rough consensus in the specs repo and what gets built by clients and released but the plan is certainly to refine that into a point in which that it unifies with the e10 development process at the merge so it does not have a formal process right now and that's also one of the reasons i'm chatting here is that it certainly should have affordable process at some point in his life time and that is certainly at

or before the merge so from where i see this like uh just to be clear i am not missed it i think micah might have a delay go ahead puja okay so from where i was uh looking at this uh each one and e2 merge process i consider this like to be in like three phases if we divided that would be helpful for both of us from the ethos client perspective and maybe from the e-2 client perspective something is like pre-merge stage hypothetically like if for this merge has to happen like in like next 15 months by the summer of 2022 so we have this pre-merge phase so we have to work on the proposals that is

needed for the e2 much later on preparing for the merge would be like next stage and post merge so from my understanding at least one of the each one upgrade we are seeing that is definitely before the merge okay and if we consider that to happen before august we we might want to focus on the proposal sites like which proposal would be if at all uh that would be needed for the eat to uh merge and then for while preparing for the eth2 whatever proposal we could not consider and they and we find that these are useful and that would be needed or maybe helping out in like whatever the shifting of brain from each

one to e2 would be required we can look into that the third part the post merge is something from my perspective are more important for researchers to figure out what is needed in each one client at the end of the day and this will drive the first and the second phases so what i was trying to mention here is like if we would like to consider this much process uh not the process of the overall uh ethereum chain running but what what we are expecting from ethereum 1.0 client maybe we have to figure out what e2 needs from us as that was mentioned in the last encoder meeting right yeah and so there's there's two parallel

things happening here there's the the practical standpoint of like communication and coordination between these two pieces of software and then there's also the how do we write it down and where do we write it down um and there's interplay there certainly um and tim and i and others are going to work on the the practical component of like what actually we plan on producing a document the next week or so that says like these are all the things that actually need to happen at least from the best of our understanding right now um and we have a relatively clear path on how to begin to integrate those onto the consensus layer side on the on the 2o side in terms of specifications and then

we need to think about how to integrate them on the other side and i think um you know a number of these things can show up as as eips but contextually the eips need the so like for example the change of the difficulty opcode um that that's you know essentially like bricked in a proof-of-state context and you need to decide what that what it returns in that context because there's legacy contracts that use it but if we just write an eip that says brick the difficulty op code it it needs the context of in the context of proof of stake because otherwise it

looks like a pretty silly eip and so at that point i mean we can point back to the 20 specs repo um but which works but there's also i don't know we need to figure out that process and mike are you back yeah yeah i'm back so just let me take your back yeah just to be clear uh what i proposed before i got disconnected wasn't um necessarily my preference just that was the process that was closest to what we have today um regarding your question on linking to east 2 specs repo so i have a pretty strong policy as anyone who

watches the vips repo would know against linking outside of eth2 repo and the reason for that is because for any sort of long-lived document repository links will all eventually 404. any lengths that is outside of your page is going to 404 and with a single editor i cannot keep up with the thousand things of 404 every day um that being said i also recognize that it's unreasonable to say okay you need to define all of uh these two specs in the eip's repository like that's insane and so i i don't have a great solution i think we might just have to accept

that we're going to have broken links at some point and that we make an exception in this one case i wish there was a better answer right yeah i mean in terms of in terms of maintenance and and if if we presume that the merge happens and the eco specs become canonical consensus for state consensus specs uh and are used in mainnet ethereum uh the there's less of a chance i mean there's definitely a chance that links break um but if we're pointing to like specific releases on that repo um you know those that are maintaining the two spectrum those that are maintaining relative eips become certainly have more of an

overlap and so there's probably less chance that it becomes like kind of an external repo that just or an external link that just dies but uh i see i mean i definitely i i i agree with you that there's a there's fundamentally kind of an issue there um and makes relevant yeah he's brittle so i mean one other and this one other potential way to do this um no i didn't think about it do does the eip refill linked to the yellow paper no for basically the same reason uh i mean the type of the class of problems that i'm worried about with the u2 specs repo is less that oh what if e2 specs when we don't go to these two it's more like

what what happens when github starts centering people and everybody moves to gitlab and now the e2 specs is not github.com2 specs is now gitlab.com two specs and then six months later they joined the bandwagon we moved to some random dark web onion yeah so again um again in this one case maybe this is a special case it's worth it um going forward like long term and this gets back to um we're saying that i don't necessarily think the eaps process is the best process for use to it might be better and would address

this if instead of having eip process that then adjusts a spec that lives somewhere else like right now the eip process kind of technically adjusts the yellow paper since you guys already have all your stuff in github it might make more sense to have your change control process b pull request against that so that way it's all in one place and right and i was thinking about that maybe crosslinks yeah maybe the eip core specs or corey ips end up being application layer query ips and the consensus ends up being like a slightly different process or at least lives in a slightly different place tell me this and i believe i know the

answer but the sum total of core eips on or at least like deployed core aps is not the entire ethereum protocol right it assumes the yellow paper and then its modifications on top okay optimistically yes i think it assumes yellow paper yeah and some other stuff mixed in that wasn't documented yeah yeah i understand um would if there was a more maintained yellow paper um and somebody doing that would that change the way the relationship with like the eip core ips and the ethernet vector repo and stuff or is that

do you consider just kind of independent at this point um i i would like that like i would love it if instead of the yellow paper we had a specs repo like you guys have for east 2 and we had it for each one and actually documented the current protocol fully and then um from there we could then do prs against that as either as part of the eip process or just replace the erp process with direct pr's to the spec the reason i haven't pushed on that or even proposed really is because that's a pretty big change and um it's hard enough getting you know one op code removed nonetheless changing the entire process so i recommend you speak with um paul paul d i can't remember his last name um

do i ask dorothy yes yes paul is sorry cat um paul is uh has a lot of familiarity with the wasm spec which has a written spec and a accompanying code spec that like kind of line by line is very literally an implementation of the written spec and he is talking about doing that for the yellow paper and updating yellow paper and such a executable spec along with a written spec might change the way the possibilities are doing here obviously there's a lot of unknowns there one will be done two who's maintaining it you know all of that uh but it might be worthwhile for

one of y'all to reach out to paul to get a handle on what he's attempting to do and whether that's relevant to the iep stuff um so let's do this we can talk about this as much as you all want to but i i will say i won't drop an eip like we did at the end of last year without chatting with y'all um and as the specs are written on the 2o side and we're trying to formalize how to do the same on the the 1 0 side i'll keep the conversation open so we can end up in a reasonable place with as few of brittle links as possible yeah if i had my way today

and we had to make a decision i'd go with the what i think what micah called the easy path or the path that like we're kind of set up for today which is the mer the eth2 repo uh does the spec all the way up to the merge and then they start filing the ips after that that that sounds like what we're set up for today um yeah i'd say barring some other decision or like reasonable path that emerges or maybe reformulation of eip stuff then i think that by default can make would make sense i the one well the one problem is there's like

there's two major things we want to do with the beacon chain one is merge the ethereum application layer into it and the other is charting iterative work on the consensus layer after the merge that didn't include sharding would probably be pretty simply to be able to be done in eips but post that but in addition to that there's the the sharding work which would be a little bit more major scaffolding work and might be more difficult to do in the context of an eip but we can uh address that when we get there i suppose we can just just call it e3 and uh um i i think what we want to

i think a good goal for when we're figuring this out though is um to make sure that eth two stuff feels comfortable rolling into eips trying to figure out the best way to say this like right we don't want this to be a hindrance i guess like let's say oh yes a little yeah as i said it the doing an eip kind of specifying qualitatively and quantitatively to a certain extent what a modification that would be done to the the e2 spectrum quote is reasonable but at the same time we're going to do an

accompanying pr in the e3 expect repo because there's executable specification that builds tests um and so there's even if we do move in to do iterative work in the eip stuff um it will always be accompanied at least for the foreseeable future with executable spec modifications which so then we're maintaining things in two places which isn't crazy i mean that's the the idea of the elevator is that you're maintaining things in two places mike i'm sorry i think you're like lagging but what'd you say oh sorry i was just saying i'm not a fan of maintaining information in two places yeah my understanding of the yellow paper is that it's a user-readable um version of what's in the

the eips combined with e2 spec the e2 spec or i mean the east one spec in the eips and then if you combine that together that's the canonical definition of ether and all the yellow paper is is a user-readable stuff and in my understanding it's a type of wiki system where people can contribute but it never is up to date and some of the new stuff right gets accepted in vips and so it should be recognized as not canonical but up to date as much as possible right so i mean in that sense it might go to to that end if we do want to maintain this thing the executable you spec in a different place

uh to be able to build tests then that would point to potentially not doing the iterative vip thing and having a different um change process more closely to those yeah then that would lead to that another thing i suggested where we have eips would be for changes to the east one clients even after the merge so like the application layer as you called it and then you guys would have a separate process likely a pull request process for um changes to the consensus of course then we there's still that interconnect and i think we just might have to live with crosslinks forever unless at some point in the future we can have

just an ethereum specs repo that has executable code for application and consensus layer um which would be awesome but i don't know how realistic that is and so we should probably have a plan for that doesn't happen this would also be a good opportunity for those who want to do this and i'm not in that camp but i know people have been yelling about this for a while to separate the eip's repo between ercs and eips so there would be a new repo i don't know were you a proponent of that micah i forgot i am i think i'm the only proponent i believe i'm just loud enough about it that it sounds like 10 people okay that might be it but uh but uh yeah

i uh uh think that this would be the opportunity the only opportunity if we were to do this after merge to separate the eips repo between ercs and eips and then that new fresh start would enable us to do all eth2 and one related core consensus application protocol work and one repo and then erc's in the other yeah i would love that very much because i could just quit reading ercs and they would stop hating my life you don't want to read the new upgradeable smart contract protocol oh my god i do not want to read the latest upgradeable smart contract

protocol or the 10th latest or whatever we're up to the one problem you might run into is that i suspect if we do this what will happen is no one will be an editor for the air sees repo like the only reason i'm an editor for it is because it's currently bundled in and i feel obliged to respond to them as soon as you split it off i i literally will just stop reviewing the rsds entirely because i hate them and i will only review core eips and then i suspect no one will take take up this dead i'm okay with this but just be aware of what will likely happen yeah yeah that makes sense okay so it sounds like where we're at is if

default happens and we don't have more of these meetings as things get closer it would be spec repo um or the specification repo for eth2 continues on and then they start doing eips after the merge um and then we figure out something for sharding later which michael was slightly against yeah yeah i would say the default should be that um application layer does eips and this layer does um whatever their process is probably pull requests and then if someone comes up with a reason not to do that then we have a backup plan

of at the merge have these two specs go to eyepiece i guess the secondary the release the in that in that world the release of a merge fork or merge release would be a 1 0 release tied to a 2o release and showing the connection between the two essentially like the modifications to the application layer and the modifications to the consensus layer yeah and you know looking at it like i'm thinking about what changes we have to the consensus layer currently in each one world and there's not many is there going to be that many in each too um yeah difficulty bombs

yeah i mean if somebody wants to propose a difficulty bomb then that would like validator rewards would like drop to zero or something like that um damn those validations the idea is to have very few right like i i think that there's a lot more moving pieces in the proof-of-stake mechanism than the work mechanism and so i would expect certainly over the next 12 months some refinement there's some refinement expected to go out this summer um so i i can't say for sure but that'd be great if it was largely stable and then we can get back to application layer modifications um yeah yeah i don't know okay um and i hope more people as things get

closer to the merge will get more involved in a meeting like this um yeah because i think we just need more think people thinking on this for different ideas um and yeah it's unfortunate there wasn't as many people on today but let's have a different let's definitely bring this up again at a future eipip meeting and hopefully by then we'll have a few other things solved like more editors onboarded and um things will be cleaned up a bit more so that i mean hope i'm hopeful but there's no indication that's happening but i'm still hopeful that we'll have more editors and things like that so we can um have things cleaned up a little more and like have a better clear distinction and what the

eath one point of spec repo becomes okay and we're moving forward on some 2o emerge specs that begin to kind of dictate some of the the changes in the eth1 layer and we'll kind of just have them written down and we'll figure out over the next handful of months where to formally write them down yeah another default is going to be the the linking between the eth1 eips like the difficulty uh opcode stuff and linking that to reasoning at an eth2 repo that's like i think that has what has to happen i can't think of an alternative unless we start including more documentation in the eip repo itself

yeah i'm not a fan of that either i would say um for for danny just the as much as possible uh limit the cross links like try to where where it's reasonable try to include the information necessary in the ip itself like don't just be like uh this hash code now knows like try as much as possible to actually specify as much as you can and then maybe have like one link for additional information to the reader that i i can provide the context verbally like the in the context of an uh merge a movement to prove mistake like this is a modification of the difficulty op code to be this instead of the previous proof-of-work context and i can say that all verbally i don't

have to even point to an external link but it's at least contextualized by something that is not in the eip repo yeah i'm willing to to let it slide in this case because this is special um the the reason i have i have this personal rule is because i get ercs that have just like links to people's personal github accounts and they're like go go here for all the details of this spec yeah okay yep that sounds good that all seems reasonable and i will attempt to be very reasonable as we move forward and i will keep the dialogue open um yeah mike i like how you say this is an exception like this isn't a huge deal like being two's like uh what's the

question i guess i'll let you because because i like you it's one time this is one time yeah i won't let anyone know that you you you uh compromised here i'm i'm sure it's gonna end up all over the internet i'm sure on twitter it'll be like oh mike is being unfair unfairly he's friends micah lets people do external links now and it's going to be a free-for-all oh my god i'm already in my life yeah get your hexagon upgrade contracts ready for your external links anyways yeah i just have a personal opinion on fear of external con

links and and 401 errors to me everything should be done in a weekly way leaderless way like for example right now we've got eip.ethereum.org and ethereum.org slash eips and we're proposing moving the ethereum.org eips over to eips.ethereum.org and that's going to break a few links and so i would like to take on the responsibility to track down those links and get them fixed ourselves because micah mentioned the bottleneck process he can't keep up with all the links and keep them all fixed but but if you put it on the leaderless bottom-up way so when someone moves a page they should be able to go out and find all the links and make the changes from the from that end when you so that

we're not bottlenecked by by anything and everything can be done by anyone but anyway just a thought yeah i mean i'm i i like it in theory impressions when i detail distribution on who fixes links yeah uh it gives me one idea though in theory uh eip specs repo uh yet e2 specs repo is currently a github repository right likes with markdown files in github hypothetically we could include it as a sub module and the eips repo and that way we can link internally right um and a an eip that modified the consensus layer could also modify

the uh would actually modify like actually do the code modification as well is implemented right yeah and that's that's like what part of why i'm a little meh on it i mean some modules in general are a bit hellish to maintain and deal with well and it's not impossible because they we have that for each 1.0 with the jello paper if or was it the beige know that the jello paper or the beige paper yeah the gel paper is like uh gel paper is a [Music] k specification of i think primarily the

evm it doesn't have all the cradle components like the stuff but and i don't know i don't know if that's actually very maintainable the gel paper uh owners uh claim that it's very maintainable but it's it's very dense to read in my opinion all of my code is very maintainable no one else is this yeah i would say i would also i would encourage one of you to hit up paul d to hear about what he's working on on like an executable um spec accompanying with some um yellow paper updates which if we had an executable that kind of both layers then we can start to do some pretty interesting

things maybe and putting that in like the 1 0 spectrum though um and there can be some interplay between the two there yeah we just throw money at someone to maintain the yellow paper i think um just get it up to speed before the merge yeah you gotta find the right someone okay um i think we're good with this topic unless anyone has any final stuff okay well thanks so much thanks for having me i appreciate it yeah i'll have another girl soon yeah we'll have another one of these eventually bye unless you want to stay whatever you want to do i'm out later all right see you um next up we have eip editors onboarding and request for funding um i don't have an update for that um so

we can go to the next thing um oh actually no we do have an update for that we have a blog don't we right uh so after the release of the block uh blog become an editor we have been approached by a few people from the community those are interested in being edited and they have questions on the process part and if this position is compensated etc i wanted to bring this to the meeting to get clarity on the onboarding process as how we can screen the application may be whom could we send candidates to or like how do we want to proceed with this particular onboarding process for eap editors i think me and micah and the light

client can just talk to them okay uh so uh like what would be the best place where we can send like any group or i don't know how does how many people are there that came to you at least three but those are like coming directly from community what we are doing at the first training part asking them to fill up their onboarding form for ethereum categories so that we can get to know about them a little bit more if they have any association with ethereum or not and some from references etc um micah where's your preferred place to be discussing with these people like either the eips

chad and eath r d discord the cat herders chat and discord or a telegram group what do you like uh anything in discord is good for me okay uh pooja do you have a place that you think would be best maybe the cat herders discord yeah mostly people are showing up in canada's discord because that is mentioned in the blog that uh uh reach out to cathardis so possibly i would create a separate channel providing access to my mica life client and you and we will send the candidates over budget and if you make that channel remind me to turn on notifications for it because i'm really bad at that so um in fact i'm going to change my notification settings for the cad headers channel after this call because i think they got muted

automatically when i joined and i don't want that to happen okay yeah i mean definitely so there is already a channel of eip uh where alita is throwing some you know stuff for the boss one but i'm gonna do we want to have a separate channel for the api data so we can continue the discussion over there because everything is going for the eip depot only there i'm okay with having the same channel okay then i'll reach out to lifeline and micah and get them added over here so uh one question one question i i have maybe someone else can ask of

all the applicants is why in the hell would you want to work for free on fbi fees uh anyone who wants that at eips i'm very suspicious of which i know i shouldn't be since i should that would make me suspicious of me but i am very suspicious of me too i don't know why you guys trust me uh they probably are asking about compensation which isn't happening yet but if they're still like i'm willing to wait for that um or like i'll come back when we have compensation that'd be fine too we can still vet them beforehand or get to know them that's not that's not a negative thing yeah sure start to that like if if that was if that was someone's answer like why do you want to do this and i said well i need a job i'd be totally fine with it

i just worry about anybody who's like oh yeah i'd love to do eip editing yeah no one says that yeah no no it's just yeah we received these queries like if this job is compensated i already have informed people that at the moment it is not but we are considering some options to get uh provide funding to uh this particular road and yeah obviously if they would want to consider it now or maybe come back later it's fine okay yeah i definitely trust someone who likes money more than i trust someone who doesn't nice okay um that's good for is that all you need for that item puja yeah um next up single source of truth for eip i forgot what this item was

for yeah i'm working on that oh that's the one you mentioned earlier okay yeah so now no real big updates there uh yeah i integrate uh last last meeting we talked micah had the idea of removing meta information in the eip repository like eip1 out of the repository and so i it included that idea in in in the proposal that i'm doing and the next step i think is to create a uh so what and we want to move that into eips.ethereum.org and so i think the next step is we need to set up some kind of staging area where we can build a new version of ethereum or eips.ethereum.org and i asked uh puja before the meeting who's responsible for that and sounds like axic

is and so i'm going to reach out to to find out if there already is a stationary grade if not i'll look towards seeing what is required to set one up like that and push in that direction but that's just just an update of where i'm going what i'm going to do next now when you say move out eip1 do you mean move it out of the repo into a website well right now we when we made the changes to the eipip process all of the new updates got made to eip1 and right now that's the canonical set of staging of um of where the canonical information is and last meeting micah proposed moving that out of there and moving that someplace on to eip.ethereum.org and so that that and so i added that

proposal and i think that's a great idea specifically since it it needs to take um some of the workload off of eip editors and and stuff like that and and so i've assumed that's okay it sounds like you might have a problem with that is is that the case uh i more just want to understand it before i have a problem with it or not um because like if it's so it wouldn't be a meta eip anymore it would just be a rule set then yeah and keep up with and we would define the canonical um med eip information somewhere on eip.ethereum.org and and that's why i want to set up a a staging area where we can move all that and get all that set up and get it because right now it is the ip1 that is the canonical stuff but we want to get a stationary set up

and get everyone on board and say yes that's sufficient we can switch over from eip1 being the canonical source to this new source when we make it live but but anyway micah do you have anything you want to tell him about why we would want to do that i'm just i'm trying to keep eip the efp's repo focused on eip standards and right now the eip1 talks about stuff that's not directly related to standardization like why yeah i pulled up real quick so i can remind myself like for example right at the top what is an eip eip rationale

um talks about the eip workflow um what belongs in successful eip like this all feels like the workflow probably is fine to stay but like the what belongs successfully i fee feels more like a tutorial or like a blog post or something that's kind of this isn't a spec this is just like some helpful information for newcomers and i um currently that type of information is spread out in multiple places and i feel like rather than putting everything more stuff into eip1 instead we can take some stuff out of the ip1 and have efp1 focus purely on this is the process like these are the requirements like it's basically a standard

for eips like eip1 becomes an eip in it like i guess what i'm trying to say is eip1 is a technical standard right now it is a technical standard with a whole lot of non-standard information like non-normative information in it and i would like to pull out some of that non-normative information and put it somewhere else as long as someone is putting something somewhere else i'm okay with that so like if we have through a blog or two prepared or an article or what brent's coming up oh yeah um as long as that's been prepared for when that happens then i think i'm okay with it yeah the idea is we would take the information that's currently there and then move it over to ethereum.org and then delete it from eip1 after it's moved

so not not that we delete it first and then maybe later we'll add it somewhere else it's definitely a migration so we're moving to a new location yeah i'm not i don't have a strong opinion on this like i'd probably if i had to choose i'd probably keep it the way it was for simplicity but like at the same time i see your points and that sounds good to me we can this could also start the thing where it's like less opinionated on how to do stuff and and more just like you said a technical specification on the process itself yeah that's that's what i would like um looking through it like uh as an example there's a history section in the ip1 that talks about bitcoin's bip process

and that really an ibm doesn't belong in it like a technical spec for how to build an eip it's like history and it's interesting and it's useful um just i i feel like the ethereum.org which already has a whole bunch more of that type of information is a better place for it like the why and the history and the you know stuff like that cool okay okay so so do you think like like the map of states that says what states eips go through does that go in there i think yeah i think that's technical like basically anything that i as an editor would refer to and say hey you're not following the

standard point back to eip1 so like if someone tries to go from draft to final i would point to eip1 and say that's not allowed see here okay so if it's whereas i'm never going to point someone and say hey look at the history and of the bitcoin process like as a reason to reject their eip so if if something is like a specification or a standard or like a requirement for the process then i would say ep1 and if it's more just metadata about the process or description of why we have this or um you know where this is the history of it stuff like that that would be moved over to ethereum.org i was a little bit unclear on that but i understand that makes a lot more sense

now okay i'll update the information keep on moving forward with that i mean there's the other option um and i'm not against this not for it um just to throw it out there which is to just get rid of vip one and just put everything somewhere else um yeah that's kind of the way i'm a huge fan of that initially starting but if we don't want to go that far yet then i would like to know i mean i i'm okay with that oh um just i mean it does mean there's just one less place that people have to know to look for things like it consolidates information um so i'm not against just one the whole thing out i don't know how other people feel right but but i think we should have a very clear location whether it's eip1 where these are the states eip go

through and this is the process you do to migrate from one step to the other and it doesn't need to be any ip1 but if that's where we want but but we should if and i was proposing moving that exactly thing so that every time you want so mike had to say you're not following this he would point to wherever that location is and i thought we were removing that the eip.etherium.org but but maybe it's entirely possible i proposed that last time and i have just forgotten and changed my mind that does sound like something i would say okay so uh which way so have you changed your mind and should i back off a little bit on that or uh no like the more you talk about it the more i think that would be nice yeah yeah i think i like that idea

because because because the eip repository is where we want to have the ether spec and we eventually want to have that the canonical ether spec stuff and have some kind of automated process where that's the canonical ether spec and all that meta information should be moved out of that so that's i like that idea but anyway so so so are we still going with completely moving but but again before we make that move we've got to have the staging area and we've got to have everything built and say this is where we want the new to be new stuff to be and it has to be sufficient for micah and hudson and everyone ether and and pooja and everyone make sure we have okay yeah everyone's happy with that now we can throw the switch so so so that's why my proposal is we need

to start building a staging area where we can start building that and moving everything out and moving in that direction yeah so you're going to make a proposal for that as next steps i think yeah that's that's yeah that's my proposal here is and i'm going to start on that next what are your feelings hudson do you think just pulling all of eip1 out into ethereum.org so we have just a single page that just has history and process and everything yeah i don't have a strong opinion because like i see the pros and and a little bit of the cons cause like the cons mainly the number one con in my head is like it's now in there is now information in two places or more that people have to go look

so like i might need to go read a blog read ethereum.org and read eip1 to get the technical non-technical and recommended right and that would be that that seems to me to argue that we should just pull all of the ib1 out and put it on ethereum.org along with so all the information is in one place both the process descriptions and the process history and the process uh metadata etc uh yeah if everybody else is finding that i'm totally fine with it yeah i like that okay we can pull it all out that sounds good to me okay i'm back in that direction i'll i'll push in that direction thanks so much for your help just just remind me i said this next week when i say it's a bad idea okay well i was wondering if i just didn't hear you

right so thanks hey you probably did i uh i i learned the other day my brain is full um i asked them a question and like five minutes later they gave me an answer and i was like oh that answered has pushed out the question and i no longer remember what i asked because the ants replaced it that's great um okay not for me so anyways if we're done with that the last item is reviewing previous meeting action items so the first one is complete transfer vip bot to github actions that's still ongoing 26.2 is brent to open a pr to the eips repo that's still ongoing we just talked about that

um editor blog to be reviewed and published that happened uh and then follow up with oasis for the json rpc what was the oasis i know i know about the oasis json rpc stuff but who was doing that was that james or james okay so we'll have to get in touch with him um about that uh otherwise i think that's all the meeting items is there anything else okay cool thanks everybody see you all in two weeks yep thank you thank you later bye