EIP Editing Office Hour #86 (EIP + ERC)

Transcript

[music] Welcome to EIP editing office hour

meeting number 86. Um we are joined by our newest editor Yohham Brier. Welcome Yam. >> Hey >> on agenda we have open PRs with respect to final review miscellaneous and draft proposals. There are some PRs which are also collected for maybe review and get it closed. This meeting will cover both EIP and ERC GitHub repositories and you can find the issue listed on Ethereum/PM GitHub repository with issue number 1885.

So we can already see the screen uh here of editor. So you're please feel free to proceed with final proposal and we can go sequentially as listed there unless we are joined by any author and if there is any author on the call please drop a link of your PR on the comment and we will be happy to address your concern. >> Yes. All right. Let's start with uh with the first one to final. Did it just get updated? Let's see.

Let's see if this also matches the copyright notice. Yes. Yes. Yes. Yes. Let's see. This was opened by All right, let's also see if the I see some of the authors are also joined. If you would please ping your yes PRs, we will be happy to take it one

by one. >> Yeah, I will first uh just go by this list, right? And then uh there's like an order order here. Yeah. Cool. Cool. All right. move to review. And yes, yes. Ah, this is under the wrong uh category.

But that's fine. >> Oh yeah. Sorry, my bad. I was I was looking for the PR which I found it for last call and I see it is empty. I was like where did it go? [laughter] Sorry, my bad. >> No worries. No worries. Let's see if we if uh because I'm not sure if we move like the states from draft to Lasco. Is it actually >> No, that's not allowed. No, that's not allowed. It has to be in review. >> Yes, I see. And is it also allowed to add changes to uh from a draft to review?

>> Yeah, they can, but they cannot change their status to last call directly. >> All right. Okay. Let's see. This uh this should also be part of EP1, right? Yes. This process. Yeah. Yeah. Yeah. Yeah. Okay. See in this case

yeah maybe like a question like what if I misclick here I think the B also checks for like like a looks looks good to me uh comment right or not >> it should be >> okay. >> We haven't tried it before. So, it will be testing. [laughter] >> I I will not try this on my first office hour. [clears throat] Okay. Yes. Good. Okay.

All right, this one. Yeah, you uh you introduced this one at AC. >> Yeah, so far we haven't received any negative feedback. So, it seems like this is pretty much useful for people, but it would require two editors approval. >> I see. I see. Oh yeah, two. Okay, good. That's great. Yeah, I think for this office hour I will not read this thing through, but I also think this is copied from an uh Oh, wait. Yeah, it's this one.

>> Some of them are and some of them are from a different hackmd which was created by me four five years ago. So we are just trying to put everything together. >> I see. I see. This is some merch thing. >> Mhm. >> Um. Yeah. So this is like a very big one. I think I will review this uh either later if there's time or I will just move on to to review more things. Uh yeah, >> let's see.

>> Uh so that is an associated one. Uh ideally both of both the next PR should be for EIP1 one for EIP repo and one for ERC repo in order to get that contribute MD uh make visible. So you can skip all three. >> I see. Oh, so these have to be merged basically uh together >> together. Yes. >> I see. Okay. Maybe it's handy to note this. All right. I see. Yeah. Okay.

Yeah. And this one in ERC also has to be merged. Yeah. Okay. >> Yeah. We are maintaining two versions of EIP1. One in E EIP repo and one in ERC repo. So we have to make the PR for both >> I see. I see. Yeah. Yeah. Okay. Let's just put a note that this should first be merged. I will ref the text later. Yeah, >> sounds good.

>> And this is what it receives. Yes. Right. Okay. >> Of this. >> Yeah. Let's see the which button. >> Yeah. Yeah, that's right here. So here if you notice uh then I have changed the title from add EIP upgrade to this add EIP8133 but bot automatically changes it back to this one. And this is noticed for multiple PR. So I'm just trying to understand is this an expected behavior or what is missing here. Can we not update the title later on?

