EIPIP Meeting 91

Transcript

welcome to eipip meeting 91 this is issue number 278 on eipip GitHub repository I have shared agenda Link in the chat so um for today's discussion we have open issues pull requests and some other topics will perhaps discuss things that we have discussed in the past meeting and we'll see where we are at that we'll share a eaps insight about editing office hour and we will follow some action items from the past meetings and I see one announcement added to the agenda here so starting with the first item

uh these are changes to final proposal we have a two PRS added here the first PR which is 7806 was a recommended by uh Panda to be discussed here this is about updating EAB 6059 the pull request number is 7806 Panda if you would like to maybe uh provide a brief background about this PR yeah uh yeah when I tried to meet myself I crashed um so that was unfortunate um I'm not sure whether now I think about it whether or not that was due to

me uh pressing commute button or switching to our Wi-Fi if it's the Wi-Fi I might actually crash again but um in the meantime one is because um we don't actually have a process for indicating stuff that's superseded and I just want to double check that we continue to not actually like no that no editor actually wants to pursue superseded as an actual thing that people can do yeah I think it was a bit complicated on how to actually deal with superseding

because we used to have it and the question arose like if an EIP by a different author comes in and says I'm superseding this EIP that kind of is conveying that from the point of standardization this is a this is the next thing when the other author may not agree so we just kind of removed that totally so we should then we should just probably close that Beyond okay yeah I think in the past there was also a discussion about the erc223 which was according to the order should be

superseding erc20 and uh this was the similar decision at the time as well well that's a bit different because the office yeah yeah that's right yeah but superseding in general I don't think it has been a precedent here I mean like definitely it was in the past but there is a president actually in the 19820 and 1 8 20. oh um I'm just thinking that the recent questions I'm wondering if we might want to allow Maybe adding a comment and perhaps a security

concerns if if for example a new I EIP allows for uh fixing of the security issue and it's otherwise pretty similar to in content to the old one I'm not sure if that's the case here but thoughts anyone I didn't catch the last thing you mentioned ah well I'm just wondering maybe maybe if it might make sense to allow for updating of this your security

consideration section if there is any IP that is otherwise pretty similar in content to the old one but also fixes the security issue are you saying if it's final yes but only the Securities consideration section no other section not the front matter yeah I think that would generally be reasonable I also wonder if it should be possible for an author to withdraw a final EIP or have a different status for something that was final but deprecated by the author

maybe final hyphen withdrawn could be a status your mic is really low Victor or me Victor's bike is very quiet and microphone is broken uh so um I think uh final Dash deprecated with final Dash um superseded by uh would be something good to consider at least in the context of erc's um we can borrow the the wisdom in ietf where they allow they specifically have a place where author can say hey this

one is superseded you should use the other one and we even use I think RFC 8190 that was superseded by that that is superseding uh the 2197 uh the like must ensured it was updated before so at least in the ERC context this makes sense the problem the difficulty is it governance so who get to decide which one is superseding which one and does the author get credit in the next one as well foreign I think no the author does not get credit because of the way cc0 should work in terms of actually superseding I think again the final hyphen with Ron thing

would be better but also allowing for a superseded front uh entry which indicates a list of erps that the author considers to supersede the current one yeah none of these sound perfect we might have to spend some time and think a bit more about it I mean we don't want the situation where something is final and widely used then the author decides they want to go Rogue and quote unquote withdraw it yeah I think probably the best thing would be some phrasing along the lines of the author considers a EIP at eipy and eipz

you have superseded this EIP or something like that yeah in context with what Matt says one I uh one uh example is the rc20 uh has widely been used uh and uh the lack of ability to check uh who they sent to uh is being attempt is being addressed to uh in 223 erc223 and one three six three um and also the the author himself has in different con occasions says

um that needs to be superseded or it needs to be deprecated um things like that is an example for motivation like this so yeah in that situation I think that we should again I think the correct thing to do is defer to the authors and again use the phrasing the authors consider these aibs to have superseded uh this current EIP and maybe we could also add lines along some lines along this may or may not reflect Community opinion in my mind like having a superseded

