EIPIP Meeting #125

Transcript

Heat. Heat. What's up?

Thank you. Heat

up here. Heat. in progress.

Welcome to EIP IP meeting number 125. This is added on Ethereum/PM GitHub repository issue number 1975. On agenda, we have a bunch of call for inputs to look into the decisions. Mostly the deadline have passed for all of them. At least what I can see here on the list. There are a few other open but not included because they still have uh time to receive some response from editors. We have a couple of items for editors discussion. We'll get some updates from earlier meetings and we'll get into insights the monthly insight followed by um a design or tool that is built by

community. Maybe we can have an introduction of of the tool. So to get started the first item on agenda is call for input. Generally this is uh Sam's item. So Sam over to you. >> Sounds good. So, uh, we have number 393, Unicode technical standards. This has been affirmed. It's just waiting for approval on the poll requests that implement it. If I could get an editor to go and look at them, I that would be very much appreciated. Um, we also have Matt's um, associate EIP editor um, call for input. Uh, that's 398. That one has been affirmed. Um so whoever wants to take a stab at implementing this um

please do. Um we also have removing online serial from the citation uh that was merged as affirmed. Um and uh I removed it from the rendering system. So that should be done. Uh we also have a uh number 405 adding a status tag in um the citation. Uh, I think we're still discussing this. I'm not sure if we've come to a conclusion on it. So, maybe we can talk about that a little bit. Um, Puja, do you want to give us a rundown on this one since this is yours?

>> Yes, I can perhaps provide some uh information on that. So um as of now the citation is a draft for every proposal that we see on eip.ethereum.org irrespective of their status. Um I have created a PR where I'm suggesting uh that this can be added based on the status like current status or the page status but it could be uh not mentioned in final and living as suggested by Sam.

So I have updated the PR. Originally it was for whatever is the current status of that proposal or the page status that will be reflected in the citation section but we have made edits. Now here we are trying to discuss what is the best way to add this in all the EIPs. Do people think that uh it has to go as per uh the status the EIP status that we follow or should we come up with um a formula like where we provide citation only when we think it is in the final and living status or we do not add citation for final or living. So that's that's the thing that we are trying to

solve here. I believe uh Sam wants to have it. Um Sam you have mentioned two things like have draft on every except uh living in final but I guess there is some change in thought. Um Gajendar Singh seems to be of different opinion. He thinks that only living and final positively indicates that this has been accepted and is unchanged. So we can perhaps um add there. Yeah. Sam if you would want to uh let let us know.

I'm like I hope I'm I have provided some context. >> Definitely. >> Yeah. Yeah. >> Yeah. So um my argument here is that in academic citations and you know thankfully we have Greg here so he can chime in if I'm incorrect but the assumption is that cited works are completed um unless they are marked as a draft. Um, so I think Oh, go ahead. Sorry. >> Go on. >> Oh, so I think it would be best to have a marker for everything except uh final and living because they're all technically drafts.

I am a little bit of different opinion like I would I mean like partially agree with Sam that we can perhaps not any citation for living in final because now they are ready but uh having draft for any other status may create confusion. Right now on on any particular page we have three different places where we put statuses. one is page status, one is preamble status and third is a citation status. So my uh thought was that we could perhaps have page status and preamble status same as the citation status with an exception of living and final. And do not add a draft to all of them because you know when page says it

is in review and citation says it in draft people may get confused. So the idea is that we avoid the word draft just so we don't overload it with different meanings. >> Yeah. Yeah. I mean either we use the uh page status if it is draft review or last call then we add the citation. If it is living or final we do not add the citation at all. I wonder your come out Greg if you have any thoughts on that.

>> No, I don't think so. I coughed with my microphone accidentally on >> Yeah, I currently also don't have a very strong opinion on this. Um Yeah. Okay. So, um I'm just going to write a comment on here and um come up with something and then uh we can either agree or disagree on that. Um >> I'm laughing in my head. Uh I know it's on keeper. So, Sam, sorry for putting you in this position, but yeah, that is a great uh path forward. Yes, please go

