 All right, welcome to the June 13th, 2023 airs cloud agent Python user group meeting. New way update and update of the BC gov code with us in DCO is doing. Talk about 082. And PR is in general. Acropy plug ins we want to talk about that update on progress and plans for that and briefly talk about adding a new maintainers so those are the topics today and anything else people want to add a leap space for adding other topics in a moment. A reminder it's a Linux foundation meeting so the antitrust policy is in effect as is the code of conduct. Everyone is welcome, glad to have you here. If anyone wants to introduce themselves. Feel free to raise your hand or grab the mic and let us know who you are what why you're joining and your interest in acropy. As well if anyone is interested in adding a topic to the agenda, let me know, and we can adjust the agenda for now. All right. Let's get started in the announcements area reminder of the documentation page that we've got. And this Thursday I'm doing a presentation at the identity sig on the ZKP is the high school math edition. So if you're interested in knowing a fun topic, going to a see a fun topic on DKPs, please join. All right, let's get into topics. Daniel I didn't check in with you but assume you're ready and able to chat about what you're doing. Yep, let's see. So this week the big news is we've completed our quote unquote MVP revocation. So we've got all the pieces in place finally that we're able to string them together manually, and are able to issue credentials present them, work them and present them again with varying, you know, revocation intervals specified and everything's turning out as expected which was pretty big. A number of our factors required along the way there. So that's, that's what's been taken a significant portion of our time. Now that we have this MVP status we're moving on to implementing the automated registry setup process. We've discussed previously, and we've been building to this point. So I anticipate that it won't be too bad to take that next step and and get the automated portion put together. I do anticipate that there will be some additional refactors and refinements required along the way, but pretty optimistic that we'll be able to get that set up pretty quick. That we're working on or anticipate over the next little bit. Revocation registry recovery is something that we have kind of just ignored for a moment as we worked on other things, which is the process of catching the ledger up with the wallet. If there's ever a time when the wallet is updated with a pending revocation but that somehow failed in the process of getting it to the ledger. All that code is pretty indie specific still at the moment. So I need to go through and and. Genericize it, I suppose. And get that working with the ledger agnostic interface. Also, looking at what it's going to take to either adapt or retain the original Indian non creds interfaces. Trying to figure out where the balance is there still. What needs to be changed altogether to just use the new interface or what do we want to like actually stay behaving exactly the same way as before. But okay, I say that poorly. The, the act by controller interface should remain exactly the same. That's the goal, but like what under the hood needs to change, I guess, in that process. So things we're considering at the same time are, you know, like, do we retain both systems. If we don't retain both systems what's the upgrade process going to look like to transition the records to look like the generic non creds objects and stuff. So there's some questions to be answered there so we'll be taking into that. Aside from that just general need to update some tests and cleaning things up so. Yeah, making good progress, looking forward to, again, knocking it out and getting this taken care. Yeah, okay. Okay, any questions for Daniel from anyone. As I mentioned, I've linked to that that project update hack and document. I go into slightly more detail than I did in these bullet points in the agenda if you're interested. That's all links to PRs and such. So. Okay, sorry just writing a note here. Okay. Finalizing the 082 release contents. Let me take a look at where we are. Hopefully the screen's big enough I'm experimenting with new screens and ways of structuring my workflow and the screen isn't usually this big but hopefully that's okay. 082 was released containing everything, obviously since 081. So there's a fair amount in there. There's sort of the list of things I guess I easier. There's 081 down here so there's a series of things obviously the change law covers what is in 082. Since then we've merged two other items, a fix for threat ID and a basically a filter on unregistered did methods so these two were seen both valuable and useful. So this is an issue with this in AATH it appears to be in this change. My guess is it's probably something with the test harness itself as opposed to the library but we've got to obviously make sure we understand that Jason I don't know if you've made any progress on that in looking at that issue. I'm just going to raise my hand. So you were right it had to do with threat ID. I just have to do some regression tests so the test that failed I got to pass but now I've got to run it back through the other ones to make sure. I don't know those ones but yeah it's on its way anyway. Okay so it is a fix to occupy? No to the test harness to the behave tests yeah. Okay good so this is not affected by it. Okay so 082 RC0 has been out for a while. The only question is, of the open requests we have, which ones of these if any we want in 082. Obviously and then and then we'll look at which ones are ready to go regardless so the question the first question and again I'm sort of open to this one is, are there things that we think are important to go into 082 of basically of the last few that were there. I don't think there's that many that that we want to rush out basically rush out and get to into the 082. Is there anything that people are aware of that they want to see in that release. There's, there's a couple items that Sean job had opened PRs for that are about them. Not that one. This one. Yeah, that is possible that would be great. That is a change that allows to change additional runtime settings on a tenant basis, rather than inheriting the main wallet ones. Yeah, so that's that's good for multi cannons and deployments and there's the other one that is the one about the logs, which is basically adding the initial step to adding context to log statements so they can be filtered by tenant right now there's no identifiers and would show which standard log statement is coming from. So that included in this one I don't see a second one from Jen job on that top. There should be another one. Unless it was a very much let me check. I'm maybe was merged I didn't notice. So maintainers we would need a review of 2233. Yeah, the law one was merged already so I think we're good with that. Okay. So I guess the one question I have considering what should go into 082 release is, we've got some other things that we know are coming soon, like deprecating, not deprecating I guess but dropping support for Python 36. And there's some other changes that are dependent on that. And there's a couple of other breaking changes so I guess the question I have is, how soon are we going to see the next release. If we do a 082 now because if it's pretty soon. Then I'd say we can hold off on some of the breaking changes. Yeah, but if it's going to be a bit then I maybe we want to try to get a few more things in. So the orientation is that we put 0082 out and then we almost immediately start working on 09 so there's this one in here that I think is an important one that I'd like to get in. This one, I'd love to get in as soon as possible but I think that's a 090. So those would be my course this one. I think there's not a lot of controversy to it but but that we've not had a review on it. So, you know, we could start to go through these one by one and see whether they're ready to go obviously three six were stuck on right because weight got so far way do you haven't been able to get past where we are just having that time right. I just poked at it and it just, it gets to a certain part, like it, it starts the. It starts one agent, it's mediator starts Bob, and then it tries to start Bob's mediator and then nothing happens it just it freezes and I can't seem to get any logs as to, you know, from get have actions or occupy or anything to indicate what's going on with that particular mediator. And I can't reproduce it locally because it works every time. So, and it has something something to do with the version of Python because it works all the way up until Python 3.7 and get have actions and then it stops working at 3.8. And then 3.9 doesn't work as well. So, I don't, you know, I, I'd like another set of eyes and different brain on it to maybe see something that I can't. Okay. I volunteered myself to take a look at that but just haven't gotten around to it. You're very busy. Okay. Okay, so that one's a big one but again we would not want to put that in 082. Um, this one looks ready to go, I believe. I think that's the one that had the dependency that had dropped support for three six. Right. I think we could probably. I think there's our, there are ways to address this and get it into a Python three six release of occupy. We've, I've worked with the multi formats library before and it's not like it's doing. It's useful. It's convenient to have. I think once we do get to a point where we're beyond three, six, I think it would be helpful to include the multi formats as a dependency. But it's also possible to work around that I think if we, if we wanted to push for that, I guess. So this is just and rock and points in the manage process. There was a review left with with comments. And the person hasn't responded. I don't think, you know, obviously I don't think this one is a high priority one. This, this is the one that I am worried about is, is this ready to go now and should we put it into 082. So I reviewed this one this morning. Yeah, and Sasha got changes and addressing feedback. And I think this is good to go. Okay, and you're good with it in 082. Yes. So that was my plan for that one as well thinking what number we can see it on the screen anywhere. Okay, 2235 so I assuming the tests pass. We'll push that one into only 2233 if we can get some reviews on that. We'll put it into 082 and then likely we'll declare it done at that point. Okay, this one has discussion going on. This one's breaking so we won't change it and then these are fairly old that we are okay with looking at them in a bit this one will go away. So that's the work that with some other work going on by BC government Jason Syro Syro tuck. And so that's, that's basically the list of all of the things that are going on so that's the plan 2233 and 35 will try to get into 082, and then 2247 will be definitely a requirement for zero nine. And that will should be the next one and we want to get that very soon. Sounds good. Any other comments. All right, that took easier and faster than I thought. Occupy plug-ins and the Liano you wanted to jump in and say some things do you want the screen or know that's okay I don't have anything to share. I think it's more of a conversation and kind of like trying to throw out there some of the things we were thinking would like to do. Ian Costanzo did a while back and analysis about which parts of Occupy that are currently part of Occupy core could be pluginified and there's a heck of the document which I can put in the wiki for reference and outlines some recommendations very best practices. And as part of the push that we're doing to get multi tenancy working better for us, which means have multi tenancy working we in particular we're using the traction plugin to manage parts of the multi tenancy. And provisioning and management. And on top of that we're trying to get some progress into the multi ledger right support for for agents. Since the idea of a multi tenant, multi tenant instance would be like anybody can decide basically where which ledger to be rooted on. One part of these would be maybe taking a look at plugins and have to separate but kind of like concurrent conversations one is like the idea we were having in Jason Sherman, I was talking with him yesterday so please chime in if you if you want was to try and start creating either a context folder in the Occupy repository or maybe even better and a separate repo for official or I don't know how to mean the plugins for Occupy so that we can start moving components out there. The idea would be to have a single entry point for the main plans are not like product specific but they provide extra functionality such as, you know that the red is queuing or multi tenancy which is just like an add on to the core functionality without being specific to any product. That would be in our opinion a benefit also for consistency in how to develop plugins in the future, there was some conversation about people not knowing exactly how to tackle them there's like a few different flavors of implementations and we would like to make them a little more standardized if possible. Yeah, so that's kind of like the idea and would like to start pushing that direction, potentially, starting with the multi tenancy piece. I don't want to add anything Jason. Yeah, I think you covered most of it there it's, I think we've got to kind of push this along so yeah like Emiliano said he ended all that work to kind of do some analysis on it, but nothing's really moved forward with that and I think you have to be kind of proactive. It may be simpler just to have a plugins folder. At first in in the acupy repo but it's probably better to be outside of it. Yeah, and the traction teams got three plugins that I can see that aren't traction specific that add functionality so they've got the multi tenancy stuff with allowing multiple tokens to be valid. They've also got multiple clients using one wallet. That thing is not traction specific. They've also got basic message storage and connection alias updating things so really small little enhancements that maybe don't have to go into acupy proper but could be used by anybody else if they have a similar situation so getting those out there getting them like Emiliano said standardized this is how you build them this is how you test them this is how you would bring them to your project would be pretty beneficial I think it gets the ball rolling maybe more people be interested in creating small little things that they're seeing gaps and acupy stuff that they'll have a venue to do so. You know I think the Ontario team they had issues with being able to contribute because they don't have access to public repos. So having only maybe a shared hyper ledger labs repo would help them to be able to share plugin code that they're creating as well. That was an issue from way back so. Okay, yeah, that's my two cents on it I think yeah it's kind of the time's kind of right to push this forward a little bit more. Um, Daniel and DCO folks you guys have areas toolbox plugins, are they specific to toolbox or do you think they would fit in an areas acupy plug into repo. I don't know if we've talked about this or not I can't remember I think we have but we're actually moving the direction of deprecating the areas toolbox plugins. So I don't think that would be something that we would want to include there. So having I mean the answer is probably correct but for a little more context that the the plug in themselves added protocols like admin protocols to acupy that could be called or used by anyone. Right. So, if the community family is useful they could maintain without ill effect, even if the toolbox goes away but probably not calling that at the toolbox plugin would assist to correctly identify what it is. So, we are totally okay if someone wants to it doesn't have to die if someone wants to continue to to have it but we might consider a game. And your thought on plugins for acupy in general is it a useful feature at this point. Any, any comments from anyone Daniel or others. Yes, I think this is generally a really good idea I think that'll having moving a lot of the functionality back by into plugins allows us to have a clear separation of concerns between different things we've got a little bit of bleed just kind of all over the place and some of these components. So, moving some of that out, then the core acupy structure I think becomes more maintainable. And because, you know, these plugins are not directly accessible we can, you know, we can say that's, that's a plugin feature that's a core feature, and we have a little bit more, we can take a firmer stance on what belongs where I guess and Yeah, I think moving to a more plugin structure is going to be really important for the continued viability of being able to maintain and update acupy in a quick way, especially with like the size of like each of these components. Like we don't take away features from acupy we just keep on adding new features, which is great. But some of these features are getting so large to the point where we could be. We could really realistically be independently revising them of acupy and not have them tied to the really schedule back and I think that would actually be a significant benefit both to acupy and these features. So, yeah, at the same time I've also. I've been, I have like, not well articulated concerns about like having a plugins all the way down kind of a thing. If there's there's definitely value in having an agent in a box and just having like a core set of things just to be there and available and have same defaults and stuff. And give a slightly more concrete example so we implemented the universal resolver plugin for acupy. And that was separate as a plugin. It was usable it was good, but I don't think it was picked up by anybody because they nobody was in the habit or or had processes established for pulling in plugins. And so until we actually moved it into acupy. I don't think it was really seeing a lot of use. It was a strategy for pulling in plugins and making sure people are aware of these really awesome and important features that are provided by plugins. I think will be important. Yeah, I think it's a bit of a balancing act, you're right, because there's, there's going to be plugins that can be plugins but are better off being in the core functionality, because of the scope today. But these idea of having like the you know the repository with the sort of like a listing of what the official plugins are what you can find I think with helping in that in the effort you were describing of like having people use them, instead of just waiting for them to be absorbed, because we would have examples on how to add them. I don't know if it is possible to make to make like you know install installable packages somehow maybe it's not possible maybe it's possible but we can work more cohesively into getting all the plugins that get developed in for specific set to be just use the same exact way. Good discussion so I'm my thought is this would not be a labs let's just move it into a repo. I'm happy to create it. I think we think we're far enough along to do that and then, and I would say we want to pick several plugins to to use as to populate it and and drive off that does that sound right. So we can work around that maybe what we should do is, if we start doing the V analysis last work of like plucking things around, maybe Jason can can think up with you when you know a foundation is ready and then start pushing things over to the other side like this is to me is needed right away. So if we could bring in the Kafka one from from sick was work that would be another good one. And then picking one or two from from traction, if they are suitably, you know, suitable for that. And then just say okay we've got three or four that we need. Now we'll do the types of things that that you and Jason were talking about which is standardizing the structures and conventions and how to use them examples of how to bring them into a deployment of occupy, and then, you know, prevent this thing of them not being used at all but actually, you know, getting the community comfortable with with both building them and and deploying them in a in a as easy way as possible. Okay, any other thoughts from anyone on that. Excellent. All right, the last topic is a happy one. We've got a new mediator. So speaking of our pull requests. I feel like this has been approved with lots of people approving it we have the majority of maintainers have approved this. I introduced it so I've already approved that I guess. So let's go to welcome Jason Sherman as a meat as a maintainer in in occupy done it all I hope to do it today. I forgot this was going to be out of out of hope to do this live in person but I guess we will because we've got to run a pilot test to see if this text change affects the code in any way. Okay, Jason welcome to as a maintainer appreciate your efforts and look forward to your contributions going forward. If anyone else knows of someone who should be a maintainer is interested in a maintainer we did update the maintainer documentation as to what the rules are for how to propose or self nominate yourself as a maintainer, and we welcome those. And we also in that document outline sort of the duties of a maintainer and sort of the, the priority order of, of, of what to work on things. This was discussed. Sorry, I have a question. Sorry for the interruption. Yeah, I'm, I'm just Luca, I'm a mentee of hyper ledger mentorship program. And I belong to standard documentation task force and ask you if you need support for writing documentation and also other kind of contribution because we, we know also the learning program. Yeah, I, I wrote in, I wrote in chat. If you need the support for documentation or other kind of contribution. I don't know if you want to. Yeah. Answer later, I will conduct you. Yes. And, and I think I guess you have a similar background. Okay. Okay, yeah. All right, so maybe the three of us could get together for a meeting and are you working with Bobby, both of you. Yeah, yeah. Okay, so maybe the three or four of us could have a meeting on this and sort of figure out. There is, there is a bunch of resources. There's a bunch of organization help we could definitely use that we've made some progress in the last year in doing that. But we definitely could use additional help. And, and so let's talk about your backgrounds and sort of figure out how you might be able to fit in. I'm glad to have your help delighted to hear. Okay, okay. I will report back. I mean, we, we have in our team. We have also software developer, and also people who have PhD, for example. They can write documentation or also contribute to, to write code if, if needed. Sorry about that. Yeah, excellent. Very much delighted to talk to you about that. Okay, thank thank you. Thank you. I wanted to highlight. Yeah, here's sort of the duties of a maintainer on a, on a hyper ledger project and sort of the, the order of, of activity and you know, contributing to the product by a poor request. This is likely the most common thing, but there's lots of other things that are important to get done, perhaps ahead of these things and that's the idea of, of, you know, making sure that these, these items are getting to enable, you know, not only your contributions, but others to contribute to it and that's, and that's a big part of this, that role. So if I use this as an opportunity to get on that soapbox. Okay, that's all I have for the meeting right now. Thank you for the topics. We went through the things a little faster than I expected so I kind of thought this was going to be a packed meeting it seems like it's not. Are there any other topics people want to raise. In the open space we have now. I'm just going to mention, mention one thing. As part of the what was describing before the effort to using multi tendency more one side side effect that we're having is we're trying to consolidate also the deployment strategies we have so we're probably going to be pushing at some point, at least an initial version of a home chart, or try to push an initial version, initial version of a home chart to the acupy repo for acupy agents. And so, maybe keep an eye open for that and if you have any interest or knowledge in that field it would be nice to get some extra eyes on it, it's probably going to be a short is going to take a while to get it perfected because there's a lot of tweaks and settings that need to be added but we're going to try to do it as good as possible in the first set. Yeah. I think that's probably. Oh, Jason go ahead. Oh, this is for after this. Yeah. Yeah, the one thing I wanted to add was, you know, probably the biggest. challenge. New folks coming into the community have is that incredibly long list of configuration parameters and the config file it's possible and that is definitely something that we need to help with the documentation and help with ideas on how we can make that a lot easier so you know, Jen, look, and I guess those are big areas where we are desperate for help so part of that is creating code like that cameo the hours is proposing by having a home chart to do that. But others is just trying to ease people into it and giving them tools they can use to to make it easier. Right. Jason, go ahead. Yeah, I forgot to file in a bullet point there just the discussion of adding a dev container areas cloud agent Python. I discussed yesterday I just don't want to go. I don't know how the community feels about dev containers and VS code. I don't have containers on VS code specific but that's kind of where it leans and then adding launch stuff. I just didn't know how the community felt about adding things like that so it's underway and it was really useful for me to solve some of these problems in the last few weeks. I mean I can always do do obviously do a PR and get people to respond on that but I just thought I'd throw that out there that that was kind of underway to maybe make it easier for new actual developers not just users of acopi but developers of acopi. We're kind of headed in that direction so. Okay. So, just to summarize the plan, Jason is working on adding a PR for adding a dev container to the acopi repo so that when you start up in for example, VS code you get a, a, a, you get an option at least to restart the container in the dev container restart your editor in the dev container and operate from there. I know, Keith you put them in a pile of places and find them really useful. Yeah, especially for JavaScript but I've been thinking about even the Python one so this is this would be a great addition I think for developer experience. Yeah, great like dev containers are pretty new to me I don't live in that world so feedback will be very important I think for people that are, you know, have created the more frequently or use them more frequently it'd be great to get some feedback on that so when that PR is out that will maybe kind of advertise that that one needs some eyes from other parties. Yeah. And it's definitely one that can evolve over time that's for sure for sure yeah yeah. And this that that will help in the getting started thanks for bringing that up. Any, anyone object to having a dev container included in acopi itself in the repository. All right, any hopefully next week then or the end of this week we'll have a yeah the PR up there if I can get some time to document it nicely yeah. This in in ramping up this is these are the things that make it go faster not not slower you may they may deviate off the path but the end result is you go faster. Going down the path so it's good. Alberto. Yeah, hello guys. Yeah I've been asking some questions on the channel. And I'm more of a front end person here and I'm just trying to get my head around how my team and I can create a high availability mediator I think I asked that question Steven you answered that question. I know you guys from BC go have like an open shifting. And I know and I understand that the mediator are all it really does is just like an input output kind of mechanism. If I'm, I'm not sure if I'm correct on that. I know, maybe like a simple easy to instance might suffice, but I kind of wanted to get your thoughts Steven or anyone else on what you recommend I know the orchestration might be a complicated when you have multi instances. But I kind of wanted to see if there's any viable options and any other teams have done for handling big amounts of of users. Anyone. All right. At this point. The challenge has been and we're happy to start and contribute to start conversations and and go through a design we went through a fair amount of design work. Last December ish on this topic, and we got to the point that we decided to hold off on it. And so we haven't made a lot of progress other than on the implementation we already have which, as, as I mentioned is not a multi container. And so we are, you know, busy gov team is willing to contribute to that effort and join in a collaboration on a design on design work of that so if, if that's of interest. I think we should get out of call and start some meetings on that specific topic. Sure. Yeah, definitely. It is of interest. I think the backing team would be the right people for that but point back to whatever. I think, can you just explain what the current solution BC cup has the basic solution is we're throwing hardware at it. And so for example, instance of, of ACAPI running as the mediator. We, we went down the we made sure we're running ask our where we made sure we're running. We're just making sure we're, oh, we are adding your cash to it and read us so that at least if when the, when the instance moves because of a rescheduling on the cluster, we don't lose anything. So that's good, but we aren't able to horizontally scale we're not able to have more instances of ACAPI and that's because of exactly the problem you mentioned which is. Each, each instance has to know which instance has the web, the web socket connection destination wallet. And, and so we did a pile of work and we think we have some solutions but we kind of defer it to see if others in the community would come up with it. And at this point, we're probably ready to say, okay, we better start on it. And so that is something we'd be willing to start and maybe the next time. The next session I can, I can do a sort of overview of this and maybe that'll be the kickoff to do more work happening. Stephen. Yeah, we've got it. Sorry, Sam, go ahead. There's a project called socket doc, which is pretty dumb about what's being passed but is designed to hold on to Web sockets, and then passes the message upstream with enough metadata to know which instance of socket doc in a cluster environment contains the ability to send outgoing messages. So that's a relatively small piece of code that we could also show that I think that would be awesome. And that would be useful. It could be used. It's relatively just needs an htp endpoint on the back end so it's relatively flexible and how it could be used, but that could be useful and we could, and we can share that. Okay. Well, why don't we plan on. I mean, this is an Aries wide. Very clear. We are not tied that this, that the mediator has to be occupied. And, and so, you know, I know, and I will publish something the other day with AFJ and I haven't had a chance to look at it to see whether it allows for that scalability or not. So, but I'm happy to have at the next app of the, you know, introducing this topic, Sam, I'll get you to participate in that discussion and we can sort of go from the basics of the problem and then figure out what solutions are already available and what we can build on. Does that sound good. That does. Alberto, that works for you. Yeah, definitely. And just kind of like a question on the single instance that you guys have, do you guys have any feedback on how that performs with locust and how many users. So, so far we have, we keep crying we've every time we've tried we've crashed locust before we crash. Oh, I see. So, okay. Yeah, has not been a problem since we put that in there. So, we're fairly confident we can go with our use cases what we don't know is how far it can go and go. Okay, that makes sense. Stephen, I work with Alberto at instant manage the overall engineering. So we can we are interested because we have a use case right now to actually test that overall and Alberto actually coordinating with our testing team as well as back in team to see what we can do. Just for clarification we are still learning this environment, kind of associated as you understand for a year. I'm trying to see if we can allocate someone with the back end knowledge to help this onto this but if we can actually give an overview as you suggested in the next meeting or a special meeting that to help jumpstart this process. Okay. Okay, I'm kind of hesitant to wait two weeks but I'll figure out what what we can do ahead of that. Maybe we could have the areas working group meeting not tomorrow but the next week. Focus on this. The venue I think is is unimportant but yep. I mean, I don't mean to say that I think either one would work fine I just what I meant to say. Are you but are you okay with turning the agenda over to that. I am so ready to get back to actual businesses that are talking about the open wall foundation. And I want to have some RFCs process but but we can worry about that. Okay, so how about this that we plan a week from tomorrow. We get together and we have all things mediator we'll get Teemo and the animal team involved. And, and we'll try to build up from there is that sound good. Yeah, that would be great. Okay. And I would suspect and we'll get try to dive into the weeds of what's there what's there now what the core issue is what's there now and what can be done with. Excellent. Great question Alberta. Thanks. Thank you for doing that. Okay, any other topics. Just so everyone knows. I don't know what day ever because I have to fast until 230 this afternoon before I get some blood taken and and I could have a coffee until 630 and all I had was old milk and so I didn't even have a coffee. I'm just struggling. That's my challenge today. That's why you always schedule blood fasting blood work for first thing in the morning. Yeah, I realize that now. First you can't eat and then they make you bleed and they say that the practicing medicine isn't torture right. You want some pictures of food from here, Steven. Ouch. No one should send me pictures from around the world with food. Thank you very much. I think we'll call it a wrap at that point moment. Have a good one. Thank you. Thanks everyone.