EIPIP Meeting 65

Transcript

welcome to eipip meeting 65 I have shared agenda in chat and uh we have a few open pull requests and some issues from EIP GitHub repository here um for discussion and probably make some decisions so we can move forward with the pull request at least and then we'll get into the progress on EIP path with some eip's inside and maybe action items or decision made from the earlier meeting so let's get started the first one listed here is a CI added

markdown lender it's pull request number five three six seven I suppose it was added by Sam Wilson uh Sam if you would like to maybe talk about the proposal uh sure this is uh actually Panda Pip's proposal um the idea is to add a bot that corrects common markdown issues and tries to key people to the lowest common denominator of markdown so that it's compatible with different renderers um there's been a lot of discussion on that pull request already I think we've settled on a relatively decent set of lints to start and we just wanted to get some consensus before merging that PR

sounds good I don't know if Greg you have any thoughts to add here I know you earlier mentioned that it is related to bot um but yeah no um on late breaking agenda I noticed Sam is here so it could be an opportunity for he and I to discuss um the reference client and how that's going and how how we should be relating it to the EIP work since we're making progress on that as we as we clear through these other smaller issues that'll be maybe a good time for us to talk yeah okay I'll put a note on the agenda

for that okay good cool I I don't see any other EIP editor I can't see uh sorry light client or exec or anyone else Panda page did mention that he would be a little late for the meeting today however this pull request is by him so I'm assuming that he is definitely on board so um maybe we can just let people know one more time in a Discord Channel and move ahead with the decision sounds fair um yeah I I guess um we can go to the next one the math Jacks one

yeah I think that's a less contentious um suggestion it's just adding uh JavaScript library that can render latex um and I think Greg you mentioned you like like Tech so maybe that's a good thing to add all right no I think we lost Greg oh no he's still here okay um Greg if you want to take a look at PR number 5596 -5596 yeah

um so the idea here is like we are trying to uh make all editors aware of any changes which are proposed and also being merged by active editors on board however it is good to always collect kind of rough consensus from all the present editors so yeah if you have any thoughts on that yeah that's all so you're uh are you okay or not okay with um adding math checks I'm just asking whether it renders properly at

the end of the line oh uh I'm not sh I didn't hear you ask anything um yeah I've never used it I think it's probably okay I think it's the most common JavaScript latex renderer but uh we can we can do some tests if you'd like yeah I mean that's the big question the last time I tried to use it I couldn't get it to work but that doesn't mean it doesn't work it just means I couldn't get it to work yeah no I I know how that goes um I guess if there's anything in particular you'd like to see like a test of um put it in a comment on that PR and we can try it out okay I mean um eips are full of of math that winds

up getting you know sort of butchered with with you know asking math in line um that would looks much better if it was you know properly typed set um and snatches from the yellow paper and things like that um yeah okay well I'll I'll try to get it to format some stuff from um yellow paper yeah yeah maybe one of the other formats works better I really don't know I I don't know where in the pipeline that final that final copy gets rendered by what system uh Jekyll is the name of the renderer we use okay

so somewhere there's documentation for the the dialect of markup that it accepts yep somewhere yeah really really good system back in the 70s yeah it had its quirks too it it definitely did right but you know they all do we knew what they were yeah that's true that's true basically markdown is worse yeah no I I agree but anyway moving on wine wine um you're right just give me superscripts and subscripts

you know I know I know I know so I don't we have enough editors on today to talk about adding a new editor I don't feel like two of us is sufficient and I think I I think he's got enough good work that there's I can't imagine any objection but okay yeah I'm good with that then all right in that case we can uh jump over to the latest item that is added by Sam thank you and I I believe Greg also wanted to discuss that uh that's the execution specs yep so we're almost done implementing London

um we've got to pause so far on on discussing how we want to integrate it into the process um since you know the merge and core devs kind of wanted to break for about a month so um yeah there's not going to be much happening in terms of like what we're planning on doing uh we're just in the final stretch of polishing up the um while finishing you know catching up to Paris and then and then publishing I'm really happy that it's coming together [Music] um you may have noticed that the um that the VM oriented IPS are are all moving to python as the uh as the demonstration

