EIPIP Meeting 93

Transcript

welcome to EIP meeting 93 this is issue number 285 on agenda we have a lot to discuss today so starting with the EIP ERC report split we will get some updates from editors meeting that happened last week uh there are pending task list which is added as an issue in the new repository we'll take a look at that there are a few suggestions for ERC governance and other area of improvement will learn where we are on rendering of eips and ercs looks like there were uh a few editors who could not join the last meeting and uh we may would like to revisit uh where we are on

that additional uh topic for discussion here is the topic of uh groups those can be created after the split to help this move smoothly there are list of questions suggested by Dano will take a look into that we have listed call for inerts and then we will have some discussions from the past meeting we also have added a monthly update the eips inside EIP editing office hour and some announcement to go so starting with the first item which is EIP ERC repo split I do not see Sam or Panda on the call I wonder if anyone else

has any update from the last editor meeting that happened and that uh led to the split here Matt said he'd be a little late but um the really short version of it is the split happened um and ercs are on their own thing it's a bit rough around the edges but they do get merged onto eips ethereum.org um but yeah I'll let Matt go into more detail on it when he gets here sounds good so um kind of next but related is like the list of Penning task for ERC migration um which Lifeline has already

created do we want to talk about this now or do we want to straightway jump into the topic group discussion and we'll come back when Matt is around yeah I can definitely talk about topic groups for a few minutes so okay makes sense so uh we'll skip the section please go ahead good topic R sure so um I just haven't had a chance to make any progress on it yet um the ERC split has taken up a bit of time um going through Dan's questions here should top new topic groups be independent of EIP ERC or peer within the same structure um the way I've kind of envisioned it and this isn't like set in stone or anything but they'd be like uh peer so erc's would

become a topic group um core eips would become topic groups um or or or working groups I guess is the name we're going with right now uh what's needed um so we have uh most of the documentation written I just have to actually put it up and introduce it um so rip numbering uh even it won't work start from a different number so um we have a spreadsheet that we use for numbering and uh we're going to use that for now and then eventually we'll move to something automated uh boundaries how do we determine what group a proposal goes to initially is that portfolio jurisdiction baked into the xp1 document and uh yeah

so each each topic group has a section um that describes what areas that they're interested in reviewing and eips or or or new proposals go into the most specific matching topic group um and how do we feel with uh sorry how do we deal with specs that feel like they belong in multiple groups uh does one group have initial jurisdiction multiple specs join specs and um I think that's going to be determined mostly on a caseby casee basis um kind of how we do today uh with erc's and interface and stuff like that um the general advice is probably going to be to to split things or to just pick one and go with it it I mean we're all

people we can we can work out conflicts um that's about it and really we're just waiting on me to publish some documents and get approval on them so uh yeah I'll be getting to that as soon as I can and that's about it for the topic group update well thank you so much Sam for covering this I wonder if anyone has any immediate question that Sam May answer on this particular topic yeah just a quick one what is xip and RP designate uh so I think oh go ahead I used X IP is a generic what is your name that you're going to be so it would be

rip and let's say there's a wallet it be WIP so I just used X to say whatever the letter is so xip means their founding document of whatever their initials are got it and RP is for rollups that's what's been floated okay cool yeah thank all right any other question also I'm happy to hear that there's work going on behind the scenes I just haven't seen any of it and I knew it was kind of a big deal in the RP call last week so I just want to make sure that the the wheels are greased and things will happen

well no I think you are right on time um yep so I posted a link in the chat to my current draft of what um like the working group that defines the governance VIPs this is what I think their Charter will be it's a very early draft but feel free to take a look all right so I see uh now we are joined by uh Matt like cin um so if we do not have any further question on topic group we can perhaps go back to EIP ERC repo split discussion um so m you did not miss much we just have covered topic groups and

try to get answer to some of the questions shared by Dano here I'll be trying to summarize it in the agenda as a comment at the end of the call so going back to EIP ERC repo split uh I was wondering if we have updates to be shared from the last editor's meeting already Sam has shared a shorter version of it that the repo has been split I wonder if you would like to uh walk us through the pending task or for me ERC migration or anything else specific coming from that meeting would like to share with the group you have something to share Sam oh no not really I uh okay said it earlier uh let's look at the pending

tasks there's a lot of them uh okay so I got the token from Jamie last night I will send that to Panda after this call and that should get us the EIP bot on the ercs I know that he's got the EP some EP review bot running I don't know if that's actually merging things let's see uh yeah I'm not sure if it's merging things so we'll have to figure that out but yeah we're still trying to get thebot running that's pretty critical