thing over there is kind of deciding a winner or suggesting Community what is the best thing best proposal or best standard available here to be adopted but if we go by the handbook that is recently updated uh 5069 I'm talking about um I think the recommendation here are for editors like we do not decide winners we are just like editors are just making Corrections on the proposal they are just making sure that proposal is right and it is up to an individual and implementer or adapt developer to pick what is the best suited for them we wouldn't be deciding winners the author of the authors of the previous

cips could decide that they would like they would prefer if a different EIP was used instead and it that would be literally kind of what it would indicate not that some eips are better than in others but it in the subjective view of the original happiest authors certainly IPS should be used instead I'm imagining this may lead to add an additional field to Preamble and if that is an additional perhaps optional um may lead to some of the confusion but yeah I'm totally open to the idea whatever group designs is there anyone particularly opposed to that idea I'm gonna go as with that as being no

right um so uh just to understand it correctly are we hoping to have a preamble field added as superseded by and we would enter EIP number over there if that is a proposal we can perhaps add it uh to the next meeting as well just for other ideas to join though I know Sam is not here so we could collect some feedback from there as well and have a decision in the next or following yes I can I can wrap that PR and it and it would and it would probably be a field that says superseded by but also the way it would actually be displayed is not as superseded heightened by Erp numbers it

would be a very clear indication that this is not the editor it's deciding this is of an opinion of the original eip's authors that certain one should be instead sounds good so yeah real quick so if you treat it as a deprecation problem you can leave the endorsement of what it should be replaced by as an optional so if your concern is you want to make sure that people can you know disavow old things but you're worried that they might have to implicitly endorse the new thing you can make that optional

that seems like something that definitely should be possible yes there's you know right it's also kind of a jerk move to deprecate something and not give somebody a good way to uh replace it but you know there can be valid reasons for doing that sometimes yeah maybe a superseded by hyphen pulse I mean I would just set the status from final to deprecated and in the Preamble put if you have if if the deprecations have an opinion that it should be dedicated by something else updated there it would still remain a final status again nothing about the EIP would change from basically

should nothing about VIP should change except for that opinion being displayed okay then it's just a there's just a matter of phrasing them correct I think we can move on to the next agenda item that is correct so just to get the summary here about this particular pr7806 are we going to keep it or we are just closing it let's keep it for the time being we are kicking that can down the road all right

right all right uh moving on to the next one we have another proposal a PR for a final EIP EIP number is 1559 and the pull request number is seven four two three I think this has been sitting for quite some time I wonder if any editor has any thought on this pull request page from the link in the chat yeah I just shared so this proposal is I mean this request is to clarify who pays the gas fees here

yeah I mean it seems fine and I see it has already been approved by panda in the month of July as well so uh perhaps it can be merged that what it requires it looks like it's been approved by Panda well me why did I refer to myself in the third person that was weird and like mine so I think we only need one more reviewer anyway doofy pending reviewer just suggest eat bot I mean is it going to merge with all the

linting errors uh no it won't need to be manually merger right okay yeah you can't can anyone maybe leave some some comment for the Victor uh do you approve I think gajendra Singh just uproot okay I'll add it to the merge View perfect moving on uh to the next section that is a list of some manual merch I believe it was discussed in earlier meeting and uh perhaps uh none of the edited objected

for it and it is queued for manual merge the pull request number is 7505 and 7506. um if someone here may be able to merge it I believe like client has manual merge permissions or is that uh access huh I'm hoping it must be salmon Lifeline but Sam is the author here when it matters you can maybe take a look and be able to merge it if like like doesn't uh if it is Arctic that has um uh override permissions can

we actually remove actic for the override permissions and transfer those to like plan because Litecoin is a lot more active I can manually merge okay feel free to do that for those two PRS and also for the pra we were just talking about yeah I think that is more 7423 is now merged and yeah whenever you get a chance please merge for 7505 and 7506.