Right. This is changed here. Okay. Yeah. H >> I mean it only make changes on the title of the PR nothing in the file but I noticed this for multiple PR so thought of sharing this here in this meeting. >> Yes I see. I see. Um, and the original title was >> right and and then the question is why why should it remove this number maybe >> or why doesn't it remove the number?

>> When we propose a new proposal, we don't have a number. So, we just add the file name. But when it is allocated with a number, it is a good idea to update with the EIP number. >> Yeah, I I could see like there might of course be a problem because if people open like if people add an EIP and then they choose their own number then the bot should not uh take that number to add to the title. But if at some point the uh number is added um from the from the editor. So so we say okay this is uh this is the number you should pick. Then the bot also has to know that that's the actual um chosen number. Um instead of that users have actually picked this

number. >> So that might be a technical challenge here. Um >> right because the yeah the >> I just wanted to highlight this maybe feature/bug. I'm not sure of that. Um because I noticed it in some other but maybe we can take it async and provide you more context of that. uh we can perhaps move move forward. >> Yeah, I I think um we should ping uh ping Sam on this one >> because he [clears throat] will know uh I think the reason is like this technical reason that is hard to figure out if this number is official or not.

That might be >> it is maybe for the bot because it is I don't know. Yeah, that's a very good question. Yes. uh but uh if we look into the PR we will realize that the number was actually allocated and that's why trying to update it. Yes. >> Yes. I see. Yeah. I think for the bot it is very hard to figure out if it is uh allocated or not. Yeah. Yeah. I think Sam should uh take a look into this. Um and maybe also because I think Sam is the only maintainer of the bot currently. Is that correct?

>> As of now. Yes. >> Yes. Okay. Yeah. Yeah. That's that's maybe also would also be great to have more uh more people also um knowing a bit more about the bot because yeah otherwise Sam always has to do it and that's of course also not very nice I think. Yeah. Yeah. >> Thank you. Okay, let's see. >> Next are the list of proposed PRs which I believe should be closed because they're relevant. EIP are now moved to final and author has clearly stated that they do not have any intent of merging these PRs. So I don't see lot of value in keeping them open. It will only increase the open PR number.

>> Right? Okay. Let me first clean up my decks. This one I will do this later. Okay. >> Could you forward this one to uh to Sam like this this question for the uh >> I I will share that. >> Great. Okay. Thanks. Okay. And you mentioned that the office

of the EIP have no intention to uh to merge this. >> Yes. Uh so before moving this proposal to final, I shared with author and author said it it is already taken care of. So it's not required anymore. And that's why he uh gave the approval to the final uh PR to move this uh because this is the fixing of you discussion link and it is already incorporated by the team so it's no more required. >> Okay. >> And this this EIP is now in final status. So anyway, >> ah okay if it was merges we would also get like a conflict.

>> Yes. >> Right. I see. Okay. Let's let's just check what's then the current status of uh set. Okay. And then it goes ah yeah okay this already fixed. Uh yeah. So what's like a nice notice here? Uh I think this is already already only already fixed by >> Yeah. And the EIP is moved into final status.

>> Right. The only thing I can do is close this. Um, and then I think people who have the rights or Yeah, I also think like how do I close this? Should I ping someone who has the rights to do this? >> Um, maybe Sam and Matt as per my understanding. Um, but we are hoping to add more people who may have rights to close this one. >> Okay. Um, right.

Yeah, I would just use this to to signal that they should close. >> Yeah. So, okay. Type. Uh so all right we already mentioned this. >> Yeah so again this is the same EIP and it is finalized it can be closed.

>> I see I see. Um yeah but then then just like the question because um if an EIP [clears throat] is final but if there are typos and people want to fix this then how how does this work? This would require approval from >> author and yeah and here in this case author has mentioned that he is fine moving ahead. So um before he gave the permission to move the EIP to final status, he already viewed the PR and he doesn't seem it worthy. >> All right. Oh, I see it is also it's it's the space although it's now >> That's because there was a number that has been substituted instead of

