EIPIP Meeting 101

Transcript

welcome to eipi meeting 101 this is issue number 316 on E caters EIP IP GitHub repository on agenda we have uh some open issues and pull requests to be discussed we'll look into call for inputs and some discussion updates from the earlier meetings there is also eips insight and yeah we'll perhaps take a look at the action item if pending from from the previous meeting so starting with the first item I have listed down a few PLL requests which requires editors approval it seems um yeah the first one here is a PR

number is 82 51 I wonder anyone has any thoughts on this one so this proposal yeah looks good to me I mean it was proposed by Sam so we were wondering if we could get another editor approval because this is to move into the last

call awesome thank thanks man very well from there we can okay uh just quickly checking with uh editors is it good to be merged or any other thing we would like to do here yeah yeah it was it was approved okay perfect yeah good to go very well so the next one is to update ERC 777 and it is on the ERC GitHub repository number is 182 it seems to be a typo for a final proposal yeah I think we have enough

approvals now so we can just merge this one thank you so I think we're good to move on to 8255 I'm sorry I was on mute so that's correct um we can move on to 8255 this is a withdrawn proposal and someone is

trying to make changes to withdrawn any thoughts around merging this one what are they changing in this one typos sure yeah it's fine I don't have any problems with this yeah I was just wondering The Proposal is already withdrawn we know that it is no going to be moving forward what's the point of engaging in any kind of yeah yeah I think that's okay I'm okay either way if no

one is strongly preferring to move on I I don't I I think we can just leave it as now yeah I mean I believe I agree because I mean this is etherum Improvement proposal so if it's not going to be adopted there's no point doing it right and it could be a way of you know just getting contribution but it's not like adding any value yeah yeah that's correct token

token fing is yeah an honest farmer all right so um for summary I'm assuming that we are moving ahead with not merging this proposal because this is an update to an withdrawn proposal and this could be from like you know as a policy we are trying to suggest here that we would not be accepting poll request for any withdrawn proposal is that the fair understanding unless uh it's from the author or unless someone is trying to revive and withdraw IP which is allowed in IP one I think no withdrawn is not allowed to be revived only stagnant

sir oh right so can author revive one them themselves no withdraw me okay so they have to start start over right yes yes got it yeah we can that's okay yeah okay for me if we said this as a policy just yeah perfect uh moving ahead we have some updates to final proposals the first one listed here is to ERC 1046 and the number is p PLL request number is 154 yeah I'm just going to close this

one um it's going to be impossible to get approval from all the separate authors um I'm just going to suggest that they open new ones if they want to for each individual PR or proposal are you going to add a comment there like just for authors to follow yeah yeah I'm perfect perfect thank you would it be possible I'm not exactly good at get but it would it be possible to just uh move each commit into a new PR or something do like sort of cherry picking approach uh yeah yeah it's if that's the approach they want to take

absolutely maybe suggest it and if they say I I don't know how to do that I'll offer to do it for them or I'll try to learn how might be a fun excuse to learn how it works there we go with that we can move on to the the next which is ERC number 6672 and the poll request number is 285 here oh do we have a CFI for this particular Pi fix the handle of co-author yeah we don't I'll

uh I'll make one for this yeah I'll make a CFI for this one okay and now curious do we need a separate CFI yeah or can we just use it with the other proposal which I think is already added here I think we need a separate one for each just so that we know like we have a record of who verified the identity and all that crap uh should we instead just set up a policy of how it is verified and then I don't think verifying uh identity should be a CFI or it should be involved in the CFI let's say if someone just uh create

a pool request and all the author or a number of the authors of that particular ERC agreed they should be able to just merge we can just approve it merg given that there's someone attested instead of using a CI yeah yeah I mean if if you want to write that up um we can approve that and put it into either E1 or somewhere else maybe but yeah that's that's a good idea okay uh and then obviously there are unique situation where there's a single only ad uh author so I I'll write it up uh Matt are you okay uh in that approach that we discuss the policy in the CI

maybe we can get back on this one when we are looking into the cfis I mean call for inputs sorry I should not call it CFI call for inputs um uh we can perhaps uh have a little bit more discussion over there and then come up with the summary for editation all right uh so we are leaving 6672 for now uh I think Sam suggested to create call for input um but we are not going to do that because we're not going to do the

individual or are we sorry I I just missed this part I'm sorry Sam if you're speaking you are on mute uh no I'm not saying anything okay no I was just curious like I perhaps missed the decision for 6672 or we going to create a call for input or not uh so I think uh Victor is going to create a call of Call for input to make a general policy about how to deal with these kind of things um and uh yeah that's that's where we're leaving this