because every PR just Stacks up and needs somebody to merge it in the meantime uh and then like more generally we have a problem where there's still this EIP reference in a lot of places on the erc's repo and I'm trying to replace it with ERC so for example in the Preamble EIP colon the ERC number and I wanted change that to ERC but there's a lot of problem and also importantly in the in the relative links um but the problem is is that because we're building the website on the Eeps website we sort of need this these

values to be EIP so that jaal builds correctly we could translate those values on the fly in the repo but I really don't want to add a bunch of additional logic that is processing EI erc's outside the ERC is repo it's brittle it's not really clean it can break and we won't really notice so I would like to find a resolution for that and my proposed resolution is what I thought we agreed upon a couple meetings ago which was to just split the E's website and erc's website and that's why I got erc's ethereum.org set up I don't know it

might even be available right now erc's ethereum.org yeah I mean ercs doe.org is live it hasn't really publicized but it's available and I think that that just makes things much simpler to deal with the all of the issues that we're talking about because we can just update everything to be EIP for the E's repo erc's for the erc's repo and then have a a link at the top in the top bar to go to Eeps or to go to ERC and it also allows for some different things to surface on the different groups so I

think like as we go forward some things will change a bit between eips and ercs and we want to expose that for erc's and I want the ERC editors and folks involved with that to be able to modify their website like I I think Panda's website looks nice I don't want it for core eips want qu appear to be like very light to download but if they want to ship that website for erc's like they should be able to do that and so that was the intention and I would like to move forward with that but I know that you guys talked about it last week and some people were more in favor of having another repository to hold the website yeah it really depends how we end up going with a working groups um if

we do one website per working group I think it'll get a little messy so yeah it's I think we need to think more oh um because you'll end up with like I don't know wallets. ethereum.org and then you'll have like rip. ethereum.org and you'll just have a bunch of these separate websites and there might there might be a lot of them so I'm not sure if that's the approach we want to have I me know what other ones are they going to be cuz I I don't see a lot of them coming out of wood works yeah it's pretty much just wallets um layer 2 and core and erc's the problem is is that they're

just not eips or we haven't really come up with a definition of those two things that make sense to people and so it's just confusing to have e. ethereum.org have erc's but tell everyone oh no these aren't eips these are erc's and same with rips same with stuff yeah I mean we we created the distinction between erc's and eips so I think we we're partly to blame for that I mean I don't think that we were the ones who did that that sort of just happened by the community like we had this ERC category and they decided to refer to things as ERC 20 ERC 721 and so that distinction evolved naturally and

we at times have tried to like push them closer together but at this point like I don't really understand the relation like I know that you're describing these things as like they're still an EIP but to me that doesn't like that doesn't mean anything like I can see on a high level that it's an ethereum improvement proposal that's like ERC focused application focused but this is like extreme Nuance that someone really involved with this process doesn't quite understand and there's no way we can ask Community to deal with that type of new want so I would rather just lean towards having a much clearer boundary between the two

things sure okay I I'll try to consider that a bit more when I'm working on the um working group stuff please hi um hi everyone um here um I go by Ox uh magician website I'm just about like something around like M and Convention around so for a while now and I know this is like sticky in the sense that a lot of people like user love it yada yada yada um but I don't see the need for it to change as like a practical you know person usage level but I was wondering if we could you know we we can have eips and what I thought

in my mind as E's or like ethereum app standards um whereby you know the overall umbrella is an e and in es you have ERC so um you know whereas EIP can just be EIP it's like an ethereum improvement proposal um or E can even fall under like ethereum core standards if you will um but then fundamentally for erc's you kind of give them the overall umbrella term e app standards and then arcs can just be like the code words um or the code names for um etherum app standards um so it's a thought I had a while ago I I didn't mentioned on the magician Forum but um simply because I feel like ERC is still

very sticky but then if there is like an interest or need or want to like be a bit more defined between the two that I think we could start going with eum app standards and then ercs just become like the code names in every app standard so when so like oh what's an ERC we like oh yeah it's an eum app standard that's what it is um that kind of thing so just some thoughts I wanted to put out so you're suggesting like a new name for the ERC category a a new umbrella good exactly new umbrella name or a new overall term for the ERC category like we can still call them erc's when we're kind of talking about them um because those like

your code names but then overall um what was the name we we we could know them as um ethereum app standards so gradually eventually you're going to have people talk about E's um and then you know what like oh what's an es it's like just map standards like like 20 like1 but that way we can kind of have a path to delineate in between um an EIP and an ERC you know in in a more social way spiritually I like the idea of reorganizing the naming conventions um to make things clearer I want to be