ahead and add some comment and we can um maybe keep it for open for some more time. I do not have a strong preference. I just want like whatever editors agree on, we can go ahead with that. All right, cool. So, moving on to the next one. This is number 406,formational EIPs and status. So, this ended last month. Uh, and this is a discussion about whether or not we want to allow um upgrade EIPs to um stay living or go to final.

Um, yeah, I think we're just looking for more comments from editors on this. We I don't think we have many people's opinions here. Uh and the two people's opinions we have are opposed or opposing rather. So um leave a comment. >> Great. Uh with that we have covered the call for input. The time deadline has already passed. So we would highly appreciate if editors go ahead and add their input. And if anyone here in the call may have thoughts, they can also add their comments for consideration.

Well, next comes editors discussion. Um, we have listed the items from what we collected over the comments to this agenda and from the um discord discussion. The first one is the living proposal informational category. Uh Sam, I understand you have some concern. Do we want to discuss this today and talk about next steps for this proposal? >> Yeah, sure. So, this is about EIP7870 uh which is hardware and bandwidth requirements for validators and full nodes. Um my understanding is that it collects you know whatever hardware you need, how much RAM, how much storage to

run a node. Um and it's kind of just like a bulletin that people are publishing. um just to let people know what they need to run Ethereum nodes. Um I have no problem with this being anformational EIP. Um I think it fits nicely into that category. My problem is that I don't think it should be living. Um because it doesn't there's no process for how we approve or or don't approve living EIPs. Um so I think living should be reserved for our own internal documents. Um, so now that this is living, the editor or the the authors of this EIP can edit it forever until they disappear. And then um because there's no way to replace authors or or

whatever, um, we're just going to end up with a eternally living document that'll never get edits. And I think we should try to avoid that as much as possible. >> Right. This also would um add a little bit to the last call inputs right about the >> thisformational ears should uh >> let's see what is 406 >> yeah um yeah I'm I'm actually not so sure because um for theseformational EIPs should this then so you are basically saying it should at some point be finalized

Yes. Yeah. >> I see. I see. Yeah. Okay. >> My stance is that every EIP that is not authored by the editors should go to final eventually or withdrawn. >> Right. I see. Yeah. for this specific EIP like I can understand why the office have made this a living EIP because I think that the reason is that it will reflect the um well the current recommendations for a note to run um well to run a note um because otherwise and this because I could really see like um

um arguments also for moving this to finalized because then at some point in time you could see what are the recommendations of a note at that point in time. So like maybe at like a fork level. Um but the somewhat problem with that is and I think this was al also be the argument from the office is that uh you cannot directly link to this EIP. You would have to find the latest well not the latest version but the latest well yeah I I guess the latest version of this not recombinations EIP which is then finalized. So I could see arguments for both points, >> right? So I think that my my concern here is that um like let's say all what

1 2 3 4 5 6 7 8 9 10 11 authors uh die, which is conceivably possible within the lifetime of Ethereum. Um there will be no one left who has the authority to continue updating this EIP. So, it doesn't really solve the um the problem of having to link to the latest EIP because yeah, some someone's going to have to make a new one at some point. >> Can new authors be added over time? >> That's true. Yeah. Yeah.

>> I mean, in in an event where they all disappeared all at once, I mean, can can it like emergency water be added? I mean that would also technically be true of editors. So that that's a really good point but that would be valid only in the case of living proposal when when a proposal is finalized. I don't think that is a scene there. >> Yeah. Exactly. >> Yeah. But I I assume the idea for this particular EIP the the hardware specs is that it will be infinitely updated for all time.

I mean I see a downside of keeping this proposal as a living because we would want to send community a signal that this is the um hardware requirement that we are following say for example for a particular upgrade then unless we move on to the next upgrade there there cannot be immediate need of change of that proposal. So having a finite status having it a final status for hardware recommendation will give also a signal that during this time period of Ethereum evolution we were following this standards but now that Ethereum is into say for example 50th upgrade now we want to have a different hardware

requirement we can have new set of proposal >> I would say there's a slight difficulty on that cuz not everything is related to to a fork. So for instance, the gas limit is valid until voted. And if that kept going up, it wouldn't need any forks to increase the hardware requirement, if that makes sense. >> Yeah, you basically document what the hardware requirement is at the start of a fork, but you that wouldn't necessarily be valid all the way until the next fork.