description. And let's see. This is a different one. 7 9 8 9 10. >> Yes. But here Dano has mentioned that he has no intention to merge this. Yeah. Yeah. Yeah. Yeah, maybe for um because this will this now creates like this backlog basically of these PRs which should be closed.

>> Um I think yeah I think you can let's see because I think all these PRs have been just mentioned that these can be closed. If you can um ping people who have the rights to close these uh these things then um we can actually perform that action. >> Sounds good to me. I will share the list. >> Yeah. Cool. Cool. Cool. Okay. Let's see. Let's hit the next one. Great.

Hey, this is already closed. Yeah, nice. >> The author decided to close it, so it's fine. >> Yeah. The status changes when I add it in the agenda. So people take a look at it. So it's all right. >> Yes. Nice. Then people get a ping. >> Cool. Cool. Great. Great. >> That so that means we should have like a larger agenda, right? Then more people get a pin. >> Um I would want to like Sam to take care of it. So I just have listed it there. But we can perhaps move on to the next one. Well um moving on to the next category. We have drafts but first few are authored by me and but I see there

are some authors who may use this office hours. So maybe we can take a look at the ERCPR number 1429 by author Yash here. Uh he would be able to respond to any question for this particular ERC we have for review. >> Yes. And uh this offer is in this call. Did you receive? >> Yes. Yes. >> Cool. Cool. >> All right. Let's see. >> Yes. I'm I'm here if if there are any questions.

>> Cool. Cool. All right. Let's take a look. Oh, interesting.

It links to the EIP. I was a bit confused. I thought that is linking to itself. Interesting. Okay. Maybe I'm a bit confused here, but

this should this link to an EIP or to the to this current uh ERC. Uh so basically there's like this uh checker uh a GitHub checker which uh enforces that every time you mention any ERC for the first time it must link to the ERC itself. And the reason that the link is not leading anywhere right now is because uh this ERC is not yet merged. So when this ERC gets merged it will create that page the ERC page and then it's a link to that. >> I see. I see. But um I know just oh wait it's >> um if I may ask uh is the PR open for 8113 already? Maybe that should be

merged before this because anyway bot will not allow to merge this if the status is not advanced. Uh yeah so this uh PR is actually open uh itself that's why so like when this PR is merged uh then this page will be available because like when it is merged only then it will create the uh the website link for EIP 8113. >> Now I see the problem here. I think you are uh referring to your own EIP in the same EIP. I don't think that should be [clears throat] applicable here. you can just proceed by this EIP instead of writing a number and adding a reference link.

>> Mhm. Okay. Okay. I was just uh trying I was just trying to maintain the format. I was uh uh I saw it I think in Yati 4626 also something similar to this was happening. >> So I tried to maintain the format of that. >> Right. Right. And because I also think uh if you would then link to yourself this should be ERC right not. Uh no uh I think I think both the EIP and ERC repositories when they are being published uh get uh get go in this format in the EIP EIP name.Meng format I think.

>> Okay. Okay. >> Again like uh >> yes please please uh if you want to say something. Yeah, like basically I wrote this by referencing other closed PRs. Uh >> and you said like the other one is ESC 4636 >> uh for uh 4626. Yeah. Yeah. The I think >> Yeah, I think uh this one or some some PR I saw where it did refer to it. Yeah. >> Ah yeah, you can see here that it it look maybe correct me if I'm wrong, but this is before all the ESC's. No, that's that's now I'm mistaken.

>> It seems to be time of 2022. So, uh there is a posy, not the EIP anymore. But uh but on there, no not there. Uh because we are not maintaining ERC repo anymore. >> We are only maintaining EIP.ethereum.org, not ERC.ethereum.org. >> I see. I see. Okay. So, this uh this should be changed to um >> No, I think this is good. This is good because they have in text they have mentioned ERC but in a reference link EIP is mentioned so it should work out.

>> Okay but uh this f itself it's called ERC-8113 this is correct. Okay. I think here if we are using 4626 for

