RPC Standards #6

Transcript

Oh, you did mention about the open PCV2 generator. >> Uh yeah. Yeah. Um so um basically Acolyte 3 um had did a port to Docsaurus um but he was using the older sort of MetaMask uh plugin. Um, but the MetaMask plugin has a lot of problems. So, um, I'm Zayn from the Open RPC team and so we don't recommend that you use it. Um, so, uh, I think there's been a big push to be able to have additional

documentation next to the RPC uh, API. And so um what I did is that the generator the newest version of the generator that's um version 2.0 um is fully compatible with the version before the upgrade to docuours. Um but I didn't realize there was a regression and the support for uh the documentation. Uh, so, uh, I did a couple of, uh, patches and accolade 3 has the, um, has those patches and a PR. Um, so I'm curious like how that worked out. Um,

and then longer term, Open RPC is putting together a roadmap for the upcoming year. Um and so um we were discussing like what would be the next step for um generation and we kind of want to move more towards um officially supporting docysaurus and then um going for a style that's something more like mentalify. Um, and the reasons for that are that you can have a tighter integration and a more modern like sort of layout um with uh support for things like curling things um just better searchability for the API and sort of like organization

and things like that. But that's kind of like a longer term uh thing. And then um one of the things I was kind of also hoping to solicit was some feedback on the road map that we're thinking about um and open RBC is just the specification language um that's used by uh execution APIs um etc. >> Okay. So that that's pretty much so my update.

>> Okay. I don't know if we can wait a little. I think Justin said he's on his way. I don't know if he'll join or should the call. >> Oh yeah, I can just hold off. Um I just >> Hello, Jackie. >> Hello. >> Hi. >> Sorry, I can't talk too much because I'm in a library. So, I'm just observing. Cool. Mercy, what are you uh jamming on? I I Yeah, >> I did I had some PRs but it has not been

meshed. So I'm kind of waiting on light clients and then due to the back and forth with the um dosaurus um implementation or is here I think I have to like redo my PR or something. >> Hello everybody. I'm sorry I'm late. >> Hi folks. I'm at the Berlin interup. I just need to find a quiet place. >> Okay. Can everybody hear me?

You can. Interesting. I cannot hear you. One moment. >> No one was talking though, I think. Oh, >> so you're you're great. >> Sorry about that, folks. Uh yeah, so I'm at Berlin Interup. Um there's a bunch of people here, etc., etc. So I am sorry I'm late. Um I will catch up with what's going on in the chat though. But hi everyone. How's everyone doing? >> Good. Good.

>> Um did everybody have a chance to look at the agenda? >> Uh yeah. Well, I did. >> Okay, cool. Is that what you were talking about? It looks like Mercy just posted a link to the open RPC update there. >> Uh, yeah, we were talking a little bit about um the Docu Source and Gatsby change. Um, I haven't run Acolyte uh 3's implementation or update on the G V2 generator, but I did put in some fixes that were regressions. um that we're preventing uh markdown documents from being able to like render very easily.

Um so there's just like a directory that you throw in markdown to and then it will >> generate those documents and you can also do like NDX so you can style it by putting sort of react components on the inside um of the markdown. So it's pretty customizable um everything except for the sidebar and then I was talking a little bit about uh the aspect of the open RBC roadmap that is um talking about a documentation overhaul um and some of the thoughts that we were thinking um going forward that would be um something that we would

integrate into the standard. So we would officially support docysaurus and then we would be migrating from Gatsby but right now uh the docuaurus for meta mask is um definitely like sort of deprecated. So it would be um just kind of gathering feedback on some of the features that um you might like. Um, and our thinking is that we can take Docysaurus and we can style that to be more like Metlifi, but then all of the sort of doc framework for doing the generation would come from the generator itself.

>> Okay. So, I'm not really familiar with the other product that you just mentioned. Um, did anybody else on the call have a chance to pull both of these PRs and build them and take a look at it? Um, does anybody have a strong opinion on either of the user experiences as a dev or even as a API? Okay. U maybe that can be some homework for folks. Um, or we can even have that conversation asynchronously.

