EIPIP Meeting #126

Transcript

Heat. Heat. [music] >> [music] >> What's up?

>> Thank you. >> Thank you. Welcome to EIP IP meeting number 126. This is added [music] on Ethereum/PM repository as issue number

2062. On agenda, we have a bunch of caller input uh which are open for quite some time. We hopefully get some resolution and close all of them. We have a few items [music] that are pulled from prior office hours and uh something that we have collected from the community and those are added as policy discussion editor discussion for today. some updates and we are also joined by a contributor who is here to share a demo of u new EIP working group. So uh let's get started [music] with the very first item. Uh those are all call for input.

Sam if you would want to maybe take it >> can do. Um yes so we have the allow links unic code technical standards. Um, that one's in favor like just needs to be implemented. Um, we have the associate EIP editors, which I honestly think we need Matt to kind of take the charge on this one. Um, I I'm fine closing. Yeah, it's closing in favor. We just need to do something about it. Um, oh, there is a PR for this. Okay. So, I'll take a look at that. Um, we also

have the status tag and citations. Um, yeah, I think that one looks like we can probably close it. Um >> so just to get some clarification right over there would we be going ahead with the PR which is already created or do we want any final changes in that PR >> like this is for the associate editor one or the >> uh the status and citation See?

Yeah. Okay. So, it [music] seems that uh so we want to add like a citation or like a status tag in the citation of every EIP. Um I think Oh, wait. Sorry. It's it's already in there. I think I'm just thinking that like all the EIPs um if they reference another EIP I think it would make more sense if that EIP we are referencing to is not in a final or in living state uh that people should actually link to that EIP as a perma link um because especially with draft EIPs some of the the concept so there's like a general idea But this general

idea tends to change. Like to give an example, uh we have EIP 2780 which says something like reduce uh uh something but in the end it will actually most likely increase um uh uh u specific costs. So in that sense if then an EIP citates or refers to this EIP uh which [music] is in draft state then in that case it would make more sense to actually reference the actual perma link or the actual status of that EIP because if that EIP then updates then if you would link to it and then read it then you would get confused because the context uh what it's exactly linked to

is not uh there. That makes a lot of sense. Um, I don't know how technically possible that is. Um, because we don't render every commit as a rendered EIP. You'd have to link to the GitHub page for it. Um, but that's a really good point. Um, do you think we can solve that separately from this issue? Yeah, I I was about to bring it up because this looks like a related but [music] a different u proposal. Um so right um yeah I I I'm not really sure

about this because if we link to Yeah. Okay. what we should maybe indeed do we should uh uh especially link to it when an EIP [music] is in draft status but then the question is okay but what if an EIP changes from draft to final um yeah I I I I'm I'm [music] not not really sure here what what this should do um because it makes sense to link like the status [music] of the EIP uh which it is when you update an EIP uh but yeah as you mentioned like this would would also need support on the site uh on the EIP's uh site itself because indeed we currently only

render the current version of the EIP and not the um the whatever version you request. So yeah, >> I think the problem statement that this PR is trying to solve here is to display the correct status. display the status which is the status of the EIP because um as of now uh the EIP.ethereum.org shows a draft for all statuses. So that is the problem statement this PR is particularly trying to address. And the question that we are trying to solve with the help of call for input is like whether we should go it for all EIPs or should we keep it only for uh EIP which

are neither living nor um final. So I believe whatever Yam suggested is something different than this problem statement and uh yeah that can be handled separately. >> Agreed. Yeah, I do think it's a good point though like we should definitely do that. >> So coming back to this uh problem statement, is it okay for now to just fix whatever is like uh uh clearly visible that the status is not m citation status is not matching with the proposal status and uh merge this PR and then we'll work on a separate PR to yeah pick up that issue.

>> Yeah. Okay. So, so just to check because okay, let me actually link that comment from Sam because then it is clear what Oh, wait. I can I should just share my screen because then people can see. >> Okay, you should see my screen. >> Yep. >> Okay. Uh so this is Sam's comment. So what what we will do here we have like this uh uh citation uh which has this this draft and now we would uh link to this. Now my only question is is this dynamic or is this then static? So would this link to the current status of the of the EIP or would it link to the status which it is when we change or update an EIP?

>> It will link like the text that would be rendered here is the status of the EIP when it was rendered. >> Okay. Yeah, that makes sense. Yeah, that's that that makes a lot of sense. Yeah, let's uh let's do that. Yeah, sounds sounds good. Yeah. >> All right. Uh, so are we fine merging this PR as is? >> Uh, yes, I think so. So, this is slightly different. Um, instead of it being like a a status colon like living or whatever, this just takes the page status and puts it in square brackets.

But I'm fine with that. Like it's not a big deal. >> All right. Um, so yeah. um we can keep that as a decision and merge the PR and close this call for input. Moving ahead, we have uh issue number 406. Sorry, I'm just closing this here. Um, okay.

So, 406 is Oh, whether things should go to living or final, right? So yeah, I mean here also we were discussing about uh their status. I'm sure um we we need a decision here. This is my proposal. So I cannot argue much. I will depend upon editor's decision. But my only point here was like any living EIP can be edited by editor at any point of time. It does not require that editor

should be as part of author. But I'm always open to add editors as authors. >> Yes. Um I I I think because so so your latest comment on on this call for input puja is I think uh well it it it states [music] the exact problem with uh with living proposals. So I think that uh indeed it's also what uh what uh um Andrew [music] suggests that the most sustainable model is actually to not create any new living

EIPs and I think that's correct like uh but what you would also want even withformational EIPs um that at some point and people [music] like at the process itself will likely disagree with you because they say okay yeah but it's like very bureaucratic And now I have to create a new EIP for for each time that we [music] upgrade this. Yes, exactly. Um because for instance if you have like an information EP like uh notes requirements then what you would want to see in the future is in the future you would want to look into the past like to to get the context of uh of of for inance that fork. So the node requirements that's also something what

