EIP Editing Office Hour #87 (EIP + ERC)

Transcript

Welcome to EIP editing office hour meeting number 87. This meeting is going to cover both EIP and ERC repositories pull requests. We are joined by editor Sam Wilson and on agenda we have PRs for final last call review a few miscellaneous and some of the draft proposals. Um Sam u maybe we can get started with the final proposal. >> Sure. >> I think this first one is just a force merge. It was already approved but for some reason it could not get merged.

>> Ah why is that? Oh yeah. Actually I should probably double check why I uh requested changes. Yeah. Okay. Uh let's see if that's there. Yes. Perfect. Oh, hey Carson. And in theory, this should merge on its

own now. So, I'll leave that open and we can come back to it. >> All right. So we can we can move forward sequentially unless there is an author requesting for uh review and have questions. >> Yeah, if anybody's here for anything in particular, just uh either unmute and say so or comment in the chat. Okay. Um what are we looking at today? Verable royalties. Okay. [sighs and gasps] So, two weeks from today is the 17th.

[sighs and gasps] Cool. Okay. So [sighs and gasps] [sighs] uh stand on royalty distribution for referable NFTTS supporting multiple recipients reference. Okay. standalone distribution for referable nonfundable tokens and royalty distribution of multiple recipients at the primary level and okay that's good

fine and 65. Okay. Okay. The recovered E7 one of has configurator ro.

Okay. Oh, they moved that button. I guess that's nice. Um, okay. Oh, good. Yeah, they did say that that

was necessary. So, okay, I'm just going to assume that they know how to implement their own standard and Yeah, that seems fine. Okay. >> Yeah, I was just imagining that uh the reason why they had later date of merge like last call ended because uh this last call status change PR is also including lot of other changes.

>> Oh yeah. Yeah, it happens. Yeah. Okay, cool. So, [gasps] I'm okay with that. Um, nice. Did this one merge? It did. Perfect. To review [sighs and gasps] 8019.

So what stated is this one? Minimal wallet manage auto login for sign in with Ethereum. All right. Um It finds one local allowed list for

automatic signing of ERC 4361 messages when simple match rules succeed. Okay. Defense of wallet local allow list for automatic signing of ERC 4361 4361 messages when simple deterministic match will succeed. Policies are created and managed only by the wallet/ user.

Okay. Um, all right. Users repeatedly sign identical sign in with Ethereum messages for trusted apps. Um, so 361

with a hyphen. That is definitely true within the Ethereum ecosystem. >> Yeah, exactly. So get prompted by the walls if they trust a certain app and they initially connect to it. This flow can also authorize auto login if applicable.

Yeah, I mean that that sounds like a great idea. Uh the term wallet refers to wallet user interface regardless of whether mobile web or browser extensions. Um Oh, yet another bug. I' I'd love that.

Okay, what if we do this one? Nope. They break this one all the time. So four um back ticks is how you're supposed to escape three back ticks inside your code fence. And just half the time it doesn't work. It's so frustrating. Um given a price for message the wallet may auto sign if policy domain muri starts with pol uri prefix. Okay. So I can actually give a technical comment on this.

I think that's what it's called. Okay. And then cross our network access. No, that's not it. That's not it. s under if anyone knows the name of the thing I'm looking for, let me know. It's um the rules for determining whether a

cookie from a parent domain are allowed in a subdomain. I feel like that might be useful for this standard. Um okay. Okay. Auto resource is not empty set is jet otherwise no resource allowed at all is non zero. The current time is less than okay >> I just put it into AI and the response is inherited.

I don't know if that is the right one here. Let's find out. Just inherited. >> Yeah. >> Yeah. I'll come back to find this at some point. Anyways, um expires that Unix time stamp. Okay. Oh, there signed with remain must be forced by wallet. Okay. Created, listed,

updated, and deleted only within the wallet UI will set how much control they want to give to users over this magic each wallet include a default list of policies for popular apps. So, let's go over here. Um,