moving on to discussions continued from the past meeting um we have another pull request to update eip721 which is a funnel EIP but the pull request is also coming up from the original author and we discussed in the last meeting no one objected I wondered if this can be manually merged as well the pull request number is 7550 so I am I I do approve of this one um it maybe changes a tiny bit too much

but I also don't but I also don't mind that because in general this is more compliant than it used to be sounds good specifically it changes all almost all instances of references to other VIPs and things and it doesn't need to do that but honestly that just by chilling yeah I want to look at this a bit this description is pretty it's requested copied directly from the simple summary it used to be oh is it okay okay I've never heard someone call it a deed

that it is not for the sense wording yeah in that case I'll take a look at it and we'll see if we can merge it awesome all right let's move on to the next um item listed here uh that is call for input as we know with the new process um we are trying to have decision collected uh over issues created and uh it is for eib editors to respond within one month's period issue 263-2270 um seven issues here plus 272 and 273

all of them are due on October 5th which is a day after today so I have not included the decision hoping that we should give another 24 hours for those editors who may not have gotten the opportunity to respond to it or may have missed it want to add it in the last minute that includes a bunch of proposals including um editors active status like uh which editor could be removed like they have listed all the editors if this is a good to be removed or not and then there is one another very important input needed for keeper of consensus election so I would recommend all EIP editors here or maybe

listening the call after this please take a look at all the open issues and respond to the issues like the add your input and perhaps we can discuss uh the result in the next meeting but in the meantime if people would like to discuss any particular issues we can do that happy to wait as well but yeah please go ahead and let us know if anyone has any particular thing that they would like to discuss I see like client just commented on the backseat editor removal would we be willing to kind of is there a system in place for a light

temporarily removing an editor like for like a short like one month period of time and then they got get automatically re-added because I think that because I think none of us here actually one and gone because we think that distributions wouldn't be useful I think we want him basically not to block any of this stuff not sure if blocking is a concern because um because of the way that the current

Charter is set up basically every editor needs to have voted in order to for it to pass before 30 days and currently we're trying to get stuff passed uh before the 30-day Mark which is currently not happening because axic has not been reviewing the call for inputs I agree all basically all the feedback from the editors at least the first feedback from editors should at least happen in the first week of the issue itself I mean usually but if it doesn't happen for like a month long time it's not really you know uh good thing it's a

waste of time to wait and just than to see that okay uh that response is never going to come and we'll anyway uh go with the decision without that particular editor's feedback so the way the cut Charter currently works is that basically uh basically there is um well first of all I'm not sure we can actually get I'm not sure we actually have enough boats to elect uh uh anyone as kind of the first keeper of consensus without that sick voting um um additionally I think after the 30

days we looked to see how many people voted that for you has it actually been 30 days until 30 days shall we to the time being consider Samos and like as like a very temporary keeper of consensus is there any uh specific decision item that we are waiting I mean like I know Sam is on vacation uh till 17th of this month and uh the specific item is kind of call for

input editor removal exit uh on the eipip uh GitHub issue number 266. and by the way I do approve like again I have been advocating for this kind of a Like A reduced like reduced requirement editor thing where by default kind of you are considered to have abstained in your vote until you actually vote so basically

basically for the purposes of Quorum you don't need to vote but your vote still counts if you didn't vote I actually like the current way the charter is set up so that you know everyone has to give some sort of a review even if it's too abstain uh basically I think the point what we want to make over the hair is that there needs to be a responsiveness to the issues that are being raised and that's why this particular issue exists that there is no response from executive

and uh if he he can participate actively then definitely we all also have expressed that we can sort of reinstate the editorship the problem is that I think we all kind of want access to be able to participate wherever we can but we also recognize that right at the moment he's not able to participate on everything his input would be valuable for a lot of these things but we also should be able to passing things without his input for the time being yes uh how do you connect correctly pronounce that

