EIPIP Meeting 40

Transcript

welcome to eipip meeting forty um i have shared agenda in the chat the first item listed here is adding execution clients information at execution dash specs so for people who may have missed it earlier in the last all corner meetings it was announced that we have renamed a few github repository and discard channels uh the one that we usually refer to in this meeting is a eth1.org specs repository which is now renamed as execution specs i just added this item to

feel like how do people think about adding information of execution clients uh at the execution specs uh like i'm not aware of any particular placeholder where we can get all these information like website github link or latest version listed there for a new user to refer to so what do people think generally on this proposal um i'm bored i generally don't care what happens in that repo no my understanding is like people who

wants to follow the upgrade or someone who is interested in running uh setting up a new client or that so if we can make it a like proper information sharing place holder that would be helpful for people okay seems fine to me cool right so um i suppose this small crowd do not think that there's an issue with that so let's keep it positive uh i don't see tim on the call today maybe we would like to mention it to him

or check with the coders if they have any objection if not will start filling up with the primary information i don't think we need to check with him i think he's okay with it right uh yeah i mean it is for clients information so clients should be usually okay and that's right okay sounds good so yeah i i can look into adding primary information of the clients do we have any particular like place for that or read me should be fine yeah the readme is it's good

all right then we can do that moving on to the next item it is update eip editors i have referred an issue there which i found on the um eips github repositories so at the moment they present eip1 shows 10 eap editors though we do not have all of them being very active so i was looking into the history and um particularly three i found a name that i have not seen at least for a year number two number five and number six so um i was wondering like

do we need to have these people here listed and like get them pinged every time though they are not actively involved or is it the right time to update the eip1 it would be nice yeah i'm conflicted so um it'd definitely be nice if we had a list of vip editors that was actually like accurate and active um like for example if you were to ping casey detrio about something ap related you would not get any help right and so having a list of editors that

were like if a user is new they're going to start from the top of the list and start paying people until they get an answer and they won't actually get an answer until they get very far down the list because the active editors are the ones at the bottom um that being said like that list of people is basically a list of people who have merge rights and have a voice and so while i would like to pair that down to the people who are actively participating at the same time i don't want to like forcibly kick anybody out and so that's why i'm conflicted because i would like that list to accurately represent who the editors are and i would like the editors to be the set of people who are actively involved in editing and at the moment that's like two and a half of the people on this

list meet that i would say but again i'm i'm generally not a fan of just like especially since you know i i'm one of those two and a half people um i'm really not a fan of like using that power and saying okay i'm kicking out everybody else who could challenge me and now it's just me in charge that's why i'm conflicted like if i was a external third party i would say kick out everybody but uh michael matt and alex um because everybody else hasn't shown up to a meeting have it hasn't contributed significantly to the editing process or decision making or actively editing for

like a year but because i'm in the process i am very hesitant to actually make that recommendation because it might be just my biases seeking to secretly gain power happy to say it's not just you um i think it makes a lot of sense to split the list like i don't think we should delete them but just have like a section saying they're inactive or emeritus is the fancy word for that i guess right any other thought on that it it doesn't really feel like we need to do anything like i don't

think people are realistically pinging casey to merge things so it kind of feels like we're just like yes on the face it seems like a nice thing because we are in the process and we know who's involved and we look at eip1 but in reality no one else looks at eip one or the list of editors yeah yeah right um i just picked it up from the issues section where someone has actually requested to get it updated and like on occasions i have seen people listing all of those people like listed on the eip editors and

i think i like both the idea of having it like you know i'm most active people on the top and like uh then go downwards and people who are not actively involved i i'm not sure if their ids are even like you know valid or they should be pinged so we can update if if if no one has strong objection at least three names i can see here number two number five and number six uh which i have not seen for over a year we can do that and uh i i don't think i mean it should be it should be personal to anyone because i'm not an eip editor i think i can speak for it like micah said that he

wants to secretly gain all the power so um if there is no general like you know strong opposition on that we can probably update the list i have no opposition and while you're in there if you just want to remove my name too i would not oppose we can't do that we want to like process go smoothly we cannot lose one of two and a half at eip editors okay worth a shot okay okay

i think we are good and we'll try to go ahead and clean up this eip one and that would be good because we are making a lot of changes this would be one of those and i i think having this sorted out will help many new people who are trying to enter the process and document some of the proposals to be a standard for ethereum moving on to the item number three um so i'm happy to share that a number of open pull requests are now below 25 like it was like big number earlier but having it below 25 is very good progress i can say uh now we have more eip additives