we would want to move to a final state and then when the fork is then uh done when we move this fork to final then we also want to have like the note requirements of that fork also to be finalized because then we can see okay this was then the context or the state of of uh whatever the fork was based on. [music] So I would say uh the information on EIP's end status it will be final uh there's not living uh because like for now you could update it for like the next year for the next five years for the next 10 years but at some point uh then the office have to take it over or maybe like the the original ideas that not be the same. So I would say everything should move to final and not to living except um I would say

anything that has to do with like EIPformational data. So uh like the the the EP handbook and EP1 >> yeah I'm I'm perfectly all right with the making moving this proposal to final status. Uh but honestly speaking I'm not very much convinced with the idea of putting unnecessary load on EAP editors because um there are certain proposal that does not require end to [music] end change that just require one particular section and talking about the specific EIP it talks about upgrade [music] nomclature. So we will have only two upgrades. If we can have [music] in a year then the this EIP

might require two updates a year [music] and as I mentioned it is not a dependent on author anybody can do it when it moves to living but uh >> so it's not it's not necessarily a load thing right it's also a um authority thing like I don't want like let's say two people make differently named forks I don't want EIP editors to have to choose which one is the authentic name for the fork. [music] Um, and we would have to do that if it's a living EIP.

>> Uh, I think this decision will be taken by ACD call because they would definitely add it in all clients. But >> Oh, for sure. But there's like that would mean somebody from the ACD call, we would have to pick the person to trust to represent the ACD call. >> So it's just easier if we just accept all of them and then uh ACD can pick which EIP number is the correct one. >> All right. Yeah. Uh we can perhaps add the decision uh to move it towards final and close this proposal. Anyway, this EIP is in draft status. It has to further go on different stages uh statuses. So yeah, we will keep it moving towards final status.

The last one we have is issue number 408. >> Okay, there we go. 408. So, oh, these are new external resources. So this is the um OASP uh CTPA and CAI. So these are um standards and documents [music] published about web security generally speaking. Um yeah, let's see. We don't have any comments on these. So um I don't think we can I can close this. So, if

everybody could just take take a look at 408, weigh the pros and cons of allowing these external resources, um, and leave a comment, I would very much appreciate it. >> Yes. Uh, I will I will do that. Yeah, definitely. Yeah. Sorry about not commenting on this. >> All right, with that we can move forward and we have a bunch of policy discussion items here. The first I think 1 2 3 four are suggested by Yuham. So Yokam if you would like to maybe talk about each one of them.

>> Uh yes let's first check what this was again. Um >> so it's inclusion of pre-final CAPs in the EIP. Uh this item was picked up from office hour. >> Yes. [music] Yes. Oh yeah. Right. I I I remember this. Um so this is CAP9. Uh and this is uh ah right okay so we have our [music] policy that within EIPs we you can only move an EIP to final if all the dependencies are also part uh are also final. Um and [music] the question here is that um C AIP19 uh this is as far as I understand

especially for ERC's like a uh a specification which is [music] uh very much used it's created in 2020 uh but it is still a review um so the question is that uh the point is that ESC's cannot move to final while it also depends on this C Aiv um yeah and I I'm not not really sure what what what we will do here because what we would basically assume is that this uh sorry this CAP which is in review state we would assume that it is final but I guess that that that's not the way how we should do these things but yeah so not not not sure how how we would move this to to file

>> I'd prefer to um wait for it to go to final for the CAP. Um as long as we link with a get commit hash, I don't think it's a strict requirement, but waiting for final I think makes the most sense. >> Yeah. Okay. I I agree. Uh do we have like a a rule that um like how does the the uh what's the rule if we depend on uh like like if you have an EIP which will depend on an ERC? I [music] would not know why that will be but let let's let's assume that um can we move an EIP to final if it depends on an ERC which is not final.

>> I believe that rule has been disabled since we split the repositories in two. >> Okay. Okay. So this uh the dependency of the CA IP would not block an ERC or EIP. Okay, that's great. Okay. Yeah, that's fine. Um I have u a small confusion here. Uh Sam, as per my understanding, uh the bot still will stop uh if the status [music] of EIP or E. >> Yeah, I thought I thought that rule was turned off. Um if it's not [music] then awesome.

>> Yeah, I think it is still there. But the only concern with the CAP is that there is no set rule for CAPIP added there. So the recommendation that was provided to the author was like use the commit history as you suggested as described in EIP1 [music] but we don't have any way to check it if CIP is in the final status because we are not checking that with bot. >> Yep. Exactly. I mean we could add a check for that. But uh >> I think that would be a big blocker here because the the problem statement that was defined to us in that meeting was like [music] uh CIP is not uh something that can be uh you know persuaded because they do not have any particular

body that they can reach out to and move it to the final status in case the person who is using that CIP is not one of these authors and as we can see in this particular case the proposal is in review status for last 6 months they have no way to like realize how long will it take and if we make that as a hard rule then we will have hard time getting proposals that wants to become Ethereum standards >> yeah that makes sense >> all right then in that case we'll stick to commit history and move forward with that and yeah we hope that they work in the background and try to move it to the final status

All right. Uh, back to you. I I believe there was another solidity uh usage of solidity uh text and terms and ERC was the problem state. >> Yes. Uh so this was basically a point which came up while I was previewing. Yeah. Mainly ERC's. [music] Um so currently and this also by the way also is the case for EIPs. [music] Um the thing is that some ERC's they use like uh solidity concepts. [music] Um and with this I mean for instance marking a method as view. So if you have a view method then uh you cannot [music] uh do any storage rights to this. Uh this is of course like now fine but this

assumes that in the [music] future like if you would make like an ESC final you would also assume that in the future this view concept or this solidity concept or even that solidity is like still the standard. Um and the question is do yeah do do we want this or like like what's the idea like this this could sound like extreme nitpicky but I could imagine that if there's like a new language in the future which is not solidity and which [music] either introduces like the same cont concepts but under a different name um that reading these kind of ESCs which are then final are then very confusing because [music] you have these concepts but you would not know um yeah what they Yeah, it's essentially like making an

