EIP Editing Office Hour #83 (EIP + ERC)

Transcript

Loading developers...

[music] Heat. Heat. [music] >> [music] >> Welcome to EIP editing office hour. This

EIP Editing Office Hour Introduction: Meeting 83, Agenda Overview

is meeting number 83 and this is added as agenda item 1856 on Ethereum/PM repo. On agenda we have got a few review few miscellaneous and draft proposals for review and we are joined by Sam Wilson. Thank you Sam. And we can perhaps get started starting with the first one which is waiting for final. I believe it is already set. Something is not working there. Something is broken there. >> All right let's take a look.

What hasn't been accept? Oh, okay. 7594 is not stable enough for a status of final. So, it's easy enough to fix 759. So this is in last call. That makes sense. Is there an equivalent 7594 move to final?

All right. Yeah. So this needs to be dealt with first. I see Andress as a author co-author for this proposal. So I'm just curious to hear that uh since this proposal is made by him uh from last call to final could

we not assume that everything which were there in earlier PRs either have been taken care of in this PR or aren't required anymore. >> Uh you mean for for this one here? >> Yes. And anyway, this seems to be in the draft status. So perhaps it was never ready or it could have been discarded. >> Uh yours, I guess. Yeah. Sorry about that.

>> Yeah. So yeah, this one's mine. It's just moving it to final, but this PR here is open. Um and people are still um discussing it. So we can't really move to final until this one gets taken care of. >> Okay. So uh this is a Fusaka proposal and the proposal is already finalized. >> So I I was just trying to understand would it be safe to assume the final uh >> Oh sorry 7594 has gone to final. Okay. >> Yeah.

>> Uh it doesn't look like it. >> Okay. What am I missing? Got it. So what about the 7918 proposal? I guess that is for [snorts] Okay, got it. Sorry, I understand the confusion here. Yeah, thank you for explaining that. >> Oh, no worries. Yeah, it's just there's an open question about this this proposal and because we haven't sorted out that open question yet, we can't really go to final. So, uh I guess I'll just ping people on this one. Um, who do I need to ping?

We need to ping Okay. So hopefully somebody will look at

that. Um >> yes. >> So next we have got couple Okay. You want to add a comment here? Okay. Next we have got couple of review status. I believe you reviewed this proposal already but uh the author has come back with the improvement suggestion. may want to take another look. Yes, sure. Good.

Yeah. So, that seems good. And let's just give it a quick read through. Yep, this seems fine.

Off to review you go. And then 7 8 93. [sighs] Um, good. Okay, [sighs]

let's see how this looks. So, most of that's all removed. Good. And then Okay. So, it's this one. Yeah, this is all looking much better.

Okay. Um, functions. Yep. Phone query cap measure in the current state. Yep. Okay. Yeah, that's so much better. These aren't like features anymore. They're like strict requirements, which is exactly what I had asked. So good. Um, everything's moved into rationale. Okay. So where is that

uh view file? This is 7893. Okay. So they've removed everything. So for now I will just go here. Okay. Yeah, this is too much of a

change. I don't feel comfortable just making it. Um, All right, 7893. So, moving on to

Discussion on ERC 1422: Draft Status and Conflict Resolution

miscellaneous stuff. New CFG diagrams. Oh, sorry >> Sam. Uh, we are joined by an author and if we can perhaps uh take at this PR, this seems to be very interesting. It is on ERC repository and the number is 1422. It's not there on the agenda. Um but the interesting case here is this ERC is already merged as a draft on eip.ethereum.org or yet we can see this is a draft proposal here seems there is some conflict but I don't know the author is with us in case there is any question >> yeah I I think it was it's already been in draft but when we made a PR to add a few extra changes um they were suggested

by you Sam last time it's somehow like combined it with the original PR I'm not sure how >> okay so it is there. Um, what's different between the two? >> just like the description, a couple other things. Yeah. >> Yeah. So, it looks like you'll just need to resolve the conflicts and then this should be fine. Um, >> okay. >> Yeah. Basically, just pick out of all of these options which ones are the correct and then mark. Yeah. Um, yeah, I think it's probably just that you didn't update your branch before you

