RPC Standards #4

Transcript

Welcome to RPC standards call number four. Uh right, we are being recorded. Uh it is May the 12th, 2025. We are postpectra launch. Uh reviewing the agenda today. It looks like it's a little thin. Um there's two things that we have called out specifically on the agenda and I'm not sure that we're going to have the permissions to execute on them. One is going through outstanding PRs. Um there's quite a few in the uh execution APIs repo. Uh over 30 and I'm not sure that anybody on this call has maintainer

status to merge any of them. Does anybody here have maintainer status? Okay. Okay. Um, the other thing that I called out that I thought would be helpful is to go through the outstanding issues in the execution API repo and flag them as things that are relevant to standardization and specification and maybe isolating those from actually new RPC requests. U, I think that would be helpful so we could kind of frontload some of the process issues and get things moving forward a little bit more.

Um, but without maintainer status, I'm not sure that that's possible. Um, this is a bummer because there's a couple really good PRs that were opened. I don't know if anybody uh has taken a look. Uh, Yakam had uh one for No, that's not Yakam. Uh, I don't know who this person is.

There was a proposal to add block timestamps to logs and there was a really impressive PR from a user named Simpson Raj. I don't know who that is. Uh, but it addresses our error code standardization that we've been talking about for quite some time with a sample implementation. Um, and so I thought that was pretty cool. That is pull request 650. uh would encourage folks to take a look at it. So, unfortunately, I feel like we're maybe at a little bit of a standstill without maintainer status. What does everybody else think?

I will say that from the theory just side, I mean like like we we want to see this stuff like final some of these things finalized. And here again, I'm how do how do we get who who has man I mean I don't know enough about the like who has maintainers? Is it just Felix? I can't he can't be the only one. Um you know it's funny uh sorry there's a helicopter overhead. One second. Welcome to Philadelphia. So, um, one of the things I actually had the same issue and did a little digging to try and figure out. We don't have a maintainers, uh, markdown file in this repo anywhere.

So, who has that permission is unknown. It's not doesn't seem to be publicly available from any of the security screens or anything like that. Um, so you know based on vibes I know that I've seen Felix and uh male and like merge things into repo but that's really just anecdata. So um I guess I can take that back to research or the EF. I'm not even sure exactly. I mean, I work for the EF, so I can go to our internal DevOps like page and like request like I mean, I don't I'm not sure that I'm qualified at this point in my life to be a maintainer.

Probably not. But at least ask like, hey, who are the maintainers for this repo? How do we get if you know, we need someone who has permissions to join? If it's I don't care if it's I mean, and I don't care if it's Matt or you know, whoever. like this whole this whole conversation is pointless if we can't if we can't get someone who actually will merge stuff. Yeah, that would be awesome. We would really appreciate that. Thank you. Okay. Yeah. See, I have been I have been reaching out and I have been posting things that to the best of my ability, but uh if you could do that internally, that'd be great. Okay. Yeah. I mean, that's that can that's the least I can do because like this like awesome. This is this is all like we're just screaming into the void. Yeah. Yeah. We could do

better. Um, one thing that I was thinking of, um, things that we can do without maintainer status. I think, um, what would be really cool is if, um, we somebody took it upon themselves. Um, again, I'm trying not to I'm trying to herd cats and not do work. Um, and so I I think that would something that would be helpful would be a document that describes how we go from specs to tests. Um I think that is an missing part of our process and I and I don't want to encourage us to take on large amounts of process. I think even just a uh updating the contributors.mmarkdown doc in um acolyte would you mind reading your um cherry

blues are impressive but uh yeah hold on one second. Yokum wants to join as well from my team. He doesn't seem to have he doesn't seem to have the zoom link. Let me go back to the calendar. I was like, where is it? I was like, well, it's on the calendar. You must not have it. One second. Um so so yeah I think even if we just uh wrote a hackmd that kind of described the process or how we would update the contributors uh markdown file to show how uh the specs get into tests tests the RPC compat test suite and hide specifically is the barometer um for client

implementation and that's who we're trying to standardize amongst um so I think that would pretty valuable. Um, wait, sorry, sorry, you can ping me. I say so. Yes, I mean I agree with that those being the that being the barometer, but what what was the first part of your sentence again? I'm so sorry. That's okay. Um, the idea is that what we don't have documented is how we get from specs to tests, right? So right now we have PRs going into a repo that um ideally will change specs but maybe add some narrative and things like that right and then we want those to you know there to be a virtuous cycle between those to output tests that clients run

and right achieve their standardization. So um I don't well here again we need we need someone who has the superpowers to actually merge stuff one on number one on the API on the on the execution on the on the specs repo and two you know the three people who do hive tests so here again Felix and whoever else like oh I know Felix I know Felix merges stuff but whoever else has hive like I mean I can open PR I've had I've had PR merge that's not hard it's just getting someone who's willing to update the specific simulator in Hive that we are playing with. Right? So and I have experience doing that as well in the past like it said you know we have plenty of commits and not enough merges