Just see if they cover that in there. Trash now here. Yeah. Okay. And um so signing with Ethereum 4361 Do they

okay they don't web application communication should use HTTPS? over here we can say What else do we have here?

Sam, there is a comment by Luke for this. Unfortunately, that entire website is just useless right now. The only one that actually works is eip.ethereum.org. okay. So, there's something else I wanted to say. I don't remember what it is. That's okay.

But otherwise I think this is pretty decent reference implementation that's fine for logic by default. All right.

>> I have a follow-up question here, Sam. Uh so I'm I'm looking at Luke's review comment saying that all of the 4361 mentioned is with prefix EIP and the link is dead. I can understand if we move it to EIPs.ethereum.org the link can be working but since 4361 is an ERC would it be appropriate to uh make the prefix as ERC rather than EIP? >> Um so the ERC's.ethereum.org or website has never worked um because of that reason. Uh if you change them to ERC prefixed then the EIP's website doesn't work. Um so we've kind of just chosen to support EIP.ethereum.org as the

canonical website and then yeah ERC's.thereum.org just doesn't work. >> Yeah. So my question was like even if we are giving the link to the EIP's website uh what is the most appropriate way to refer to an EIP and ERC uh like um as a number? So for 4361 should we mention it as EIP 4361 or mention >> always EIP? Yeah. >> Perfect. >> Yeah. So the um the build system will rename all of the files to EIP- um >> okay that makes sense. No, not really.

But that's how it works. >> It makes sense to me why it is there. >> Okay. Uh 1965. >> I guess this is uh already reviewed by Gachender and requested for force merge. >> Yeah. How do I hide my minimize comments? Okay. since it yep, that makes sense.

Choose two arguments that represents. Yeah, that's fine by me. 2539.

Where's that? You see a discount cap? Yep. Fine by me. Contribution guidelines. So here I have tried to address all the comments from you and Yham and um yeah I

see already we have 80 plus conversations. So I was wondering if we can merge it and then yeah about the style guide. Yes, I have a recommendation that I have added there. So it's already there in P1. So we can maybe use it. >> Put it there. Yeah. So in the uh related PR which is there to add this contribution MD2 EIP1, I have already uh included the style guide uh improvements there. But we will revisit it. Yeah.

>> Okay. Uh yeah. So I have pinged Yam as well. Uh so whatever recommendation he did I have already incorporated in the file. Assuming this is like first iteration, we could see more in coming days as we share this file with community. This is pretty good. Yeah, thanks for

this. This is definitely an improvement over not having one. >> Yeah, I really hope that this will help us get better PRs. People have some references now. Yeah, I actually just learned about from um Dan on the uh steel team that uh you can add context for AI models uh in like claude.md files or agent.mmd files. And I think we should probably do that for here since so many people write EIPs with um AI.

Yeah. >> Um >> I have no idea how to do it but uh yeah >> definitely something we can include. So this is just the primary version of it and as I mentioned we should see more improvements. We'll share it with the community and what other challenges they are facing based on that we'll keep updating this file. So there are very few typo on um spacing errors shown. Other than that, uh the RFC um style guide changes are added Okay,

>> I can see one more error or conflict that it will that it will bring. Uh, initially the file was named as contribute.m MD when we created the PR4 EIP1 edits. But now the file has been renamed as per your suggestion to contribution MD. No, so we have to update this one as well. >> Yeah, that makes sense. >> Um, should it be contribution or contribute? Okay, whatever you prefer.

It's fine either way. >> I think it's um supposed to be contributing MD. >> Yeah. Right. Yeah. And all uh like uh are in caps similar to readme. So [clears throat] yeah, I have updated the file like that. Yes. >> Okay. Yeah. Okay. John is pursued at a later date.

Yep. And then the future supported the language. Yeah, I'm okay with this. Um, >> Since we have to do it on both repos, so