actively involved like we have at least half more we are making good progress in this direction and um i am a little concerned about the open issues because as of today the number shows 485 open issues like which is significantly high i'm wondering how we can decrease this number and make this ripple look good and invite participation to address real issues like issues we actually want to discuss and you know get resolved so i have listed quite a few issues from that repository and [Music] if that's okay we can yeah this

i think that in order to get the issue countdown we would have to first stop encouraging and or allowing people to have discussion two links be in the issues right now our policy is to say either create a magician's thread or create a github issue for discussions too um as long as we have that policy there will always be i think a large number of open issues um also we tell people to start the eip process by creating an issue to discuss it and so i think as long as those two things are present we're never gonna get the issues down to close to zero like it'll always be a big number and so my strategy has thus far been just ignore that number um and just basically ignore all issues in general

i'm not against changing that though there's some caveats there like um we don't necessarily want to force everybody to create accounts at other services like they already had to create a github account we don't want to necessarily make them go create an account somewhere else just to create an eip which is why we allow them to do github issues i think github now has a discussions feature that maybe we could use instead which maybe is more appropriate i don't know yes uh uh that was on my list like the how to address issues like number one is like discussion tooling um i i think uh

we have made some changes to reflect that discussion to link should be the fellowship of ethereum magician because that is the place where most of the uh devs are hanging out to discuss any of the issue and sooner or later if we have like central place for discussion i think is going to be good not only to get discuss that particular proposal but to look into other issues which are like you know being discussed in the ecosystem and the number two would be address and close open issues like p issues that those are not like you know even if the pull request is done that is a standard or have been rejected but they are still there so we might have to look into each one of those

um i hear micah on on thought of like um not forcing people to have another account to create a discussion to link but um as much as i agree i feel that like having a central place for discussion is also good i'm curious if people have different thoughts so when we institute that policy github discussions did not exist you know discussions now exist does it make sense to keep discussion two links in github discussions and just stop recommending people go to ethereum

magicians absolutely so we'd achieve the goal of a single central place it's just that central place would be github discussions not github issues not to ethereum have you used github discussion so yeah i'm very cautious just because it's a new feature like what if they can it in three months because it's not a good feature um i would what's the reason we don't send people just to eat magicians um we want to encourage we want to i should say support um pseudo anonymity and the more accounts you have to create at various places the more difficult that becomes and so but allowing people to just have this kind

of accountant yeah i like it which is yeah that's what i do uh do you know what they ask for uh what the uh i'm not sure uh i can try to log out and log back in see if it gives me a prompt or something uh it won't give you one because you've already approved but i haven't approved so i can log out and log in and find out yeah in one second yeah yeah because i i would rather move stuff to like a platform that we own as like a you know bias towards that like obviously we still need to use github um but

um yeah so at a glance looks like it asks for email address do we know can we make it so ethereum magicians doesn't ask for an email address like that seems unnecessary if you sign it with github yeah it has an irrevocable permission for an email address it's unfortunate i can ask jamie yeah yeah i'd say let's find that out if we can remove the email address requirement then i see absolutely no problem with email address request requirement um like i can see the argument for why do i have to give my email address to some service that i may not trust um

github is you know well established ethereum magicians not so much and so you know the few other people you have to give your email address out to the better in theory if you're trying to remain kind of anonymous um now that's the general argument i mean this it's it's not a super strong argument but i can appreciate it like there are people in this space who prefer anonymity and yet they also contribute like it's not like we just want to do it for the sake of doing it there are people who i've seen contribute meaningfully that don't like giving out their email address or their picture or whatever yeah that makes sense i i just picked jamie i'll let you all know when i hear

back on that uh my personal thought is like there are only a few proposals which actually needs like a detailed discussion and most of the proposals they are good with like uh the pull request github discussion only although i i prefer that it is always good to have central place for discussion let's see what uh what it goes with the fellowship of ethereum magician but people at at the moment they they do provide a email address to github um and like they have one like you know one place where we are discussing it so if if there is like no