really careful of like introducing even more cognitive overload kind of like what Matt was saying earlier where we have more acronyms that people need to get straight of their relationships so I think whatever we come out with at the end should be as sort of simple as possible even on the naming level yeah I think this is originally what I hoped would happen with this split and I was kind of overruled a bit because originally I hoped that we would completely separate eips from application standards and let application standards be their own thing govern themselves yada yada and now we're kind of in a different world where

the expectation is is that they'll still always be a part of this working group ethereum Improvement proposal world and we're still figuring out exactly how that's going to work out but I think as long as we are unwilling to let erc's sever their ties completely with this governance group then yeah I don't think that we can adopt another umbrella name around the RC's I think we can still have them separa tized completely at least from like I like the whole referring to things exclusively as erc's versus eips

and that they're now conceptually separate things in my mind is the direction that we're heading with the repo split and I feel like that's good enough um and then I don't think we should have like new let me just for the thought like I don't like the idea of having things called rips and wips and I think that's going to be really confusing I think it should be like a wallet ERC and uh rollup ERC and a defi ERC and like those are just ERC and that's the name for the E that um e was talking about um that would be my preference so I I don't have any strong preference about what they're called I I really don't give a what the abbreviation is I'd prefer if they were all eips I guess but um

like at the end of the day we're not governance really we just hold documents for people so I don't I don't see why we need to completely sever the the government stuff but this is opening an older discussion so I don't I don't really think we need to go down that road again until we have you know a concrete proposal on the table which is waiting on me so I'm sorry about that yeah I I agree with that let's not reopen the discussion I think it's something to discuss in the future but for now like let's just focus on I mean we've got a lot of fires to put out with respect to just making this split you know work out correctly so I don't know where that leaves us with respect to the

websites um I feel like it's much more straightforward to have separate websites and we can think about this problem more as we go forward and if later in the future we're dealing with three or four websites and we're like damn it would be easier if these things were all put together then maybe we can do it but I don't like the idea that we're opt early optimizing for something that doesn't exist yet E I see your hands raised uh do you have anything else to add or is it from the last one yeah just uh just a few last thoughts on this particular um topic um just around like how we can even

socially navigate um eips erc's um so I had after the after the split happened I had this thought where I said okay at the end day we're going to be doing eips and erc's but even at the paper level we're still going to be looking at an EIP for an ERC um so what about you know the key thing is if we're able to indicate to people what things are and particularly I thought oh why don't we consider like so for example you know how in the optimism Collective they have like two houses that kind of thing I was wondering in you know at least from The Magician's perspective started from magicians and maybe we can proliferate from that we can have two camps where it's like okay we have Camp um what's the name Camp core and Camp application or Camp EIP and camp ercn that way the document even

people are able to see that oh this is a cord this is an application um that way if they see some kind of even if they still see EIP in like the paper somewhere they look at a class or the camp and they see oh this is a core EIP or there's an application EIP although like would want to see an application ERC um I Shar the post in the chats to to to kind of give more Li to that but then also I think on the agenda for today there's like a topic on the Preamble so I think we'll Circle back on to just some of this um delation thanks thank you thank you everyone for sharing all thoughts here like from this

discussion uh I think I I'm getting that we are still not clear on website side um I checked with panda he mentioned that he would be joining later today maybe in in a few more minutes he would be joining so if he has changed uh perspective or I'm assuming that because he is the one working more on the website s and if he's recommending at this point that we can continue with one website we'll try to listen his thought as well and see if it is very difficult or relatively easier to maybe having separate website in future so just for uh people documenting notes we do not have any concrete decision as of yet we are hoping to have one website to go ahead with and look into other questions that we need to answer

today um one other thing that I wanted to mention from this conversation here I really like the the idea of division of erc's uh like ERC wallet and ERC RP or whatever else I'm saying this because you know we have one structure as of now that is documented in EIP 1 which is all about standard track EIP we can perhaps have uh whatever like we want to have multiple ERC categories we can have some certain standard track not standard track but ERC divided into different categories that is a separate discussion that um um Sam mentioned that would be clarified after the working group or the topic groups are created we can revisit that question but as we have on the

agenda today there is a proposal of having a separate erc1 I'm little shaken by this because as of now we are still having a unified numbering number allocation system we are maintaining it with a with a Google sheet in which we are trying to make sure that one EIP number that has been allocated to an EIP should not be allocated to an E ERC so I'm wondering like what people think about having this separate erc1 or is there anything that we can do to add information in the present EIP 1 and let EIP 1 be the standard document for reference for any category or type of eips I think we just need to give up on