the first time we should add the link. >> Uh no I have I have used 4626 previously. Okay. I think in the first line or something. >> Yeah. And and and you think it is not dependent. Do you Oh, you already have mentioned it as dependent. Perfect. >> Required category. >> Yeah, I see. Yeah. But uh so this it's not backwards compatible, but it still requires it. Yeah, I guess that's correct. Yeah. Yeah. Yeah. Maybe. Yeah, that that's more like because I think this this one looks fine but this technically does not really require these ERC's, right?

So it is important that other EIPs those are mentioned in required section should have advanced status than this one in order for this to move forward. >> Right. Right. Right. All right. and force doesn't find those. Um, okay. Well, let's Right. I think this looks good.

>> Yeah, we can perhaps address more changes in the review status, but for draft seems like it has qualified. >> Yes, exactly. Exactly. Let's see what uh Okay, Sam has also looked at this. Great. Great. Is this your your first ERC? >> Uh yeah, this is my first. It feels great.

>> All right. Congratulations. >> Thanks. >> But we can perhaps start with PR1455 in ERC repository. And we are joined by Prem. >> Hey. >> Hello. >> Yeah, I'm interested in getting this one merged because a bunch of other ones depend on it. So, >> Makes sense.

>> Let's see. Let's see. Interesting. One of my friends is called tone. This might be a circular dependency actually. So I might need to take out the ERC 80048049

I realize because one has to be more advanced than the other. Right. >> That is true. Yes. >> So that's I'm going to have to pick that up. >> Uh it does not depend on these, right? You're just linking them. So I think >> well but does can you can you yeah it doesn't depend true even in the linking structure is it still a problem to be circular >> there would grow error linting error there would be >> but can you override it because you know it will work out fine once they're both merged okay fine so then it doesn't have to be >> yeah I didn't know that >> right but this should already be merged right 8048 Right.

>> No, neither of them emerged. >> Ah, okay. So, these depend on on this one. >> No, I I I was I didn't understand that that that the linting error can be uh overridden because it's just circular when it comes to the linking because there's an it throws an error if the other one is not merged and that's that's a circular problem. Means they can't be merged at the same exact instant. I mean uh that can be overridden but uh in that case editor might want to have you present in every meeting explaining this issue you know because they they would not want to override it if the block bot is flagging that we consider

it >> then I can just take it out I will just take it out I can always add it back in later >> I think that's a better approach >> yes I agree >> let me just check on I can stream 848. All right. Yeah, I see. Right. Um, but Pua, why don't I see like the block flagging this? >> Because this hasn't been merged yet like as a as a maybe you can scroll down. There should be some error uh by bot. Yeah, one pending review. There are some checks

which was not successful. Can you >> Ah, right. It's here. >> Yeah, >> but this is a proofer error. No. Uh, that has to be in the linting one. Yep. >> Yeah, it's it's it's here. The bot just didn't comment. Okay, I see. I see. >> Right. And then so 811 or 8048. So these PRs are also open for these PRC's. I see.

I see. I see. >> I just took out that line. Do you want me to push the PR or wait? Not push the PR. the the commit or wait. >> I mean, if you could do it, then at least one can be approved today. This one? >> Yeah, I'll do it right now. Yeah, I'll do it right now. >> Uh let's see. Puja for the RFC's do they need to be linked as well? >> Yeah. Yeah. Yeah.

>> Yeah. in copy pasting this is available in EIP template and we should link it >> right yes let's see that's >> ah yeah it's indeed that we can directly change it Go. All right. I just commented it for the EIP uh section. Oh, wait. I should actually comment it.

>> I think maybe did it. Yes, I want to delete and I want to comment the the bot did not flag this uh but yeah, right only the these URLs, >> right? >> Interesting. Okay, let's see here.

So yeah, I took it out. So the next I added a commit. >> Cool. >> Guess it'll take some time to run the checks again. And is it for 8119? >> Yes, 8119. I took out those two um >> references. >> Okay. Then it would be a good idea to look into the new commit instead of this >> Yes, good point. Good points. >> But it'll take some time to run the PRs that run the checks. So, uh yes, you won't see any new error. You won't see the errors.