No problem. Um, but I think I think that's kind of the the question that we have is on the one hand which which experience do we think devs are going to like better and on the other hand which one's going to be easier for us to maintain um and keep up to date moving forward uh you know based on where open RPC is going to go and obviously we would strongly want to consider Zayn's input on that since you know he's here representing the RPC or the open RPC side of it. Okay, I think I can do that and then get back to give you feedback on it.

>> Cool. Thank you, Mercy. >> Um, and again, we could just do that asynchronously. Um, or even comment on the agenda for for next week. >> Yeah, I was hoping to uh I I thought maybe Acolyte was going to be able to make it, so I was hoping to see um how it ended up being styled out. Um, but uh yeah. Okay. >> Uh, cool. Yeah, you might have better luck trying to catch up with him online. Um, I'm happy to do a Discord introduction if that's uh necessary.

Um, and so in the in the uh, you know, interest of keeping things brief, I I want to hint on one more point that was there on the agenda. Um, we can kind of skip the the thing on the style guide, I think. Uh but the second point that I have in the agenda here is the notion of divorcing structure from data. Um and that is uh it's an idea actually Matt and I were talking about here at Interop for a little bit. Uh we think it might have some legs. Uh but but right now the end point for our specs is really does RPC compat pass in Hive? And as we've discussed in the past, RPC compat does a straight string comparison between expected input uh and expected output.

And you know, we think we might be able to relax that quite a bit uh by leaning more towards JSON schemas and having a separate test suite that really just focuses on semantics and you know, formatting and all that all that stuff that we expect for it to a badly behaving client. um but with a minimal uh coverage of you know the return values and the actual data that's being tested. Um what do folks think about that? Um is that a direction that folks want to want to pursue? Um is that useful to you as an API developer? Uh does anybody have any thoughts on the matter?

>> So I have some thoughts. Um, I used to work in at QA um on Infura and I I fully support that idea. Um, sorry I have to whisper cuz I'm in a library. >> Um, anyway, uh, yeah, I think anything to help the devs. Not everyone cares about that. The JSON schema, we did a bit of testing out like that at Infura when I was working there. Um, so I fully support this move. >> Awesome. Thank you, Jackie. >> Um, well, I wonder did you have any thoughts on um, you know, the level of, you know, input checking? Um, so for instance, you know, you have a problem

when you're testing an RPC call because today uh, when you do a string comparison, you have to know that the values that are actually being filled out in the response are correct. Focusing on just the schema allows you to kind of ignore that. Um, but you know, there's there's still a need to actually have some some you have you have to know what questions to ask it through the RPC, right? So, if you're going to say get block, you need to pass it a hash. Um, if you're going to be asserting on the structure of a specific um, you know, get block call.

>> Uh, today the way that >> Sorry, go on. I thought you were asking a question. So, like I guess what I'm saying is um, we need all different types of tests. So that that's why it's good to have just the schema type of test because some people don't care about the string comparison like they're okay with some discrepancies there. Um so I guess that's it was that simple just being able to have the option of just a schema comparison >> right so it's a testing and depth type answer it sounds like. Good. >> Anyone else? Yeah, I think that that makes sense to be able to have some schema validation.

So, at Open RBC, we actually have uh a JSON schema like spec uh tester. So, like um I know Shane has done a lot of work on um basically validating um gaff client calls versus like what the spec returns. So um you can see like what those discrepancies are from the documents and I know he's found a lot of like issues with the actual specification versus like what gaff is returning um during that. So a toolkit like test coverage is I think pretty good slash almost

complete for doing that kind of like schema validation. Um, so that could be somewhat useful and I think um like being able to have a minimal thing uh that like covers the all the possible states uh because like I think um the validation can't be decoupled from the data entirely because like if you need to validate that you're returning uncles properly uh the semantic meaning uh goes beyond just the like the syntactic meaning. So you really do need syntactic and semantic validation. Um yeah.