language but I don't have even Theodore pardon have you learned python or I I can hack it out it probably wouldn't run it's but it's decent pseudocode that's the problem is it's it's not code that's coming back out of a tested client so not yet not yet well I mean that'll be an issue I don't I don't think I want to learn how to get that client running and yeah learn enough python to actually integrate code and test it into another client um but I can write through the code

that's good enough and it can be a bit better than that um because I'm basically stealing code from the Epsilon group um and it's it's better code um but anyway that code is not particularly related to the uh reference implementation because it predates it um and that could be aligned I don't think it can be aligned just by you know GitHub diffs um the code is there to demonstrate an algorithm um not to demonstrate a diff to any some other system yeah putting it in the

patch notation would probably clutter it up right well getting it getting it aligned um so it's recognizably the same you know the same algorithm in both places not gratuitously different but um the other trouble with the diff is that that client moves on so you've got a diff against some earlier version of the client um and that that works against the EIP being reasonably self-contained specification um but anyway that's one place where things things have moved to Python and it's a

question of how do we keep that python aligned with the um the reference specification yeah using the same notation to the extent that it makes sense yeah like same constant name same function names where applicable yeah exactly yeah same algorithm yeah one one of the one one of the scenario I can think of is that there was a recent pull request to update the um one of the parameter names to be consistent with one one five uh one five five nine I I just want to call out that that's a good thing because keeping parameter

named the same across different at least different eips is going to be helpful for readability and understanding yeah for sure I think having just like a a uniform language to talk about ethereum is a huge benefit one thing though about specifically using python is that I realized some of the early eips didn't specify parameter pipe like one question I have is for eip7 at introduced delegate call and vitalik wrote the there's six operands being taken but I had a hard time figuring out like what what length of those

parameters or operands needs to be python doesn't give you that I wonder if thoughts have been given to make it more explicit of the lens of parameters so if you're talking specifically about the parameters to delegate call the opcode itself they're all popped off the stack so they're all u256s um but in the execution specs we do use type to python so everything has types do we want to suggest or mandate that implementations in python as reference implementation should be explicit in type um I I think we can probably make that

comment on a PR but really it's that's up to the author I think that's like a um more of a Content thing than a like formatting thing but yeah we can definitely suggest it yeah I I I feel this editorial because it's uh like if you want people to adopt your EIP you have to be specific in uh in the type um so that the clients implementing your EIP is consistent across the board all right so I think some suggestion may work here you can probably leave a comment on the

pull request and that author decide on that but going back to uh the discussion of execution specs uh if I remember correctly a few meetings earlier we were on a page where we were hoping to have a meta for the changes those are proposed I am wondering the if we are there yet on uh we still see some discussion needed to be reaching their proposing status we have the same hack MD the timber app um we haven't really progressed beyond that yet because like I said the merge and awkward apps is paused for the time being right piano I'm gonna share the link

here oh you already did no okay I have shared the link to the hack MD uh that Tim has shared earlier for people to refer to I believe the changes has to be done on both the elmcl sites so we should look forward to the meta proposal that is coming up for the expected changes with executable specs thank you for sharing all updates Sam moving on to the issue sections um I have listed a few issues which I collected from the eips GitHub repository a few of them are created by Panda peep

I know he is not on the call but I just wanted to share with all the present participants if they have any thoughts that they would like to share or else they are always welcome to leave a comment there the first one listed here is new contract interface and EAB should be required to include a privacy concentration section this is by animusu um yeah anyone has any thought on this um I think we're a blockchain and we're not a shielded blockchain so I don't think um we really need to write privacy sections but that's just my opinion I am not a lawyer problem here

yeah yeah excuse me that's a good point all right um yeah I mean like obviously if there are some changes that people are interested in proposing any changes the next step would be to propose it and form a full request creating an issue definitely gives a good start so people can start adding thoughts over there yep and I think the next one which is uh eips should preemptively add a CLA is also by the same author I believe I I think uh panda is also uh in favor

of having a CLE with patents waiver uh I however personally feel that uh that I have concern uh that will make it harder to contribute to eigs and uh before my Mikhail quit I think he voiced a strong opinion about um not having CEO and clas um yeah I I I think my stance is weekly against having a CLA I can see the value of it but I can also see the the barrier it creates so I just want to hear other editors uh opinion on this I guess I'm weakly in favor of having a