external link to the solidity specification and yeah um I mean like rules as written I don't think we should be allowing them but I think just based on historical convention um we do. Um do you have a strong preference either way? I I I think it's yeah like I'm I'm flagging this like as a possible problem but I think what what we should do uh like as a uh I don't think it it will not make sense to start blocking like solidity entries now because as you say

like that's also the impression which I had is that we allow solidity contest because it is like the current standard. What I do want uh to suggest is that we would uh start to do that now that we would only allow um coder blocks of solidity where it is clear what solidity version is used and with that I mean the uh the major version so like the first member of solidity because then it is clear like okay you are referencing to like solidity eight or nine or whatever um and that in the future you can also look back uh in the past like okay it this solidity version and then this definition was then uh so that we include the version of solidity that

that's basically the the the thing so like this pragma version uh solidity >> I think that makes a lot of sense so if somebody's using solidity or terms from solidity we ask them to include the version number somewhere >> exactly yes >> I think that's very reasonable >> okay cool >> I'm sorry to interrupt here I have one more followup question here. If we are asking them to write the version number, are we also expecting them to add the link of that version somehow? >> Uh so so I I I would think in in this case uh this would happen in solidity coder blocks [music] uh and if you add this uh pragma solidity version uh uh

comments this is also valid solidity code. So I would not say let's link to this but let's uh uh um yeah [music] include this this version and uh this may be valid for ERC just in case of EIP if someone wants to write down something are we trying to provide some general information that we should be using any language [music] but we provide that what version uh they are using or we recommend people using pseudo codes in general to be um not specific to any language like we can perhaps add that in contributing.mmd as a guideline for future and try to encourage community to follow that what

people think here. >> Yep. I think that's that's I mean I'm making a poll request for that right now. >> Cool. >> Okay. So, so I move to the next uh point. >> Sounds good. >> Yeah. Okay. So, uh this was um Yeah. So, this is about using AI. Uh I am currently not using AI but I got a lot of comments from uh people like okay you should really start using AI uh uh for like some um well very simple tasks and

that is like uh for instance if there are abbreviations in this in an EIP or in an ERC they should be defined before you uh do the abbreviation without of course like very specific [music] Ethereum related examples like we are not going to uh uh force people to to define what an EVM is for instance. Um but my main uh question what I wanted to ask here is uh because as an EIP offer we want to be ne neutral uh and we also want to ensure that there is no question that we are not neutral um and this would then maybe be more part [music] of like the office hours which are live and also recorded. Um like do we have any [music] problems using AI there? And

with that I mean of course you are not going to prompt an AI like okay what do you think of this EIP? No we will would just use u AI for like very specific tooling like okay uh um yeah these abbreviations for instance. >> So I take I think a fairly cautious approach to AI. Um, I'm not against using it and I think if editors find it to be a useful tool, um, absolutely go for it. But the ultimate responsibility rests with the editor.

Um, so it's not like you can just point at Claude and be like, you know, the AI made a mistake. No, you made a mistake using the AI. Um, but you're right. I think it is difficult to maintain like an element of neutrality when using AI. Um, yeah. So, I think it's just be careful. Use it if it's useful and be careful with it. >> Yeah. Okay. This this makes a lot of sense. Yeah. I also completely agree with you. Uh, it's not that AI takes over or oh yeah, but blah blah [music] blah made a mistake. Uh, no. Of course it is in the end the responsibility of the editor and not [music] like if any

kind of tooling makes a mistake then still it is you the editor which is actually uh well proposing changes or leaving like feedback. Um that should be coming from the editor and not uh uh uh yeah it's not like the AI's mistake that's uh that this goes. >> Exactly. Yeah. Yeah. >> Yeah. >> Cool. Cool. Okay. That's that's that's good. Good. Agree. >> I still believe [music] I I still believe that the suggestion of yam of having the abbreviation be explained in the proposal will be useful. So maybe for very common abbreviation or I mean AI will provide a full form of anything that is available on the internet but for general people it will be not

possible all the time to go through that. So having as much as documentation of abbreviation in the proposal will be a right idea. So I I I'm still with Yam on that to add it. Yeah, I I was using this like as an example of some uh some rule enforcement what what you could easily do or maybe not easily do but easily check using AI. So it would flag okay you have these abbreviations this not defined so uh define them. Um but I I'm actually not sure like we could also enforce this kind of rule [music] uh into uh the Yep or EC ruling. The question then is because I would find it yeah um I can I can understand that we

also want to define all abbreviations but yeah I mean yeah okay I yeah h like for instance the EVM like defining this as like forcing people to define this as an impreviation seems slightly over the top but on the other hand like in in [music] 50 years if if the EVM is not a concept it anymore then then it would make sense. Yeah. Okay. I'm [music] not not really sure about maybe someone else has some deals. >> I have um a list somewhere um I don't know where it went. Uh that's like my glossery of of terms that I don't require people to define and I keep intending to publish it somewhere um

because I feel like that would be a useful thing. Um where is it? I don't know. I'll go find it. Um, it's probably on my hackmd. Um, and I will publish it and then we can talk about it and maybe put it into anformational EIP. Um, >> yeah, that that actually makes a lot of sense. Yeah, glossaryy is also the the the the exact right word for this. Yeah. Yeah. And glossaryy of of abbreviations. Yeah, I I like it. I like it. Yeah. Nice. I just have to find it, which is always fun.

Very well. The last item here is making office hour more effective. >> Yes. Um so I think I have now done maybe four or five office hours uh so far. Um and the last one I was not very happy about it myself because what happened is I only well I basically only read like one ERC. it was like a very big one. In the past, I used to say, "Okay, this is like a very big EIP. I will do this after the call." But that's also not fair because then I would only do like short EIPs or ESC's in in in the in the office hour. Um, so the main question is okay, how would I actually make these