Well, I mean, let's let's say in some future version of Ethereum, everything becomes alsified and it it never upgrades again. Um, that doesn't necessarily mean that the hardware encirments won't keep going up because there'll be more state. Um, the validators could keep, you know, computers could be 100 times faster and the validators might vote for, you know, 100 times more gas. And so the hardware requirements will have gone up even though there are no actual protocol changes and you know it might you might need a terabyte of sorry you're already at a terabyte you might need a pabyte of this storage or something just because you

know in a 100 years time there might be that much state >> from a developer point of view I can understand that it makes sense to have it in one document but from a community point of view I see an advantage of having a new proposal every time some something change something major changes for the reason that uh if uh this proposal this hardware proposal keep on changing not everybody will be noticing anyone who wants to run their node for the first time then they come to the Ethereum standards repository and try to take help of whatever information is available say for example this EIP is available to let them know what their hardware requirement should be but they

won't be visiting every now and then to check the latest one. >> Okay, then this might might be a process. I don't know. Um would it be possible to um have like a superseded by header where you could point >> Yeah. >> Well, there's there is super point at the new one. >> Uh no, sorry. There is super Yeah. So, there is a way to withdraw an EIP. Um and you can say what the superseding EIP is but once you go to final um there's no there's no indication of superseding or not.

>> Yeah. But the alternative here could be the new proposal that you are documenting. You could mention that the earlier one as required. So that kind of create a reference that earlier this was it but now this is the advanced version version of the hardware requirement >> that that creates a backward link but you might need a forward link. So if you if you're following a historic link saying this is the hardware requirement you want to be forwarded on and say this isn't this is no longer the hardware requirements go look at this new one if you see what I mean.

So if you landed at the wrong place, you'd be redirected to what the current one is if you if there were multiple though. So I'm going to guess that we're not going to have a resolution on this call and that we should probably discuss this async and come up with some proposals on how to deal with this for the next call so that we can we can come to a decision on it. Um unless somebody objects and they want to keep talking about it now uh I think we should move on to the next topic.

>> Yeah. For one last comment on this one because um if you will change this EIP from living to final that's not possible by the procedure because it's now in living. So that's like well I would say uh the final state is living uh here. So if you want to do that in the future we should also add this as agenda point to to discuss how we would handle this. it since there's no way for a final document to indicate that it's no longer relevant. Um, living actually seems to be the right status cuz living document you can keep adding the new requirements to um or if you prefer um

um put the supersedes in the living document um take it to final and uh point them to the new document. But otherwise, when they hit the final document uh for some old requirements, there's no way to know that it's an out of outofdate document. >> Yeah, that's a good point. I think um whatever solution we come up with, it needs to be be able to indicate what the next sequence is if we have multiple ones. Yeah, that makes sense.

All right, we'll move it to the next meeting and try to uh get it async. If we can have some solution, maybe we'll further discuss it in the next EIPAIP meeting. Moving ahead, uh we have next item merge this asformational EIP. So this proposal is uh by Greg. Uh there are two part questions. Number one, if this can be merged as anformational EIP and number two, which was identified in yesterday's office hour uh call that there are two core proposals which may want to refer thisformational proposal. So unless thisformational proposal is merged, what is the way to provide that information

for those two core proposals? I believe one was 7979 and the other one was 8013. Uh Greg, if you want to add more context to it, please feel free and then we can open the floor for editors to share um what they think about this proposal. >> Um well, of course, I very much prefer that it be anformational proposal because that's exactly what it is. It's information for the community um so they can better understand how control flow works, why static control flow is important um and just basic information that's turned out to be

turned out to be needed in the discussions of this issue over the years. Um and I've been specifically asked by some people um to get some such document and uh both given given that the document itself was factored out of the core EIP um I could put it back there but it's just too big a motivation uh for what's actually a very small proposal. Um, and there's really just no place else to put it. We could put it in the assets, but then something fairly important is getting buried. Um, I'm not in the

foundation, so I can't put it on the foundation blog where it's prominent. Um, I refuse to participate on X. Um, and uh, just basically I think anformational EIP is the best place to put something like this. It's uh, intended to educate the community um, and be there permanently uh, as motivation for um, at least two existing proposals um, and existing discussions.