strong opposition by any particular author like we want to have it on the github issue to be discussed i think it makes sense to either continue discussion in fellowship of ethereum magician or if there is like small discussion needed and addressing just concern that needs to be fixed before the proposal can be moved to different status that can be addressed in the pull request section too i think you're in issues section really no almost no discussion should happen the pull request because they are transient they go away well sort of very close yeah i'm totally i'm totally fine with strongly

recommending everybody uses ethereum magicians we have not in the past i'm fine with changing that i do like the idea of giving people an option that doesn't require them to dox themselves slightly more agree it's like i'm hesitant to remove the option of github issues for the requirement because what that requirement boils down to is in order to create a pull request you must give ethereum foundation your email address more or less and at least that's how some people see it and it'd be nice if we can you know remain credibly neutral and say you know you're not required to give us your email address though we would really like it because we'd prefer discussion to happen there and if

we can remove that requirement then that whole argument goes away and i have zero problem then to be fair like i see like very small number of people who may have like not created an account with fellowship of ethereum magician but even if there is one user we should respect their privacy i'm not saying that we should force them to do that but i think in general recommending making it a strong recommendation going for fellowship of ethereum magician may uh you know in future help us people adopt this as a part of process and like they'll be fine with that okay

um so uh i had listed here quite a few issues which i found that like either may not be relevant to the present date or maybe something that you know we need to take a decision whether it should be there or should be close so my my question here is for eip editors of course like at what point we think that these issues are not relevant and should be closed because we have like limited number of people actually looking into it and leaving comments so i think my gut reaction is we just follow the same strategy for stagnant so

um if if there's six months with no discussion on an issue like this where the user is proposing some new idea um then we close it uh separately there are if it's a discussion two for an eip that has gone stagnant or has gone final we close it which i think would handle all these right well eventually we'll handle all these that's kind of hard to enforce how do you mean i mean just tedious or uh i mean of course we could write a box

to do it but that would be not very easy uh sure so i guess from a policy standpoint i i think what i described as defined policy i i have no intention of actually upholding that policy um but if someone wanted to like if pooja was browsing noticed one i would have no problem with implementing that someone implementing that policy does that make sense yeah right yeah i was more looking towards what policy should be and these both look like very good suggestion the one that we are using for a stagnant on the pull request the same can be applied on that i don't know if if it is technically feasible or not but

i know alita you had implemented some bot for the pull request section i would be curious to know your thought if the same logic can be applied here to reduce this number oh sorry alita has a mic issue she mentioned earlier in the call so maybe we'll get back to it later but in general uh policy was do people have uh like you know different thought i think uh in chat she just mentioned that yes it is possible and it can be applied probably so yeah the two points that micah

mentioned was if eip idea is six months with no discussion close as a stagnant if eip discussion to issue then we have to close it and if eip is a stagnant withdrawn or final right i think this will significantly lower down the number because there are many uh proposals uh which are actually closed they are in final status and their issue is still less there so yes assuming someone actually goes through and implements that policy i think i agree he'll lower number a lot yeah i think the first step here would be like if the bot leaves a comment that if there is no further action it will be

closed within a week time or so i am assuming that an author may respond if they are really interested into that however manually whatever can be done for the issues which which like you know which are new but uh they may not be the right fit for this particular place so i'll try to leave a comment on that and like you know we have people we can do that and uh for uh like in general response to bot i think we'll get some response and that would be helpful so there is this one issue which is a number

3604 um i am curious to know if there is any update on that i know it was brought into community's attention a while ago it's about update mobile layout to wrap versus overflow um i'm not sure if this has already been addressed or if this is something that can be considered for engineering [Music] i'm pretty confident that their problem is safari or ios for those who don't know ios requires all browsers to be safari even chrome and firefox on ios are just safari wrappers it you'll get blacklisted from the app

store if you try to provide ios users any other browser unfortunately safari um is very non-standard they are the for those of you that have been around the web for a while um they're the equivalent of ie6 no like they don't implement things right and they're very slow to implement things and these cause problems anyway this person said they're having some rendering problems which you know is a reasonable complaint but i don't have a ios device to reproduce so i'm unable to verify what they're claiming um which also makes it hard to troubleshoot and fix so so yes this is potentially an engineering problem it could be solved by engineering step one

though is just to reproduce it like someone with an ios phone needs to try and see if they can reproduce this problem do you have a link to the issue or something like like it's in the agenda the number is three six zero four three six zero four okay i can look at it right now as well so yes there's definitely a technical problem um just basically a incompatibility in the ui with safari is my guess it could be something else but um the person's screenshot indicates that it's safari the rendering is definitely wrong like that is not what it's supposed to look like

