EIP Editing Office Hour #13
EIP Editing Office Hours · 21 Mar 2023 · 58:21
Meeting 13 of the EIP Editing Office Hour, held on 21 March 2023. EIP editors and proposal authors work through open pull requests and questions about the Ethereum standards process. This meeting covers EIP pull requests heading to Final, Last Call, Review and Draft along with proposals coming back from Stagnant and miscellaneous pull requests.
Topics
From EIP Editing Office Hours, hosted by ECH Institute.
Transcript
welcome to EIP editing office hour meeting 13 I have shared agenda and chat we have a few pull requests added here for a discussion we are joined by a couple of authors who would like to discuss their proposal some of them are new to maybe understand the process so um maybe Sam if you can pull up your screen and we can start looking into the proposal we can start with the first PR number 6506. 6506. I shared the link in the chat yes so I am here mostly to kind of find
out what the process is about getting this included in to see what the next steps are I have made um all of the recommended changes that the editors requested formatting wise and structure um and I added some other stuff um as well in the comments and so I'm just trying to figure out what the process looks like yeah so it's just um waiting for somebody to look at it so probably be yeah no problem so one of the comments that I got when I submitted the initial pull request was about reference implementation I built a proof of concept made a proof of concept repo that implements this standard um it's not included in this markdown file because they said it shouldn't be so
it's attached in the comment history of the pull request as well okay yeah um if it's a reasonably sized you can put it in the assets directory it is um not I guess so so the actual the actual like um interface the actual like defined interface is included in this style but I have an actual like solidity implementation with like solidity files and test cases and scripts and stuff that's in its own repo because those files are big okay yeah yeah because like we we do encourage you to put a reference implementation in The Proposal if you can um but if it like if it's huge then yeah it's best yeah elsewhere if you if you scroll down later you'll see the defined
interface with the functions yeah absolutely there and I Define all that um what that looks like in terms of like an actual solidity implementation that like does all of the things that this EIP describes that's in its own repository okay yeah that works yeah so um these events here these are like code Snippets right so they should be in back ticks as well okay super small knit um so all the stuff past all the wallinator tests or like stuff that you all do but I can go and add change those as well yeah it's just it's just for like style and consistency it won't block merging it it's just the
next time you make a commit um try to remember to to do that uh yeah no problem um I didn't know if they needed back text because they were headers but yeah if it's code like a snippet of code they should be in backticks even if they're in headers because sometimes if you don't do that it messes up the spell checker and then if you do it for seven of them but not all of them then it's inconsistent so it's better if it's code just to put it in back ticks okay yeah like I said it passed all the formatting checks but I can't add those as well it's not a it's not a huge deal like I got you yeah I'll I'll check that out okay
all right okay all right and this all looks good escrow Government Center cool good and then
okay okay chains okay yeah this is looking really good um this is yaml I assume right um yeah I just copied whatever the template was yeah yeah it's just
might as well indicate what it is um I copied it from um the ERC 4626 version okay yeah so what do you can I can you elaborate on what you mean by yaml there for me just for my reference oh uh it's the um the like markup or not markup the language that this is this looks like yaml yeah yeah no it is yam I'm just wondering like do you want me to say something or how do you want me to oh no it's just um if you put the indicator of what language it is along with the backticks here it'll highlight it as yaml oh I didn't know that okay cool good to know yeah and all of these things that I'm adding here I'm probably just going to
commit myself uh so don't even worry about them um good good good great and then this is also the animal okay is there a space before that is that um okay I'm not sure how that'll render hopefully it'll render correctly
um okay verify that looks good there's a lot there's a lot of events yeah no I know it's uh Not Unusual okay modification okay good dispute okay I want to dispute for humans International has been files okay
now this is this is looking really good this is um written the way a standard should be written so excellent yeah like I said I just copied from 4626 because that's very well written okay dismissed so I guess while I'm doing this um have you been um like do you have anybody in mind for who you'd like to talk to for like getting a review um who do you think your like users are going to be who you who are you going to integrate with um those kind of questions um yeah so in terms of like actual review I'm not sure the target audience has been gals I've been in conversations
with uh redacted and Hidden Hand primarily okay um but this is particularly for I guess generalized for any doubt implement um particularly ones that have on-chain voting is well I guess ones it up on it's a applicable to ones that have on and off chain voting um so right now my focus is on on-chain voting so but it's applicable for anyone okay cool yeah because so you said you're curious about the process so after this has merged as a draft um it'll be this is this is going to get this is draft right yeah okay uh it's up to the authors so you guys to figure out um
who to talk to in the community to get reviews from outside of your team um and then once you're satisfied that you've had enough review you can move uh what was once you're sat once it's completed you can move it into review like the proposal itself then you can get reviewers and once you're satisfied that it's been reviewed by anybody who might have an interest in the EIP then you can move it into uh the last call status and that's you know entirely up to you when you want to do those moves okay yeah okay yeah so luckily it's just me um okay yeah um and I have or been um the stakeholders and people I've been talking to have been in I guess I'm in contact with them for several months as I've been working on this
um so I guess once they they've already signed off on like the content so I guess once the formatting is done it should be good to move it cool yeah so is this something you'd expect to make it into like open Zeppelin or um potentially would be really good um yeah I'm picturing some kind of a standard library for Dows to be able to implement and then you just Implement like one function specific to your to your Dow yeah that makes sense I'm not really sure how I would go
without getting that um into like open Zeppelin I'm just working on this as like a master's thesis but oh yeah yeah it's um I think we have some contacts there that uh we could talk to cool um yeah so if you look in the comment history down below there's a proof of concept implementation um that the full like testing Suite with premium concept okay yeah that's that's perfect I'll just um add these changes and then should be good to merge awesome and so when you merge it goes into what it goes into this repo but
that doesn't mean it's it's actually approved so there isn't really an approved right it's it's uh we're just a bunch of documents we don't really decide who uses them or if like we have several different competing standards for URLs for example we we don't make really any judgment calls on them other than like do we think they're reasonable um so it's kind of up to you guys to like find and convince people to implement it so then what exactly is the difference between like just merging the end of the repo and last call uh that's kind of an indication of how complete it is so after we merge this in draft um
that's kind of a signal that you're starting the process once you put it into review that's generally when you're signaling to everybody that like hey the standard is ready for you to try making your prototype of and then last call and final are basically like we're done we're not making any more changes this is the absolute last chance you have to bring up any concerns before it's released to the wild okay I gotcha how often do these meetings happen so I can get this changed every two weeks but um feel free to just ping me or whatever if you need me to take another look um
I'm on Discord and Twitter and yeah yeah absolutely the only place you can't ping me is on the eaps repository because I get so many emails from I'm sure I'm sure you do there we go I appreciate you all taking the time to to look through mine how about broken the GitHub UI gets so it's great okay so I think we're good yes all right thank you no problem um yeah there we go
hopefully I didn't screw anything up if I did let me know awesome so this just uh approves it I'll make the changes and then it can merge I I just committed the changes oh oh okay yep so it should just go in on its own unless I you know broke something but uh hopefully I didn't all right um so we are joined by uh next uh like a group of authors for the proposal 6672 I just have shared Link in the chat no perfect thank you very much thank you for joining thanks for yeah all right so what we've got going on
here we've got some spam I think is this part of your team or is this spam that's a good question we have a lot of people here from that particular group um I don't know Archie Randy boy anyone maybe yeah talk about the proposal go ahead yeah okay yeah so we are from retriever uh we are the one that uh proposed uh eip6672 uh so basically this proposal is about a multi-red team of nft so uh we already in the
uh in the retention protocol vertica for years and we also see that there is uh there was a protocol called uh EIP called five five six zero uh but that EIP is only works in a specific scenario so what we are proposing here is like uh to improve that EIP and try to uh try to create some standard uh that can be used in multiple scenarios okay cool cool so uh my first question is is this
person part of your team um the last one is the cynic one person here oh nope no okay yeah we get a lot of spam okay so redeem in this context means like you have an nft that's like let's say a a ticket that you can exchange for a physical object so multi-redeemable means you could exchange it for multiple physical objects or projects yeah okay
yeah so um foreign yeah so okay
perfect we see six six seven two years Okay so um because these ticks yeah so when you're using Code like what is a backtick so like a code reference you you can use the exact interface name and it won't complain about it as for the example do we like just like uh put the descriptions over here or we
can provide any like because we have done like several projects based on uh these scenarios uh do we also uh is it okay we include the links or we just like put the descriptions over here you just keep it hypothetical like um yeah like you can just like you could definitely mention the project but it won't let you link to it so um yeah okay this is canceled okay okay
yeah probably not even worth mentioning okay and get rid of snappings let's see what I'm just great for the good I'll probably give it out of t an operator okay so this allows an operator to so a single operator so in this proposal and operator is what like the the party who is doing the exchange
between like the nft and the object like the physical object or okay yes and then you so each operator can also redeem the same nft multiple times not just once per operator yes yes uh it's uh the duplication is mainly duplicated by the Redemption ID so if they want to like block certain like uh IDs for redemption in place they can put the same IDs there so that they it's the Redemption ID is more likely an order ID as in e-commerce yeah okay but Redemption IDs aren't unique to an operator so yeah I mean that doesn't really matter too too much yep okay
okay so you require 165 here um but you don't actually say at least you didn't see anywhere where you say that it needs to implement yeah one six five all right let's see one six five yeah
or just don't don't require one six five oh yeah yeah yeah uh I'm pretty sure Okay so okay the coverage now is required to use
the key in the difference reflective parents yeah yeah okay so I think it's similar for most of these so anything that's like a must or required or shall needs to be in the specification section while the like justification for it is fine in the rationale section um yeah so like the idea is you should be able to just take the specification section and with only that you should be able to create a compliant implementation um okay choices okay that's good additional information Redemption
see something complicated extension okay that looks like yeah so okay it's compatible with UFC 721 that includes monthly redeemable
okay and then your interface was called just erc6672 so there's no I there um thank you okay yeah yeah
21 sorry I think it's just ERC I don't think there was an eye on there um looks good yeah this is a great reference of limitation by the way I really appreciate it okay needs discussion so this is fine for a draft but if you want to go past draft you'll need to fill that out obviously um yeah otherwise that looks great yeah okay yeah so the next step is we will like fix according to these like comments and uh uh like book another time or or we just like um somebody should hopefully look at it
um before uh you don't necessarily need to come on but if somebody hasn't looked at it by the next meeting feel free to just bring it back up yeah all right all right so this proposal is for moving into review status I guess and we are joined by the author here so you just need another author to approve it okay sure yeah thanks yeah shouldn't have anything yeah yeah it should be fine okay yeah great thanks no no problem all right let's go back to erpip
oh so just to be clear here Sam did you mention that the pr number 6610 about 4844 that requires just another author's approval yep exactly okay um uh that's a note for you uh probably it's just waiting for another authors to be approved okay and the next one is we are joined by authors of proposal 6239 I have shared the link in the chat perfect hey how's it going foreign
Jessica I guess you are the right person to talk about proposal 6239 yes hi all right uh this is Spam I assume this Maza for zero one five it looks like spam all right everything's passed see everything's been updated okay let's give this a read through okay
is okay good social identity perfect foreign create and update um
um I think you also love this um the the question in the um yeah it sounds like something I would ask yeah um so that's um that's separately uh defined this to events because um the the create rdf will be triggered when the token was first uh mint minted at the first time and the update will be um will be triggered when we are updating the rdf statement so I missed the statement the rdf statement in the token can be updated so it's um it's a
time difference and um the the two events is um makes it easier for the listeners to uh to capture what happens and have the corresponding process of that after the uh the lesson the event okay that makes sense okay thank you so you're still leaving rdf data as
um like up to the implementer right it's not defined in the standard itself uh yes I will leave it as to the implementer because the rdf is actually something that already already been standardized and it has own um own standard to uh to to describe the integrated scammer and the yeah yeah I missed the data schema uh we we did we did try to include a link here but uh field because it didn't accept external links
so actually we we intended to include something from the web 3C website page for a reference so that the implementer can actually check the reference on how they're going to implement that right um I mean more specifically like this struct here which you have in the comment like I rdf is fine if it's left outside the standard like that's out of scope for the Erp process but the struct itself for encoding um rdf data so this this little blob here that's not part of the stand like the standard or or is this something that should be left up to implementers as well
I think that's not um the IDF is not part of this standard right right I'm talking specifically about the struct that I have highlighted here so why isn't that struct part of the standard uh uh I'm not quite sure that I got the question uh but I I think here is because um the rdf there's uh actually different synaptics like uh somebody used to Ado and something is other the all so um we have a multiple products here can be included uh to
describe something so we sometimes we use a with the array type here okay um I'm not super familiar with solidity but can you compile an interface without this struct being defined that's like is that allowed and we can check that pretty easily [Music] actually I don't want to diff at all I want to view the file here okay
yeah unless it's defined or imported in one of the contracts it wouldn't compile yeah that's that's what I was thinking yeah so that's probably my my biggest concern is that there's there's if somebody is like using the standard um and they want to write say a like I don't know just a website that displays this rdf information for any generic token they won't know what the structure of the rdf data struct is um without like manually inspecting each contract um so do you think it's better if we put
some uh example implementations um it's more it's not about there being an example it's about like if I were to write a like a dab that displays rdf data for an arbitrary token how do I know what the what rdf data here means like if I want to display these updates or changes over time and I want to decode it how do I know how to decode this form the destruct I see then
um we could add something to for those explains about the rdf data okay maybe I'm also just missing it so if I'm like not understanding correctly please feel free to call me out on it um foreign
[Music] can be actually be pointed to through the URI so I think it's better to uh for for the for the decoder to find those information there so you're talking about this one here yes okay so that would be so this the schema URI describes how to decode this right
yes but it doesn't describe how to decode this okay I got it I think right please please correct me if I'm wrong I I don't know for sure hey can I can I jump in here just just a quick suggestion yeah so can you scroll back up to the last uh yeah to this one so if you have the rdf data uh this this needs to be defined when you're compiling the smart contract otherwise you cannot call it and if you're calling it from another smart contract you don't have access to the internet for the smart contract to check
right if so you can't really use Oracle to get the structure in itself so my suggestion is to go with a defined RFD data struct that covers all of the use cases and if there are some Fields um like for example if you compare the last one so the one that uses arrays of predicate an object and the the previous one just has one predicate and one object you can just use the one with arrays for that and you know your arrays for predicate an object can be of size one if if that's the case
um this way any smart contract can use this interface without worrying how it will work and the issue here is if you support multiple RFD data structs uh when compiled you you might get different interface identifier so if you rely on programmatically checking whether or not the smart contract is uh has support for eip6239 then you wouldn't be able to do that because he wouldn't have to you wouldn't be able to deterministically say this hash matches this one because you would have to or possibly three
different uh identifiers there I see um for the should actually implementation because we uh already did some implementation of the smart contract um so uh What uh where you said um just have the re-type there is a squad for the standard um something we we separate because for the action implementation it is uh it's
a best practice to just include one one statement I mean yeah that would be my suggestion because this way you could programmatically determine whether a smart contract implies to your standard or not um yeah yeah unless there's a a reason to go with one of the other two options here I would suggest just only defining this one and then making a note that says like uh it's best practice to use array of length one for predicate an object um and I think that would probably handle all three use cases I'm not too
sure about this one like this one seems very very generic um but these other ones seem a little bit more specific so if this one can encode everything that this one can then I would just go with this one okay you can okay I think these are code blocks um so we are
um planning on allowing links to w3c we're just figuring out the specifics um so once we get that sorted out you'll be able to link to it eventually okay it rdf um so for the update stuff um is it going to be common like who is going to be doing the updates is it the person who deployed the token contract or is it anybody um it definitely cannot be anybody but actually when the incrementers was firstly deploying the smart contract
they can Define who is going to be update who is going to update rdf it can be someone like the implementer and somewhere in the white list or um get this uh just uh they Define it for us okay so um for contracts like erc20 and ERC 721 we generally don't include um interfaces for minting or updating the metadata because it's usually very unique to the implementation how to do that so I'll make the same recommendation here that you don't specify how to make
changes to the rdf and leave it up to the implementers unless you think it's going to be common for multiple daps like like let's say I'm making you know a token that has rdf information in it and I deploy it um How likely is it that another dap is going to be changing the rdf of the token that I deployed because if that's going to be very uncommon then I don't think you need to standardize it but if it's going to be very common you probably should standardize it and that's up to you and just just a recommendation I see um it's not common for the others to update ads but for the um for the this owned app right the
users or the the deployer of the smart contract it might be common for them to update for example because this is in the social contest so there are many updates like following and unfollowing essentially the common case right yeah yeah so the best place for a standard is when you have multiple different implementations trying to talk to each other so if it's only ever going to be the deployer that's making the rdf updates then you probably don't need to make a standard for it but every like reading the rdf stuff that that absolutely needs a standard and I think that's great
um so it's just if you don't want to deal with the update rdf stuff at all you can just remove it from the standard and it'll make it like a little bit smaller okay but that's it's optional if you want to standardize it and you think it's it's going to be worthwhile by all means keep it in it's just a suggestion yeah I see okay update ideas are we still in the specification section here I think we are yeah okay good good remove IVF needs to be adapted
okay [Music] okay so this more like all right so that's looking really good
just um a few comments on there yeah thanks for coming out and uh I appreciate it thank you so much all right so we're moving to 67.43 yeah that's for last call here all right okay last call just make sure there's no active discussions going on
yeah the last comment was 29 days ago yeah that's perfect let me just give this a relief through the non-transport interface for non-punchable tokens okay okay personal achievements yeah that's good energy what two
four six five four okay all right so uh I know this is really really late in the game um but having a Boolean that's negated is always incredibly annoying from a developer standpoint and I would very strongly recommend is transferable instead of is non-transferable um but uh that's that's entirely up to you guys
yeah yeah I get it I mean uh would you mind leaving the comment in the discussion yeah I can do that wait I don't think this is the right discussions right now of the count
okay foreign you have a comment in here addressing my yeah
um yeah okay uh yeah one of the issues uh when you're defining booleans and uh integers and solidity is the no default value which means that it's always false so if it's non-transferable you have to set it to true it doesn't revert yeah I mean if you set it to true this means you actually did the action okay yeah okay so I think that yeah that looks good and I have no problem putting it into last call with my objection being noted there we go
thank you no problem so we have three proposals here to be moved in the last call all right let's take a look at these okay so that's moving into final foreign doesn't seem to be a ton of discussion
so yeah I guess this can move into final three yeah all right nope 6700 yeah I guess by the same on touch no
also moving to final to watch an asset so this one I thought had some active discussion on it let's see 24 days ago okay so let's actually give this a more thorough read we won't script IPC wallet won't Translate okay
I'll just request that is fabulous smooth is there a 69 there foreign please
foreign foreign
all right and I think that's pretty much all the time I have today so I will see you all in two weeks all right thank you so much yes I'm just um to let you know there are three oh I guess four proposal in last call and one more in finally call waiting for review so if you get a chance to maybe take a look Offline that would be awesome yeah of course yeah thank you everyone for joining us today and hope to see you in two weeks have a good one everyone