Um so it basically it is anformational EIP meets the definition of informationformational EIP. I think with some work it will meet our standards of quality. So I just don't don't see any issue there. um I'll tolerate the workaround so that I can get the uh underlying core EIPs uh you know get them get them usable so that they have a link to to uh this document that they that they do depend on. Um but merging it as anformational VIP is my

strong preference. I've said that way too many times. So, >> I'm just catching up on my old comments for this one. Um Um but yeah, I I my like initial thought on this is basically to put it into the a core EIP, but if that's not practical because it is quite long.

I mean I I I guess I could live with this. Like if I can if we have a hardware requirements informationational EIP, I don't see why we can't have this too. So >> yeah, maybe also to ask because this is I think there are like two two points here. The first is what's uh um what's like anformational EIP and I think the point that this hardware EIP is merged as anformational is also a an argument to to merge this one. But the other question is um and that's something I wanted to check. Is it possible from one EIP to link to the assets of another EIP?

>> Yes. >> Okay, that's great. Um right. Okay, that's that that that Yeah. So, I'm thinking because uh like this could be a workar around. Uh Greg wants to uh reference to this document from these two EIPs. So, what could also happen is that we put this document in one of the uh the asset folder of one of these EIPs and then other EIPs can link to it. Um, but I will also just state that I think it is better to have this as anformational EIP uh because that that feels more uh right to me.

>> Yeah, I withdraw my objection to this. I guess we can we can bring it in. All right. Uh, any next step for Greg here? I'm assuming that the proposal will be reviewed and merged as draft. Anything inspecific for his action items or he's just good to use this? Yeah, I think uh Sam if you and I could go like one one time over this EIP, but I think that um yeah, I I think we could maybe also merge it as is if uh this HTML document

is deleted. Um yeah, I I think what we're still trying to fix the references so they render correctly. >> Yeah, I just I just committed that. Okay. You actually Well, what what we had was close but still wrong. Um >> yeah, you you need it needs to be four spaces and no blank line after um the the the carrot number square bracket. Yeah.

>> Okay. So the >> it is the most annoying construction of markdown I have ever had to work with. So I I'm sorry for putting you through that. >> Markdown is so primitive compared to the tools that we worked with in the 70s that >> hey I'm I'm all about latte for sure. Anyway, um if yeah, if that's taken care of, um there's there's edits I want to make, but they don't need to be done until after it's merged. Um

>> um one thing I'd like to mention is I'd urge caution on too muchformational EIPs along this line. However, this is quite exceptionally different one because so many EIPs themselves are based on or require this information that is >> and it does not have to go any further from here and we are expecting this proposal to be merged as informationational EIP. Uh and I believe that will also address the concern of uh referring that to the other two core EIPs that was discussed in the previous um office hour.

Moving ahead uh we have uh two other items that's not much for discussion but mostly for references. In the last uh EIP meeting uh we were joined by couple of Ethereum Foundation dev uh who are willing to help out with um some of the existing issues in the EIP's GitHub repository. I have created related issues. Um both issues are added on um EIP review bot. Please take a look uh with all the description that uh we have added there. I believe there is a pull request also created by um David. I don't know who is the right person to

maybe take a look at it but I wonder if any of the editors would want to take a stab on it and just leave comments if that is good and can be merged. So depending upon the progress of the PR this can be you know considered as resolved. Okay. Yeah. Matt or Sam maybe take a look at it. Um do we have it for both issues? Let me quickly take a look at it. Oh wow. Yam has already added a lot of uh comments here. Um I wonder Sam if you have anything to add on this issue.

Please feel free to take a look at it. We are trying to figure out what is the best way of EIP number allocation with the help of bot and we don't need to have someone manually adding the numbers. So these are >> we had a we had a call about this a week two weeks ago. Um so I think we have a reasonable path forward on it. So yeah >> cool then we are going to have numbering bot in the EIP GitHub repository soon. Thank you for taking this forward. All right. Uh so next we have um updates from previous meeting. I am assuming that this has already been taken care because it's been a while. But let's go ahead and have some updates. Grant more