office hours more effective? uh I I think the the basic answer is okay you have like an agenda just uh the editor itself so that would be me uh should then come prepared so that [music] people that you can actually do a sync discussion on these things uh but yeah send maybe have some [music] some general tips um for this >> I agree I don't find office hours particularly useful like I I always hope office hours will be people coming on and asking questions like, oh, you know, how do I do this?

Or, you know, is this is this the right way to reference something? Um, that's what I hope office hours is, but it's really just people coming on trying to get a back door to get their proposal reviewed faster and like it doesn't feel useful and I have no idea what to do with it. >> Um, >> well, oh, sorry. Yeah, >> no, I I I would like to make two comments here. number one Yam you are I'm looking at the leaderboard so you are at number one uh leading leaderboard of editors that means you are you have reviewed quite a decent number of EIP/ ERC's and second thing uh Sam I feel like having a place where people can [music] come and share their problem is important

>> absolutely >> yeah that is the reason we want to continue this office hour because now it the word has spread people know that if some [music] EI PR is not being looked for very long time because we have like 400 plus PRs in EIP repository only. They know where to uh put it so editors can have a quick look. So I would be in favor of continuing it. >> I have a question. >> So I'm curious about the office hour workflows. You know, I haven't uh been in one, but I get the gist. And I'm wondering um what would it be like if you know I know there's always a an issue and people may

ask certain questions on there. What if a part of the workflow for someone attending office hours was um they have to post some of the questions or their talking points in advance so that they're at least biased towards you know asking coming with an intention that you think is what it should be for. So that if you have a certain scope that you wish people are doing that it's required or strongly suggested. Maybe you get to, you know, get in the front of the line first if you come prepared and [music] you say what you want to do first. Say what you want to talk about and maybe people conform to, you know, what you think office hours should be for. What would that look like? Why don't we do

that? I mean, I'd be okay with that, but I think that puts more work on pua. Um, I don't know how you feel about that. I'm totally fine to enforce this idea. I I believe right now office hour is being considered as a platform where if someone comes and add a comment an editor will take a look at it. We would encourage people to like add the problem statement. Why do you want to this office hour? I think something like that that might even be something where um AI might be useful. Um just parsing stuff just it's not going to say you know don't let that be the the final gatekeeper and arbiter but it can

definitely be a convenience. Well okay you know uh puja I think you know this this person here seems a little bit of a little bit off. Maybe you want to you know suggest that they do something a little bit different or they come with a different focus. So, I think um the burden doesn't have to be on you entirely and you don't have to, you know, be that strict. People want to show up. You want to gather some enthusiasm. Okay, maybe it's a little off topic. Um but the process doesn't have to be burdensome, but maybe it could be shifted more structured to fit the scope better. And you maybe I can help, maybe not. But just some of my thoughts for the process that I wanted to share.

>> Appreciate the feedback. We'll try to encourage community to like come up with real problem statement not just for getting the attention of review. >> Yeah. Interesting because uh yeah this also uncovers like it's always fun if you find that you have unconsciously made [music] some kind of assumption. Um and uh uh so Sam's definition of the office hour is like a different one what I have been following but this is also because how I perceive people indeed using this office hour and indeed uh it will it is currently I think perceived as indeed like the the fast

track to get like your EIP or ESC uh reviewed uh which I'm not I don't think that that's that that's the thing because we we should still and I also uh find myself not doing this some some in some cases because we should review of course from the oldest first to uh the newest I actually did clear like a backlog of EIPs uh this week I think so that's [music] nice but not ERC's because I also have to do that um but yeah I I'm I'm really like like because indeed what what Sam says like the office hours should indeed be like a feedback point [music] and not like the fast track to to to to yeah to get an EIP or ERC reshoot. But yeah, I also

would not know like how to do that, but I also like read those suggestions. So, thanks [music] for that. >> Yeah, thank you. >> All right. Uh I think that's uh all items on policy discussion that were added by Yam. So maybe we can move on to the next one. Uh the next uh section is about dispute resolution. So we have been receiving some um grievances from the community with respect to some issues or challenges they are facing during the course of EIP process like either EIP is being documented or EIP is being transferred um moved from one

status to another status or uh the discussion forum. I have added two or three examples here. Uh so the first one is about authorship dispute. Um I understand that editors [music] role have been defined in EIP569 that kinds of says that editors are not the person or the group of people who would be making all decisions. But because the community has so much respect and faith in this uh uh the job that editors are doing, I I brought it uh to this meeting to maybe we can figure out some solution, some some guidelines we can share with the community how uh they can solve these

issues and where they can uh [music] go to try seek some help. So the first one is about authorship. Um uh I think there are some back and forth uh responses on that issue and uh I had a chat with the author and the author said that he is not in a mood to close this issue because he is still hopeful that one day he will be included in the list. So that's one example. uh I don't have the author present here but uh I wonder if anyone has any further suggestion on this issue or yeah what do we do with it or how we can help.

Oh that's a big one. >> yeah. [music] Yeah, Ju just just to chime in on this one. Like I I'm not going to look into the context of this one because apparently this is a very big item. But um yeah, I I think the the simple way to to say it is the rules what we have is okay. If you start an EIP and you're an offer, you are also the person who has to approve all the edits to your EIP that includes new offers. And I think we should not set a precedent where um where we change this because um yeah of

of yeah of the community is saying that that this should be an offer or whatever. I [clears throat] I think we should not set this as a precedent because this opens the well this would open like an historic change and then people can say yeah but you did this in the past and this is now exactly the same so we [music] should also add people as an offer or we should change things or whatever. So yeah >> that's pretty much my view as well. Yeah, but I think this is just the beginning of the uh these kind of issues and uh I think I have a proposal later uh um in the agenda which I will bring