you know erc1 being special and just pick whatever ERC we want and put the rules for erc's there and it'll just be some random number I I disagree I think we should either do E1 erc1 as separate things or put all of the content in EIP 1 for describing the ERC split and how erc's are going to be managed in the future but I think that like how erc's are governed is as important to erc's as EIP 1 is to core eips and we should keep an elevated status and not give it some random arbit trade number because I think that the category is that important or the document is that important but that's my

take we encourage for authors or or the philosophy we try to promote for authors is that numbers don't matter and I think we need to adopt that philosophy ourselves um just like there's nothing special about it being erc1 except for the fact that it's the first one in the repository but it's the living document that describes the whole process I like if anything's going to be special it's that yeah that's like the the number one thing that guides every contributor developer and even third party Observer who's like looking to wonder how to navigate this particular side of ethereum development I feel like that is very critical so yeah um I'm with the other gentlemen in that it is a valuable

um area to focus on and to get right most importantly um less you know newcomers and and even existing folks have like major issues is just trying to um find their bearance with erc's do we see any downside in updating EIP 1 I'm suggesting this because when we initially started with this EIP ER C po split uh there were a lot of proposals and we try to have that accommodated in the existing meta EES that we have for example the charter concept that was updated to uh EIP 5069 if I remember the number correctly and part of it was going into EIP 1 what are downsides of documenting uh ERC related changes because we do have a meta e that

describes that EIP repo has been split and uh yeah people can find Details over there well if we put all of the um like formatting rules and everything into e one um it'll get really really messy if the processes diverge so I think it's valuable to have separate documents describing each each group whatever we want to call them yeah um agree with uh with Sam um there's let me see if I can share this um page but you probably have the link to it already um with regards to even like the changes for that um in the

chat if you have something to share screen and talk about it you can perhaps do that oh okay um okay I'll first are we strictly discussing the arc1 document now but I can probably switch to my laptop and um talk more about it okay just give me a second switch to my laptop sorry okay perfect no problem uh so um I was just wondering like if e ERC uh specifications or the documentation process needs to be documented separately do we really need to have the same number like as ERC 1 I know we are somewhere around 7500 plus

can we give a a bigger number allocate a number which is different from EIP 1 like any standard number let's say ERC 10,000 or 8,000 9,000 whatever it works out but what I'm trying to advocate here is let's not have duplicate number for for ERC and EIP till we have number allocation process split as well I don't think that's an important Hill to die on um I I think that it's so much more important that everyone knows immediately where to go look for the process for how to govern an ERC or an EIP and having number one be kind of a special number that is allowed to be duplicate only to describe the process

itself is a willing and useful exception for the entire community of authors and editors Etc um I feel pretty pretty strongly about that but you know obviously that's just my take again wonder what editors think about this number allocation and then definitely we can dive into the details of it can you repeat it sorry uh so I'm wondering like what editors think about the document a or go to document for ERC do we want to keep

it EIP erc1 or can we come up with any other number which hasn't been allocated but kind of special in a way I really don't have that much preference to be honest so if Sam has a preference we can go with it my preference is we just write a document for ERC and follow the normal rules for assigning numbers that is the RFC way it seems if you look at newer ways of doing things in rfcs they just write an RFC that's the number and it says this is how we do this so I think it's okay

I to having a redirect from rc1 to that number but yeah I'd rather not not a bad idea yeah if it's like an alias that's good enough like to me as long as people can find it really easily the actual number to everyone's point isn't the important part it's that everyone's mental model of where to find this thing and what it means is elevated or special in some way but that can be an alias or a redirect that's totally fine by me okay yeah I'm fine with that so I guess the decision is we put it at the assign like the number from the spread sheet and then we redirect from one to that number

sounds perfect sounds good all right um wondering e is ready to share the doc yeah um so for those wondering I've put the doc in the chat but I'm going to share my screen right now um so um I believe you guys have uh access to my screen now yes we do y we're good okay perfect so this started off um as a yeah as a PR from um Joakim um I'm not sure if he's on a call right now joim LeBron but then I saw then I decided to kind of ADD and like polish up a bit flesh out a bit

into into this so pretty much like what's an ERC it defines the whole process but the key thing that catches um the the the what they call the potatoes and meats or chicken I think they call it is um what belongs in the in the ERC structure and particularly in its pre um so in the Preamble I decid to kind of build out a taxonomy so naturally you have a an like the field so inad of the field saying EIP it would say ERC and then you have the number to it title and as you go down what you will see um are two new field or um two new fields and one existing one I think fields that people are familiar with usually type and category now with um what was the name um with eips normally you you see