In that case, maybe we can come back to it and >> yes, I think it's a good idea after it's run some more. >> And could you also like link these RFCs as I explained in this comment >> I don't I don't see that uh that com. So the RFC's they have to have to have a URL to the um well to the uh >> if you click on commits it's it's there. I can send here it is.

>> Yes, but you we still need to have a URL here for the RFC's. >> So here you have to have a link to the RFC 2119 and 8174. I mean that could be just copied and added here but again that is not a blocker that it cannot move forward. It would be a good idea to have it added the link added. >> Let me just lick the comments so you can see it. Okay. Let me check the remainder of the file.

Yeah. Maybe just like a general question like so this is solidity code. It's not Viper code. So I'm not really sure. Is this that correct? Um I just think that uh the idea of the um the key and parameter uh is a universal to viper but I haven't studied it much so it's true I should be more specific in my study of Viper to see if it's a one to one match or requires some slight variation. >> Yeah I think if the if the data structures of this mapping is the same as in Viper like they do the same thing at high level then it is correct.

Okay. Okay. Cool. Okay. Um, yes. Let's uh let's wait for this spot and then I think it is fine. >> What do you think? >> Yeah. I mean we can come back to that one and we have other peers we can look in between. Yes. Uh let's see. Next one is 1259 I think.

>> Um 1429 is done. 1463. Have Have we done 1463? We can look into that one. Minimal agent registry. >> All right. This one. >> Yep. >> Yeah. I can just mention about it. It's that um we have 8004 which is the agent registry for Ethereum. It's an Ethereum Foundation project. Um, but what I noticed and and thought about was that they are promoting the idea of it being a singleton. So, one registry per chain, but I uh had the idea that probably projects will some projects will want to make their own registries. And also some projects might want to use a more

lightweight solution. And so this solution uses ERC6909 which is much more gas efficient than 721 and also is completely onchain. So it it's it's a bit of an opinionated u agent registry and it allows for teams to register to deploy their own registries. That's that that's the motivation. Yeah, maybe just for stale you might

want to uh also st these kind of parameters. Let's see. Maybe I'm missing something.

But where is this? Uh, >> sorry. I think that I wasn't clear writing that clear as it could be. It just means that when you the 8119, uh, the really the whole point of 8119 is just to say that we should have this space. So it should be service colon space the parameter versus service colon the parameter without a space >> right >> or the key. So that's that's a standardization. It's a little detailed but I think it it adds to the uh the standardization of this type of service uh parameter parameterized keys. I see that but I could make that more clear.

It's not very clear. [clears throat] Yeah. Yeah. I think I think think yeah this this might be a bit but it's uh yeah let me actually write these notes down because otherwise I forget to do this >> and also this one is blocked by a bunch of >> Yes. Yes. Of course. But it's only It's m dash. Where's the dash?

I >> No, no. Thank you so much. Right. Let's see. Let's see. All right. In the stereo actually using the uh how do you say it? The cursive uh stereo metallic. Yeah. Yeah, I keep learning new things every

day. So, this is like the new KYC, know your agent. >> Yeah, I like this term. I don't know if it's necessary or not, but it came from the A16Z 2026 year. What needs to be built and they said KY, know your agent. >> Yeah. Yeah, I like it. I like it. Cool. Cool. Cool. Let's see. The copright is not complete, it seems. >> And let's see because there were like a lot. I think I've seen all these 730.

All right. Yes. And that's the other one. 849. Mhm. this one. >> Now, I have a little debate about optional um features and whether they need to be part of the required statement. I think some uh reviewers said that it should be part of the required statement, but I I don't want to overwhelm readers by a lot of requirements. So, I think that the optional one should not be in the um in the required statement. Uh do you have any opinion on that?

>> Let's see. Um the optional >> so 8049 is actually optional. >> Yes. Yes. Yes. 8048 is required. Yes. Yes. Yes. Right. I think >> yeah it depends a bit on um I mean when we are looking into it could we also improve it with the language we use if we should there um are we making it mandatory