I I guess I haven't figured that out yet exit can anyone help me with this yeah that that's how we refer to him as his full name is Alex barig zazi I'll just say Alex and yeah I think we all want Alex to be able to participate like uninterrupted but I think we also don't want him to interrupt us and maybe we have negative status where basically we say that these ideas but what I was proposing having an intermediate status where for example if say you're on vacation like that would

be something that would be useful like hey I'm gonna be on vacation I might not being able to keep on top of everything but if there's something that catches my attention I would still like to review it or something like that like that that is something I would like or even more more permanently as like a like currently like you haven't been kind of on top of everything but also we still think that your contributions when you've contributed have been valuable kind of something like that like client you're the other kind of governing editor on this what do you think I'm not sure if I have a good side of

how to deal with this Alex has put a lot of time into the aps setting it up to be where they are today and I know that he hasn't been as active for the past year or so but I want to find a way for him to continue contributing as long as he's going to as long as he's Desiring to yes and it's pretty clear that he does desire to continue to contribute so do you think of that kind of almost like vacation mode thing as a good compromise for the meantime I also don't really want to make these

processes more complicated and add like different types of statuses for people so I kind of feel like we should see to that end I would agree however something I will note is actually I think we can do this without actually requiring a consensus vote because of kind of the ability for us to kind of delegate stuff so I think that all access should need to do is just say hey I delegate uh my votes too to um like whenever a new call for input is is given is receiving is like received I automatically vote I'm saying until my

vote has changed no consensus required yeah I think it should be easy enough in the sense that I can just say that I don't want a sabbatical and that's basically that's it I mentioned from this time period to this time period light client do you agree that that is should be possible within the current framework yeah I think either saying I am going to be away for this period of time or I delegate my votes to the specific person either of those would be acceptable I'd

rather not change the actual Charter description to support it explicitly but I think implicitly this is something that we can accept okay that's good um I will therefore change my vote on the call for embed foreign like I'm trying to find out I don't think I see Vector spot here for exec because the process suggests that it has to be unanimous minus the editor being

removed yeah yeah I have seen uh yeah as a very valuable Community member and editor and he was very good at authoring and uh and and reviewing so skill wise experience wise I look up to him and he like him to stay um but the current status is that he was not being active enough um so I think it's more about the intention I think my view is similar to what Matt says as long as he wanted to continue contributing I'll be voting to keep him uh if he doesn't have enough intention to stay or if we cannot

continue to provide a good environment for to motivate him to stay I think we need to think about what we can change or if he wanna um leave this Duty um yeah but um I think it's it's really up to his own intention and I just want to make sure that we have a good communication with him um and understand what his intention is and also he voice out his commitment sounds good maybe um Panda if you can update your profession on this oh you did good and a

Victor if you can also add I see your comment now yes uh Victor you can also maybe add your thoughts over here and um the last date on this is October 6th so and I know by that time Sam will not be back but if we have unanimous decision we can perhaps mark this as oh you know so the way the unanimous really works here is if everyone unanimously votes yes it doesn't require unanimous no vote as long as a single person votes no that would be like and also me now uh then it

is basically automatically closed foreign probably this one's not going to pass as for all the other call for inputs I'm pretty sure my client you've reviewed all of them but can you just double check you have um I'm also checking myself oh like client you haven't actually voted for the first keeper of consensus that action you should do that all right

maybe we can revisit this in the next meeting to see where we are at conditions actually there's a few of these copper inputs that like client we haven't reviewed yet would you mind doing those kind of now-ish perhaps during the call like the majority of them are just editor removals that I think most of us would agree are obviously no but had to be open to just like as a formality and there's also the election which is important enough that I think we do

actually like well I mean without you or someone else we don't actually have enough votes to finalize it so please do that I'm like yeah I see you response here in the chat says yes so I am hoping that he would take our time to respond to all the issues here amen respond to call for input added here in the issues in the essence of time let's move on to the next item which is about a repo split EIP number here is 7329 I suppose in the last meeting the eipip meeting