usual standards meta and information but the categories you see network ERC um consensus yada yada yada for erc's I'm decided to take a a different turn on that um a more dedicated turn into the app ecosystem app standards ecosystem so your your types remain the same standards track meta informational but your categories improv so categories such as token wallets um um token wallet D metadata standards um Haim include package formats for Library and interface um formats as well um for smart contracts and abis stuff and registry for um I think structur like stuff such as like I don't know like ens

stuff and everything um naturally this is um this is all these particular um categories are in the realm of like discussion and kind of further Improvement but then um the category is supposed to give a given contributor developer or Observer or researcher um a top level um View of where they are going to explore so if you if you're talk about ERC pertain to tokens you definitely want to be looking at token category if you're talking about ercs pertain to wallets you definitely want to look in the wallet category and then from there you can further add in um more Precision um based on subcategories so this can be nft ft like so fun fungible um semi fungible so bound tokens RW Hardware wallet software

wallet user Ops those who are familiar with like the intent base systems um account abstraction and so on and so forth also in the realm of um of improvements by the way subcategories are optional um but the key thing is that the better you can introduce a subcategory to your to your proposal documents your ERC proposal documents the clearer it is for people to understand what exactly you're touching on what exactly you are looking to um improve um so those are three key Parts I ended up um building a build a taxonomy so an ERC into a type um which I standard track meta informational also one thing to note um in terms of um the categories um for meta erc's it is

optional for standards and informational it is you know required that you kind of state a category and subcategory um but for um meta erc's it's optional um such as the first ERC itself that doesn't have a category um but yeah moving down into like the visual a itself so you would be able to know that okay every ERC should have a type standards meta informational and every type should have its categories and um every category should have a subcategory so naturally every C every type can have um the same categories as the other type um so yeah um standard track metod informational um I've added more information in terms of like oh how do you define these

categories and then you have like interface you have wallets um and a subcategories and so on so the the key the key idea is that besides that nothing else really changes like the the process flow in terms of statuses are the same um and I noticed um draim used like the old um how do you call it like the link into external repost and yeah he used like the client specifications I felt like a lot of these parts we could get rid of or we could kind of improve on but I didn't touch them because I was like okay you know they might be valuable but that's up to the room to really decide if like okay we should be um looking at De like consensus list I thought we could get rid of it but the

the the crooks of everything is pretty much like the new taxonomy which is geared towards application standards so um you know if tomorrow um adal decides or you know wallet decides to add in hello I think someone came off mute go ahead oh okay yeah so if someone decides to come in and build like a a wallet um ERC they have every opportunity to decide oh do we want to handle so bound tokens differently or do we want to handle um I don't know um account abstraction U matters differently they can always find that um I have to I actually have to improve this this supposed to say subcategory I apologize for that um but this way

you're able to have like this Precision to it and that way um everyone knows what is what to the to to to you know closer to the to the needle itself um I think this is like one of the valuable aspects of the entire ERC um what's the name guideline document and uh I I yeah I'm going to put a cap on that I'm open to any questions or thoughts or suggestions around that so have you compared this to uh Panda's tagging proposal so every EIP could be tagged with with one or more tags the Link's in the chat um and then you could build a taxonomy out of those links in the chat hang

on um is this the one Sam posted yes that's the one I okay one second tax so you just could filtered by topic yes no so I think this is so how do I call it if erc1 is the blueprint the tags are kind of like how you can even Implement them I think the tags would even work phenomenally for um subcategories especially because in the document um I make it clear that wait hang on where

are you yeah in the documents I make it clear that we would like um for um proposes so let me suggest uh other values can be suggested in proposal and reviewed by ERC so they can be suggested in The Proposal so I guess the tags are like a great way to kind of propose them and then ERC editors can then look at them and say oh it looks like you're trying to talk about this oh yeah this looks like a a good enough tag to kind of have its own subcategory that kind of thing um that way those who come in um are also able to kind of see what's already being used and also kind of suggest newer ones so I think um the tag in system is kind of like a how you apply onto the blueprint that is um this

particular um documents all right so yeah they work hand in hand I think yeah so I'll I'll take a good look at this this is an aor request on the erc's repository right uh I like to think so because I did the pr on yeah it is it is yeah perfect okay so okay awesome great awesome um I'm Wonder sense for every ERC to get its own tag automatic like if like if you when the be the requires header yeah that would be the requires header I think and we lost Panda all right I I