um so yeah so i just need to reproduce it step one verify the cause of the problem and then fix um i mean part of the reason i haven't done it is because i hate safari and i refuse to support anybody who uses that terrible browser okay yeah i think they work finance safari maybe it's just like the code when there's code sections or something but yes it's breaking on the print section only yeah that's fine for me yeah check out uh eip 721 um that's the one the user reported was the problem

and if it doesn't break for you then i'm okay with closing that as could not reproduce yeah they can just buy a new phone right that's a good kind of solution we are sharing here okay okay uh so yeah i think we'll uh we'll try to leave a comment i mean like if if any other user do not face the same problem even i will try to check it on my cell phone and then leave a comment in case it is like individuals problem then uh then maybe

uh this issue can be closed um so uh similar to that like that is the one um like we don't know what's going on like should it be open or not i mean should it be closed there is another issue uh i'm sharing the link the number is three five four eight which i think was related to uh one five five nine uh the proposal uh now that this is final and this thing uh this issue seems to be old i'm not sure should there be any policy of just closing it or how do we go about it uh so this is one of the examples where it's um basically someone has an idea for an eip and they're following the

proper instructions which is to start from um an issue and get feedback and so this is where i'd say follow the process we described above so six months no comments close it as stagnant and that will be in like october november or something yeah that can be an approach to handle these issues okay do we want to go by all these proposals and make a decision like is it the right time to close it or

i'd say let's start by just following the procedure we described and i'm totally fine with someone else just taking that up and making a call on them um the key is there's most issues will fall into one of two categories it's an eip idea and those in those cases it's someone who has an idea and they're proposing it to the broader ethereum community for discussion so they're just saying hey here's an idea let's talk sometimes people format this like in the eip so it kind of like it's an issue but it's like got the iep sections um the same same thing so these are just people with ideas for eips that are not yet draft eips they're just good ideas um for those cases just if it's been six months when no one's commented we'll

close that stagnant and again i'm totally okay with whoever takes this task on just handling that themselves i don't think we need to get like unanimous decision worst case scenario someone closes what's the name correctly we just reopen it the other issue to look for is ones that are the discussion too so if usually someone will say in like the link title in the title or something i'll say discussion two for eip one two three four um or something along those lines and those ones are usually pretty obvious they usually have a link to the eip and it says somewhere in there this is a discussion to link and for those ones we just would have to check the eip that they're referring to if it is in one of the the kind of terminalis states so such as final withdrawn or

stagnant or bannon would abandon whatever we called it then we would close and if it's not we'd leave it open and again same thing the first one whoever handles this task i'm totally fine with them just taking ownership and dealing with it all i don't think we need to run it by the whole group that makes sense i think there is i mean like if this is a different category here i i have just shared the number pr number is 3636 so they just write it like will that be and just idea category and we can do the same thing because it's difficult to actually get what they actually want to do with this like do they want to create

an eip which one three six one nine three six three six decentralized blacklist three six three six one second yes this one looks like an idea so this is basically someone who's saying hey here's an idea and they want to their plan was presumably turned into standard so this would follow the rules for six months no comments close the okay and you can usually tell us an idea just like if someone's just describing like a some solution to a thing um those are just all in my opinion fall into the category of ideas that people have people format them differently there's all sorts of

like some people form it like this so you'll format it like an eip some people just like it's just a couple of paragraphs um so the format differs but they all generally have the same theme of someone is describing a solution to a problem right that makes sense cool so um i'll look into some of those and i don't know we can check on the feasibility of getting it done with the help of bot and yeah we'll come back on this again anything else before we move on to the next topic not for me

okay so the next one is eip erc editors in training progress uh we had this meeting uh yesterday uh there were over a dozen of proposals which were like reviewed and light client and william left some comments on that one particular pull request that i want to bring it here is number three five five one i just have shared the link here so uh the question that we were trying to discuss there was like this proposal is actually uh proposed as an informational eip but uh editors think that it could be an

erc so what uh is like you know the general next step what is the role of editor here like do we need to strongly recommend to change it to erc how flexible we are like okay totally on the author whatever way they want to do that any thoughts here i don't have strong opinions about the training process i've been out of the loop on that um yeah actually this is like a kind of proposal because i have seen this type of issue coming like twice in like recent

