 All right, welcome to the July 25th areas cloud agent. Python users group community meeting. A few things on the agenda, mostly to do with PR as an issues and moving things forward. We are recording the call and a reminder to everyone that this is a Linux foundation hyper ledger meeting so the Linux foundation anti trust policy is in effect as is the hyper ledger code of conduct. Let's be good to one another. Anyone have any announcements to make, or if anyone is new and wants to step up to the microphone and introduce themselves please do so. Nothing to say today. All right. Okay. We'll start with release 090. It is has been released. So 090 went out yesterday. I'll post an announcement to the to the board. To the discord channel and various other places to let people know it's out there. In doing that we did add deprecation of the SDK so the two things that are key in this one. Well, three things, at least. These are all in the change notes the change log but in particular. 39 Python 36 to 39 is now the official change. We are now no longer using the Ursa library but rather using CL signatures. And there is an official deprecation of the ND SDK notification on launch so if you use the ND SDK on launch you'll get a notice to migrate away from it. And there is a migration document which Daniel has been good enough to put into the into the notes that describes how to do a migration from the ND SDK to ask our. So, all of those contribute to the act to occupy release zero nine. So, again, definitely encourage everyone to. If you are using the ND SDK to move away from it, and definitely suggest that if you're starting up, don't even start with the ND SDK go right away, right ahead to using ask our ask our. Ask our and and the related components are faster more robust. There's been a number of fixes in the CL signatures that, including some things that will be announced in the near future. It is much better to be off of the ND SDK and on to ask our any questions or comments about that. I will see in the chat Moritz has said hello but doesn't have a working mic glad to have you here and I'm glad to see the PR as you've been putting in lately in the conversations you've been starting. Welcome. The auto flags I did a short presentation which I realized is not up here so let me. And I'm not even signed in. Okay, this is embarrassing. Man, at least I know my pin. None of those are even right. How do you get to the switch password managers, everything's a mess. What am I going to do here. Well, I'm going to stop sharing for a moment. Sorry about that. I wanted to a brief presentation on the auto. So I switched over to proton as a password manager from from big warden. All right, sorry about that. And I'm obviously still in transition and definitely can't handle it when I'm under pressure. Sorry about that folks. Jump in any time here on this on this presentation because I'm just sort of sharing what I know and a bit of the history. When we created it, the auto dash dash auto basically allows you to set a flag such that the controller does not have to be involved in the middle of a of a flow. So, it allows basically the occupy itself to simply respond to messages received so the assumption was when we started these things and we were talking more about protocols and evolving the initial protocols was that. Every step of a protocol was an opportunity to insert business rules that that, you know, every message was was there to move the protocol forward but every step would be controlled by, you know, whoever is is the business process or the person behind the protocol. So that when you got, for instance, an offer, you would use some business rules or for a credential that you would you would use some business rules to decide if you wanted it and then you would send a request and the other side would consider if, even though they had sent the offer already they would consider whether the request was acceptable or not. And so every step would involve the controller, the original developers didn't like that while developing so the auto flags were added. So that for development they could, they could go faster they didn't have to worry about writing a controller just to test out the internals of occupy. And so the auto flags were put in and they were put in as debug flags. One day, one of the developers added the send and end point for issuing a credential, and he was smart enough to realize that when an issuer says I want to issue a credential, they don't really care about all the ins and outs of the protocol. As long as it's following the happy path the expected path for issuing a protocol. The issuer doesn't have to know that the offer was sent that the request was received that the issue credential was put together and sent off. They just wanted to send a credential here was the data and occupy could take care of the rest. And that really was a way to specifically handle the auto. So we wind up with a whole lot of autos that got added. And I've got a list on on two screens here in various categories. And a big question now goes should autos be expected in a controller obviously you can turn them off but you know should we take them out of debug status should they be used in production. And if so which ones, and you know if there's any guidance we should give developers on it so any anyone have comments so these are the ones related to establishing a connection. These are the ones related to issuing a credential and presenting a proof. And then on the next page. Some things around actually probably should have you put this one on the connections one auto pin connections. This relates to the introduction. And then finally some related to both mediation and endorsements. What do other people think about the auto options and do you use them in production. Go ahead way. We use the auto options quite often. I don't have the list straight in front of me but we have several of them like auto provision auto respond auto accept. Okay. And your advice would be to use for generally use them. Not as debug but actually use them in production and leave them. Yeah we've been using them all across the board for years now. Okay. I'm not sure what zoom link that is anymore because I've been back and forth on so many zoom links unfortunately. Hyperledger keeps changing with what they want them to be and think it's no big deal to change passwords and its problem, or to change new links. That's unfortunate. So what I'll do, wait, I would like you to get a list of them so I'll put a place in a ticket to accept those, or to put those in. The endorsement ones we're going to have a session tomorrow and actually here's a request actually I've got this in here at the areas working group that we're going to have a discussion on alternatives to the endorser auto flags. So that'll happen tomorrow on the areas working group call so invite people to that one to talk about endorsement. Obviously mediation is another one that's interesting. Similar to endorsement we want to have some level of control over that. So it would be good to have that auto disclose features. It's almost a no brainer I don't know how many people are using auto disclose but it's probably something that should be almost automatic. Maybe we should use it instead of paying on on on back and forth. For finding out what features another agent is using and try to promote its use. So we should remove, remove the auto flags, or sorry, the debug on it so it sounds like we should for most of them. So that would be a more documentation change but basically would be removed altering the category in which they land in the config file. I would agree. Yeah, okay. And then my thought was to document when using them, you know, the auto auto paths. The other impact that comes into play is where a user interface needs to come into play obviously wallet there's wallet and human use cases and the enterprise and business rules and of course those two pin melds because in an enterprise use case. You might want to pass it off to a human you might want to use business rules you commonly would use business rules to decide what to do on things, but possibly hand things off to humans as you're going. One of the things that I had promoted I had been long, an advocate of not using auto flag so I'm part of the problem here or created the problem but I thought we should have done was simply create a controller that had auto settings off and and and have basically the controller implement the auto in other words do the do the thing necessary to respond in an auto way so that then everyone can start with that controller and then build in the rules they wanted for their own particular business. Now I'm an advocate of still doing that defining a generic the controller, but assuming the auto settings are on so it doesn't need to do that and then default rules for a typical enterprise agent. So at some point, it would be good to build to define what that should be and build it out but at this point I don't think I don't see that happening you know, it's not a big issue right now. Any other comments on open. Is this a burning topic or just something that that should be at the back of the should be more or less the back you right now. So I think this topic came to my mind at least when we were talking about a change to the automatic behavior and and whether it should be considered production usable or not. So that's the biggest change in my mind is just like a shift in perspective and then making sure that the automatic behavior is actually well behaved. So for instance with the PR that I have open. There was an opportunity for a misbehaving holder to change the credential between the offer and the request phase of a credential exchange using Jason Aldi. Right. So I think we need to. So for one point of caution I think we need to have when we're going through and just making sure that it can't be abused in any way, having the automatic responses. It's not a new problem, because a controller that was inadequate would also have been able to miss those same sorts of issues, I guess. Yeah, the other thing that's been on my mind and I was I was a little distracted by like half of my team being in a different zoom room but I was trying to. I was thinking about how there's there's some overlap between the idea of automatically proceeding through a protocol in a certain way and governance machine readable governance and following rules defined by a governance framework. So I think there will be some interesting opportunities in the future as that continues to develop for. You know there's the standard just business rule automation stuff that people could be using but it could also make sense for us to use governance files as a way for. If nothing else to indicate to a holder who's connecting to an issuer or verifier or something that it's okay to automatically accept that connection according to the governance framework. Or, or to proceed with a certain kind of presentation because the governance framework said it was okay. Those sorts of things. So, previously I think when the auto flags were considered a debug thing, the quote unquote natural place for that governance file handling to take place was in the controller. But I think with moving that closer to occupy with the automatic flags considered a production valid thing. It might make sense for processing of governance rules to be something that makes it into a plugin for at some point or something like that. That would be, that's pretty cool. I mean, one of the things when we're talking tomorrow. Emiliano is going to talk tomorrow on the areas working group about endorser rules and it's similar to exactly what you're saying which is we're trying to put them into a format that can be machine readable. So that we can separate out the way the rules are generated from the processing of the automated processing of the rules. So that that's one example of that but I know you guys in DC has done an awful lot of work on machine readable governance and and how to apply that you're right a plugin here would be very useful. Yeah, it's, I think it's something that we've largely been approaching from a controller perspective. But I don't think it would dramatically change things and it would make it a more widely available thing if it was also just generally plug in a bowl to any occupied appointment. Yeah. Jason, go ahead. I'm going to mute there. So just so I'm clear my head is the idea there that the instead of using auto flags that we would use rules, like a governance thing so that they're like the auto flags will get replaced by a rule that would say yes we want to do this and then it would get refined for whatever certain credentials certain things. I don't know that it would necessarily replace the auto flags, especially if it was a functionality that was included in a plug in as opposed to core API. So I might have the auto flags and just, you know, have the very straightforward just automatically doing stuff and then the plugin could provide more specific rule based automation. Okay. Yeah, let's just try trying to wrap my head around to. It would be quite a step to go to, you know, like a rules engineer governance thing but I think that's the right way to go because I know from other projects that that's kind of a desire by the business side of things. And then to me the next logical thing was an auto flag would just be basically point at a default rule set. So sometimes I don't like seeing things where it's like, there's an exceptional case like if there's going to be logic that's going to control the flow and maybe an auto flag should just basically point to a default flow so we don't have these two sets of projects that it's the flow is always dependent on whatever we decide on governance structure rules engine, etc, etc, no kind of thing. But, you know, obviously that can be done in stages I think so I just tried to wrap my head around that I think it's a great idea to start moving into something more comprehensive than just a flag does one thing. Yeah. I think another example that we should keep in mind is something like revocation where where instead of trying to follow the protocol. We, we hit the complexity because we realized that, you know, exposing all of that logic and requiring the controller to do all make all of the decisions is just the wrong thing to do. It just makes things too complicated and harder to implement. So that's another example where, you know, it's a much better idea for us to build more into the, the core functionality. So that, so the controllers don't have to deal with that level of complexity. Cool. Any, any final comments from anyone on that one. Okay. So PR is an issuer and issues are the remainder. This one came out. I know there was another issue. Daniel you posted this yesterday about marshmallow usage to remove the deprecation warnings. I'd love to see that I believe somebody else has already put in an issue about marshmallow and and some additional comments on that did you find that one, Daniel. Another issue on marshmallow I don't believe I've seen. There's another issue. Shoot. Perhaps it was in a PR I'll have to go look for it but somebody had put in here's here's a way to clean up a pile of these. Oh, that was me. That was on a PR a while ago I linked to that in my comment. Yeah, so it on a previous pass of attempting to update occupy to newer versions of Python. I think we ended up needing to abandon this branch it just got stale and we took a more incremental approach as a community and that ended up being better. But we went through and updated a bunch of dependencies and a bunch of these deprecation warnings and I haven't looked at this in a while. I put together something that helped me to to address those issues. I frankly don't remember at all what I did but I do have a link to that tool at least so yeah. Okay. I assume this is a help wanted one. Yeah, I think so. Yeah. Yeah. So we'll try to define you know exactly the options here I think there's there's another PR. And I'll try to find it. Daniel that has a bit of an assessment on the marshmallow errors so it's not that link that you've got but it was from from somebody else in the community and I'll have to look it up. That said, you know, here's my experience with it these are because of this. And here's some things that could be done to clean some of them up. But I suspect this is a help wanted I think your tool could be an alternate or a temporary way to do it if we can build it into a GitHub action. The specific warnings that I've got that I was pointing out in this issue at least is just a matter of needing to change up the arguments to the the field. What are they called the field things for for fields inside of a marshmallow schema so that should be just a one time thing and then in the future as as new schemas are added or modified. We just need to continue to follow suit and not use the deprecated attributes any longer. So, for this issue and for the vast majority of the deprecation warnings that are being emitted on tests. That should be a one time fix. I think you're right in saying that there are other warnings being emitted by marshmallow related to schema name collisions and those sorts of things. And that might be what the other PR and comments you're referring to where we're talking about so. Okay, so the idea is basically it's going through the the routes.py and and making it a mechanical adjustment to a whole bunch of places as I. Right, so the one example I copied was just a singular example but there's, you know, maybe a few hundreds or thousands evens of these sorts of warnings being emitted for a bunch of different locations. And apologies, what do you have to change to fix this. So, let's see this one metadata keyword argument is deprecated so changing from metadata to, I think it's supposed to be like, what is it supposed to be. Alternate attributes to to stuff the metadata fields into now more specific ones or different bucket of things so. Oh, it's okay this is what it says sorry I shouldn't try thinking on the spot. So keyword arguments were being automatically turned into metadata on fields and now those just need to go into a specific metadata argument instead. Okay, I was wondering why because I didn't see metadata in there you actually they actually want the metadata argument specifically as opposed to right. Yeah. Okay. Cool. Okay, well we've got to help wanted on that we can see if we can make a little bit of progress on that. And if anyone wants to jump at it. And you've got somebody will then take a look awesome. Excellent thanks. Poor requests. Sam before we move on. Sorry, Steven before we move on from that. Have we talked about the performance of marshmallow. We have not. So, when I was doing performance testing against acupuncture we saw that marshmallow was using I think it was something between like seven to 10% of the CPU time of acupuncture. Adam had made a suggestion internally about a compatible marshmallow layer that had better performance that we could potentially switch to. I just wanted to bring it up to the community in case there's interest in looking into that further. Definitely. Adam what did you find. Do you know that or could you add a ticket at least to. I'm trying to remember when it comes to me I will create a ticket, but I think it's not a heavy lift with possible benefit of speed increase. I'll create an issue. That'd be great. I've heard lots of grumblings about marshmallow but it's not something I know a lot about toasted marshmallow marshmallow but 15 times faster okay there you go. Daniel's got it. Okay. Pull requests. Let's take a look at the pull requests. So there's a couple of new ones. These are are going through discussion so I think these are under review any comments on these two or just let the review process follow. There's some comments on that pop one there from in Kimba. So this one is one that I'd appreciate some additional input on from anybody who's familiar enough with did info and how act by storing dids and rookies. So, Mattis Mattis Kimba. He is proposing that we make retrieval of did info by verification method, essentially be a pluggable thing. And I think that that solves a problem. There's definitely a problem that needs solving and this would do it. But I'm wondering if there's a better way for us to go about making it easier to to sign and verify credentials using dids that we own. If there's a better way for that. I've left some comments that they're kind of vague. I can go into a little bit more depth but yeah just call for more eyes on this issue would be appreciated and I can spend some more time thinking about it and blushing out my thoughts as well. Okay. So, that's Jason Sartok that's kind of your space right now you've been way too deep and dids and did docs and so on so might be one you could take a look at to. You put this in yesterday Daniel. Okay, this is the one to do with. This would this is what triggered the open discussion this is ready to go I assume. Yeah, yeah, I think this is in good spot. Okay, we'll get that one I probably shouldn't hit that because we probably don't need it because we're probably going to murder something else, but maintainers if you could take a look at that one. I'm change up. What is the status of this one. I think you're on the call. Yes, so the rework I've done is basically now supports selecting legend through the end point I added a few inputs are related to that. But basically what I'm doing right now is testing that because there's an issue with multi tenant multi leisure where if you try to register to be. The local data it is out so basically I'm doing some testing with the rework with that. But the right part is done so basically the new feature that have to be added that is done basically trying to fix the issue with the review. Okay, and there's an issue on the previous one. So that should take care of it so though anyone interested in this this is a feature that allows a tenant in a multi tenant environment to. Set a bunch of the acopai, you know, sort of what were previously global parameters set them at the tenant level or configurations I mean. And in particular these ones allow a tenant to choose what ledger they are writing to from a set of ledgers configured an acopai and as well what ledgers they are reading from. So that will allow the tenant more control over what they're doing and that's a big use case at at in BC gov is as far as the traction component that we're building. Yes, low on that's at the tenant level so the tenant, those with, you know, access to control the tenant behavior can can configure the tenant to talk to to write to a specific ledger. To quickly clarify this is this is behaving like a config that you set and then it applies to each of the methods that cause a ledger right as opposed to an attribute on each of those endpoints that do it right. So just to clarify, so I can have multiple tenants and one tenant cannot to be sick of ledger one cannot sovereign ledger. Yes, yes. Amazing. Cool. Okay, so that's still a work in progress keep an eye on that one and do review I think this one's ready to go we didn't want to put it in 090 but I think this is ready to go. So if anyone, any of the maintainers looked at this I know I shouldn't have clicked update on that other one because this is the more likely one to go. Andrew gave it a thumbs up confirmed that it worked on his M1 Mac. Any other. Anyone else take a look at this. So I haven't explicitly marked to prove on this one but I think this is a good change this is one that multiple members of my team have. They've worked around it. Yeah. So I think having this this change in the script. It makes sense and I think it'll be fine so I've got, I got tired of telling people about the work around so yeah. Yeah, you'd like to see it. Okay. We might even enable auto merge on that. So that one will go in in a few minutes and I'll try to resist hitting update. Sherman you're working on this one right now Jason. I am working on it as we speak. Yeah. We talked about this weeks ago. Sorted out what we want to do and Jason's working on that. And Jason Syro I think this one should be closed. This was kept around because we knew Jason was going to be working on it but I don't think this is needed anymore. Correct. I think so. You're not doing anything with this one right Jason. Sherman or Syrtech. OBE not at a band. Okay. I did want to take a look at a couple of these other old ones that particularly if we've got people here. We've got changes requested on this one that haven't been done. So the students of Tim here we don't have a resource to work on this right now. No other way to put it. So I don't know if you want to close it or if you want to come back to it another day but unfortunately, it's going to be a little while. Okay, out of band protocol sounds fairly important. Maybe we should take it over. Got a few changes but it. You still need it done I assume. Yeah, it's it's at some point it's important to have a problem for it there. Yeah, it was something that was a gap. Not much of a priority as it was when we first put this in now. Okay. Let me think about that when I might close it we'll see. This one we agreed to close. Sadly. Eventually we'll get back to this. But right now, I don't think, as Daniel said, it's, it's, it's not really ready to go and I don't think any other works going to happen on it. So we'll close it. Key phrase being here. All right. We'll close that one. This last one change out while you're here. Is this one still worth moving forward. I'm not sure I think this was linked to one of. Andrew's PR. I think I mentioned it in one of the comments. Yeah, I think it's been so long. Maybe we can just go ahead. Okay. Okay, so I'm going to leave it at that. I'll take a look through these other ones to get more of an idea so we're not doing it on the fly. In the future and I'll, I'll do a better job at being able to provide context for these. Is there anything that this one came through. I really like this one for those who haven't looked at this and having interest in dids and reg X well worth reading the information from chat GPT that was generated merits. Thank you for doing that. The only thing I wasn't sure of here. So the idea here is there was a couple of things that I put a comment in. The core idea was to a make the did the regular expression easier to understand. And this idea here for defining how defining the regular expression so that you could see the parts of it and get have names for it. So I think what was proposed was adding more information such as the fact that, for example, this string here excludes lower case L and uppercase O and zero to prevent make, you know, confusing characters in a did. So that's good. We have the did solve which is interesting that that we explicitly are looking for that presumably for performance reasons. So adding some comments around this in the code would probably be useful just so people know. That's a good thing I think definitely without question and then the other idea is applying that reg X to this. Tim, go ahead. I should shouldn't we accept those that have characters that are undesirable as potential did but only have that search pattern be applied on the generation of the kids. In other words, you're saying that the did spec does not disallow that therefore we shouldn't. I don't know, but that's my question is if the did spec allows those special characters we should still search for them right. Yep. Is this base 58 encoding characters for base 58 encoding I bet you that's what it is. Yeah it is. I think the did solve pattern. So that portion of the pattern that includes did soft specifically does have those limitations, but I don't think the general ones to have the same base 58 alphabet. Yeah, I see. Yeah. I think we're okay with that. This is specifically for did solve whereas this is the general did and this accepts either. Right. I mean, the big thing for me comes down to is the do we use did solve enough that we need the performance benefit from having a separate match versus the more general match across all. Again, I don't have an answer to that question. That's a performance question. And then the second thing. So, I mean, I guess we leave as is for now because because of some and then the second part is this nicely breaks it up so we know why again. And then the other question is do we update all of these places in the code to use the did regular expression. And I would think we would want to use the same one everywhere. Any question on that. So in the comment that I left there. I think updating the regular expressions in all places. It's kind of a forward looking change because at this point in time, the rest of the code surrounding like connections and stuff is still expecting that did to be shaped a particular way. And it would, it would fail in other ways even if it passed the regular expression validation. So, I think there is definitely opportunities to make sure that we're consistent with the projects that we're using for these different but that alone doesn't like solve the problem I guess. And that's because in certain places, we are wired to did peer or what a master now did unqualified dates right now for did calm and only certain dates are supported elsewhere. So we haven't removed the dependency on those other days which is the larger problem. Right. Okay. The, the other example in addition to the unqualified did is for the end points that results in ND ledger rights that did did are expected to be the unqualified names basically as well. Yeah. The biggest thing then is is the action out of this. 100% on on doing this. The bigger issue needs to be outlined, because we're getting more and more to, you know, we absolutely need to support did web. And hopefully the upcoming did web us that we hope to see soon. We have to make this more generic. I would really like an issue that, you know, sort of outline that Daniel. So calling out where we still have specific did. Yeah, limitations. Like, like what, what is the action we have to take on this in order to move this forward. To make it that we're not tied to specific did. Right. Yeah. Yeah, I think that'll be a probably a bit of a more in depth analysis but that's something I can see if I can add to my to do list. And all I was thinking was try to put as much as you can into a new ticket to say, here's what we ought to do for that I think this one talks about the rex and that and I think that should be done and and the, I think even using the red jacks in these patterns, or in the other places wouldn't hurt us right. It just means, because they would still pass. Right. It just means that you still can't use did web or something like that, or any other. Until the other problem is addressed and what I'm thinking is if you could put in your initial thoughts of what action needs to be taken and you know some sort of example. You know, don't spend long on it but just put a placeholder in as an important ticket that we need to move forward. And that's, and yeah, don't spend a lot of time on it. But I was not aware of that one of, of how deep that was but I've always wondered about it so. Okay, yeah, I can open a ticket for that. Awesome. Thank you. And merits thank you for doing that they. Yeah, comparison of the results would be pretty cool. We'll talk about tomorrow. So people can join on that one. But basically this is part of the community transition is the idea that anything we're sending unqualified right now will wind up being sent qualified and Jason's making really good progress and exposing the core issues in this of how to do that. And what we're trying to make it is that we eliminate unqualified it's entirely so that when we initiate sessions did con connections, we would use a peer did to to convey the did doc essentially that the key components and a did doc to has a, or sorry, did peer to has a peer three associated with it for, for performance and, and size of messages shrinking those down so the plan is to do that but another part of the plan is to actually convert unqualified needs to call to deep did peer three qualified kids. And so Jason Scott a bunch of information on how to do that. I'm hoping in one of these days soon to go through and close issues there's a few in here. But I saw. Yeah this this one's done right. Yes. Yes. So I'm going to take a look and see what other ones we can close because we've just got too many open right now and a lot of them are questions and so on. So let's take a look at that we can close another. So, take a look at closing some of these down and, and we'll get these merged in and closed. That's about all I had for this meeting. So that helps. We are having maintainers meetings alternate weeks so if anyone is interested in attending the maintainers meeting it is on the calendar, and you're more than welcome to join but it's, it is just a half hour meeting and it's entirely focused on exactly what pull requests are there or what are needed and sort of maintain or distribution of the review of activities and then sort of direction of where we want to go next in these are our next big effort is is definitely pushing off, putting an on creds RS into occupy. That has a lot of work to go into it. And so anyone that is interested in joining in that activity. There's a number of tasks to be done and will start and we'll be assigning those out. So, obviously always taking a look at what's going on and keeping an eye on the issues that people are opening and what they want to dress. Daniel is asked your last question. So I did peer three is deterministically calculated from a did peer to so after sending a did peer to you just always send the did peer three afterwards and then the receiver just has to or whenever I did peer three is past it should be able to find the associated did peer to and hopefully that makes sense. You can't go from three to two, though necessarily can you, you, because you'd have to. Okay, so when you receive a did peer to you can calculate the did peer three and then you can store an index from three to two, but you would have to wait if you didn't do that step then you'd have to go through and check all of your two to see if it has to that value. You have to you have to record. Basically you have to report both and be able to find them pointing to the same ticket to the same record. Okay. Gotcha. And, and for a while we're going to have to do unqualified plus two and three well no sorry unqualified and three and, and then two and three after that. That's my understanding. Robert. Yeah, thanks. I was looking for the recording from the last meeting two weeks ago and at the bottom of the meeting page the text transcript looks like it's for that meeting but the YouTube link looks more like a workshop or something and doesn't match that transcript. All right, let me, let me find that the hyper ledger folks take care of that. So I didn't realize so I will check that and I'll start checking meetings to make sure we got the right ones. All right, thanks. All right, thanks for letting me know. Excellent. All right. Everyone have a great day. Thanks everyone. Thank you.