up which if editors agrees we can perhaps share as a guideline but I see um the second uh u item here in this section of dispute resolution feedback and comments for consideration. Uh we are joined by uh EVVVM org [music] uh team member. Uh he had reached out with some specific issues. I think the idea here is he's trying to add some feedback for a particular proposal. U he finds that it may need some kind of changes. Um I will pass it on to you evvm.org to maybe explain this the problem statement and what you are [music] looking for.

>> Hello. Thank you for the opportunity. Can you hear me? Yep. >> Okay. Thank you. Thank you Sam for replying here in the chat. And the question is regarding I there is the post. I don't know if you want me to share the screen or you can you can check it what I just posted uh on on on the chat about my reply the 28642. H should I share my screen or or can you open it? Uh, I can't like there's a reply to this post cuz I can't see it.

>> No, it's it's it's the post itself. >> Okay. >> That I just made uh because uh I I replied on May 6 after the EAP 8250 was posted. Uh I replied with exactly this information erh regarding what can be improved and and how EVVM can help on the shape architecture and feedback on this proposal because the key announces are something that we have kindly implemented since three years in in many of the of the core components they they want to reach on Ethereum. So we give a a strong feedback but the thing is that this this proposal

passed to merge uh the merge request without addressing our reply. So we we we asked the author on on Twitter about it and the the consequence was that our post on micians was deleted uh not replied because wasn't addressed. So here the issue is is is two things. First is um why the the our reply wasn't addressed and the the EAP pass it directly to merge and second uh why was deleted. H but at the end of the day the moderator re uh recommended us to post a

separated post that it's something I just made and now we have to reply again. But how uh should what did we do wrong or how can we reply again to avoid another flag and deletion of our our proposal and maybe there is nothing else to do here also because I don't know if the proposal is already merged but we made the the the comments and trying to add value on time. So it's a lot of things I think.

>> Okay. So, um, first I unless your comment was like rude or whatever, and I I I don't think it probably was. It shouldn't have been deleted, I don't think. Um, we can talk to the mods and see what happened there. Um, but, uh, yeah. Um, as for whether or not, um, [music] so the authors of a proposal don't have to, um, apply your, um, suggestions. I mean, they don't even have to answer you if they don't really want to. Um, but, uh, we do try to encourage that, you know, collaboration is better than competition. Um, but that said, uh, if you wanted to make your own

proposal, um, just like copy paste theirs, uh, with whatever changes you think it needs to be made, uh, you can do that and then you can take that proposal and advocate for it on all core devs. um the EIP process, we don't decide which proposals are going to be the correct ones or whichever ones get implemented. We just record the documents. So, uh if the authors of the proposal aren't receptive to your your your suggestions, um yeah, just make a copy of it, make the changes you need, and then convince the core developers that that is the direction um that they should go.

Okay, that's a very clear and helpful reply. Of course, it's nothing not what I would like to hear because I I personally think that that the centralization and the and the and the also not nonsensorship [music] and and the collaboration was happening in these spaces that we have. Uh and and really from my perspective I'm not I'm not attached to the June foundation or the core devs or I'm not friend of them personally. I'm not enemy neither. H but h but well how can I collaborate then because I see that we can do something for the video from my trenches but [music] at the end of the day they

are deciding which which EAPs go through or not. And I I I thought that that maybe Ethereum magicians forum was the place that we can have that kind of conversations [music] the interface you know. So >> it's supposed to be >> it's supposed to be okay. Yes. So maybe it's not it's not working always always because I see that there is very very rich uh conversations there and many APS are getting shaped there since months. Uh so there's a lot of collaboration.

Well, so this is just a bad experience for me at the end of the day, right? >> Yeah. And I'm I'm sorry about that. Um, >> yeah, I mean, I guess it's fine. >> Yeah, >> I I do think, you know, do submit at least a pull request um with your suggestions. Um, I I think it's probably worth mentioning on all core devs. Um, but yeah, I'm sorry that it was rough for you. It's uh we we try to be as collaborative as possible and I guess we kind of dropped the ball here.

>> Okay. Thank you, Sam, for your words and and the information. I understand that I I what what is wrong, I guess, is that my comment was deleted because I didn't I wasn't rude at all. There is my message. There is everything that I posted. But but okay, I understand. Yeah, maybe to to also to to to [music] just say like indeed the magicians like the entire process is supposed to be like super open. The magicians is the place to have these [music] discussions. So the fact that this reply was removed for whatever reason is just not correct.

Um and maybe as [music] uh yeah but just mentioning that that that deleting this does not make sense because now you have to open this new thread and this [music] of course uh is not the place where you want this disc to be. want this discussion to be on the actual EIP discussion. Um, also for the the visibility of this reply of course. Um, but Sam maybe as another comment because I also got a a question like last week or or so. There was someone opening a thread on magicians uh because this is a requirement for the ERP. So there should be a discussion place but this person could not do that because uh he either this person either had uh not

enough karma or whatever but he could not open a new [music] thread uh which is also like blocking and gatekeeping. So I don't know what what the policies there but I think this should also be allowed by default because otherwise people cannot submit [music] EIPs because they cannot create threats on magician. >> Yeah. So, I think um Discourse as part of their anti-PAM feature um requires you to spend a few minutes reading other posts before you're allowed to open a thread. Um so, you just have to like read a few discussion threads and then you'll be able to to post.

>> Um yeah. >> it would be nice if um a bot would just open the discussion thread and we don't have to worry about it. >> yeah uh that's that's maybe even like a good idea like I actually don't know who manages uh magicians and who are the moderators of this or like the admins. >> Neither do I. >> Um fortunately I am one of those. So if uh such concerns comes up, I'm happy to help and I try to like uh help new authors who are trying to have their um discussion link created. So please