>> Yeah. Okay. I mean it sounds like we're pretty much in agreement on that. It's just a matter of finding that line and we want to tilt it in this case. You know, we want to do as much in the schema and relying on the schema as possible and yet still afford uh and facilitate the more specific stuffs like the uncle case that you're setting there. Okay. Okay. Cool. Um, last question that I have for folks and like I said I want to keep this brief because uh, you know, I was late and I apologize for that. I want give you some time back. um who has JavaScript experience and would be interesting interested in um kind of taking over a couple of those PRs that are floating out there um that Acolyte

was working on potentially you know making sure things are up to date working on the the npm environments uh the build process uh merging in the PRs for both for either rather uh the um I just blanked on Zane what's the name of the uh renderer that we're using on the open RP PC Gatsby. Gatsby. >> Yeah. >> Um either that or docu depending on which one we go with. Um it's it's we're we're getting to uh implementation time I think on this. Um and um I'm unclear as to who can who can pick it up and run with it if anybody.

Um, so we're probably going to be opening issues against the um, execution API repo uh, and hoping for somebody to to take a look at those. And, um, I do have Matt's ear at the moment, so I will be hassling him to approve any PRs that are that are coming through. Um, so I I think this is just a long-winded way of me asking like who, if anybody um, is available to volunteer for work. I don't want to put you on the spot right now. Um if you want to reach out to me in private and say hey I think I could take this issue I could work on this issue awesome um I don't >> go ahead >> I did start working on some issues and also when last client mentioned about it

I sent him a message although he did not reply but that was before um we had to go um through this back and forth um um the stories and the Gatsby implementation because I had an a >> okay >> that that actually have like is linked to this other PR. So I don't know it depends on when this get merged or gets resolved on the final um outlook we looking for for the documentation. >> Okay. So perhaps I'm looking at the wrong bottleneck in the system. I will talk to Matt about that.

>> Yeah. Um and just like for clarity from our perspective on like the open RPC side, um like the docs from MetaMask like which we also like wrote um like are not an uh like the condition to be used I would say for like uh the like sort of the theory um like ecosystem.

And so essentially what happened was we were in the middle of this system overhaul because um like there had been some rust. We jammed on it uh and then we got the ecosystem back into like working shape back when it was like pristine. And I think in between there are some concerns that um like folks wanted to see like more side documentation. And so side documentation like works again in like Gatsby. Um and so it's like it's kind of at this tension point where >> can you give me an example of what side documentation would be? Um, so like I think last week or a couple weeks ago,

um, you had like an introduction as to like how you use the spec, how do you contribute to the spec and >> yeah, that's the good stuff, the narrative, >> all the good stuff. Like >> it's more than just the spec itself. >> Um, so like we >> wanted to be able to support that. We actually used to support that, but then there was a regression that prevented that. And I actually reached out to light client maybe one day before um the uh the docysaurus um landed.

>> So the timing was just slightly weird. >> Um but like the real issue with the docysuruses is that it's not maintained. A lot of the packages are like really old. And the other thing is is that it doesn't support the newer features that get you things like error group error grouping uh extensions and other bug fixes um that we've done to your open RPC. Um and we don't really have a way to like update that. The other sort of major issue is that it's hardcoded to use window.ethereum Ethereum and as the RPC execution API standard um you probably

want to be able to specify exactly what your RPC call is and not necessarily need to um grab like for say the wallet provider that's providing the windowed Ethereum. >> Right. Right. And like um so there's that and then there's also the usage of stoplight on the inside of the stoplight schema which is causing the schema validations and the docysaurus um issues. Uh and yeah so those are like sort of the major issues on why the docysurus plugin is probably not the answer. But it's not that we don't want to move to a

better system that facilitates just like a better experience. So, um that's that's part of the reason why we're putting it on the road map for this upcoming year. And so like it's kind of like probably one of the highest priorities and like we'd be like really open to any sort of feedback on like whether um working to help improve test coverage is like a higher priority or a complete refactoring of uh the documentation generation would be even higher priority than that. So, um, yeah, those are those are my, um, >> okay, >> my thoughts on like the Gatsby docysaurus. And the okay thing with the