patent Grant um I don't necessarily like the idea of having a separate CLA um and I'm also not sure I like Micah's approach of just ignoring legal concerns but uh yeah I'm not a lawyer again so I have no idea yeah um we are in some way creating the new legal precedence I guess I wonder I don't think Greg yeah Greg go ahead I don't think other organizations um go to all of this effort um

it's it's a lot to ask of an author to be signing off on all this legalese um if an author is concerned they can the author themself can add the legalese that they feel they need um but otherwise it's just being offered to the world um here it is yeah I think the concern is more on the side of um like consumers like if somebody's implementing an EIP they might be concerned that the author has a hidden patent that they haven't released even if the author uh is not is releasing the patent chances are

they buy infringe someone else who have not have anything to do with the econom right you can influence a patent have you can just run into a pattern without the author being both true so even if you so a client has to make their implementing client have to make their own judgment and research if they're serious about this I I'm in favor of the practice that we can recommend that EIP proposer to say that they release the patents so my take on the EIP is that it's an improvement proposal so therefore if you want to be adopted as an author then the

easiest for you to like the more the easier you make it to adopt it the better for you as an author and wearing a hat of uh of like editor or editorial contributor I would say making authors from different background the easier is to contribute the better for the entire EIP repository so that I would say using that argument I would try to Advocate that we can recommend but not make it at a mandate okay and I also have shared the link to um a document created by Panda peep in

favor of this proposal so yeah people may go through and probably leave them or comments there but I agree with that I definitely agree sorry the recommendation is to create an optional CLA or no no what Victor just said I I think uh I'm in aligned with you um uh Sam in that uh CLA might be a little bit too much uh so we can have something recommended in the content of EIP e um yeah just like a little note in the copyright waiver section yeah so you're

optionally sign up any pattern that you're aware of and you own but like as a as a group of EIP repository we don't require it uh little mandate it that would be my suggestion I wonder if that's a country yeah I think that's reasonable um would you mind putting up a PR so we can discuss the specifics of of what you're suggesting did uh um the CLA uh issue be a good place to continue the discussion yeah yeah I'm just saying like a PR would be good to actually put the like just decide the actual wording okay okay that sounds good yeah I can do that great

thanks thank you moving on the next one is it at EIP it is proposed by Panda peep looks like a new one not really new seven days ago but there is a proposed change uh to EAB number if anyone would like to take a look or have any opinion on thoughts on that the number is five six five two okay we can if anyone has any thoughts they would

like to share right away it's fine we can we can discuss that otherwise um I have shared the link uh probably we can add comment over there the next one is a dynamic required approval so there is some proposal of okay how many approvals should be required I'm gonna share the link here uh that is five six five one issue number five six five one again by Panda peep so this is this is the more complicated

um approval system that Mike had proposed um I don't think I have any problems with doing this I just think it's complicated um yeah I wonder if the suggestion is to be using bot to get this thing done like yeah yeah it is it's to have the bot like change the approvals over time or the required approvals yeah I mean if this has to be done by broad um even if it is complicated and it can be put into like codes and can be run

then I think should be fine right so we can probably the next step would be to have um couple request to the EAP bar repository to maybe see if this works okay now we we don't have panda on call uh so maybe we can bring it up later the last one here is uh automatically merge all new eips and the number is five six four one so I'm a little torn on this one because

a lot of eips still have um like mixed up motivation and rationale sections in in the first draft um but you know the formatting has certainly gotten a lot better lately um so maybe we do this I don't know actually I have to have an opinion proposal I feel like it should not be merged as dropped on by itself without a reviewer reviewed by an EIP editor even if body is doing a good job I believe there is manual intervention needed at least for two statuses number one is when it is merged for the first time as draw and number two when it is merged as final I believe that we want to create a

standard so the first pass as draft is also very important as we have the final pass as final because we don't want to spam our repository with all proposals getting in as draft and it never goes through different statuses and never reaches to final that will swell up the repository I mean it will add a lot of maybe not so useful proposal even if they are syntax wise correct it if they even if they are drafted properly so that's my thought on that I think that's a really good point I think it just convinced me that we don't want to do this I think a lot of VIPs get abandoned in the draft stage and so the only time an editor gets to review it is before it