right. Okay. Yeah. Well I I'll I'll think Yokum hopefully is going to join here in a minute. Not that I mean here we're not able to do anything. Oh there he is. Hey. Hey yum. Um but hey guys. Are you Puja? Are you listening in right now or are you just on? Just curious if you have any maintainer who if you know who has maintainer status on the execution APIs repo. I'm pretty sure it was light clients to begin with. So I'm pretty sure he does and I can reach out to him too if yeah I was just gonna open an issue with DevOps and say how do we get someone else to have because like he can't do everything like we like we don't have there's just not enough manhour in the day for for light client and Felix and who I don't know who the other few like

people with superpowers to do all the work to look at stuff and if they're not attending calls there's no point in them being the only maintainers like right yeah no I think DevOps is the best way to go about doing that All right. Well, I'm gonna open an internal issue for IA. I mean, you know, it's one of those things where like obviously if Justin is, you know, our our cat herder, there's no reason he I mean, I don't I don't know how I don't know I don't know what the rules are for who has maintain access on the on the Ethereum or repos. I mean, Justin, you probably can't since you're not part of the org, but um yeah, that's right. And typically um you know what I've seen with other projects is that there's a contribute the contributors document that outlines how to contribute also

explains like here's how you become a maintainer and I don't see anything like that in there. Okay. Well, it's just never been it's just always been let's do what GU did and hope for the best. And there's enough of their clients now that it's time to stop doing that. Not that Guth is wrong per se, but um Okay. Okay. Well, I I will open an issue internally for DevOps and we'll and I'm going to tag Felix. Um, and is Matt still does like client still maybe he's still part of the or I didn't think he was at the EOS anymore, but okay.

He's on the team. Okay. I thought he Okay. I thought he was working for OP. No, it tag me too. Okay. Yep. We'll do. And then that we'll just we'll get that going internally just so that we don't have to like have the same conversation every two weeks. That would be awesome. Thank you so much, Carrie. Yep. Echolyte. I'm Andrew. I just I'm just But all right. Um then I guess the floor is y'alls. I think we've covered uh what I had on the agenda. Um we'll cover it a little bit harder next time. Um but does anybody have anything else they want to discuss?

Yeah, maybe just a general point. Um yeah, I thought that the Zoom URL would be posted on the decent RPC RPC API channel on Discord, but uh it was not there. And apparently I should get it via some kind of calendar. But yeah, I think this is also because I' I have redirected some people to this call from this uh API uh PR. But yeah, they could also not find Yeah, they are not here, I think. No, they are not here. Okay. Yeah, but for for the process itself, I think it will be really helpful to also post this URL on the channel. Absolutely. Or at least on central page because then we might get uh slightly more one eight or maybe one/4 of more people. Yeah, that will be

Yep. Good point. And we've done that. We've done that in the past. The Zoom link is um always up to date on the Ethereum calendar. Um there is a standing meeting for this. Um yeah, it's just not on the RP. Yeah, it's just not on the GitHub issue associated with the the calendar link isn't actually there. So that that's something that um maybe we can do that going forward. Okay. All right. I the automation has facilities for reusing an existing calendar link. Um I guess it might not be pulling it in. Kuja, go ahead. So we have made some changes about the calendar and the zoom link here. Going forward, whenever Justin will be creating a new agenda for the next meeting, the Zoom link will be

automatically added to the Ethereum protocol calendar. However, what we can do is we can repost the Zoom link that is already added on the um Ethereum protocol calendar on the GitHub agenda. That way people can get it easily. That's one way. And the benefit of that meet uh zoom link going forward would be that it will summarize the meeting notes and will also create a fellowship of ethereum magician thread. So people can have the conversation in a similar way we do have it for acdc or DT calls.

Yeah this sounds very good. Yeah for the for the process. Very good. Yeah great. Okay, Pua, I will reach out to you. Maybe we can pair on that just to make sure that I'm up to date on the latest. I know that the formatting of the issues has been under in flux because we're adding cool new features to the bot and whatnot. And so I want to make sure that we're we're doing that right. I'll I'll hit you up maybe later this week. Sure. Yeah. And also to check like these kind of calls are also the calls to to like to to Yeah. Maybe there's a a bit preliminary, but also discuss like changes to the J RPC, right?

Yes, 100%. This is exactly where that should be happening. Um, they'll just be more effective once we get some maintainers in here. Yeah, I see. Yeah, of course. Yeah, that's why I said Yeah, but I've I've sent these uh these people, they want block timestamps in the in the locks, so not a very big change. Very helpful. Um but yeah, then this should be the place to to actually to propose and push that. Yeah. Cool. Anyone else? Okay. Well, uh with that, I suppose we should give the remainder of the time back and um the cat herders will go cat herd in the other

direction. We'll try and get this get this sorted out. Thank you, Justin. Thank you for this call today. All right. Bye, everyone. Bye, everybody. Thanks. Bye.