should I should improve that um requires header I I definitely missed that let me I'll improve that apologies for that that way it's a bit more clear like just from the document itself all right so I know we have a lot of other topics today so I want to make sure that we um get through them all um what was up next was this the EIP 5000 um what was the outcome for this sorry oh it's I'm going to read the PO request and then we can talk about it yeah yeah thanks for presenting this this was a lot of really nice content yeah I appreciate it right all right yeah so uh next uh thing was like oh okay uh we had this number 5,000 and then we'll get back um on the web page

rendering if there is anything else to be added here so yeah uh the poll request number here is oh sorry it's an issue number 284 yeah so this is uh profit ZX they're kind of um a very adversarial um participant in the eips process um and they are or we asking for transparency on the renumbering of I think everybody remembers that um po request uh and I post a summary if nobody objects I'm going to close the issue perfect yeah that was the idea of adding it over here I think uh the response that you have added here kind

of satisfies the question but it would be really nice to see if anyone else would like to add anything to that issue yes number 284 all right um there is one other thing before we move on quickly to hear your take Panda U as of now uh we heard that you are in favor of having one website eips ethereum.org for uh um rendering all the eips do you by any chance have any other thoughts or change your mind and and want to go ahead with separate reposit separate websites at this point of time

I'm not sure I can hear you gav if you I have your sorry apparently there's a fire alarm sorry all right no worries we'll get back moving ahead um we have multiple call for inputs I have added all those issues here the issue is still open till November 194 and 16 but editors are requested to maybe take a look these are last date where we can like you know close the issue with whatever responses we have collected but it would be really nice to get responses beforehand anything uh Sam if you would like to add on these calll for inputs oh uh sure I

can run through them um so yeah before we get onto too many new topics I just wanted to call out I think that we skipped the discussion for ERC 7539 um which was related to the EIP RC split and erc1 um I don't think it'll be a super long discussion if we can talk about that now or I could wait if other things are higher priority okay fine if it would not take long let's go ahead and quickly wrap that up that will actually uh conclude all the items listed there for discussion yeah so the quick tldr is 7539 is primarily useful for defining an

extension ERC which um basically extends the functionality of a pre-existing ERC in sort of a more strict sense with some definitions of what that means I made it simpler from Sam's comment and from discussions with the rest of the editors I think that we can even make it even simpler and include it in erc1 um so most of those discussions can happen relatively asynchronously but I think it's really important um the most important aspect of it is really a subset of the requires header which would be an extend header or extensions depending on which direction we go from

um and that would uh allow for very explicit forward and back linking between erc's which extend each other like ERC 4626 extends erc20 and ERC 7540 extends 4626 whatever we can talk about the details um on another time but if there's any major points that anyone wants to call out I think that the most important place to land is having some form of an extensions header even if it's not super formal how extensions are defined uh that's basically my position with why I made the ERC in the first place well thank you for sharing um as I

can see here in the comment like it is something um that maybe U of more relevance a post working group is implemented and there are a lot of things that needs to be clarified with respect to ERC especially when we are trying to have it with tags and having a different category so it's good to have the proposal on table we can perhaps have it discussed in future when we get clarity on the specification of erc1 if that helps yeah that helps I can't even pull requests from initial ideas but yeah that's a good place to land for here for now thank you so much and E if uh there

isn't anything further we can perhaps stop sharing uh oh oh sorry yeah um no worries at all and then now we can move on to call for input back to you Sam sure so um the first one up here is withdraw EP 7199 uh just reminding everybody about it um it's a rule that should have been an ep one and it's not so this is just to remove to withdraw that PO request the next one is remove external implementations from erc20 uh this one probably has a bit more debate on it um there are links in rc20 to particular

um reference implementations specifically consens and open Zeppelins and uh dexan raised the concern that that unfairly privileges those implementations um there's some you know question of of neutrality whether we remove them because it's final or not um so this is issue 287 um and the deadline is November 19th for comment on that um so another one that came up is ratifying the editors listed in ep1 so right now um we don't really distinguish between editors and subtypes of editors in our governance documents um so uh gajinder and Ben um there's been some

question as to whether they're full editors or not and I would like to um settle those questions once and for all uh so I have a call for input open on that um deadline is November 19th for comment um and then finally we have uh there's an accidental function that was included incorrectly in erc223 um before it was finalized um it's pretty clear that it was like a get merge error at least in my opinion um deadline for comment is November 16th on that one um yeah I think that's all of the current calls for input um yeah awesome thanks thank you Sam um and one point uh on that one of the call for inputs was