gets merged as a draft so yeah I think I'm against this yeah I think we want to encourage people to um start from bigger ideas on The Magicians um the starter of discussion from something closer to an EIP and let things die on the vine there um but people will work the way they're going to work um and we no longer use the issues for that purpose like we used to right I would agree so the best way is to like encourage people to start and

have more discussion on Fellowship would be like pre-draft section right till it is being washed yeah yeah an actual pre-draft status might might be helpful to keep those sorted out um to make clear that this is you know this is an intended EIP now this isn't just a general idea to discuss and then maybe not assign an EIP number to pre-draft until they actually go into draft oh definitely do not assign it okay that's an interesting idea yeah I think that's absolutely no number do not call it an EIP all it has is a title right and unless we are at a point

EAB number Ed signed by a year I think it we can also call it in the form of pull request I mean if not the title because title sometimes could be hard to find but pull request number is way easier to find it it can rest in the pull request yeah there needn't be a pull request it can it can live at the it you know the very top entry in a magician's thread um it can be arbitrarily large marked down uh and editable so it can and it maintains the history so um a draft a pre-draft can be maintained there for discussion it doesn't need any

help uh from GitHub foreign [Music] looks like he is around to have to join this meeting we can uh probably move on and see when he joins and if he may have any thoughts to add we can get back to this one uh but in the essence of time let's move on to item number two I'm assuming that

we do not have any decision or do we on this topic if I could back up for a second to the patent issue I looked at the Creative Commons license again and it it specifically says that it does not um does not affect patent and trademark and I think that's appropriate um that we just not have a policy uh it's simply a specification we don't endorse the specification we don't certify um it's simply that and it's totally on the user of the spec

um to um to be aware of any patent or trademark issues and it's perfectly fair for the author to hold patents with the intent of of you know licensing patents that's that's fair it's a specification that's all it is that sounds fair and I believe the next topic that is listed as here for formal discussion is about license and yeah what license to use for EIP assets we discussed this in the past but I believe there were no um conclusion or diffusion on that and we wanted to have a little bit more of

discussion here so yeah um some if you would like to give a little bit background on this topic to just chart the memory of everyone here uh some editors want to force all assets to be cc0 and I I don't want to do that I want anything that isn't um copy left to be allowed for assets Greg do you have any thoughts on this I'm not a lawyer again I mean um on a high level I personally

think that when we are talking about ethelium and we are talking about having something as a standard and giving place to ethereum repository we should try to make uh things uh as much as open source free no patent no like trademark things so people can use it freely ethereum is an open source blockchain we are like trying to I mean anyone is welcome to come and use it so why to add things which may or may not have a permissions to be used or reused actually but that's my thought on that I would be happy to hear other uh editors yeah that that's my thought as well like if somebody

wants to come in with a and mandate that you have to use a certain algorithm and an EIP and then you know a year later they start suing everybody uh because they patented that algorithm I think that's completely ridiculous and we should try to avoid that situation like and now we are joined by Panic uh Panda we were discussing couple of proposals by you issues that you have listed and one of the latest one which is currently under discussion is about the um patent and also the use of license for EAB assets I wonder if you have any thoughts to share on that

sorry didn't catch that second part um so it's about the uh license usage for years yeah you sound fine to people I don't know if it's something on your own Panda but it's it's definitely me I'm right next to a road right now and I'm outside and on really really bad internet and a bad computer okay not a problem um if you can hear me now now we were discussing the allowing patenting staff or maybe assets which may have some trademark already or should it be only which is

free for people to reuse license issues if you have any thoughts on that but you can share it well I think it's pretty obvious that well I mean for one thing all the uh all of the uh assets should be sorry all the EIP should be cc0 uh just so that anyone can just use an EIP without having to worry about randomly being sued um like in any case um and I feel like patent and trademark uh waivers are just like kind of an extension of that you should be able to use an EIP without having to worry about randomly being sued for using it right that looks like General