editors decided that there would be a meeting to discuss Matt's earlier pull request and if there are any changes to that I wonder if there is anything that the group would like to share and I propose at the time for the meet uh one week from today normal eipip time I guess not everyone's here but there's well light client and uh Victor are you available at that time what time sorry I I don't I didn't scratch that one week from today same time as you know as a normal eipi being meeting

one week from today so next week right next week I think uh I should be able to make it it works for me but I think we should probably have Sam there also yeah I yeah with everyone yeah well I just don't think we can like pull him from vacation to split the repos laughs also speaking of the also this is a pretty last minute change as to splitting the repos I have come around to actually I agree with that spilling groupers is a pretty good idea I still think that it's

core that differs from most of the other EIP types not ERC um and I again still would kind of prefer if it were the Corey IPS that were split I this is a last minute change and I don't imagine that a lot that anyone's gonna like approve of it but like just throwing it out there like client and Victor what do you think I felt that interface seems to be go between to go closer to uh erc's I know that Matt has a preference for interface and network to be deprecated

um so far ercs are all about smart contracts if um Network and interface are deprecated uh some of them can go into executions back and consensus back some of them seems to be relevant to um other things such as the recently uh finalized six nine one three uh the one that allows multiple wallets provider to be injected into chroming into browser environment um those things needs to have a home and I like to know uh what people think on this meeting about those kind of EIP or

ERC should go into so so I think the way it was supposed to be with the interface was kind of everything that was in between smart contracts and applications wanting the Inner Space with smart contracts well well yeah or go interface uh unfortunately what I think it's become I I then ERC would be every kind of everything that doesn't fit into any other category or go ethereum request for comments the problem is that instead it's been the other way around ERC has become only smart uh only kind of smart contract related stuff and then

everything else has now gotten into interface I think there is not too much distinction between interface and ERC um Ergo that was my that was why I tried to like I did add that thing that like moved well inner interface into ERC and some of them into core I'm still not sure like I think like client did not like any of them going into into core um if so that's fine but like at the very we've gotten really

off topic here we're talking about this repo split what I'm suggesting is for now does it make more sense to split erc's and everything that's not pour out into a separate repo or does it make sense to split only arcs and leave core and everything that's not ERC in the repo I think what we decided was that anything that requires hot program needs to be implemented on protocol level

would go into eips and everything else into erc's okay and this is the repositories or the kind of categories we also decided not to have any categories and deprecate the categories and so yeah okay so that's an idea and also many yeah with that in mind I'm actually going to be closing my um call for input for removing the networking and interface categories because that seems to be kind of uh since that kind of well actually I

won't close the call for input um I'm just gonna change the decision to get rid of the networking and interface and then close the original PR because that seems to be effectively what we've decided on already have something to say oh I I think I agree with uh What uh Gad gender um does

um I think we simply think alike uh anything that the half Forks require a much more senses and anything that doesn't require hard folk is like you do it if you like and we'll see how many people yeah so I agree with that definition that seems like a pretty well defined one minus again it leaves networking up in this nebulous state where it actually does have if they're networking despite despite not kind of directly being able to cause hard Forks because again it's not part of the chain it's just how the nodes talk to one another

nonetheless if you again it does have the power to cause chain splits if I understand correctly if it's kind of like like basically like think think of if an uh if uh networking Erp was made that kind of had a like basically made some backwards and compatible change which shouldn't happen because of the way networking governance yeah okay yeah I see but like it is to some degree consensus critical does anyone disagree with it being

consensus critical so I think we need to look at the model I mean it whether it's consensus critical or not um because I mean there's absolutely networking changes that can be ignored and still reach consensus and you can get everything wrong and still reach consensus but it's the developer audience that's looking at those is where things differ um so core would be like the core developers working on the the court consensus and execution layer clients and ercs would be like dap developers there's also um looking at the comment thread and I think based on some of the other things I've been reading in the community um a separate wallets group that would deal with issues like the uh um 6968 or whatever EIP that one about the injection of how you Marshal a wallet