the other one is for ERC repo. >> Makes sense. Yeah. Okay. Perfect.

All right. And final living to draft stage conditions. >> So this is to address the bug that was highlighted in the issue and I have added the end result in the comment below. Uh the one change that it brings is like at present eip.ethereum.org does not show any final status but I had to add that in order to like be make it consistent and in order to use that. So >> yeah that makes sense. >> Yeah final and living will have now status is mentioned there.

So the citation error uh will not have the draft as the status for final and living. Now it will have the appropriate um status. Okay. So, um, so Does that make sense? I think that makes

sense. So like if it's done, so in final or living, we don't need to put uh anything in the square brackets. >> Um yeah, if we want to do that, yes, that is possible. Very much possible. We can have like I I used a shortcut here but instead we can put the or else if condition and we can do it. Yes. >> Yeah, I think that makes sense. Draft stage. Yeah. Because it doesn't make sense to put living or final into is draft stage.

>> Uh so if you can take a look at the output there. So I had Yes. Um >> yeah. Yeah. Exactly. So living and final shouldn't have a tag. >> Okay. Okay. Yeah, it is doable. I will update it. >> Cool. Thank you. >> Retail renaming by bot. What are we looking at here? Green nomenclature. >> So again, this is anformational EIP. Um I have intentionally removed the link of the upcoming two EIPs because uh if we keep on adding links for upcoming proposals this can never reach to a final status and the intent here is to keep it uh final not living

but yeah open to suggestions here and uh this does not uh like recommends anything for future. This is uh just what has been done in the past and uh just suggesting that if people would like to use there is no uh enforcement that people should use it or people must use it. I should have added related. Sorry. Yes,

that's no worries. >> Maybe I have to update it for all of them. Yes. >> Yeah. Yeah. So here I am assuming because these are

permitted links we can use that because we didn't have any meta file meta for those. >> Yeah that's fine. I think um I think Tim went and made some like one had a bunch of them. Yeah. >> Yeah. I have taken the links from that particular file only. Thanks for review Sam. I will update the

links that you have highlighted and obviously we'll wait for other editors to take a look at it. >> Cool. Yeah. Yeah. This should be a section like the renderer [clears throat] should do this and it can. It's just Okay. And finally living to drive. Okay. There's that date >> that's merged. Clarify.

>> There are a couple of bugs or like we were not sure. So here in this case um this PR was for author change and this EIP has multiple author but the bot specifically ping only one author so I wasn't sure like why was it why not all authors were pinged because anyone could have approved it right anyway this is merge just wanted to figure out >> it said there's only one GitHub username so it can only ping the one a with a username >> okay got it >> so it's it's normal behavior I was just trying to understand if this is right or wrong. Similarly, here it says that two authors need to approve. I don't know why because I see the one author has already approved it.

>> There's one more reviewer from that. My understanding was either it should be waiting for editors review if needed. Otherwise, just one author should be good enough. >> So, it has not had a an approve. It's only had a comment. So, this this isn't an approval. >> Okay, got it. Maybe I can mention to the author. Yes, that makes sense. Cool.

>> Um, that's on status. Okay. What's going on in here? >> You can maybe take it offline, but I wanted to bring it here uh because I I feel like uh uh this particular proposal requires more attention. Uh I don't see the right usage of word status and stages because this is to uh write about network upgrade stages and EIP statuses are something different. So we should be very particular about you using it wherever appropriate. I okay this is I think you could

yeah >> because in the motivation section it already uh clarifies that this is about network upgrade stages so we should not mix status and stages is my thinking in this direction and that's why wherever I find it like we should not keep status I have replaced it with stages although it is not called but because it is a process related so I thought of sharing with editor as well >> yeah I'll take a look at this one uh I actually like I really appreciate that Tim went through and wrote this it it has made my life so much easier >> yeah right >> yes and I think getting stages and statuses clear will will help a lot too um so keep that one open um there. So 7932