Gatsby is that all of the changes into the Gatsby ecosystem are non-breaking. So like they work just as your ecosystem worked before the docyurus landed with like no changes other than just like the major version bump and making sure you're on the latest version of Node, that kind of thing. >> Okay. Well, I will um I'll dump all that on Matt.

>> So those are those are my thoughts. I know it's a lot. >> No, no, it's good. It's good. Um I think I got a good TLDDR out of that. Cool. Um All right. Well, I'm actually ready to call it here. I apologize for starting late and ending early. Um but things are a little bit crazy on my side. Does anybody have anything else that they want to bring up, though? I I don't have anything, so the time is really yours. >> Um I just have a question. Is there like >> further discussion on the um PR on

standardizing JSON RPC error codes? >> Yes, there was a PR open. Yes, good question. >> Um I guess what do folks want to know about the error codes? Um because Sims is in the middle of another meeting so he couldn't be here um today. Um >> so this is PR 858. Is that right? 658. Sorry I misread that. >> Uh this is the grouping one. Yes. Yes.

Yes. Actually, Sim says that he can join now. So, he's he's getting ready to join. >> Yeah. Cool. >> Yeah. So, I think I think um the TLDDR I guess maybe I should wait for him to join. Um but Mercy, I don't know if you had any specific questions or if you're just looking for, you know, a path forward um to either adopting this or getting it merged. Is is that kind of your question?

Yeah. >> Sims has arrived. >> Hello, Sims. >> Hey, folks. Sorry for being late. Uh, I was on >> No, no, no. That's okay. It's been actually super chaotic over here as well, so no worries. >> Cool. Cool. Um, >> yeah. >> No, yeah, sorry. Please go ahead. >> No, I was actually going to give you the floor. I just wanted to do a quick, you know, context. Uh we had some uh some time to go over the RPC um I'm sorry the the PR with the error groups in it the RPC. Um and I think we were kind of curious as to what you imagine the the path forward um and next steps were to

be on something like this if if we were to adopt error codes. Um also you know my my feedback on it was I think this is good. I don't see any reason not to pursue it. Um but the the real issue that I think we would get a lot of lift out of is being able to abstract out messages um from the error codes. We obviously want all the clients to be aligned on the codes themselves, but we want the messages to be uh free form and we want the clients to be able to add whatever information they have in their own context to the messages. Um and and that is another thing that I I don't know that this approach can solve, right? our assertions are a string comparison right now and that's that's

the real actual problem. Um but is that is is that a part of the uh problem space that you considered with with this? >> Um I did definitely I can send out an alternative proposal. Um just to see if if that can align the error messages themselves. Uh but it's not mandatory like you mentioned. And uh we only want to you know focus on error code as as to start with at least because that's going to solve a lot of problem. Um uh adding the error messages or standardizing the error messages going to be cherry on top. Um just I know makes the user experience much more um better uh overall. But it's it's definitely we can

we can redis. I can write up another proposal. It's it's not too different. uh I will be just standardizing the error so it'll be easy for um the clients to adop adopt and uh it's not like a too big of a deal. I'll I'll rephrase this. Maybe I can send another proposal uh in the next meeting, but I can go over their codes focusing just on that for now. >> Okay, that sounds that sounds pretty good. Mercy, did you have any other follow-up questions?

I'm trying to think through. I'll just drop a message. >> Cool. Uh should we should we I can represent uh whatever I did last week. Uh now that we have a bit more folks, let me quickly share the screen. Uh sorry. >> Oh, yes. I see she has a PR I do it. Yep. >> Okay. I wanted to ask like for example when an established application like have let's say clients have like have their hardcoded error handling or existing um specific client code how are we going to like work around this are they going to redo it or >> um okay that's a that's a great question