days i understand that earlier it we discussed that it should be author's choice and like whatever category they want to put in either erc or informational or any other category of eip should be fine i i mean i am just trying to understand is there a way which can be helpful to authors to make a decision on that if they are a little confused or not sure of um so for eip for core eips it should be very clear like if it changes the consensus rules between the core clients and the core eip if it doesn't then it's not a core ap um for erc if i remember correctly i mean

i've been while i looked at eip1 but i think for core eips or sorry erc's it's pretty vague right yeah right the confusion is between an informational and erc or maybe an erc and an interface so like it was discussed last time like rpc related and like api related can be an interface but there are fine line and people sometimes get confused um for interface it's usually things like um you're defining a an interface for lack of a better word between two disparate systems like you've got two clients or two a client a server that

are talking to each other and you need a standardized interface between them because you have many many relationship so if you've got like the simple example is um like web browsers and web pages you have many web browsers you have many web pages you want all the web pages people talk to all the web browsers and so you need to have a standard interface that they can communicate across that boundary and so that standard interface would be like maybe the javascript ap standard javascript api for the browser um and that would you know that's similar in the ethereum ecosystem to the json rpc api where you have many clients and then you have applications that many applications that all want to talk to those clients and so again you have a many-to-many relationship and you are trying to define

the communication protocol between things on one side of that relationship and things on the other side of that relationship um erc on the other hand is um more i don't know years he's weird your c is basically like functionally it's basically standard contracts like which arguably are usually interfaces but if it's a contract in the evm then it usually goes into erc category i don't know if that helps at all yeah right of course it helps so yeah we are just trying to you know let people know that you can refer to eip1 but

there are some corner cases where they get confused and they come for help this eip3551 is one of those although it's just a pull request as of now it hasn't been merged uh so the author is trying to make it as informational and it seems like more of an erc um so we are waiting on author's response this is yours this is definitely new rc right yeah so we are just waiting on you know the author's response uh i suppose william left a comment and so did lifeline and we're waiting for his response and if he's like strong into

getting it informational i'm not sure if there is other way well that was one of the case that was discussed in the meeting yesterday i wanted to like you know have a general opinion here so that's all on the eip erc training progress the next topic here is json rpc api spec progress update uh i see arita left some comment on the agenda i know you have some mic issue so i'm just reading out her comment on the

chat jason rpc is the hidden berg at the moment i'm hopeful i'll be off the project soon more time for bots okay so there are some changes going on in the process and like the status of this project is in question and we are looking forward to understand what what is the amount of work left to be done on this uh it's not very clear at the moment we hope to see some responses from different team involved in this maybe we'll try to get back on the topic next week or in the next meeting okay um that's all

from the agenda and uh the last item on the agenda is from the previous meeting let's go quickly check if there is something that we need to do revisit the topic of version release process and documentation in three weeks can someone remind me what was that i missed it okay i'll look into it um number two was put the limit account non-eip on the next all core dave agenda yeah it was there and the good thing is uh the decision was quick one went into

the last call and the other one was withdrawn so that was a good progress there wrong yeah right i mean that was hanging for over six months and the decision was done like real quick it was good sometimes we just need to like bring it to attention at the right time otherwise it will be shared for another six months i'm glad it's over yeah so then the last decision here is document in eip1 and in the eip template not to have authors put the eip number

in the title that was related to erc proposals and the good thing is yes that has been updated uh the eip1 template readme file all these places have been updated with that and there is another change which we discussed in the last meeting that was about the uh description section so there is this change in adding the description um and that will be uh in the template itself exec has made the changes like on eip1 and the template itself so that's another information for people who are looking

into documenting proposals as a fresh like new proposals and that's all from the agenda item listed here anyone wants to bring up anything else nope so i had this one question um that i'm curious to understand what do people generally think about this meeting in sense like should we continue it bi-weekly and discuss these issues and like even if it is not too full it's fine it's pretty late it's fine we can

go early or do we want to have like a list of things to be discussed and have one meeting once a month that could be like 90 minutes or so i feel like we can probably do 60 minutes once i mean we can schedule it for 90 and be done earlier but is there anything that like would stall too much if we only discuss it once a month not as long as people are active in the