but not but not specific to this 6672 um yeah if it just going to create like a general one I'm not going to make a specific one for this okay perfect so the next one is ERC 7201 and the PLL request number is uh 2 01 at ERC GitHub repository any thoughts on this one it seems a bit contentious looks like the author is not in

favor I have not misten yes one of the author is not in favor of marching this the I think they ended up approving it on later on um yeah it looks like they approved it so this would be a clarification I think I think this is a fine change but I'll make a CFI for it since it is technically changing a final EIP okay perfect so let's move on to the bigger

section of it it's a call for input there are five call for inputs I think the first one is by kander Singh and rest all by Sam so yeah whoever wants to take it yeah regarding mine I think I'm fine if we don't really want to go through the pain of renaming and S sort of rendering from authors to maintainers uh but I guess maybe we can just mention it in E1 and sort of indicate that uh author is not really a credit list it's just people who will maintain the

EIP any difference of opinion or do we want to add that as a decision I know we still have some more time left to collect more input it's the last date is March 20th maybe keeper of consensus can take a call to keep it open or closed um I mean if if you're withdrawing it feel free um to just close it I don't really there that much no I mean instead of withdrawing what I'm saying is that maybe we can uh mentioned this in E1 that uh author is not really a credit list and it's

just list of maintainers so it's not really fully with drawing but yeah small action yeah sure I mean be afraid to change it I don't have a problem with that so the next step here would be a small PR to EIP 1 if we wanted change to be reflected in EIP one yeah I'll do the here perfect um so the next one is a 318 Sam four so um this was asked for by um any

IP author um I believe it's the one that's working on falcon yeah so um they want to link to a project because it's an implementation of the algorithm they want to use um I'm kind of against this just because I don't know if you can link to an academic paper it's a lot better than linking to a particular implementation um or or or an RFC or or something along those lines um but I put it up here for everybody to be aware of it um deadline is March 20th leave your comments thanks the rest of them are probably

mine too yeah okay so a different author this is for 320 a different author um on a different proposal asked for a link to cips or a chain agnostic Improvement proposal I think yeah uh it's like another standard body like eips but less focused on ethereum um deadline for this one is March 21st uh leave a comment on there in favor or opposing if you care um moving on to 321 um this is changing a reference implementation of a final ERC um deadline for this one is March 22nd um again leave your comments if you care um

if not we'll see what happens on March 22nd um next one is 325 this is um changing an author's username in EIP 1193 um I think this will be taken care of with Victor's General proposal on how to handle changing usernames um deadline for this one is April 7th and then we have um oh this one's gender so this is 37 oh no we got that one already Okay cool so that's all of them who um so yeah maybe the the next one uh which is about General policy when we

have the call for input we can perhaps share that with editors to collect more feedback and see if we can make it as a general policy over there y uh Eric you have your hand up yes yes kindly I I just wanted to add some comment regarding 318 and this is the EIP that the sorry the B request that I opened because um I proposed another H EIP which is uh 76 um 19 which is H bringing the post Quantum um signature to ethereum um because this is um this is a new kind of this this is

also evaluated by nist the you know the this organization that works on um standardization of of new cryptographic um um staffs so um we analyze it and and um saw that at the end Falcon is a good option and this is it when it was evaluated by by people uh in in the in the EIP team they suggested to suggested me to add a new um a link so it can be H better understood the implementation and these kind of things but the thing is that I couldn't find um um a a suitable option in the in in the to reference an

external link so I proposed that H with the intention not to modify the EIP but but the because it was the way I found to to add a reference to to this implementation so just wanted to to emphasize that thing so maybe H because I I want to to know not get Frozen that proposal which is the EIP 7619 but maybe fin a way to to to to get this proposal moving forward so maybe um if it is um not accepted the the the proposal to modify or add an external

link for just that um er implementation um maybe I I can just um move uh that option and leave the EIP 7619 without an external reference implementation maybe that would work some what do you think um so it's difficult to implement a like a hashing algorithm or or an encryption algorithm without knowing what the algorithm is in fact I'd say it's kind of impossible yeah um but we also need to be able to

um you know have our guarantees about um how long these links are going to last um so maybe if you can include part of the reference implementation in the assets directory would be a good way to resolve this temporarily um or if I mean I guess there's no real yeah I don't know I I'm trying to find like a a document describing how Falcon works that isn't PQ clean um and I can't seem to find one so uh yeah maybe like what's the license of PQ clean uh I'm not sure about the license actually let see C clean is not licensed all right so we yeah