editors force merge permission. Earlier we had only two editors having this force merge permissions. Do we have more now? >> I thought we did um but if it hasn't come up I will um talk to DevOps about it. I think yeah name was proposed there right so I wonder yam if you have the permission maybe you can confirm or yeah >> yes I I have this permission but I don't like I don't like to force it so I have not used it yet but >> that's perfect so we do have like this thing resolved we wanted to have more editors getting this permission so I guess Yam was the only one who was proposed in the last meeting if we

needed for more editors we and perhaps mention it in the meeting and get that done. Next is EIP documentation format for test cases and reference implementation at a canonical place for new authors to refer to. Um I know we had been discussing about it. I'm wondering if we have anything in specific in mind. Do you think we can add it to the contribution MD uh that we have created or people think that it can be living as a part of separate MD or could it be added to template MD?

That could be another place. maybe the template would be a good place for this. Um you could put it in a comment and then Okay. Okay. Then uh maybe we can take a look at it and try to come up with something by the next meeting. All right. Let's quickly take a look at uh any of the open action items from the previous uh EIP meeting.

It's taking too long in my end. Nops I think we have pretty much covered everything. Board's news section. I do not see EIP inside guy here. So maybe we can skip that. we can get the updates async. Next is uh availability for hosting EIP editing office hour. Uh we have added the schedule. We concluded meeting 97 yesterday and for meeting 98 we do have SAM on um calendar.

uh we would appreciate editors to uh go ahead and book their slots for upcoming weeks that would help community to follow along and I'll be opening the agenda with respect to availability of editors. Um as we do not see EIPS inside person in the meeting maybe we can move on to the next section which is um showcase or feedback for any any project or tool that is being developed by community. I guess we are joined by RTO here today.

He wants to share something about central coordinating design and review issues. RTO take it. >> Hello. Um so real quick before I start would I be able to share my screen? And I have some diagrams in the middle of my presentation I'd like to go through. >> Yes, you have permissions. >> It should work for you. >> Okay. All right. Cool. I'll do that in the in the middle of it. I got quick hands. So, I'll get that done. So, Sam, you're here, right? Because this is working group style. So, definitely need your attention because >> I'm here. Don't worry.

>> Awesome. All right. So, my name is RTO. I'm here to introduce a multi-reo local build system that I just finished for the EIP working group. The PRs are linked in this meeting's GitHub issue. Issue number eight is the central coordinating document. Um, but since this is my first time in this, you know, Ethereum ecosystem in a live meeting, um, I'd like to quickly introduce myself and some of my background and tie it into the work that I just did.

So I am a crossf functional chief product officer, UX leader and full stack engineer. Retovision is my brand. I work fractionally. retovision.com is my website and I'm a contributor to about a dozen major OSS projects primarily doing front-end work on flagship and documentation websites often to improve user and developer experience especially on mobile devices tends to be a lot of problems on mobile devices but I got an eye for that I really enjoy it uh this includes git the Linux kernel OASP systemd and Kubernetes. And of course, the current

EIP repo where a few months ago I fixed a systemic issue where the theme layout was broken on mobile across 100 or so pages in the main pages. Um, that fix was when Sam first invited me to contribute to the working group, though I'm just finally getting around to it right now. But, okay. So, this is going to be a short introduction to the multi-reo local build system. That's a mouthful, so I had to repeat it just to get it in your mind. Multi-reo local build system. Okay. So, I'm going to describe what problem it solves and how it works, but unfortunately, the build process still takes over 10 minutes. So,

we're not going to do a live demo. That's probably like 5 minutes faster than the Jackekal version. This is Zola, but still too long for a demo. Okay, so if anyone listening is not familiar, the EIP working group is a ZLab based architecture that's been worked on for about 10 years with the intent of succeeding the current Jackekalbased system and it is maintained by none other than Sam Wilson. So when I first started working on the working group, I wanted to contribute to the site theme front end. So, the first question I asked was, "How do I build the full site so I can test my changes?"

After doing investigating and digging around, the answer confusingly seemed to be figure it out yourself. Invent your own path. There was no formal way that I could find for doing it locally. Now the CI has a path for coordinating across the multiple repos necessary to build the site but that is not really practical for local development and the current EIP repo system has the same problem. I encountered that um doing the fix for the the mobile issues. I wasn't able to do the entire workflow in one sitting. I had to manually shift things together to reproduce the system. So for the working group, I built a local a