from adapt page um I think the developer audiences as more important than what other lines we draw around it it's it's who's going to look at these and decide they need to be implemented whether or not it requires a hard Fork whether or not it causes consensus failures it's which particular layer in the stack are these changes going into I think is the more important Network the problem is that networking is its own layer here and doesn't therefore fall into either of the other two I would like what's the example of the networking layer that does not address uh consensus or execution client well I mean I'm pretty sure that for example

one of them was just a way to kind of export the validation keys which to be fair that one doesn't actually need to be networking and would be perfectly fine there's an ERC as I think like client pointed out but at the same time um I to me it definitely looks like networking the ipus to share more in common with quora eip's process wise than they do with well except maybe they don't kind of what I'm thinking of is that like core devs already encompassed to very distinct groups I see the kind of execution layer groups and the consensus

layer groups and I think that probably the networking group would be pretty easily integrated into this system yeah I think it works well because when I hear networking Dev P2P or P2P lib I don't think of like Json RPC so I think about lower level networking that's below everything on the stack so putting again in ERC none of the RC people care about um you know the particular packet structure of the dev P2P packet or whether it should be deprecated and going to live P2P So based on that we can probably exclude it from ERC anyway but we also can't speak on behalf of the core devs here and whether or not I'm

speaking on behalf of the courthouse oh great perfect so you would be okay with kind of integrating networking people into the core Dev kind of yes okay and in that case we will currently transfer the networking eips into the EOC repository but if you ever want them feel free to take them for now um can I one use one example to help being maybe Evil's um Advocate Devil's Advocate uh with with you um so uh one example is that whisper has

been used for our sharing uh main pool uh with each other and actually if people want to propose something different uh they could and uh they should be able to and in fact I think it would be good for people to have this ability to have competing proposal and some proposal can explore um censorship resistance uh approach maybe even add their own um incentives approach um so that is something that could be addressed that maybe or they have need to look into it but also aboard your audience the less control needs to be in uh would be would benefit this kind of

thought exercise um so far if you want to run your own minor if you want to run your own mind cluster you can actually just share them in in a database if you want to so um this is significantly different from what needs to be in consensus layer or in execution layer um if we use that as a as a um as a start exercise what what would be your thoughts you might thought would be to put it into core because it's mostly the kind of work the core devs do um I think one measure we could use is if it shows up on one of italics road maps it's probably going to be in core and so that would be whisper

I I'm not sure if I hear that stake I I mean not like competing to which one win I mean competing to cope with exist even longer sorry repeat that I missed it so basically allowing different um different uh sharing approach to coexist for that for a much longer time like the long term you can have multiple approach to share your transactions uh can to to share your uh man pool so mempool is absolutely a core Dev consideration it doesn't have to be involved in a hard Fork I think for it to be in the core devs

um it's it's not the layer above that the core is is I mean we're talking about sharing transactions that you know immediately sounds right at the core layer um of producing the networking consensus so that's why I don't think that the requires hard Fork is necessarily the right um standard with it it's more the core Dev audience that's going to be addressing it um because stuff like PDF and epbs has also shown up on the Telex roadmap and that is stuff you know when you're interacting with with the transaction pool um that the core devs typically concern themselves with and um you know are concerned about when they see or not concerned about when they see other developments they think you know when I say concern I say take interest in it's probably a better phrase than concerned

about but they would take interest in in developments like this and you know possibly one way to look at it is things that might end up uh becoming merged into the core protocol even though they're not merged right now is the other sort of thing um I don't think like erc20 is going to be emerged in the core protocol um but again the stuff that you mentioned like um you know standardizing the way transaction gossip happens long term for storing for um stuff like uh proposer Builder separation I think those are right up the lane of the sort of discussions that the core devs as an audience discuss so that's why I feel the separation based on audience is what is most relevant and I see right now probably three audiences um there would be like a wallet audience