made the pull request like locally. Um, that would be my guess, but um, >> shouldn't Yeah. Yeah. I mean, yeah, it's not a big conflict, but will it automatically merge it now since it's in draft mode, or do we still need to do it through review? Uh, no. It should automatically merge it as long as there's no um errors from the linting tools. >> Okay, cool. Sounds good. Thank you. >> No worries. >> Thank you. We can move on to the next. It seems like you have already resolved the first one. So, we can go for the CFG diagram.

>> Sure. This person has approved too many poll requests. What is that? >> [snorts] >> There it is. And This thing is great as long as it's

still working. There we go. You are now blocked. Um, okay. >> Is that [clears throat] a bot or is that a Getter feature? That is a bot. >> Okay. >> Yeah. The um DevOps team was getting swamped by uh block requests. So um they built a tool for us to just block anybody we want. >> Amazing. >> Okay. Yeah. Yeah. This is just an asset change without that makes sense. And then 7979 Greg is listed as an author, so I don't

even need to look at this. Go for it. Remove deprecated Google+ social link. Is there really a really >> I was surprised too. Like do we have that? >> Oh, that's funny. That's really funny. Um, okay. So, yeah. Go for it. And then um do I still have that? Uh >> would it require two reviewers approval here or just do it?

>> Probably, but I I'll probably just force merge it if I have to. >> Okay. Yeah, it's not a big deal. >> Yeah. Okay, good. I don't have that on my copy, so I just need to recreate this on the ERC's website. I am so excited to not have to do that anymore. Um, that was includes social. I mean, it really doesn't [clears throat] doesn't matter that much because I don't think we have it set in our config, but whatever.

Repository Management and EIP Contributions

>> But do we really need to maintain two copies in two different repositories? Like we don't have EIP1 in our IP. Could we not just have it in EIP repository? >> We could. Um, it's uh it's kind of like a side effect of how uh Panda Pip and and like client did the repository split. Yeah, I really wish it can be solved because >> until yesterday I didn't know that I have to make the PRs at both the repos. I just edited one.

>> I didn't know until a little while ago myself. I just Yeah. Um, >> another topic to educate people who want to contribute to EAP1. >> Well, hopefully we won't have that problem anymore. Um I've gotten quite a bit further on the um >> the new website >> the new website. So >> yeah. Um okay. So let's prove I will just force merge this because I have too much power in this repository. There we go.

Um >> we need that power Sam [laughter] >> otherwise we would have like swamp with the open peers. Yeah. How difficult is this pull request to review? Okay. Here's the assign prefix here. See EIP. page title XML escape.

So that seems fine. Okay, then that's just used there. Yeah, that makes sense. Okay. Page title XML escape. Yeah, that's the same. I mean, yeah, that looks like it's good.

Excuse me. Um, I would prefer to get somebody else also looking at this one. So, I will go leave a note. Referable NFT royalties.

Discussion on NFT Royalties and ERC Proposals

I love NFT royalty pull requests. >> Yeah, I mean for this meeting we have got most of ERC's and some of them are very interesting. Okay. So 5521 is that what a referable NFT? Yeah.

65 the

So, we have royalty info. Is that used somewhere? It's used in reference royalty. Reference royalty is used in an event. So, that's good. Yep. Good search base configuration. Okay. So you need 712. Is that in your requires? It is not. So we can add that [gasps]

71. Yeah. Okay.

Yeah, that's good. Super one. Okay, >> I guess our template also suggests that it should be CC0, right? >> I believe so. Um, >> no it just says DC0 at the end. So >> yeah that >> so is it something like I know we have been in this loop for so many times. Is

it something that we want to make in a required requirement? >> It's at least something we should add to the tool. Um, >> yeah. >> Yeah, I think I have a Yeah, I have a an issue in here. I just haven't been able to work on it yet. >> Is it in EIPW? >> Yep.

>> Okay. I will see if I can share it another community and anyone interested to pick it up. Contract level on metadata. It's failing in here.