thought process of some of the editors here too so yeah and this is probably particularly relevant for core eips because you don't want ethereum itself to suddenly get talented yeah I don't even know what would happen in that case maybe we should include like some patented image algorithm in ethereum just to see what would happen foreign Ty with that no we can't expect that okay um is it fair I just think that's too much to ask of an author um

patents are a Minefield uh you can't you can't help but violate them at Oracle Engineers were not allowed to look at patents because the penalty for knowingly violating a patent was three times the penalty for unknowingly violating it um so it's it's just a Minefield the author can't be expected to do a patent search um and it's unfortunate um but it's just a risk that um that the client teams take I think part of the defense is simply that

they're they're if they're not being done for money um so the particular patent waiver I added is basically the authors if they have any patents uh that they use in the IP then they aren't allowed to sue anyone for using the EIP well they should disclose them right now they're not obligated to though that's true so basically just means that they don't they can't patent troll it has to be someone else a third party we yeah we specifically we specifically say that we have nothing to do with them

um so I'm generally in favor of just leaving it as it is [Music] um I hate putting more requirements on authors and we haven't had any problem yet um I I feel similarly as Greg I I can see the value of requiring patent to be granted or be disclosed I feel it's a little of a tool too much to ask and also you can't prevent someone who propose an EAP infringe someone else's patent uh if they're not aware of so I

think it's yeah what I'm suggesting is that basically the pattern waiver I've added is that the authors can't sue people for uh for their own pants other people can other other anytime that it's a patent not owned by the authors like say like some some random third party they use some random third-party uh images image thing that's lies that is uh patented the authors had no idea uh the patent waiver wouldn't apply there since it's specifically the authors this clip and authors is uh rights that are waived not those of the third party

[Music] I I mean I'm not in favor of uh have it optional and make it a convenient way for people to waive the patents um because as author if it's a sincere author uh the easiest it is for the adopters the better for the EIP so any sincere author would try to make it as easy as possible but I coming from an industry that cares a lot about patent and IPS like for people like me I'm not even sure if I were able to contribute to EIP anymore if there is a mandate for patent

granting because of uh other type agreements that I have with for example like my employer so that that's the background so I I when when Greg mentioned that in Oracle employees were not even permitted to make a patent search I I totally resonate because that's some other trainings I've seen as well so I I think we're entering a space of legal practice and uh none of us I I assuming is a lawyer here on this call I can see the value and a good heart behind it but I think we we need a

little bit more we might need a little bit more expertise uh in in a call for uh for making it such a strong decision I think optional is definitely valuable like making it optional I think is definitely valuable to be yeah all that PR does is add it to the template authors could absolutely probably just delete it I I've seen authors sometimes change the cc0 to something else which oftentimes gets very quickly corrected sometimes it requires a bit of prodding um in terms of the agreements with the employer

um that applies to licenses too you have to get permission from your employer and that explicitly states that in the cc0 license that you have to get permission from your employer if it might be the property of your employer yeah um cc0 is much less like I agree that actually required I could agree I I am I am weekly in favor of requiring uh there to be unaware present uh um I I think another thing here is I don't think I want this optional um because I think that would create more uncertainty in the minds of people implementing eips I think we should

either leave it completely unstated and that way no like everybody knows or doesn't even think about it and it's up in the air or we should do it for every EIP uh if we have some eips that give you a patent Grant and some eaps that don't that's going to make people really hesitant to implement eips that don't have a patent Grant so I think it's better to just to just not or haven't not in between so why would that be a problem if people are more hesitant and hesitant to use erps without a patent Grant what's the problem and that they absolutely should be more hesitant well then they shouldn't they shouldn't be in the Eeps repository basically it's like we want eaps to be as open as possible and if we're considering patents for some eips we should consider them for

all eips if we want EIP to be as open as possible why are we even considering not having a patent because we're we just want to ignore the whole patent issue entirely we're just assuming that there are no patents and everything is open and free and as soon as we acknowledge that patents exist we should acknowledge they exist for all eaps I guess that's fair let's keep let's keep the pr open but yeah yeah exactly we're using the CC uh we've been using it for a while it's no problem it's been carefully crafted by lawyers in this domain it's got precise language on patents