requires header. >> Oh, I bet I bet this person. >> Okay, cool. Yeah, I think that was the thing. Yep. So, we can perhaps remove this PR and delete it because it seems like not very useful one. >> Okay, hang on. So requires header 80052. Okay. So the actual pull request might be useful but the comment from that person was definitely not.

>> Um so let's see 7932. Do they actually mention 7932 in the body? They do. The necessary parameters and structure for saturation are provided. Okay. This is final. It's draft. So this just requires an author. So yeah, so this is fine. If an author wants to approve this, they can. But this person needs to go away.

I love DevOps for making this bot. It makes me so happy because it doesn't just ban them on this repository. It's every single Ethereum repository. >> Yeah, because this particular individual also have like PRs and issues in bot repository. So, it's good that it is banned from everywhere. [clears throat] >> so I think the next one suspicious user list is for the same one. So if this individual is bought, we addressed all of them.

>> Okay. Yeah. Yeah. >> So do we need to close all of these things? Uh how do we address? >> Yeah. Um but I will still open them because oftent times there are more bots in the comments. No. Okay. This is this is another poll request. What are you doing in here? Ah, of course. >> So that is added in almost every pier that the individual has created. So I found it is easier to go by username and then list all of them. So you can close it.

>> Yep. All right, then. Those are all the same. Okay, that was a Oh, there's a lot of them. Can I delete them from here? >> No, I can't delete them from here. Yay. This is a prolific bot. They really

wanted to get some attention. >> Very active one. Okay. Is that all of them? No. This is an issue. Go away. It's typo.

Yeah, I don't think this really matters. They're just adding the links. It's really not necessary. [gasps] Yeah, this one can be closed.

Uh, written name. It's this person again. So this one is already taken care by Nixo's new PR. So >> all right. All right. [sighs] >> We already looked into it. Sorry about that.

>> No worries. uh you may want to check it's fellowship of ethereum magician link there are some questions and I try to respond to all those question so basically this is for documentation of these upgrades now there are question whether we should have this kind of meta living and things like that so >> that there was a meta for the first three BPOS's >> it was not so I have created All three. >> Okay, this one's just defining.

>> Yes, it defines that in future these will be the parameter changes. But what are the changes and why those are there is not mentioned anywhere. >> Yeah. So fix the links. Yes, I will. Yes. Yeah. So just [snorts] uh fix links

That makes sense. I have added this rational in BPO3 that we are following a formula and we are using this number. Maybe I can have some text here added in the first one as well. So it give clarity in the very first one. Wait, a malicious webp in 11122. Interesting. There's a malicious webp.

Oh, yeah. I saw I saw that they were adding it. I assumed it would just be an ad of some kind, but it's actually like a gross. an onchain mic for token registries. We are joined by the author in case there is any question.

Yeah, just a few really minor things. just those two and then we should be good to merge that um contract level onchain metadata. This is fine. It's just uh

Okay, I think we did that one already. Minimal agent registry. Yeah. Okay. So, Yam's um comments need

to be addressed before we can merge that one. 8127 human readable token identifiers. Uh there's not much time I know, but I

just made the change on 8122. >> So if we uh can merge it, that would be great. >> Yeah. What was the uh or request number for that one? >> Uh that's it. >> Oh, this is the one. No, >> it's no minimal token registry. Uh Wait one second. Minimal agent registry. >> Yes. Yeah. Sorry. Agent. Okay. Perfect. I fixed the uh copyright

and I deleted the confusing statement. Let's say deleted. Oh, sorry. It's um 1463. >> Yeah, this is the right one. It just wasn't showing up in the uh poll request tab for some reason. Um, see if it's there now. Of course not. yeah, that works.

>> Cool. I think we can wrap that up here. Thanks everybody for coming out. We'll see you all at least somebody will see you next week. Maybe me. Take care. >> Thank you, Sam. Thank you everyone for joining us here today.