feel free to send it to me. >> Okay. Um can you see what happened to the comment? Uh actually yes u uh to this comment it was flagged as a spam by one of the authors and because it was flagged by the authors the bot has to flag it as spam and uh it was to be deleted. >> Yeah. Was it spam? >> Um [music] if the com uh I can't see the comment anymore. >> Ah okay. But because uh the author has reposted the entire text in a separate thread, it doesn't look like to me. But I believe your suggestion of making a pull request right over there makes a

lot of sense. like uh um that's an suggestion uh to EVVM team that if you strongly feel that the proposal changes you are suggesting are meaningful you can make a PR to update that EIP and um if [music] author does not accept it you are free to create another proposal and share it in all core dev meeting [music] and let the core dev team u make take the call which EIP they want to take it in the future upgrade.

All right. Um with that we can move on to the next one. Um I had a couple of point but I see we have only 10 minutes left and we are also joined by uh RTO. Uh RTO u if you would want maybe okay give me two more minutes to finish up this one. So editors can maybe take a look at uh um it async and provide a feedback. So in the same section of dispute resolution there is another comment uh by me itself like I had uh opened a PR for an important EIP EIP7723.

It was created back in January but that is still open. uh this PR is actually making very significant change because we understand EIP status and network upgrade stages are two different term and they should not be confused with each other but I see the proposal is still open. So these are just two three examples that were picked in order to bring this to editors that there are some concerns which are getting into the community and we should uh try to provide them some kind of solution maybe some guidelines that we can publically share in the next link a proposal to document dispute resolution guideline. I want to here propose uh if possible as an EIP if not maybe we can have some MD file somewhere kept in the EIP reposi uh

GitHub repository to share it with the community and that can keep on building like what are the problem that we are receiving and what are the suggested guidelines from editors. Whatever we are discussing in these meetings may not be there for people to refer because that will be buried under the number of lot of meetings that we go over but having them documented somewhere at one place where people can go and find these kind of [music] problems and suggested solution would be a nice thing to do. So yeah, I would request uh editors to maybe take a look at the problem u the proposal and if you have any feedback comment um we can perhaps discuss it in discord or feel free to add it in the uh hackmd itself or if anyone wants to maybe give a quick

comment uh we can take that otherwise we can invite RTO all right so maybe we'll take it async RTO So uh please feel free to share your screen. I believe you have something to share with respect to EIP working group uh that you had already given us some context in earlier meeting. Want to show how it looks like? >> Yeah. So is there a hard cut off time at exactly the end of the hour or >> u we we can go a little overtime if editors are around.

Okay, so for those who don't know me, my name is RTO. I am a crossf functional CPO, UX leader and full stack engineer. My brand is Reto Vision and I work across you know various OSS ecosystems primarily focused on developer experience and for the past couple months I have been dedicating my focus towards getting the EIP working group into a launch ready state though I'm not the final arbiter of that but from what I see the issues that have been uh raised some of the bugs some of the opportunities I see for u improving the project to be the successor for the

current EIP system. So, I'm going to go over not a finalized set of features or a system. Right now, I finished a significant amount of reviewable work, but it's still in the review pipeline. So, consider this um pending pending a a long review process because there's still a lot to go over. So, if anyone's not familiar, the EIP working group [music] is intended to be a successor system to the current EIP infrastructure, not the EIP process, more of the uh the tooling behind it.

This is Sam Wilson's project. It's been going on for uh about a decade. Uh originally built as a CI tool. I've taken the initiative to try and expand it into a developerfacing tool where you know average contributors can use it for coordinating local builds because there's a lot of repos that's uh a lot to manage and running linting for proposals locally instead of having to do it just through pull requests as some examples. So here's a few of the things that I'm going to touch through quickly.

Okay, so last month I introduced the idea of um the multi-reo local build system in version one. Um it's my first time attending this meeting, my first time uh interacting with Sam and bombarding him with uh three massive PRs for a very large system which he uh very kindly offered to review the very next day which he did. So he came back with some feedback on the direction, the vision and the implementation and the architecture.

A few weeks later, uh maybe closer to a month later actually uh I came up with a V2 system. The link is in the issue for this meeting. You can check it out. There's a coordinating issue that has all of the tracked PRs, 23 of them across four repos. So far, the first PR has been merged. Second one under review and a lot more to go. So, you know, hats off to Sam because, you know, he's grinding out here doing [laughter] balancing a lot of stuff and this is a lot to go through as well, but this is a very important project.

So, some of the substantial rewrite though we're not going to get into everything that it does. The gist that we need to know and understand is um there's a lot of repos and it's not easy for a developer or a contributor u a future editor what have you to manage the process locally. So because of this fragmented process, I'm trying to have this tool become the means with which anybody can come on board and get set up. They don't have to manage multiple repos. They don't need to have to manage many flags, a complicated CLI process. It should be pretty

straightforward. And a part of Sam's feedback was shrinking the user command surface which I'm going to show in the next slide quickly. Um the iteration also has a separation of concerns which the build EIPs is a Rust native tool. Um it's probably several times the size that it was but it is pretty well separated for the new layers that have been added. We want easier user onboarding for the different binaries coming on board. We don't want to have people needing to scrge around for different dependencies and being stuck in dependency hell because that is hell that we don't want.

And the latest version also has a way to reduce build times. For me, I have a slower laptop. Uh maybe other people have a faster one. For me, it takes 10 minutes to run the full EIP build process. The system allows you to select certain EIPs for a demo. So for me, I can get this up and running in a few seconds, though it's not the full thing, but that makes a tremendous difference for a developer experience. So here is a preview. Again, not not set in stone yet, but here's an idea of what it may look like to interact with this system for getting it started. the very first command that people will get

familiar with, the very first thing that you run. How do we get all these repositories, you know, cloned? How do we get everything, you know, operational without needing to really learn a system deeply, build EIPs in it? That's all you need to know. Sets up the workspace, clone sibling repos, has the binaries in the shell for this pass. So from that command alone in that one shot you should be able to run the remainder of the commands yes across multiple repositories.

