 perfect timing. So I'm going to share my screen quickly here and again just go through what I outlined as kind of a quick agenda. Again I was mentioning last year we did our last yeah oh my gosh feels like a lifetime ago we did a fun little retro with a live audience at the last club summit to get feedback for so the work that MPM is doing and how we're working with community and our also to get ideas on how we can introduce new collaborators and new ways of collaborating with the community and so I do have a reference there for the RC process that we've had in place for the last little while and I would love to essentially use this time to get feedback if you have or haven't you know made a proposal or seen that RC process or you know maybe it's been intimidating or you just don't know about it yet I would love to get feedback about the RC process itself in this session and I would also love to get some you know soft kind of information out of this discussion about how people are using MPM today how they can be using it tomorrow which is why I suggested we could do another kind of retro if we want to and then I want to also touch on some feedback that actually John noted the other day to me and a DM just had noted that sounded like Express has been able to maybe widen the scope and ownership of folks who can help triage issues which has been a big problem for our team for sure we have a very small team right now that's dedicated to the project compared to the larger community that I hope and think wants to get involved and so there's some ideas there potentially that we could introduce some sort of like community team our community triage team that could help and that could be a step forward to a more sort of a different state of a collaborator that may you know eventually become a maintainer and how that looks we could have some discussions about that and then as Bradley noted it'd be great to discuss also you know tighter coupling with node I totally agree and think that that would be good good discussion so how do folks feel in terms of this as agenda is this okay yeah some head nods and stuff so great what we can do is I'm gonna put together a little retro board I'm gonna put these three items these sort of like three buckets into columns and then I'll let folks so custom demo we're gonna say you get to watch me stumble around my screen for a bit do do they pay you just kidding you love yeah it's super easy to get started and you know we've been using it with our team or we used to use a lot more with our team during our retro retrospectives it's just a quick and easy way to get some some fun fun feedback I just like the idea that also it's anonymous so when you're giving a feedback here I think people are a little bit more open to be more transparent and we got some funny feedback I know at the last summit some fun feedback ideally you're kind to us we're doing our best here so I'll paste the get the link here paste this into chat just so everybody has this as a reference and then we'll time box sort of the feedback part of this feel free to add comments in each one of these sections so what are what are features you wish the MPM CLI had it doesn't today how do you think we can improve let's say the RC process and if you don't know what it is maybe that's even the item that you'd like to bubble up is that you know visibility or the communication of what that is you know and you know don't know and we don't do a good enough job to show how that can be used and the process and then also I would love to know beyond MPM install you know what is the most used sub commands that you find yourself using so so we'll go through this I'll time box it to about let's say five five minutes feel free to start adding blocks in here and then what we'll do is we'll take some time to then go vote and also merge things together and discuss the feedback so feel free to take about five five minutes right now to start adding things to the to the board and I just want to give a thumbs up everybody has access or know and so yeah as you can see like the cars should be hidden until we put the switch so does anyone have the script to scan the bash history handy I was just googling that but I don't know how to I'm looking at the clock in order to get my sub commands these things control our is that and I should note here just quickly as people are starting to add feedback we definitely are trying to focus on maybe CLI specifics I think in the future we're gonna have a better understanding how the registry in the CLI that that relationship how that can involve in the future we have a whole team dedicated to work on the registry and we've you know bolstered the folks there since we were since MPM was acquired by Github so yeah just want to be mindful that that's sort of the frame a reference work frame that I'm hoping to get feedback from especially since we have a bunch of folks from the CLI specifically on this call about like one minute left of people feel like they need a couple more minutes of time you know it seems like there's still a few coming in maybe I'll give folks a cup like two minutes two minute warning a list of features that you wish MPM had is growing quite sounds like we all as a community have a lot work to do well I struggle a bit because some of them are just needing node and MPM to talk more not necessarily on the MPM itself sure I think that's completely valid awesome does anybody need more time so quickly what I'm gonna do here is turn on the cards okay so I'm gonna take the next couple minutes we can sort of go through these and try to emerge the ones that we think are duplicates or essentially similar and then we can go through a process of as we're reading through this feel free to you everybody gets about six votes so feel free to just thumbs up what you think you know Alliance and is most let's say important to you across the board here ability to publish multiple packages from my repo so you know this is this is a huge one for sure deliver code cache modules disable only install scripts allow running other scripts tell me what intrinsic modules were able to be loaded from code that was installed some way to do full updates of all of the latest major minor private staged releases to increase the font here but so I'm actually gonna use my votes here ability to do GitHub and MPM release from single-command yes I also agree that's great our all-story scope tokens yeah MPM in its people use tabs command to see check the latest version of all our depths in it asking about app first package publishing packages Billy host you know packages on MPM yes I agree I'll ignore wow okay that's I don't I actually don't think there's a lot of I think there's not a lot of overlap unless other folks are seeing at least in the column of features they want to see they'll do here oh I'll ignore is ignore specific an actual audits failures yeah so let me see if I can do this I'm gonna stack rank these so they're sorted by top votes yeah I think a lot of this there's a couple in here that I think we've already started some discussions around specifically the audit audit resolutions I'm not sure if the person that made that knows that there's a sort of an RFC an outstanding RFC that we're trying to break down into two separate proposals one for audit resolutions like a audit resolution schema and either file or change to well probably like an audit JSON file that then we could utilize to silence needless audit warnings so that's actually in the backlog awesome so let's let's take a couple minutes also to essentially did anybody want to talk about anyone of these so we certainly we certainly have used the internal API the JavaScript API for the MPM CLI at work being nice to have one that is a little more polished or stable it's gotten better with the libmpm stuff but yeah it's a little bit wonky it's getting even better we hope so there was a major refactor done primarily you know kicked off by Isaac back in the summer with a project called Arborist which is essentially the going to be an MPM 7 quote-unquote MPM Street doctor so essentially that API should that project alone should really help with being able to do interesting things novel things in user land tooling and I think it should be and I think that there's definitely a takeaway here to make sure that documentation is better for for those steps that we we own for a lot of people the MPM CLI is the only project they know about and they don't know about those child depths like like the libmpm projects that we consume ourselves so it's good to hear that there's people in the wild that like want to use you know want to use the same tools that we are I can vouch having used it that it is much better than the current state but I also want to encourage you all to think about how it can be even better because there's a bunch of places where I have felt like bringing Arborist is the you know proverbial bringing a gun to a knife fight right like it's like that does everything right that MPM needs it to do but a lot of the tooling cases that I've been working on and I think a lot of other folks like I'm sure Jordan can talk to this it's like really you actually need the tiniest little sliver of it like like load the real tree or load the ideal tree and then like iterate it right which when you are doing that with Arborist very possible and much like I said significantly better than it is today because with the MPM six dependencies you just can't really do it but also like I re-implemented some of it and it's like twice as fast because it's doing half the work but I don't need it I don't need the other work right I'm just trying to do some simple analysis right like what I think Jordan did with the what was that package that you worked on Jordan that used Arborist LS engines yes exactly is Arborist Arborist is really really really very awesome it's a great improvement if it delivers on the promise if I if I does what it's meant to do it's it's just going to be a game changer in terms of no longer having to run minus or F node modules every time and I haven't tried that function just yet but in addition to Arborist it would be nice to get an overview of all the other modules in terms of how they're going to progress because we've well some of us have heard about Arborist since that it's coming and that's awesome but some of the modules may be getting deprecated may be getting moved and it's because there's a lot of them it's it's kind of tricky to to remember all of them and to keep track of all the ones that are available I think the the script writing stuff I think there's at least two or three different generations of that under different names as well yeah we have a to do right now to index essentially the supported we have a maintained section maintain dependency section in the wiki of the CLI so if you've ever gone in there there's some documentation and all just quickly jump over so folks see this and this list has not been well maintained and we need to do our job also to your point on getting an understanding of if some of these things are going to become deprecated or or not deprecated but like we won't be using them within the CLI necessarily you know what what does it look like for long-term maintenance of some of these dependencies so this is a good list if you're wondering you know what what are some of the depths today that we consume internally and this is sort of speaks to also what Brad was saying like you know there's some things in here that we know that the community consumes outside of the CLI in their own tooling so we we're very aware that the surface area that we support is a lot larger than just the one project right so it's that's really good feedback I think that it goes to expose that we need to be giving even more visibility into the status the state of these projects and their future so like road maps etc. release schedules all that so go ahead Ra. I think just to speak a little bit about the point Wes brought up we definitely have already no radar to do some refactors on Arborist I know like we want to break down especially the other data structures like split like split like so like definitely there is some Arborist like refactor on our to-do is there an issue though like Wes you said specifically you thought there was work to be done either in the API itself for the documentation did you feel like you can create an issue against the project itself and just yeah so it doesn't get lost I can I worry because it's so influx like and and every time I bring it up to Isaac he is very aware and has said yes we have plans so I don't want to like pile on and I also don't want to like repeat things that are already top of mind but I'm happy to if I just don't want to you know I don't want to I'm already a squeaky wheel sometimes so I don't want to make it worse no I think one key key thing there and what you just said and what we're trying to do is we and us like like I want we want to change we versus like us like as a group everybody on this call you're giving your time right now and and interested in the project and I'm giving feedback and that that's huge so my hope is that like we continue to have the lines blurred in terms of the maintenance of the MPM project and people feel like they can contribute and that the road map is something that they're affecting and that you know the work that's being done you have our ship so I'm interested in those types of conversations of how we break down the walls of like you know there's there's some innate like road map or understanding of where the project is going that only we know which the is the dedicated team that that seems problematic to me so I want to make sure that like we start to break down that that kind of like you know feel free to create an issue and we should all have a discussion about it right yeah I will do that but I don't want to promise a timeline because no I don't want to also like yeah yeah okay but I will do that that's awesome is there anything else in this sort of like features so the top two or three maybe it would be good to look at JavaScript API for publishing packages this is definitely interesting this is a that's written in JavaScript we do have it live in PM publish right yeah I'm just wondering like what what the outcome of this is like pack and then I guess I can even turn like yeah this three week I added that option so we use JavaScript for publishing and PIM packages and we use we call CLI from our JavaScript so if there is a house API we can just call in PIM API directly for publishing uh I see I see I see like we are to create a charge process and call the CLI command to do publishing or other NPM projects okay so okay I see and you are potentially able to do that with live NPM publish today I haven't explored it yet thanks for the link live NPM publish right and take the loop yeah do you share thanks Ryan I don't have the chat open so folks have been hey what's called here oh awesome thank you Clod it she's been working on that a bit recently um okay a better off story scoped off tokens web off flow this is I think this is definitely something that we can improve kind side is 2020 you know I think we can definitely do our job there's even small improvements to the off token experience that we have today so it might be longer term especially because this is dependent on the registry and what the registry supports in terms of enforcing that off and and let's say scoped off tokens this is uh for folks that don't know this there is an rfc about stage publishes that mentions scoped off tokens and so that that we think might help address maybe this kind of feedback that people want a more sophisticated publishing um uh at off work flow okay uh the next one here and now maybe we'll touch on this the last one unless folks want to bubble it up and then we'll move on to the how we can improve the process some way to do full update of all lives the latest or major minor um full update so is this similar to ncu like no uh check updates is this the idea there I'm not sure the exact oh I see so instead of just having npm update and a single package you would just do npm update dash dash all maybe yeah yeah exactly just uh with uh with every token you you can define your npm install but sometimes you want to let's say try to upgrade everything and even if it's break to test and fix it and it's let's say some kind of big project or the stuff or monoribo and stuff like that you need to update uh every depth uh uh with the latest or everything to to remove the let's say the dashboard or every symbol you want so it will be I think it will be a great addition to to be able to even if it's break everything with a flag or something like that to be able to to update everything to the latest uh maybe you choose a latest major or latest minor it depends but something like that uh the reason why I re-implemented some of arborist was because I just implemented this okay so for what it's worth this is a very good thing to have and this is what we're going to be rolling out inside at netflix uh yeah I have my script to do to do that also I would love to get feedback from the group like do have people also use like other tools like I know I've used in past also like node check uh I think it's node check updates ntu and ntu dash you yeah I use that one and I use it all the time man I've always like questioned why isn't this just in npm I feel like this is I think the other thing too is coming from just other package managers I've always expected npm to do that and then I was to remind myself when I'm away from node for a little bit then I come back like oh yeah doesn't actually work that way it works this way I gotta go use some other libraries to update everything so it just seemed odd so I think there's a couple things there one I think you know the community is clearly saying that this is I use that too like by the way I work on npm and I use it I think there's a some opportunity here because we have just um I think we've just ratified the dash dash all um uh flag for I think it's um is it uh I forget cloudy it's for npm outdated or what is the command it was sort of attached to the npm on yeah that that flag so instead of oh because we were removing depth so um that all flag I think would make could maybe help in this regard um but I think that you know we historically I don't know the context going back to when uh update was originally created but the I think the idea here is that we want to respect your your semper range um and so to be very explicit about when like what type of updates you want to to have might make sense so dash dash all and then latest or something like that might help yeah dash dash dash dash break everything if you're looking for a name something break everything yeah break everything this is the current behavior I think for some of her it's fantastic but sometimes it's not enough like I think it's a great defaults so yeah I don't think we would ever change the default but I think that a way to opt in to break everything um or just truly give me the latest um yeah this intro fixing fixing the bugs in the default would be great so there's some behaviors that the default does that just even though yeah saying we won't we will take those what you wanted right that which is is is what you're saying is the default but unfortunately it doesn't actually work right if you say you wanted 1.0.0 it'll change you to care at 1.0.0 right and that's so like so I don't want to harp on the bugs there I want to I would prefer to present an alternate universe and and talk from there which is what I've been working on yeah I hope that some of that nuance is going to go away here soon um between our yeah with our best between the LS update and outdated we're also looking at potentially some designs for for how we can merge those views because we've had those discussions about what's the difference between outdated LS um you know you're just showing a list of packages like you know what what's you know different states um for each right so but I also think that one one of the issues with the current thing is that it's not really thinking about it as a holistic workflow it's thinking about it in sort of these isolation pieces right like like the description here is I want sometimes to break everything right that's actually a user story and we don't really have a coverage for that so we have like this outdated and and updated and because the the we're thinking very low level when that was implemented it's like well outdated tells you what updated will do well actually that's not really what people always want right like there's cases where we run updated multiple times so you say you run outdated then you run update then you're an outdated and you actually get different results you don't get no no no response anymore you get like totally different list of dependencies right so it's like a bunch of workflows here that weren't thought about in a holistic sense they were thought about really in like this well updated does what or outdated does tells you what updated will do right and that's just not what the user actually wanted yeah yeah okay I want to quickly just time box this so we can get to maybe the rc processes and then I feel like only a few folks actually got to the that last column to unless everybody just uses npm run or npm just install and that's the only thing they use well real quick before you jump reds um sure is there anyone on the call particularly the npm folks who hopefully will be looking at this chart later who doesn't understand all of the green items because some of like either the person who posted or someone else can probably fill in and so like I don't entirely understand the demo ones and would love some elaboration for example I think that's great feedback let's maybe dive in just make sure that yeah or even if we don't have the time just a high level overview I don't want to deep dive into any of them yeah yeah but even maybe it's just uh I mean at last just leave a comment there you can where the person can like explain a little bit more but like like you say we might come back to this and will be nice to have a more context at least yeah so the ability to host a demo packages packages might be specifically the one maybe you noted um I'm not sure if anybody else has ideas of what that would look like hi I had added that hosting demo packages on github or npm so currently github if I release any tag version then I can download that ts file in dino but then there is no guarantee that it is immutable there is no guarantee that it's immutable uh immutable can be changed right so there should be a way for package authors to publish a version on dino so that the published version becomes immutable how isn't dino's url model though like that's an important intrinsic part of its design like that seems like something dino would have to alter because it's always a url and every url is always mutable yes so uh the url like the contents of url you mean right use my request was the contents of url should not be mutated once it is created like for example in npm I add a tag to a package and I publish to npm then if anybody downloads that package uh from npm it's always guaranteed that that particular origin will not change but that's like a contract between you and the server right like like that's an implicit part of the npm protocol but it's like yes yes so there should be some locking mechanism introduced so that when dino publish is done and the url is hosted on github or npm that uh version is immutable but once it is published okay so you're essentially asking for a like something that works with dino that provides the same immutability guarantees that npm does yes okay thank you that was I just needed the context can I get minor clarification is the expectation that you would need to have a unique url for that version or are you seeking okay so if you go to dino package.com yeah yeah like that or dino package.com yeah and yeah this is a definitely interesting interesting idea we've had discussions with unpackage in the in the past and we've actually tried to start to uh provide features similar um historically but um again that's that might be a or larger discussion to have with the registry folks down the line here um but I think I understand yeah go ahead mouse if I could add one thing that I think it's really interesting in the story of of deno here and I think this is a great example of where like npm as a team needs to collaborate outside of just npm um publishing to deno land right now to my understanding is adding an entry to a json and then like it sets up uh redirects um so and deno itself kind of like prided itself in its initial initial release on the fact that it did not have a package json that it did not have these things um for what it's so for what it's worth um this is in no way me saying we shouldn't make that npm shouldn't offer something for this community um or or something like unpackage that that publishes the URLs but a great example would be like a deno package as it exists right now generally doesn't have a package json doesn't generally have a main doesn't generally have like a lot of things that we talk about potentially even already validating unpublished um to the registry so there'll be some interesting work to be done in kind of like meeting um ryan the deno team and the people who are working in that ecosystem like where they are to figure out like what does publishing even mean um to your ecosystem and what do you want um I think similarly um in the cdn like approach like something like unpackage is very unique and awesome in that like hey like we could kind of break everything apart but as long as modules are using uh bare specifiers and those bare specifiers are not coming with an import map to resolve it the exploded packages are not even useful so it's like um again I'm not saying we shouldn't explore this I actually think it's one of the most important things for us to explore and have a story around but I think there's some really interesting questions to be had about developer experience and kind of like what it means for that ecosystem to be engaging that requires kind of all these different stakeholders at the table and I should also add to that if any folks didn't see Miles's talk um at the OpenJS world I think with um I forget who was also on that uh call their mouse uh for export maps like as it seems to like land in this as well certain seems like the web um the web or the front end module story is starting to look a lot more similar to nodes um and and there's things interesting there too around like web packages and signed exchanges and bundles and like there's so many other technologies that are being worked on um I think there's a lot to think through about like what the future of these technologies looks like yeah yeah there's a lot good uh references that I even picked up from from your talk so um okay I apologize we're we're running late here uh and low on time um is there any uh any other items sort of on this list that may not be a self-explanatory that we want to to bubble up here in the green section at least so yeah I think you can actually kind of merge the frozen intrinsics one a little bit with the audit um filtering just having any sort of audit filtering quick defaults would be nice uh manually filtering would be painful so the intrinsics with the where's the audit sorry is it audit got pushed way up there yeah sorry because like with frozen intrinsics you don't get into the prototype pollution noise usually so so can I ask here you're you're asking for some layer in the process to do some static analysis on the source being bundled into the tar ball so that we can tell which intrinsics are being used by the package that's a different issue no frozen intrinsics is just a way of basically doing things like freezing object up prototype so prototype pollution is technically possible but okay but in order to do that right so so you're trying to skit npm to tell you if this package would be affected by that you would need to see if it modifies one of the intrinsics right um no because the reports generally state you know this is a prototype pollution attack it does this it's part of the oh just for the cv but npm packages aren't even necessarily code or javascript right like it's just a tar ball in a manifest in a name and a version like so that like I can see how that's useful for some reason they got flags because somebody yeah because somebody had had sneak thought that it was a fun idea to yeah yeah i mean cv is certainly like largely incorrectly or hit npm modules but like they could be command line they might not be javascript right like it could be you npm install something that gives you english instructions to do something bad and the cv is on the instructions right like I could see something like that maybe getting hit by a cv at one point so like well I think totally see the utility here like it feels too tightly scoped for what npm generally does to me I think it's something prototype pollution in particular is a lot of noise on it it totally is and that's like that's a huge just like and so like I perverse incentive of the way that the security apparatus is designed but like yeah go ahead sorry I particularly just want to have some sort of sane filter that hey I see this problem comes up a lot node introduce the flag to mitigate it just have a list of like things that are mitigations like you're using like attach it to the the cv itself and say like here is the fix instructions or something or if you're running with this it don't warn on it or whatever so this goes back to I think as well probably to your idea of like being more tightly coupled with node like npm should have a tighter coupling with that a downstream support that right or is that sort of aligned yes so like node is updating features in response to like noise from the npm ecosystem and like there's there's just not back and forth that as those features land in node there's no way for npm really to communicate that right now that hey there's a newer feature please just use that if you want this to be quiet sure I just want to be mindful of time because we're essentially getting up there in terms of the rc process itself I would love to to take back this feedback and potentially if you feel comfortable feel free to add a comment with your you know ad and I can follow up with any folks individually or we can have discussions there I'd also encourage folks who haven't been to one of our calls to to join us we've been trying to run our discussion weekly so similar to sort of this roundtable that's sort of we've had today and a little bit of a retrospective is a little bit of a shift from what we normally do but it is opportunity for us to have discussions like this about features feature work that we should get to and things in flight I do also want to quickly just note and thank John for for poking me about the idea and concept around having a team of community-based folks that are willing to get into our repos and start to help triage issues and that just means labeling and maybe helping contribute to give feedback and also PRs is there anybody on this call that has any interest that I could tap later in terms of maybe being a part of that team I have talked to you I may be able to supply one or two I'm in the process of leveraging that process as a part of changing our organization's behavior let's change that's interested don't put my company's name down there that's part of the rules okay um feel free to add yourselves to let's say a list if you're interested in getting more involved or potentially seeing what it would need to be on that team and then I can follow up with anybody after this call to see what that might look like I'm definitely interested in expanding as I said the sort of circle of folks that are contributing and I appreciate everybody for contributing today their time and feedback so yeah I appreciate it I'm gonna stop sharing my screen now did anybody else have any like sort of last notes or comments they wanted to give so I was just wondering if everyone would be clear about code cache is that something you would know what it means uh is this towards a little bit upwards upwards upwards upwards are you there maybe I can deliver code cached modules go ahead bro are you asking for the delivery from the install to be the cached form or because v8's bytecode cache is per architecture um so it's not portable or are you asking for um the code cache to be generated when it is installed so I would be fine with both ideally it would be already generated upfront so that it does not slow down the installation process um and and then during install it could just be checked what system it's currently running on and if it is already there or not otherwise you would have to generate it of course um but even if it's just done um after installing that would also be already great because um node js startup time is one of the main issues for big applications and this would improve the startup time and the ideal place out of my perspective to do this is uh code cache modules so one thought that I have here that um don't have an answer to but it's just like a question I've been asking myself as um selfishly I am like ramping up on product at npm and thinking through these problems in that capacity um but kind of like where would it make sense for npm to draw the line on what they offer as kind of like official products versus like what are base capabilities that npm needs as a platform to allow others to build interesting services on top of it uh I think a really great example of something like this is um like pika and the work they're doing with like pika and snowpack so um you know like pika is doing something where they have like an alternative cli that is able to you know like transpile modules for the browser at install time so to um kind of what you were saying there um ribbon about like code caching like I personally feel uncomfortable with the idea of like the registry of record making any large changes to the source text that's being published by an individual um but I see no issues with on one hand like having tools in place that um allow for like kind of optimizations pretty uh publication or allow for all sorts of like interesting ways of handling things uh during publish or alternatively you know like enabling services that can take published assets and then from that kind of do these optimizations at install time um but I'd be really interested in kind of like other on the other people on the call's thoughts about like kind of where npm should draw the line as a platform and what what is the responsibility and I guess the other flip side to it too and I don't see anyone on the call who's running any of these other registries or other products but kind of like where is the line to ensure that we're also allowing for innovation within the ecosystem and not just trying to be like the whale that eats everything yeah I have a thought to share about specifically at a product vision I think even like uh I would love for us to even have the the capacity to maybe just have like alternative implementations too right where we consume the internals but in a different way right so that we can be like more exploratory and even make sure that we have a core that can be reused across like competing uh clients right uh so I will yeah that's some of the things I have in the back of my mind I would love to have a more time to play with for sure I just want to be mindful of folks time we're about five six minutes over and I know this is the last session of the day again I would encourage everybody to join us again in the weeks to come here at the open RFC calls as well as hopefully discuss you know this session and other sessions in the Kiko chat as well as there's the slack channels for the node project as well as the OpenJS foundations slack channels so I would encourage everybody to join us in those channels and feel free to poke me if you have any other feedback you want to give but this session or sort of npm in general and also feel free to poke miles or anybody else that's on this call as well so yeah with that I want to appreciate everybody who stayed till the end here thanks Michael for for also jumping in and recording and we'll try to jump over to I think is there a last session or a sort of another call that's happening here at the end of the day if you folks know looks like there might be the end but might be the end is well I mean I don't want to go out with a whimper I'd rather go out with a bang here with the club summit was the last thing on the list so well I can say this it's my birthday today we could we could drop to the central garden and see if people are still around oh yeah that'd be that'd be fun I know for myself I actually also have a hard stop so I'm not sure if other folks it's Friday here in my area so I'll be taking the weekend off and I hope everybody's staying happy healthy and safe wherever you are and yeah I just want to say thank you again and I enjoyed a lot of the sessions I was able to participate in and I appreciate when we can get together virtually and especially when we can get together in person so cheers everyone talk to you later right bye bye