um and it's carefully just saying we have nothing to do with that this is a specification follow it at your own risk yeah and also Patton is a very jewist jurisdiction specific thing um I wouldn't be surprised if there's some even some jurisdiction that doesn't even consider patents uh could a protected thing uh it's it's very widely used in the Western and in in many countries but I I don't think it's a natural thing as well um so maybe leave it to the implementers and their own jurisdiction to determine

whether uh patents in their place is any specific patent is still valid in their own jurisdiction right um so as part of it suggested we can probably keep this one open or the school request open if we have pull request number I don't see it added here on the agenda and we can continue discussing on that looks like we have provided opinion here it would be nice to collect thoughts from other editors um

anything anyone would like to like add to just wrap this up and this topic in their sense of time probably we should move on yes please go ahead panda let's wait for there to be a lawyer on the call background but I am not sure if she is ready to be talk talking on this topic today um shivangi if you have any thoughts if you would like to share anything uh hi um yeah I I've taught International contract law and uh um intellectual property law for many years so I don't teach anymore

um but yeah it's a complicated topic so uh I would rather not the basically what I said in the chat that it may be easier to just talk to a practicing lawyer who's more familiar with the ethereum community and can give good advice that sounds like a fair advice coming from a lawyer obviously we can expect this uh so yes if people are more interested we can probably reach out to Foundation team and see if if there is any um scope for change uh though Greg already mentioned that it was crafted very well taking into considerations of all legal

aspects so we should have our trust in there but because this is open source because we always one come changes um it's good to keep this open for some more time and let's uh hope we get some traction from the foundation side is that a fair uh like Midway to move ahead gonna be sounds like a good idea cool thank you very much all right uh let's move on to the next topic which is EIP bot we have a few people on the call I know there are some progress going on um I would say if you would like to share any updates

so there's the EIP bar there's the other kind of Bot I'm working on which is eipart but faster and a bit less code and not automatically tested so that's probably something that I'm going to have to uh add sooner rather than later main upside a bit I think more simple code base uh also works with deleting files um the ability to add or remove um basically it kind of works uh pretty simple simply so adding new rules removing or rules modifying them really like that easy they're all in one

place separated by file name um downside of course it's been manually tested but doesn't have automatic test cases which is something that I think about it probably should be added before it's merged uh as for the EAP bot itself uh a I'll leave it to you thank you well we closed the issue 34. it was beyond a marriage that was a last week I just test the the issue 63.

which concerned the fact that the deleting the EIP 5000 in that time through the EIP 5255 actually it is no problem with the with any of the two existing Bots the EIP double double b and the EIP bot uh you're very common in the in the issue 63 respectively and there therefore you will you can see there the the test

[Music] um why the the bot didn't fail I mean basically just to Briefly summarize if you're gonna delete any IP file you are not gonna delete it right in a file without the AP1 format claiming to delete any EIP file anything it's straight it's going to be tried to be merged to the EIP o must follow the the rules and that's why basically the

the bot in that time thing not not precisely because they were not uh go ahead go ahead that's not entirely true although the CI was failing there uh EIP bot was also failing uh because uh in in the code it's assumed that firewall always exists when a file is modified I added changed or deleted it'll always be accessible the problem is when it's deleted that's not the case uh it uh when it when the bot calls the GitHub API returns a 404 not found and if you uh go to that pull

request um hold on delete right well I I don't know about that I was I was testing this and basically when you delete a file the the AIP bot doesn't even start because the AP bot activated with the pull request number which is associated to a file sorry please which is also Associated to the file that presuming contains in the IP just to finish the same case goes with

the EIP double b if the Rules start following following the template for the for the file if you want to delete the file you just go and delete it you you try to to merge it and it's gonna be uh EIP Double Double D is going to check the the template the aipbot is not gonna run and the CI will run we should just need to consider the fact that there is a a non-existing file what you're trying to or delete it file what you're trying to match I mean those uh of course you can uh write a you can write another bot

or okay this bot I just just as I comment in the issue just to consider the fact that you are the the pull request that you're trying to to merge is just uh from the from the fact that the file doesn't exist I mean that's it there's that that's it that's the best case but uh as it is is not failing yes it is they're both well objectively yeah um that's fine whatever you say like kind of I've determined that this is because the and I have determined that this is because the uh PR that's updating pip uh 23 35