The build command is going to build from EIPs and ERC's the theme repo. So you get the full static site that you can render locally if you want to edit it or what have you. Um, preview is the way that you're going to actually serve the build site. A serve command is separate but similar to build and preview. Serve is a Zola native. I probably should have said that the pre-processor um is based on Zola for serving the site starting the sat static site. Um, this serve command is part of the developer server where you can experience live

incremental rebuilds very fast. So, you make a little change, it should update immediately, but you're not going to use that for full builds. It doesn't survive to my knowledge um these incremental changes. The build goes away once you turn the server off. Well, it's very good for testing changes. Now, the feature I love is being able to choose certain proposals to reduce the build time. For build and serve, you can add a flag or use a config file, which we won't cover today. Add the flag only, as you can see, and the proposal numbers.

and the [music] build process will only build out, you know, the theme, the theme site with those proposals added, which can dramatically reduce the build time. It's been a very useful tool for me working on um other issues. I've worked on other things outside of the uh this particular build system, building on top of it, and this has been a very instrumental tool for making it very quick to being able to test out other features. And last but not least, this may become a very familiar tool. Uh build EIPs editorial lint and the lint number or the EIP number that you want to run. And that will check if you are going to pass see if

it's going to break down or what have you before you make a pull request. So these are you know some of the ideas. I guess it's, you know, kind of a prototype, but it's concise, condensed, and it looks I'm pretty happy with it. Okay, so diving into the next thing away from the build system, though, I kind of use this on top of the build system because that easier to test. I made some adjustments to the um the oh actually I didn't even go through the agenda. I showed you guys

the agenda. Okay. So, a few things I'm going to cover because I'm going to turn the slides off. So, I'm just going to tell you very quickly uh what's going to cover next because I'm going to show the demo site that I have. So, I also worked on uh revamping the navigation UI for desktop and mobile. Should still be very familiar. um adding uh replacing the search mechanism that the working group has with a full text search system based on page find. Um that also has a feature for supporting semantic search because that is a limitation with uh doing a static site build without having a backend. So having a alternative means of supporting semantic search I thought was very important because I think research is tantamount to being able to

navigate EIPs. Um, and a very soughtafter, long sought-after feature for having a hard fork metadata page that tracks all the hard forks and the respective EIPs as well as having metadata on the EIP pages for the hard forks that they correspond to or some wording like that. Yes, tongue tongue twisters in my mind, but we're going to cover this quickly. So, let's go. Okay, I am going to share my other screen so I can show you what I have. So, I'm going to stop sharing this.

And this the proper thing? Let's find out. Okay. Yes, it looks very familiar. It looks like the EIP site because that's what it is. No drastic changes here. But the first thing Oh. Oh. Oh. Oh. Whoa. Whoa. Whoa. So, what? This is This is sticky. Yes, this is sticky. The navigation is fixed. So, or fixed as in literally fixed to the screen. Sticky. So, one of the um guiding principles I had when looking at, you

know, how can we improve the theme without changing it just for the sake of changing it because it's been here for a long time. It's worked for a long time. Not perfectly, but it's worked. This is a site that you browse. You browse and you peruse. So, I believe that efficiency is a guiding principle. How can we make the navigation serve the process of browsing and perusing as efficiently as possible without getting in the way without being too fancy and you know being straightedged with it. So one of the first things okay let's make it easy on desktop to you know go to the different categories go to the different

everything here. Now uh one of the demanded features uh in the working group was to have popovers. So now when you doesn't have too much me sorry the the stupid uh zoom toolbar is getting in the way of me like pressing different Okay, that's better. [laughter] That's better. Okay, >> I think you're getting them on the list page. Yeah. >> Yeah, you you get the point. I wanted to show it on EIP. So, so it shows a little bit of the metadata right there. Um, and this was not as easy as you think. This was not client side. There's a whole uh added step to the build process. A very

important step for generating additional metadata that can be used for multiple features including popovers, but also supporting um search and a few other things. Uh, but yeah, that's one of the cool things. And see what else. Okay. So, we got sticky headed for desktop here. Okay. D. All right. So, before I get into mobile, so one of the features that I think uh is going to enhance navigation, make it a lot more smooth. So, every page has a table of contents. All the EIPs. Is there a table of contents icon?

Not that I'm aware of. So, an open book. I chose an open book and I wanted to streamline navigating the table of contents. So when you are on a table of contents page there will be an icon for navigating table of contents. So the each page gets populated with the table of contents in a menu for that particular page. If you go to a page that does not have a table of contents, oh it's gone. It's not going to bother you. But when it's there, uh, it does what it needs to. Or you go to a different page. Okay. Populates different. Okay. Jump jump jumps around. try to make things convenient right there. So that's uh a new thing that I thought would be very useful.

And now let's get into the mobile world. Okay, so again this is the desktop mobile, but it's still mobile nonetheless. So here we are. What where are we? What are we doing? Okay, so look at the bottom of the page. We have a bottom bar. My favorite thing to have. So the bottom bar basically replaces having top navigation because we, you know, there was the u little hamburger menu which had a a white block that had very illeible text. It's been there for a while. The text was kind of offcentered.

It wasn't it wasn't uh it wasn't working. It wasn't working. Um and in the service of making navigation seamless, I wanted to try and make mobile as efficient as possible. and I didn't want to get in the way of, you know, this beautiful word mark. Have that right there. Leave it alone. Let it be. So, the bottom bar has um four different buttons for context. When you're on the top of the page, there's three. But once you go down, okay, let's do quick stuff. Especially because when you get into I'm going to go to the menu here. Got a little nice menu. when you get into these big pages over here, when you're navigating and scrolling, you don't want to scroll back to the top and

that is a lot to do. Okay. And quick search. Quick search was added by um another um developer who contributed the initial uh fuse system for search, which we'll get into in a second. Um sort of preserve that, but having it a little bit different, a little bit different button, but I I kept his modal idea here. Okay. Yeah. So, this is what it looks like for a proposed, you know, revamped navigation system. It's not that different, but it's different enough where hopefully it enhances smoothness.