that makes it really difficult um yeah I guess we can leave it in the draft um without a link and we'll try to find a a source for it if that's okay with the the other editors mhm okay okay but as you said um maybe referencing some Link in the assets section could make a work around wion um if you could just put the code in the assets directory would be the best option I think but um if there's no license then we can't really do that yeah yeah okay okay I I'll I'll take a look at this and maybe next time I I'll I I'll

try to contact you or see a way to to to resolve this thank you Sam yeah sorry it's not the most clear process right now yeah I understand thank you thank you both so moving ahead we have other discussions continued or updates from the past meeting and the first one here is working group chatter I don't know if we have any updates on that um we had some discussion at the the recent uh face tof face in Toronto um between myself Matt and uh Trent or Tim rather and

um it kind of threw a wrench into um the design that I was going with which is that you we'd have the same treatment for all working groups um Matt raised the objection I don't know if you want to talk about it Matt or if you mind me summarizing it you can go ahead and summarize it sure so the the the general Vibe I'm getting is that we want to treat erc's and eips and possibly rips as special in some way where that they're the only working groups that get repositories and then other working groups don't get their own Repository and are kind of subw workking groups under those three um which is very different from how I

had implemented it so I'm I'm kind of thinking a little bit more about how to do this and uh yeah no no updates on the actual documents or the implementation right now just just some thinking well thank you for sharing that um does it make any difference in rendering like I understand you wanted to have it rendered with the help of working group but the web page that you were working um is it possible to have all of them rendered there because as of now we do not have a placeholder for rips uh yeah I mean in the end it doesn't really matter what the repository structure is it's it's possible to get them all to render

on the same page perfect I think that would be helpful and oh uh I was about to ask Sam is there any um guidance on uh how to practically enable subw workking groups let's say ERC is a is a working group but it could be pretty broad um and maybe people will be only interested in a section of it what's our current uh guidance in

enabling those discussion uh enabling those discussions as in discussions about how to make the process or the actual like working group discussions I for example I would Envision some people want to work closely around erc's about nfts right and some people might be interested in working around uh ERC of 12 uh signatures like 12 12 71 and and like canstruction side um what are those like how do you see these kind of small group of interests uh in this structure of our new

Charter right so I think uh that's that's where the um tension is coming from so I would like to see them have their own repositories their own um build system like they would have the exact same status as es whereas with the uh design that uh Tim and Matt are are proposing they would um all live under the ERC repository and umbrella um so I guess my answer is that isn't decided yet and I have no idea what our guidance is going to be yet okay uh happy to kind of FLIR the B idea with you yeah I I and I agree that it's good

for them to have separate uh repository and separate place to discuss of separate place to kind of collaborate um and then as they gain trust in the community they can have more access or recognition by other part of the working groups yeah that yeah something like that I think so on the topic of RPS um I did had a chat with um one of the RPS um working group

members uh at Denver um it seems that they are interested to maybe show up on one of our future meetings for eipi and we'll get to learn more about it but uh due to its present GitHub structure I think it is a a little complicated to uh render their data on e. ethereum.org yeah but I hope if if the website Sam is working on if that also includes RPS data that would be nice to have in the meantime yeah it it will whenever we whenever I I get around to proposing it

yeah sure no problem moving ahead we have eips inside taking a look at the data we do have one EIP which is a networking EIP proposed in draft status that is EIP 7636 extension of EIP 778 for client enr entry and we have five drafts on on ERC side there is one proposal in final status which is for ERC category and the proposal is ERC 7092 Financial Bond congratulation to the author and we have two proposals in

review which are on uh the ERC side ERC 7007 zero knowledge AI generated content token and ERC 7590 which is ERC 20 older extension for nfts don't have any proposal in the last call so there's no rush but uh authors editors and Community are invited to maybe take a look at the proposals which are already into draft and review statuses with that there is further announcement for EIP editing office hour the meeting is uh planned for March 19th at600 UTC

I have added the link to the agenda uh which is issue number 324 at eat cats EIP GitHub repository people can also check out the video from the uh past meeting meeting 33 and quickly taking a look at the action item here um yeah I think we have covered all of them here okay did we get to to this call for input adding additional author okay yes we did it yep okay perfect I think we have covered all the action item from

the last meeting we are a bit early if anyone has any final thoughts comment to add for this meeting or maybe for future meeting please do let us know and with this DST change in the United States the meeting time is an hour later but I'm wondering if people are interested in keeping this or if there is any suggestion on moving it it to a different time I know we reached to this time after a long struggle but yeah any suggestion around time or anything else people would like to add here I'll take answer to both are no

change and people are Happ happy with this short meeting so yes uh we can have our 30 minutes back thank you everyone for joining us see you in two weeks have a great day see you later everybody you later thank you