the implementation uh I did look at some of the client code like get uh I don't Basu was long back. I did look into it. Yeah, it's all over the place. There's no standardization. Um the actual implementation what I was thinking is initially I could pro or we could uh whoever wants to volunteer we could come up with a standard of um uh creating um uh you know a framework or library to import just their codes and then use them or um just implement it in any way the clients want to and it's uh the the easier way feels for them and then we can is do the validation on the EVM

compatibility testing that we have a lots of framework right um uh the hive client or RPC test gen um anywhere uh there is no particular constraints when it comes to the implementation um the the original plan I had was just first work with one client and see how this goes and uh once we have that implemented and see how easy or hard it is we can define how we want to uh standardize these error codes. Maybe it would be best to you know um convert that into a library and then expose it so the clients can just consume it or or just um you know use the error codes.

Now the error codes are standardized and it's in the spec. Anyone can just look it up and validate. Um so that was the two idea I had initially. >> Okay. I think the second one will kind of like make sense because most of the time if you're looking at um implementing it on one client first most of the time when trying to do it on another client you face a lot of issues because some for example the each simulate call we're having there was a lot of differences between get and the never mind then those had to like be there's always a backlog coming up at every given time.

No, I I I do agree. Yeah, for sure. Um yeah, if you guys think having an standardized library makes sense, for sure we can work on it. But I I don't know how much um useful it's going to be. Uh uh or how I I think we can discuss it for sure. Uh any we can have some ideas, brainstorm and come up with a framework. Uh sure, for sure. Uh the only thing I was thinking is how this would actually be you know standardized in a sense that can be implemented in a library and anyone can consume it because at the end of the day it's just the standard code quotes. Um maybe we can have constants

that just you know uh gives out the grouping and people can use it but only if you go with the error messages maybe it'll make sense much more. Uh but yeah, I'll give it a thought a little bit more thought and I can come up with something next next uh call. >> Okay, I I'll summarize this and um I'll put it on as an agenda point for the next call. Thank you. >> Um >> sounds good. You have your hand up. >> Yeah. Hi everybody. Um, so yeah, I just wanted to ask just I I learned about this call from uh talking to Frederick and I was suggesting some things around like

>> RPC security and he was like, "Oh, there's actually like a work stream on the RPC stuff. >> So I wonder what is what is like the the process around this?" So like is this like a big rewrite you're doing right now or is this more topical things? Uh like what's good question? I know it's a bit high level. Sorry. >> No, no, that's okay. That's good. Um, I can answer it quickly because then I have to go. But the the TLDDR is right now we are just trying to get the RPC layer specified uh and something that we can test against and something that we can document it and present it to all Ethereum devs, right? So everybody has a Hold on a second.

Um, so like all developers could have the same type of experience working against it and they'd know what to expect. Security is a very interesting one. Um, and I think that this would be the right place to have that conversation, but probably not for some time. So, for instance, you know, there's things like um JWTs uh being specified in order to access the engine API layer that happened to be specified as part of the um gosh merge um when we when we introduced that stuff, right? Um, but there's no real blanket uh prescription or guidance on how to secure any of the other APIs, etc. Um, so I think that TLDDR is that you're in the right place. Um, I don't know if the timing is just right yet,

but there's no reason that we couldn't have these conversations in parallel. you know, the the the specification of of the of the um the JSON calls and responses is moving pretty slowly and we actually have probably, you know, we could carve up a bunch of time in this call to have discussions about security as well. >> Sounds cool. Sounds cool. Yeah. Awesome. >> We'd love definitely love to touch on things like I don't know like better authentication and you know authorization for the API that things that haven't been touched right in the definition of the API initially. Yeah.

Yeah, that's great. Um, okay. So, hopefully you found the JSON RPC channel in uh the Ether R&D Discord. That's the best place to get in touch with us. >> Okay, perfect. That's good. Thank you. >> Awesome. All right. Well, thanks everybody. I have to go. I appreciate um I appreciate all your patience putting up with me as I'm in such a rush state. Awesome. See you everybody. Talk to you soon.

>> Thank you everyone. Bye bye. >> Thank you. Bye. Peace.