local build system that gives contributors a straightforward path to run through the full site pipeline from their machine intended to have um a level of parody with how the CI actually works though some divergence for local convenience. So the system serves two purposes. One is site development like building, surveying and previewing the site locally and the other is editorial work validating proposals against the EIP rules which you can do locally. You can run either one independently or both.

So in the current version you start from the Oh, maybe this is the part where I should show some diagrams. Let's do that. Okay, get that build system. You know, can you guys see my screen? >> Yep. >> Okay. All right.

Okay. So in this version, you start from either the EIP or ERC's content repo clone locally since that's where most people think to start. Then from there, you bootstrap with a single command to clone each of the sibling repos required for the full build process into your workspace. Um, you also have the option of cloning the uh pre-processor and EIPW if you want to work on them also though not necessary to run the full build process. Uh, from there the simplest thing is to just build or check you know that assembles the site from your local repos and runs the full site pipeline.

That's the baseline path. Uh, if you want more control, there's a workspace config file where you can point at a local theme checkout, change the build route or switch profiles, um, including a parody or parity oriented profile that uses remote inputs instead of local ones. You can also work dirty, so you can build and serve from tracked uncommitted edits without having to create intermediate commits that you may have to roll back for every single change. And for live iteration, um, serve uses the, uh, Zola development server. It still has the 10-minute build initially, but changes afterwards will update um, very quickly. And separately,

preview, which uses tiny HTTP because we ain't trying to add a lot of dependencies here, um, in order to take the a static build of what's already built. So, you don't need to run the full site build every single time. um for certain changes that are already made. Uh and separately for the editorial side, uh editorial validation happens as a part of the PR check path. Editorial lint here lets you run just the proposal checks locally and editorial me down.

That's better. Um editorial build mirrors the PRCI path. It validates the proposals and then runs the site check on top. But if you still want to do the full site build, you just do the regular site build with the changes. That is basically the gist of everything. Um, it is a site build. Ultimately, it is a static site builder. Um, it has a lot of moving parts going on to get it in this state, but ultimately the simplicity is what we're going for that in a a few commands you're able to orchestrate multiple repositories and get the full sight

pipeline built um without stepping on the toes of the everimportant CI process because uh the way I see it right now with the CI process, how it's structured, It's like managing the airplane in flight already and the working group is like trying to repair the airplane in mid-flight. Um, but how are you going to do it on the ground? So, this is a process for local development that makes it easy to play with the airplane without having it be in the air already.

Um, I do have the issue, as I said, linked and I would definitely welcome people to uh try it out locally. I do have instructions on how to set it up and get some feedback. I would definitely like to know if it works cleanly on your machine cuz everybody needs to know that. And if there are any workflow gaps or use cases that haven't been covered, if there is anything with the command surface or setup flow that you think could be shaped differently, I would definitely love to get your feedback on that.

Cool. Well, I am pretty excited to dig into reviewing this. Um, thanks a ton for for the contributions. Um, I have started looking at it and so far, um, is there any way you can break this up into smaller independent PRs because this is going to be a beast to review on its own? >> How do you It's >> fine if not like I'll I'll take care of it. But yeah, >> if if it were to be smaller, uh, how would you figure? because yes, we have uh four repos right now and I didn't even include uh bootstrapping in like the theme even though I think that's

probably a good idea. I think you should be able to go on any repo and be able to spin up the full pipeline. I think they should all have uh a call sign connecting but I left that out for now. What would it look like for you if I were to simplify this? Because from what I see um >> I don't mean like changing the functionality at all. I just mean breaking it into more digestible p digestible pieces that are smaller because I think the the one PR adds like 2,000 lines of code or something like that. So, >> and I would stack these PRs. That might be easier for you. They would still maybe separate stack.

>> All right. I can uh I can look into that. Yeah. >> Yeah. And if you can't, not a problem. Um I I'll get to it. It's just it will certainly be easier for me if they're a little bit smaller. >> Okay. Is this something that would be in the triaging pipeline soon? Because uh I have in I have it in me. I'd like to make a sprint towards getting the working group uh system towards a launch ready state. Whatever that looks like, I'd want to discuss with you further, but um I have the energy to try to push things forward. I'd like to see it go through. So, what is your um estimation of being able to triage um multiple contributions to this to getting it to the finish line?