between distinctions of editors I have added here here a link of uh EIP editors and Associates so as of now there are uh two set of uh people who are contributing as editors editors are editors and there are a few Associates who are trying to support the EIP editing process but they are haven't been added as full editors kindly take a look at this uh Google sheet I have tried to add all individuals who have came forward to support ERC editing as well so people who are looking into both side of EIP and ERC governance or supporting with documentation have been

listed here based on editor or associate if there is any change pleas do please do let me know I can update it but I think this will give us a very good visibility of how many peoples do we have around uh in order to support the reviewing of erc's and eips can you add me to erc's editor please okay I will go ahead and do that yeah so there there's the distinction between like EIP editor as a governance entity or or a role so like and then there's the people who only look at erc's and the people who only look at eips um and that's kind of what that

call for input was meant for clearing up it's like who is actually a governing EIP editor all right yeah got it I can also act as an associate for the ERC did you I mean you are already an editor um you mentioned associate as an ERC by the way this is open for comments so please feel free to leave your comments if there is any mistake I think I me Jo you mentioned that there is a mistake in the name uh spelling I will fix it later on com yeah gaj Singh I sorry I I missed

that part do you mean to be added as an editor for ERC as well associate for ERC is better because okay okay then we may get a little bit more clarity on that part as of now we have added editors and Associates because those are the tags we are using in Discord for people to know but editors are people who are already listed in EIP one I hope when we get clarity on call for input as Sam mentioned earlier we'll be able to add it over there but I understand the intent is like you may not be actively reviewing but open to help and extend

your support if that's my correct understanding here yeah correct Perfect all right uh let's move on to changes to final proposals we have a bunch of can we go back to this website question because we got to figure this out do we have Panda back on go I don't know where he is but we got to figure this out guys we we split the Reps on Friday and it's a tire fire out there so I mean does it matter what we do with the websites right now as long as we get the rules for the markdown files consistent yeah I mean I don't think it really

matters so long as yeah I mean I guess it doesn't really matter too much I think it's a lot simpler to just go with the separate websites and have a link between the two because we just have to make the changes to the documents and if later on we're like we really just need this to be a single website then we can write like I think that's a lot more development work you need to update the website to support the different formats or you need to have some sort of um software that translates the erc's to the EIP format like I think that there's a lot more work to do there than just having separate websites yeah my concern is that like some of the rules we have in ew right

now do depend on the content like are we still going to have the rule that like a core well maybe the other way around an ERC can only reference Corey IPS that are in a more advanced status like like I can always seamlessly redirect I mean we don't really need to have a merged website as as long as the look and feel sort of gives a unified view to the user yeah it's true too so I don't know I mean there's a lot of things that can be checked in the erc's there's I have no I I don't know I don't really have a lot of thought on

exactly how we want to deal with that but I think that like right now we're not in really a good place where we're kind of asking them to put things that don't actually link to anything so it works in the back end with some translation we have and I want to resolve that ASAP I know more things will break along the way but to me the fastest and simplest thing is to have separate websites and we can go from there so the one person who is actively working on it and is not in favor isn't on the call Matt I'm not sure if we would be able to make any decision without that because in the last meeting we made decision in your absence and

that was different from what we are coming to a conclusion today okay yeah maybe we can take it on the Discord and see because there we will get this yeah I mean this is just this is terrible open a call for input and then we can put all of our on there oh my God we one or two websites and then we get to wait 30 days for axic to not answer yay is there a list of what's broken I

don't really understand even if it's not broken what we want to decide like let's assume everything works perfectly right so what whatever we decide let's assume everything works do we want erc's ethereum.org and eips ethereum.org or do we just want eips doeum org yeah but that seems like that can of wait but what's broken right now should not wait yeah that's what I was talking about we should come up with whatever markdown rules we want and then worry about which website organization later I mean is there any disagreement about the markdown rules so is the markdown rule we use ERC D whatever. MD in erc's and then EIP Das whatever MD in in

everything else yes okay we can make that work are there other markdown rules that are problematic the other main thing I think that I would like to change is to change the EIP and the Preamble of erc's to ERC yeah I mean that that would be fine or or we just change it to number that way it's not different depending on what type of file you're looking at yeah either of those are fine if you have a preference I really don't care but I think that yeah we need to make a decision so any final uh statement any from anyone on this one do we have a

decision or we are still working with the unified website will continue discussing on Discord and maybe come back uh with a decision for the next meeting okay so so right now it's um we'll keep erc's ethereum.org working and we'll keep eips ethereum.org working as they are today so both on eips we'll fix the markdown rules so that it's sane for authors um and we're going to rename EIP in the Preamble to just number the problem is we're getting to the thing that I don't want to do is write these like translations to convert them back to EIP whenever they get to the E's website to build the full website well we don't I'm not saying