And yes, I put the homepage in here because, you know, for a long time, um, I kept forgetting what the homepage was. I was like, "Hey, wait, wait a second. How do I get back home? Where's the homepage? Do I press all?" And then I was just very confused. So, I wanted to add it back for uh my confusion, which I'm sure other people may also share. Okay, next feature to introduce search mechanism. originally the working group was using a fuse.js JS and sort of a fuzzy search client side and it was um parsing through atom which is uh not optimized

for search and it was also doing a lot of heavy lifting client side and there was a request to explore different search pools. Uh but a key constraint was that there's going to be no back-end service. At least to my knowledge that was a key constraint. This is a static site. So that immediately reduces the prospect of having a full-blooded semantic search or vector search because that's not something that can be you know casually done client side in a browser. It's intense. It's an intense thing to to do. Um so in focusing on full text search I landed on integrating page find which is a very popular uh very popular among documentation sites.

It's wellmaintained to my knowledge and it's Rust native so it fits in with the pre-processor without introducing a new language to the tool chain. Um, so now we can do full text search with keywords and we can, you know, filter things down similar to EIP insights. So I'm just going to look up Ethereum because, you know, why not? This is this is Ethereum. Here we go. Oh, we got a lot. Yes, we do. Oh my god, we have so much stuff here. I don't I'm not going to parse through all that. Proposal category, statuses, authors, etc. Okay, everybody's seen search before. I don't need to get in too much of the minutiae.

Yes, searching by year, when, etc. Okay, so what I like about this that helps. >> Sorry to sorry to interrupt here, Rito. Uh I see Yam comment that he may have to leave in next four or five minutes. I wonder if there is uh more to it like uh do we think we can wrap it up in next 5 minutes or so? >> Yes, we can. >> Okay, perfect. >> Yeah, no one wants me to rant about search. Everyone's seen search before. Okay. So, uh convenient part about this is it's URL based. So, you are able to share the link with other people. You are able to return to your search um if you leave. So once you go to a

particular uh particular page, you don't need to start search all over again because the search query is URL based. So you can go back and it will be saved uh for 24 hours. It automatically saves it. So it sort of treats it similar to an app um except it's a static site. Last but not least, we get into the hard forks. Okay, so I made a uh seen various you know requests for a feature that you know can actually track EIPs

corresponding to hard forks and have this be in the entire site. So I made a network upgrade hard fork indexing feature. U it starts with a small EIPW validation change that allows meta EIPs to declare network upgrade. Then the pre-processor uses those marked meta EIPs parsed inclusion sections and a historical backfill rules to generate the hard fork index hard forks page data and per EIP network metadata. Um the theme then renders that uh generated data while correctly handling weird edge cases like you know Petersburg and uh Dow fork where they don't actually have um anything uh to

show EIP existing but it still gets accounted for. So here we have the network upgrade showing up that it's included shows the exact status and has that for all of it. And right now we have a uh a transition period in in this intended here for migration um because we don't actually have everything with front matter yet. We have a hard-coded list um that [music] that would probably remain permanent for historical ones that have an atypical um parsing scheme. But for uh more modern ones, it would be relying on fraud matter for a migration.

Okay, so that seems to cover all that I have to show for it. Um still a lot to review. So, thank you for your time and allowing me to share. >> This is looking absolutely amazing. Thanks so much for your your work. >> Cool. Glad you think so. Thanks for taking the time to review it because I know this is a lot. [laughter] >> Yeah, this this is really cool. I uh I love it. Also like the hard folks is like like well like like a thing what has been asked a lot. Uh [music] so this is great and also like semantic search.

This is honestly the first time I I even hear this word, but I love it already. So, that's great. Yeah. >> Sorry, that was like the last thing and this is not not a long discussion. So, um the built process also has a search corpus that you can use uh locally like you have to do it yourself. This is not part of the official it's part of the official pipeline but not for production. Um you can generate a search corpus used for debugging or for thirdparty consumers. You can take that search corpus and you can make it chunked. There's certain flags so that you can use it for semantic search and I have a repo which you can see inside the issue for this um this meeting as as a demo that takes that generated search

corpus and uses uh qrant to create a vector search uh mcp server which I've tested out which you can use with your AI agents if you want or any other uh mechanism. So, you should be able to take the EIP corpus and use it however you want to do research within reason for how we're able to build it. There's only so much flexibility we can have, but there's enough. And this one that I made here, this repo is a little bit specialized. It's one way that people can test it out. So, I recommend checking it out. And I'm excited for people to check it out and test it and uh give some feedback if you can. Always good to have some feedback.

Great. Thank you so much for sharing this. If you find any further update, I'm happy to include it in the next agenda and give you more time maybe in the beginning of the call. So, anything that we miss out today could be covered in the next one. >> Sounds good. I appreciate that. >> Thank you for joining. And one last question before I let Adidas leave for the meeting today. We are approaching towards the 100th office hour. I I believe I have also proposed this in the discord channel. Uh we would like to have maybe longer than hour session if people are fine with that.

>> Works for me. >> Um yakam would you would you be available like we can do it for 2 to 3 hours depending upon your availability. I can obviously connect with you people async and try to get that. So if there are any suggestion and the last thing is for the next EIP IP meeting uh by default it falls on 17th uh but if we can get it sooner [music] would the 3rd or 10th work for editors >> uh let's see the 3rd of July or the 10th >> June sorry of course of course sorry >> uh let's see I [music] think yes both work for me.

>> Both work for me. I think the third is slightly better. >> Okay, cool. Then we will keep it on 3rd of June. Thank you everyone for joining us here today and staying a little longer. See you around in Dart Channel and in [music] other meetings. Have a great one rest of >> all right. Thanks everyone. Bye-bye. Heat. Heat. [music] Heat.

Heat. [music]