adapt audience and a core Dev audience foreign faces would move to ERC yes I would probably agree with that so can I kind of say for now we are basically when the split happens we are sending networking and core to one Repository and every and ERC and interface to another and also probably allowing transfer because there's going to be some things that eventually we feel that we probably feel should not be in that Repository I think transfers are fine I think when we get a full topic group we're working

with group model up as well we'll need to consider that to and possibly consider multiple ownership of like a of a spec where there's like a primary owner and like you know other interested groups that want to track it as well I think that's a topic worth discussing too but I think this is an interim step until we get the functional topic group model up okay so for the time being do we think that it that it should just be do we think that we need both sides to agree the transfer any IP or just decide that once the EIP or Justice or just decide that doesn't want the EIP I mean what does it mean to transfer an EIP so obviously we're going to have two repos and it's literally deleting the following one repo and adding it to

another I mean yeah but it's not so simple like we have links that go to that repo we have links that go to eops.etherium.org and so what like every time we want to transfer these we have to set up this redirection and things so I think that we're probably gonna have to reject the website so right now we don't actually have a way to do that redirect so we're actually going to have to create a new repo that basically because I in the you know in the repo split EIP it does say that there should be a new website however there's a few things that again would need changing before that can become a reality the first thing is that we need kind of a way for that to be able to happen like

we might have a sub domain setup but like none of us actually have the power to set that subdomain Additionally the sub domain is already set yeah but well the the subdomain is set up to be able to like have a Pages site there but also that there needs to be a GitHub Pages site to put there and right now like right now that's there is actually a GitHub Pages site at ercs.thereum.org yeah it's I think a private repo right now ER ethereum slash erc's we have control over it it's really just a matter of putting the

correct files in the repo and making sure that the configuration of the website is set for erc's versus Zips okay I see so what I think they've currently done is actually just team named it to EIP it's not ethereum.orgon that basically means that the the two sites are currently mirrors of one another so they have it set up kind of in a temporary way um for the time being can I propose that I basically take out the website code from the eip's repo and stick it in a new one I mean why not just keep it where it is

and have this I mean the C name is set to erc's right so it's like a different website because when the repo split happens again we have to set up all the links to the new site so that things don't like eips.etherium.org EIP slash eip20 don't give a 404 page um so all those redirects will have to be set up and well for one thing if I'm being honest I don't think anyone in the core Dev team actually knows an FJ call to be able to make those happen I believe I am currently the resident website expert for this and even then it's going to be a lot of

Hassle and is going to require a bunch of configuration files and I'm not actually sure even how I would go about doing that I mean one thing I would do like that would be extraordinarily temporarians instead of deleting all the EIP files I would have to like go through each of them and stick like yeah I know that I think about it I don't even know how I would do that I mean that's kind of what the script does on the original PR it goes through all the erc's updates them with text that says this has been moved to this repository oh but it does not automatically redirect and it does not change the canonical URL it does not automatically redirect yet

okay so then the website change itself has to be blocked until that is fixed because the canonical URL must be changed at the very least thanks and again so this is again what I think it might be worth separating out the website from the rest of the kind of the erp's repository because honestly every single other bit of cooling like linting like uh the review bot like all of these are outside of the eip's repo because they don't need to be inside the erp's repo things don't update to

the EIP review bot happen after changes to eip1 they like they follow each other but like yeah so ethereum the ethereum.org so the reason why this is all trickier than it would actually usually be is because um of the fact that we're using GitHub Pages GitHub pages does not support 302 permanent redirects so you would have to so it I think the way that you would tell search engines hey this page is moved is by obtaining the canonical URL and having another meta tag that has an auto refresh of one

second to the new URL but yeah I think we're nearing the end basically a right client can I just confirm that it would be okay for me to try to at least separate out the website I and yeah I'm pretty against it I'm happy to like review a proposal for doing so but generally it feels like something that I don't think we should do okay uh let let's discuss this further on Discord then because we are at 1001 yeah I have to hop off um cheers

everybody thanks for the call Pooja thank you thank you thank you everyone hope to see you in two weeks from now have a great day