EIP Editing Office Hour #35
EIP Editing Office Hours · 2 Apr 2024 · 48:40
Meeting 35 of the EIP Editing Office Hour, held on 2 April 2024. EIP editors and proposal authors work through open pull requests and questions about the Ethereum standards process. This meeting covers EIP and ERC pull requests heading to Final, Last Call, Review and Draft.
Topics
From EIP Editing Office Hours, hosted by ECH Institute.
Transcript
welcome to EIP editing office hour meeting number 35 we are joined by sson and a few authors this is uh issue number 328 at ethereum cat holders GitHub repository so we are going to get started with PR number 186 thank you Sam no problem let's make this a little bit bigger how's that is that readable it is better yes okay cool so let's go through the were there any specific questions or were you just looking for a a review it's a review uh we already had
some back and forth in the issue so we just looking to mer as draft okay perfect I'll take a quick look through it then so yeah good no let's check here yep okay so that's good so we can that one uh what was I talking about here okay
yeah okay so nothing major let's give this a quick look through okay good RS for okay looks nice okay that looks good okay I'm going to ask you every time I look at your P request but your interface identifier is correct you've double checked it yes sir perfect
okay good seems fine perfect thanks for changing that it makes it so much easier to understand where you when you can see like where the new stuff fits in super super useful okay good seems fine nice list of requirements good token
commitments okay is not an extension of okay CC1 good yeah so this is perfect so we can approve this as a draft there we go um it might not merge unless all of these are resolved um yeah you can mark them all as resolved yeah I think we're good yeah will will you merge it or do we need to
mer in our uh the bot should take care of it in a second um well longer than a second but it will merge eventually um I'll keep it open just in case so going to go off to um 28 oh go ahead POA sorry oh yeah yeah I mean it's great like we we are joined by the author uh of 7 to8 so yes oh perfect yeah it looks good I'm just waiting for the the spot to finish and then should be good to merge U well it'll merge itself and then I can merge this one um yeah so that's the two going into
final um yeah so both of them are waiting on bot is that correct yeah so okay perfect just keep those up all right yeah yeah we can move on to the last last call proposals sure um to last call okay um please tell me I can edit this okay good referable nft is that gu so referable ever since I uh was working with HTTP I always screw up the spelling
of referable because they spelled it wrong in the spec um bit of trivia for you uh okay so two referable indicat time Bas indic okay to construct reference relationships among n okay the relationship between each n of forms a directed graph the St uses to query track and analyze their relationships neat DJ May reix okay referring indicator new nfts okay
cool a structure that contains referring referred referring Keys okay another customized an optional attributes not naal pry of agreement recording the ownerships of referred ener okay was that defined somewhere RT so that's the first time it's being used so that should probably be expanded referable
nft all right do that okay so what is 2 weeks from today would be the 16th so I'm put you to the 16th and then so the only reason I'm making these changes directly is to try and save time when things are moving into last call it's a little bit annoying uh so normally I wouldn't just directly edit them that's great yeah of course otherwise if the author will be making full request it will be again delad yeah exactly so as long as there's only minor changes in here I don't mind uh there
we being created or profit sharing reing the profit sharing over recurring referring is an outdegree indicator used to show the referred as an ingree indicator okay okay by colors men okay set node okay so you're an interface erc1 165 165 okay Lo with a note in the RFD gets referred and changed okay preferred of
neat okay so Target contract refer okay so that seems fine the referable D for quaries and Crosser okay 7 okay who approved this previously if it was me I was not uh not doing a great job on that uh this is 5521 so that was mat all
right this is intended to so the problem here and if anybody's watched my um reviews before this is going to be a very common complaint um these aren't explaining decisions that are made in the EIP they are um explaining why the EIP as a whole needs to exist which isn't isn't the point of this section um okay so can be fully ERC 721 compatible byk test cases good a reference implementation and then it's fine these are decent security
considerations okay so I'll commit these but I won't prove this okay so is there any action for the author I I suppose we would want yeah I'm going to have to explain a few things to change here [Music] um so let me actually before I get into that I just want to check if there's any
active discussion on here because that's important as well February 14th um yeah I think this is reasonably resolved um there's been a month and no replies so uh okay yeah so let us leave a [Music]
comment okay this standard is intended to establish the referable day okay okay um all um Sam in that case would we want to
change the last call date because that's not the date by the author right uh change the last call date yeah yeah end date yeah I like make it further out yeah I'm just wondering like did we make it we could probably make it like 3 weeks or something but I can just edit it whenever they they update the request yeah MH yeah um
for all right so let's go back to so this one's merged 7528 and then that means this one we should be able to merge now let me just make sure there's no discussion on here yeah October that's definitely good to approve all
right so we are joined by another author and he's here for proposal 4824 I believe this is to be moved to review the poll request number is 330 330 and that's on uh erc's that's correct all right did you have any specific questions uh no I think I just want to ask how do I get this to merge I think we this have been gone through like a long discussion through the um on the previous repo yeah which one yeah it's just um just a matter of getting somebody to look at there's not
much you need to do yeah it's basically just some like I fix some typos um and add us some clarification type stuff okay perfect I'll uh I'll give it a read so we're going into review okay an API decentral okay so an API for decentralized autonomous organizations focused on relating onchain H chain representations membership and proposals great D so um not not enough to for me to actually complain about it but if you wanted to be a little bit more in depth about how you accomplish your goals you could put that in the abstract add just like a sentence or two about like um like are you adding like solidity
interfaces to do it or like I'm assuming you are but yeah so yeah again it it doesn't matter it's not a big deal but there is room in there for a little bit of technical detail um okay okay okay stand your perfect okay yeah yeah so like this this little bit here um could be in your abstract um but yeah it's again not important um uh every contract must implement the okay um bit of a stylistic like comment but again not enough for me to actually make a
comment on here just say this proposal instead of linking to yourself um but really doesn't matter yeah um four okay okay and then nice thank you for saying what type of thing this is that's good um or may create the store Dash primary address okay um looks like you have a find and
replace error here uh you have a a hyphen in your contract name which I don't think is allowed no uh okay um it I mean it might be I'm not a solidity expert but yeah neither am I honestly another one of the authors offered the uh the relative small amount ofil code he provided okay yeah okay so this is a if creates external registration contract so this is the external registration contract okay so I'm probably would have mentioned this last time unless this is
new but I'll mention it now um we generally don't have uh implementation in the specification section uh you just provide a solidity interface and then if you want to provide an example of it you put it in your um reference implementation section yeah the um I think the idea here is like uh so this is specifying like a number of different um registration Vehicles so one you can just inherit the interface yourself but otherwise you know you deploy this registration contract um to kind of declare that your primary address has effectively a dow URI yeah
so for this um does the like does the implementation need to exactly be this or can it just be any contract that has the same interface um so I think it's like it kind it doesn't even exactly this but it's sort of like you know you can imagine cases where Dow deploy is a subow right but that's not like a that's not a registration contract it's just a just a subd right okay but that subow might cona might contain this um uh you know this interface in which case then it's confused like this this does this Dow I refer to the Dow that deployed it or the new
Dow yeah okay so I will leave a comment on this um just because I so I I I'm not an expert I haven't read this like super in- depth I'm mostly reviewing for like formatting and stuff but I think this should probably be in your reference implementation so just give me a sec I'll write up a a comment here um I um I did move one of the things to a reference imputation like uh cuz yeah we had talked about this I think yeah a while back so I moved the factory contract into the reference applications um like into the
assets uh so we had to find like a like a one for the factory right yeah but uh yeah just like the registration trct itself I mean I guess we could try to specify it a little bit more abstractly um but it's it's it's just like a you can't just deploy anything with the interface cuz then then that's confused it's not like no no but it's like uh you can deploy like anybody so the reason why I'm asking so some contracts we do allow in the specification section because uh they're deployed with like let's say a create 2 uh thing at a specific address uh so the content of the contract needs to be exactly this for the address to make
sense but for this as long as whoever's making like Implement like whoever's registering their their um Dow Dow URI uh function has something that looks like this contract even if it isn't exactly the same as this um so like I I guess I'm saying like obviously you wouldn't want to put this onto another Dow and then that Dow would have to decide like there wouldn't be a way like you were saying there wouldn't be a way to tell the difference between the subd Dow pointing to its um uh Dow URI or to the parents Dow U uh so you wouldn't want to do that that obviously makes sense but uh if I wanted to say write a super gas optimized version of this contract that would be allowed fair
enough okay yeah so let me yeah let me think about how to how to fix that a little bit okay so I think that's probably going to
be my only comment um okay good good [Music] um okay then this is the factory registration Factory contract to Comm index okay so that's you're moving that down into the reference implementation section so if
down okay fine D may be post directly in the D contract in cases where both occur should take precedence if there are multiple registrations most recent registration should take precedence good that looks fine context okay okay proposal okay okay contract U should okay pointing to a j okay I'm sure that's all
correctement okay contract um [Music] discussion address where did that K memb you okay to
prevent contract address okay that sounds fine your ey Fields content may be directly embedded as jonon which case you ah okay yeah basically some users want to be able to just publish one file rather than maintain a bunch of B points that makes sense yeah yeah appear in the okay okay and this is actually like a a
um this isn't an example it has to be literally this yeah it has to be lit that just checking yeah okay down your eyes okay okay good schema good okay well we considering on train aspects yeah that's great that's good
explanation for why okay yep perfect um ignore but um um yeah like so I know in Jason schema I'm
a little bit more familiar with it but you can express like exactly one of so you could say like either a URL or uh like this the full schema um but again don't don't worry about doing that if like your text is fine yeah we uh we'll probably implement an actual Json schema for this right now it's just in Json LD so it's it's really just the context files okay yeah I don't know I don't know Json LD at all so I don't know if it has the same kind of like validation rules and stuff but yeah okay so we're still in the rationale section
yeah we can just keep I'll just remove that uh yeah you can just like if you're explaining why like okay so every unique onchain proposal uh must be Associated to a proposal ID because that's fine in the rationale section but if you're saying like if you're adding a new requirement here cop of the requirement upstairs so yeah okay good that seems good process the actual status is to
governance system prop okay and this is just a collection of what people actually use so that's fine activity log U okay govern proposals yeah seems good okay good it's important for spam so the bot is going to complain about this um you'll need to yeah don't worry too much about it you'll just have
to get like uh comments are only allowed in in uh draft okay I guess I'll just remove it it's fine yeah I decided anyways not to include Dow ID I would just author that as a as a different different standard good um
so oh yeah makes sense okay um okay what else here
okay um expected okay be okay good good okay we have here yep where would I put acknowledgements then um we don't really have a good place for it uh so I'm like I'm not going to tell you you have to remove it um just generally we don't include them um okay yeah I would really like to include them if that's okay yeah yeah you can leave it there like if another editor tells you to take it out you'll have to take
it out but I'm okay just having that little sentence in there okay um okay okay yeah so yeah there's another one here yeah I think it it was just like a find and replace problem yeah it's possible I'm not going to comment on all of them but
you'll probably want to fix those okay yeah cool yeah thanks for coming out and uh good looking proposal just a few small little um changes but should be easy to merge just uh feel free to ping me on Discord or or come to the next call if you want to get a quicker look at it I know you've been waiting a while for this yeah it's been around for a while I keep forgetting to actually move it to review status um but we're doing a lot of work on it elsewhere that's exciting yeah it's um going to be really useful I
think a lot of dows exist so having some standards around them is going to be good exactly yeah yeah well awesome thank you so much Sam appreciate my pleasure have a good one so we can move on to the next last call 322 Okay cool so see how the discussions are going
here okay so no no super exciting discussions there okay so we'll change this to uh I don't know April 23rd May here
just do that okay the specification establishes standard method for interacting with steal address the transactions or transfer perfect moreover the specification abls developers to create stealth address protocols based on the foundational implementation outline of the CRC utilizing a single contract toit the necessary information for recipients in addition to the base implementation perfect standardization of non-interactive stealth addresses stealth address generation presents the potential pracy okay
one or two public keys that can be used to compute a stealth address for given recipient a spending key a private key that can be used to spend funds okay a viewing key is aprivate key okay you
okay new stuff for the impation methods okay SCH chosen much increasing integ must we added to Okay so um 50 69 I think
yeah okay if no long be editable requirement doesn't make sense um yeah where was that there these extension specified the iner identify for the scheme the Ali for St address Singleton contractor specified as follows
okay this must be a single to contract with one instance per ch uh
so okay okay okay5 6538 may be maned by the user inter register with public available registry contract delated in ERC 6538 what is that 6538 okay
stagnant you're moving into last call have move on mention yeah 65 here is out of
draft [Music] okay uh 6538 is that in your requires it is not um 638
6538 okay VI test sh Foundation is not t Okay in addition stealth address scheme the cool okay re keys that looks good that all looks fine that looks good checks okay
announcements good okay okay um
for to the specification section all right this okay deploy ah okay create using okay so why is that in the backwards compatibility section um
okay good good good 4337 good cc01 and cc01 good review all right so I'm going to call it here um just want a few minutes break before my next call uh thank you to everybody who came out um I will see you all in two weeks thank you so much Sam have a good one you too bye bye