for 8049 on must with with master >> um well I tried to make differentiation between mandatory aspects and the suggested objects aspects. Um 80049 I think is is quite useful and and and good but it's I wouldn't say it's necessary because it doesn't uh have specifically to do with the specific agent itself. It's just about the contract the information about the contract. So I think it's correct and uh optional and you know that kind of thing. Yeah, I think that would be an important criteria to decide whether we would want to keep it in the required section or not.

>> Maybe you mean optional totally optional is not in the required section, but should is in the required section. >> I I mean I'm imagining that, but we can definitely double check it with other editors to figure it out. Yes. >> Great. That's a good I I like having some type of um some type of guide line there and that makes sense to me as well. >> Yeah. Yeah, it's it's also maybe a bit about because sometimes these RFC words are not completely uh intuitive, >> Um I think for optional Yeah, I think it would also somewhat depend and this would maybe like the debate like how because you are right. You don't want to

overwhelm your readers with like a very large required section that people think wow great now we have to to to include like 100 parameters for this thing. Well, actually that's not not the case. Um, yeah. Interesting. Interesting. Yeah, I would intuitively say, yeah, I don't know. I have to think about this a bit. Yeah, I think but because like the size of this ERC, it's not super big. So, for the readability, it would not change a lot, I think.

Interesting. Interesting. Okay, I think this uh this with a few minor comments, this one uh also looks looks great. Let me see. Did I No, I didn't submit it yet. All right. Oh, wait. Then this comment is not correct. Let's change it. two okay

let's see and then there was one more right then >> yeah we don't have much time but pre if you have any other question for any other peers here listed here we can perhaps quickly take a look into that. >> Uh no, my goal would be to um move from the dependency tree from the bottom up obviously. >> So from the bottom I have 8 uh 119 and we did that. I appreciate that. Then there's 80488049. Those are um next on the dependency tree. So uh yes, I appreciate that. Uh however moving those forward can be done.

>> Yeah, let's see. I think yeah this is not blocking. I think we can merge this one. Yeah, it was it is not is it a requirement to have this RFC's linked or not? >> I mean we can do it in draft uh sorry review status as well. Um okay, >> but that's not a blocker for merging it in the draft status. Okay. Okay. I think uh we should merge this one then. Do you would you agree?

>> Yeah. It seems less dependent proposal. So >> it's the bottom of the tree. Dependency tree. >> The root of the tree. >> All right. Let's merge it. >> Yeah. I will uh I will also note that um because like editing these ERC's it's different than reviewing the the ERC's or yeah it depends on how you would think about it but editing is more about like okay we check the style we think if everything is consistent um and this this is like completely at a different level of how I would normally uh well

I'm not going to say review ERC's but like check these ERC's because uh then I would also really want to get in depth to the topic itself. So that is something which I have not done here uh and that is different from what I would normally do but I will also go into your other ERC's and to to take a look there uh and you might also get some feedback on if I if I notice some things about like the content so not not about the sale but about the like content that uh >> yeah they're very connected these things. Yes.

>> Yes. Yes. Cool. Cool. All right, that's great and >> thanks so much. >> Yeah, it's good to see like we are solving. I think uh we have couple of minutes left which would not be good enough to look into any of the other PRs right now but if I may request I have also put on like 1 2 3 four PRs for new EIPs whenever get a chance asynchronously also possible please uh leave some feedback and we will take it from there.

Or if there is any simple one like upgrade nomin feature if it can be merged which does not seem to be dependent on anything that would be really nice to have. >> Yeah. Cool. Cool. All right. We'll stop sharing my screen. >> Thank you all. Have a good day. Oh, >> okay. Thank you, babe. Bye. Bye. Right. Yes.

>> Yeah. It's like not something which we can leave in like a minute. So >> that's perfectly all right. Thank you everyone for joining us here today. Next uh meeting is going to happen on February 3rd with editor Sam Wilson. We are going to review some more of the EIP and ERC GitHub pull request. So if you have any, please drop them to the agenda. >> [music] >> water.

Heat. [music] Heat. Heat >> up [music] here.