that's how we're going to end up implementing it right I'm just saying like in the short term we might need to do that and then in the long term we might have something better how much cross linking is there between eips and erc's in the like split nomenclature that's a good piece of data we should get I think relatively little yeah probably something if it was it we need T store or we need create two and that's about it if it was close to zero then we could probably just like clean split everything and like kind of edit out those references or something I don't

know but yeah that's good data to get so well I mean the the cross link I think are going to have to use absolute links like I'm not really sure there's another way around that yeah exactly so if you want to link to an EIP from ERC you would just link to the Eeps website the website or the GitHub to the website because if you link to the GitHub then when it goes onto the website it will link to the GitHub and we mostly don't want people browsing the GitHub unless they're looking at the history of the e or something yeah it's

like if you're on GitHub you should probably like ideally if you're on GitHub and you click a link you stay on GitHub but I'd rather you know if you're on the website you stay on the website yeah that makes sense Dan you have to add something here yeah so when your last call if anyone had anything to say this whole process that we went through of splitting the repos I thought that two separate websites was part of the process and always part of the end goal to have ercs do ethereum and eips doeum so I feel like you know changing this last week so it's all going to one website is a very material change in the opposite direction inside of one week so I was always under the impression there was

going to be two separate top level domains and that is always what I was operating on these past six months yeah I agree with that I think I I I stand with we should have these two separate um top level domains um I think it's it's very valuable okay we'll get there um I know this is an hour here and uh I just quickly want to uh check on uh the next meeting time we know that uh uh due to Daylight shifting there would be different time zone here in in the United States not different time zone but the timing will be different do we still want to keep it at, 1400 UTC and

there is another reason is the rollup meetings that is going to be on exactly the same time editors have any thoughts want to keep it or have any other proposal I'm not going to be able to make it if it's going to be during the rollup call so yeah I'm fine shifting it to after the rollup call that would work for me that's actually perfect yeah but after the rollup call is the eof call somebody's going to have to look after the eof call then I mean yeah we're going to have some conflict I can do before roll call but I know that's starting to get pretty

early for some people uh I could do after the roll call I I don't mind like or we can skip next one oh is it just a one time oh it is I mean roll call yeah roll call Connects every month so every month on the same week of the month so sometimes it's going to conflict sometimes it's not well for the eof call yeah okay I hear that we're going to make bigger changes to the number of calls and days of calls maybe the beginning of next year so we don't need to go overboard on figuring something out right now all right so how about for next call let's do it after and if Puja if you're

running the eof call I can I can run this one oh no I'm not running actually it is Matt who is running I'm just recording it I'm just saying that because Matt again will not be able to make it I think that's fine for one call yeah I gotta go to the EF call now by the way but we need to figure this website out thing before this end of this week we can't wait till the next call so let's talk about it on Discord all right I'm gonna drop all right thanks guys so thank you Matt so finally we are going to be at the same time at 1400 UTC is that the decision for uh the meeting on November 15th I think we were saying after um R call so that would be what 13:30 UTC

yeah 15 oh yeah yeah no no you are right 13:30 I don't know on my calendar I and roll call are also conflicting so yeah that you're right figed out it's it's 15:30 okay perfect yeah all right so let's go ahead and do that uh Francisco I know we are over time but please go ahead and add if you have to add something over here yeah sorry um I had one of the items in changes to final proposals um I don't know if we can cover it now or I can make it super quick but basically ERC 1271 there is a small security concern um and we want to I I'm I'm one of the authors we want to update the security considerations and

the reference implementation but not the spec so since this is a final ERC it requires would require an exception how do we proceed with this so generally we discuss this kind of exceptions as you can see it is listed on the agenda for eipi meeting unfortunately we could not get to uh attend those today I hope those are being attended by editors async if not then we'll be happy to bring it up in the next meeting generally we try to get all editors on board for making any changes to any of the final proposals so if if even if it is security related we need to get all editors on board for that so what's the next step uh that I should do uh do you have a link to the

changes you want to propose since this it's since it's a security thing we're not okay it fully public yeah yeah yeah but I think you're in the telegram group I am yeah yeah I just wanted to ask you here um so I will make a call for input um which is like our our formal way of making a decision with a with a date and um I we'll let you know where it goes yeah sure um uh please tag me on on that uh sure what's your GitHub username it's frano I'm I'm also there on the agenda oh perfect okay

yep all right well thank you everyone for joining us today see you all on November 15th at 15:30 UTC have a great day