ap editors channel i'm totally fine with using like discord async communication um in fact i slightly prefer it they the problem always is getting people to engage so if people are engaging regularly in the editor's channel then i'm totally fine with just using that even or just having these just supplementary or once every month or whatever we'll have to stop letting people just use the eep editing channel as a chat room for finding core developers for their token forks but yeah if only i could code

um only this call wasn't recorded everybody else would have opinions okay uh yeah i think once a month we can schedule that for 90 minutes and worst case cut it short um does anyone disagree with that sounds good to me is is everybody who shows up these calls regularly in uh both the cat herders eip room and the uh r d eaps room the one that's bridge to telegram is that right i don't know no no no no i'm just posting you in the wrong place then because there's like an ipm i mean are you did someone invite you

into the scam no but there's a eip improved vip improvement proposal hq telegram room i don't know like i mean i don't post there a lot that sounds like a scam so yeah that was there when we didn't have this discard channel in place and like um ever since uh we have this rnd discard that most of the thing is mostly discussed in eip editing channel however we also have a channel on ech discord like eip editors where we sometimes discuss some topics with like

which do not require like bigger audiences so these are the two places where eip editing or anything related to eip is being discussed mostly so yeah i think i i mean i'm also fine either way i was also good with like having twice a month but like 30 minutes and like if it is 90 minutes or like have a bigger one is fine i feel like we have made good progress in like past 20 months when we started we had a lot of issues a lot of like challenges now that we are getting clarity on that and some of the issues are even brought up to the all core dev meeting i find that it's a good time that we can we actually

come up with a list of proposals or issues or challenges to get together and you know save everyone's time so i'm happy to reschedule it any any preference in that like you know middle of the month or end of the month we can start four weeks from now and then just have it every four weeks does that make sense yeah yeah sure same uh on a similar note i i'll be also curious about understanding how much engineering work is needed for like you know eip editing side do we see good amount of work that that

we have done so far or what is the frequency that we could see you're not looking hard enough like i could i could keep an engineer busy forever basically so i think the bigger question is um like what is the budget yeah right now we have we have like 20 hours sorry 40 hours a month we do and uh yeah we have to go for further funding so i'm just curious like should that be fine or increase decrease whatever what or

bounty based or whatever you guys think would be helpful i mean we can take uh whatever help we can get i think is is valuable the a slightly more interesting question might be um you know do we should the ethereum foundation or whoever is funding this allocate resources to improving the ap process versus other things in the ecosystem that need help and that's that's where things become a little more questionable i do think there's some high value items in terms just eip management that we could benefit from and most of those i think are already in elite to-do list like for the bot um one thing to keep in mind is that if matt is successful in achieving his

goals we'll hopefully be kind of not entirely moving off the eap system but we'll be changing it significantly like whatever our processes will change significantly and so we probably want to be careful about sinking too much engineering time into a process that hopefully is going away at some point in the future i know there's a lot of vagueness in those statements yeah i understand that like we have made good progress with the parts and if the process is going to be changing like like in next six months to one year time there's no point spending another six months in developing the part that we

know that will not be helpful so yeah i do think i do think there is at least value um regardless of what happens in at least handling a few of the kind of top items on elita spot improvement list um things like making it so when an editor approves the ip it will get merged and um making it so when an editor authors an ip they need another editor to approve little things like that that hopefully will be relatively small tasks but pretty significant quality of life improvements for us i think you think the eip bought the github where like brought his codes are there

issues section of that would be a good place for like people to report something and alita can pick it up from there um sure or the bot repo itself i don't remember where that's at least it probably has a link and probably a better place is if you have a feature request or a bug with a bot probably the right places in that repo yeah right ethereum uh slash eip dash part i think we can make good use of the issues section there and like keep on adding if there is any issue and you know people want it to be

fixed so uh from this uh is it safe to assume that whatever time is being allocated for engineering work like 40 hours a month is okay and we can continue doing that for another three to six months and if there is no significant change yeah i think we're all on the same page yeah that's good that's helpful now because now this is the time that we should start looking for like another

three to six months so i was just curious to collect thoughts and feedbacks and start looking into options so that's all for the items listed on the agenda today and we are almost at time so yeah thank you everyone unless anyone has any final comment or thoughts on any topic nope i'm sleep deprived so i'm going to keep my mouth shut since this is recorded all right thank you everyone for joining us today uh i'm going to reschedule this meeting like on four weeks from now and we'll update the invite accordingly thank you have a good one

yeah thanks everybody