Oh, interesting. Yeah. So that's an easy fix. The other one less so. >> Yeah, I guess these uh this and the next one is um requested by ENS team. They are like really working hard on it trying to support and get this thing done. Okay. CSU defines a standard for storing

contra level metadata on chain. It extends 7572s. Okay. So presumably you need clients 7572. Uh contracts may optionally use 8042. Um, so then we can go and edit this.

and primarily focus on offchain metadata sources since concept onchain storage contable. Okay. Awesome. Okay, this seriously is an option. Maybe

that was just to store country level metadata on chain. Um, yeah, I guess. Uh contract this. Yeah. Okay. updated. Yeah.

Uh this is the key iss flexibility for storing any type of data. Uh, optical key program should use the tune format. Interesting. >> I believe they want to like push these two proposals together. Um, is there some way that I can link to

this that is [gasps] the specification? Okay. What license is this? This is MIT. so do that and then so This name is standard.

So what is that ERC hooks? Is there a file called ERC hooks that you're adding? No. Um yeah, it looks like they are working on the third proposal which would be ERC hooks. But in that >> Oh, >> I see.

>> But in that case, it should be in the uh required section, right? like maybe we can take a look if they have already mentioned anything over there. >> They didn't have a required section. >> Okay. Yeah. Yeah. >> Then there definitely mean definitely this file is missing which we need. Yes. Yeah. Um, let's just do there. Uh,

That's fine. It's fine. >> Um, one thing I note here Sam that in

backward compatibility section they have mentioned a bunch of ERC's number there without the link. I mean as I understand only one proposal perhaps um 8004 is not ready yet but is this an acceptable way of mentioning I mean I don't see any dependency here maybe just a piece of information but how do you see it >> where where sorry >> uh backward compatibility so it says that fully compatible with the are we looking at the same >> oh that's yeah that's pretty vague um just give me a minute so we are looking at 8048 it.

>> Uh we are looking at 80049. >> Ah sorry my bad. So in 80048 I think it is mentioned there. Uh could you maybe take a look? >> Yeah of course. Where'd it go?

>> Yeah. So, >> yeah, >> they should all be links. Yeah. >> Yeah, that's what I was wondering. But, but here's the problem. Like, if they if we enforce them to link, they don't know when 8004 is going to be matured and like finalized. >> Yeah. the preference would be not link but just wanted to know if this is an allowed format. >> Um so the first time you mentioned it you have to link to it and I think that's reasonable. >> Um so I think what would be let's see yeah they have a bunch of those. So we'll say here um >> now it makes sense that they should mention it because if people want to

know more they are not adding the EIP here just the reference link. >> Yeah. I think this is a good piece of advice. >> Yeah. Yeah. So unless they are ready with 8004 perhaps they can remove it. >> Exactly. Yeah. Um Oh, was that this one? I think that's

this one. >> Yeah. Yeah. >> Okay. Yeah. So we are at now zero knowledge token. I guess you already have done it. No 804. Oh >> yeah. I haven't done 8048 yet. I just did the one comment. >> Uh wait. Is this just a duplicate of the other one? >> No. No. You just added the comment to 8048. So that's why it seems familiar to you. >> Wait. Yeah. um contract level onchain metadata onchain metadata for token registries. Okay.

Discussion on Zero Knowledge Token and EIP Linking Issues

>> Yeah. Yeah. That's why they want to move these two proposals together. I guess it is required for ENS or some >> Okay. Yeah, that makes sense. I guess they do. Or key value store.

Yeah, it's fine. [sighs] Okay. 8048.

Was that Did I read that right? No. Diamond storage is 8042. I mean, that's fine.

Conclusion and Wrap-up of the Meeting

Cool. I think I'll wrap it up here for today. Um, I think we got through a decent number of them. Um, thanks for organizing, Puja. I appreciate it. >> Thank you, Sam, for joining us here today. See everyone in next week or next call. >> See you. >> Bye-bye. >> What's up?

>> Thank >> Heat up here.

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