uh sorry whatever it is uh the diamonds one the one that updates that deletes a file uh deletes the two files actually it's failing with the exact same error I once created a PR to update my AIP deleted the found assets folder it failed for the exact same reason it's very clearly because it's sending a get request to the GitHub API they fetch the contents of a file which no longer exists that is the reason why it is failing admittedly there are other reasons why this particular PR can't be automatically merged the eipw issue the uh issues and the hit more proofer issues uh both mean that if that if we wanted to manually merge it it

wouldn't work but it is a bug that you cannot delete files even if even if you modify your own EIP delete a file in the assets folder erpw sorry not erpw uh Erp bot will currently error because of a bug where it tries but that's a different but that's a different issue that's an ID that's a 92 which is not uh not the fact that the leading the EIP file which is the issue 63 that that's what I'm testing on and speaking about what you're speaking about is the is the leading a file that belongs to the naip that's a separate issue that I haven't tested but I just

tested is the point on the IP file and I use great testing right now and and I mean it's no problem they are the same bug it is the root cause the root cause for both is the same I happen to know this as a fact it works for your IP asset files it works for uh just random files when I when I deleted and added new CI files it through the same error and it's from the same error for when Erp uh 5000 is being deleted the idea that the aip5000 well 5000

wasn't deleted for the box is because you were not deleting the 5000 but you were doing was trying to match another VIP that was wrongly configured which which was the the file that was brought I just wanted which is which is so which is totally different to the case that deleted any AP file I mean you were trying to merge the the EIP 5255 which the third line was delete EAP 5000 that's not the I mean that's not gonna the bolts are gonna fail due to the fact that that's not the way that you run and at least that you want to include uh I don't know that that you want to include

a condition into the EIP one that said that when the fire sale when the file says the delete an AP uh you're going to have a particular case say to to analyze the the bot I mean to to make the boss wrong but the reason that this what you're saying is true because uh that's not that's a separate issue but the issue for deleting an EIP file is exactly what I test I I haven't tested your case to I mean to refer to what you say and I'm quite sure that if there is the issue open for that is because there is a bot actually we discussed that in that time when we were reviewing the the open issues but for

this issue for deleting a an EIP file from the EIP repo I just tested um but next we considered into the CI what I see is the case that the that that file doesn't it's not going to exist anymore but I recommend that this should be done I mean manually I don't know for any of the editors or whoever is in charge of uh which is a person that are the editors whoever is in charge to maintain the AIP repo Integrity but uh yeah I see what now you understand what you say you say that that's like the other issue that we were discussing uh one or two weeks ago

um yeah that that issue I haven't get them which is an ID 95 95. sorry to interrupt here uh Jose and panopy that's okay that's okay yeah looks like we are getting into weeds of this uh technical uh proposals pull requests and sort of issue probably we can take it offline and continue discussing on the get the repository yeah uh we are on time like we are one minute past the time uh we would like to quickly wrap up this call if that's okay and we can continue discussing either on the Discord Channel or on the guitar pull request

so thank you yeah thank you Jose and thank you benefit for sharing the updates I would quickly like to like just check on the agenda item we do have VIPs inside and AP editing officer for EIP editing officer the second meeting was conducted yesterday it went well we discussed a few pull requests and try to help some new Authors with their questions I would encourage more authors to join meeting if they have any question concerns or if they would like to learn anything about the AP editing proposal process and for eip's insight I have already added uh the link in the agenda

on a very high level we have five proposes merged as draft and we have two proposals in last call with um a deadline for proposal 5528 which is refundable fungible token the deadline is 16th of October and there is another one which is uh 4834 hierarchical domains and it has a deadline of 30th September so if you are in if you are adapt developer or anyone interested in either of these proposals would have comment or suggestions or would like to reach out to author this is the time before this proposal move into final status

so please leave a comment either on discussion to link added to the EIP um and yeah I think that's all the time we have got for today's meeting thank you everyone for joining us today I hope to see you in two weeks from now thank you everyone have a good one