I'm pretty excited. So, I'll probably start reviewing this tomorrow. Um I I don't know how long it's going to take me to review it, but I will certainly start tomorrow. Okay, cool. Cuz then I'd like to get on to other stuff like having um I want to replace Fuse with a different type of search mechanism. Like to switch up the nav. I think the brand needs to stay the same because the brand is like a temple here. It's like this beautiful bland generic temple and I don't think it needs to change. But I figured some people are thinking, "Hey, maybe we should change it up." I think it's uh it's a brand as it is and let it be what it is. So, yeah, I'm I'm excited if you're able to triage with me and try to get the working group to the finish line. That

sounds cool to me. Thank you for uh Thank you for that. Cool. >> And thank you. That's that's a ton of work and I really appreciate it. >> Right. I'm very right. This is a good work here and uh just for you to know it uh if you if you want to maybe make a full demo of it we can connect and have an a dedicated session for that. Uh we do sometimes promote projects like this. So we have a ecosystem project demo a podcast where we can uh share the information whenever it is ready like whenever we have this working group

thing working or if you want to provide a demo in order for other people to kind of make use of uh this process. >> Okay. So if if we were to do a demo because I'm definitely down for that. Um I guess we would be using v video so we don't have to sit there for 10 minutes waiting for the site to build >> right. Yeah. Okay. >> Yeah, that works like you know you can either go ahead and do demo or if you have anything done prior maybe we can show that and you can explain the process in between because sometimes you know building takes more than 1 hour >> to showcase. Yes. Uh please if you are on the catus or e institutes discord please bring any of the herders there

and we can work with you to schedule the meeting for having this demo recorded. >> Sounds good to me. I'll follow up on that soon. Sounds good. >> Cool. Well, thank you for joining us here today and yeah, for your work to make the dream come true. I know Sam has been working on it for quite some time, so he's excited and we are excited as well. >> All right. >> All right. Uh, that's pretty much it for today's agenda. Um, I mean, let me quickly take a look if this is good and we can go ahead and do Cool. Uh, so I think that's pretty much for today's agenda. Uh, does anyone have

anything else to add, share, or maybe to bring up for the next meeting? I'm happy to include it in future's agenda. All right. Um, in that case, I have one random thought that I want to share. Maybe people can hear it out and uh, think about it and we can discuss it even further. one point that was mentioned earlier in earlier today in one of the conversation here that uh we do not have a way to let people know to not use the proposal not use an EIP which goes into final I don't

know if this is going to resolve that or not but I am wondering if there is a way by which we can perhaps for example we have required section in preamble that tells any current EIP that whatever EIP you should look into it before reading this proposal or this can be mandatory or this can be required before you implement this proposal. Is there a way to kind of future add EIPs for a past EIP? For and if that is in the required section of any of the future EIPs, we add a preamble uh there like future implementation or feature required

section and we list all the EIPs which are using uh 1559 or which are built on top of 1559. I mean what do editors think about adding this special preamble field which can let people know that you should also look all these future EIPs might help. >> So I think that's going to be a post um whatever we end up deciding to do with the website uh because we'll be able to generate that really easily with uh EPS build and it's probably possible with Jackal too. Um I don't think we need to add a field for it. Um >> I get it and yes that is a very good

suggestion because adding a field will go uh for retroactive appending the proposals which make not which may not make sense but if we can display it with like UI only that would be nice addition. The same way we intend to display the uh network upgrade stages and network upgrade name in the UI. Cool. Uh so yeah, I think that's pretty much it for today. If people think of need of having it further discussed or whenever we are ready with uh the new UI, we can perhaps bring it back and see if this can be implemented. Um,

yep. I think uh that is pretty much for today. Um, for people uh who follow EIPIAP meeting, this meeting happens every third Wednesday at 1600 UTC. And we invite every community member to maybe talk about the issues and challenges that they have with EIP or the governance process in general or if they are building any tool cool tools for supporting the EIP process. Thank you everyone for joining us here today and see you all in the next meeting. interesting.