 Hey friends, we'll get started soon. I guess. Hey, Roto. Not the bot, I think. Oh, the bot got us again. Yeah. You know, last time I got in early enough to, and I took ownership and gave, gave him the boot, but I was distracted this time. All right. I am sharing. Yes. And we're already recording. Roto, are you done traveling? Yeah. All right, today. Wow. How are you feeling? Good. Okay. Very good. Okay. I think we can get started. Welcome everybody to the. February 20th, 2023 areas did come V2 working group. I am your host Lance and I should remind you of the antitrust policy for hyper ledger as well as the hyper ledger code of conduct. So far we have introductions updates. And we have a demo for the camel did come stuff that Thomas has been working on. And maybe we'll do a comparison of the DWN carry did come. Well, we'll talk through possibly that comparison. And if we have more time after that. We can go over a status of AI P3. And anything to do with the area's agent test harness. So, please feel free. Let me put the link again. Or our session today. Yeah, feel free to add yourself to the attendees list. If you like. Yeah, any announcements or other things that we want to cover. Today. We definitely will do Thomas's presentation since we've. Focused on that for today. But anything else. Okay. Sounds good. Okay. And then any short updates that we want to mention. Regarding the. Test harness or any of the frameworks. Related to did come V2. Otherwise we can leave all that. Just looking to see. Bruce, did you. Did you have any updates that you wanted to give before Thomas's presentation? I met with Phil's students a couple of times. During the week, and they have completed. The did exchange protocol using just a development environment. So as soon as you put some kind of a simple UI over it, we can begin trying to interoperate. Great. Very good. When, when you're saying did exchange, you're talking did come V1 or V or, or. They're, they're working solely on V2. Okay. You know, nothing to be one. Gotcha. The did exchange step though is simplified in V2. Correct. Yeah, that's my understanding. Okay. Okay. Anything else? It's there. Bruce, did you want to post a link or anything to their work? It's up to you. Just want to make sure there isn't anything visible yet. Okay. Yeah, fair enough. Okay. Very good. All right, Thomas. Yeah. Hi. Yeah, go for it. Thanks. So. I tried to share my screen. Oh, yes. Let me. Unshare mine. Stop here. How about now? I need to. Yes. Okay. I see. I see a command prompt. Yep. Perfect. That's how we like it, right? Yeah. Okay. So let's start it. Let's jump right into it. Without further ado. The thing is called did come. And it starts, you know, it starts a terminal prompt. And as you can expect. There's some help messages with all the various commands you can do. And, you know, I won't read this to you. We have a number of protocols that that are supported their wallets, dates, invitations, connections, and so on and so on. And the full thing is, is here. If you type commands. Yeah. So there's tap completion. Yeah. So, and let's start with what we all know about. Let's start with an interaction or integration between the Nessus agent, which is this one. And occupy. So conceptually, this platform supports multiple agents. Remote agents. And they can all be interacted with using, using this CLI. So first, let's see what we have. So we say wallet list. And at this point, it interrogates its environment and it, you know, it notices that there are, it's an occupy instance running in a docker container. And we have one wallet in it. It's, it's a trustee wallet. So with the government as being a trustee, we can onboard endorsers, for example, like the Farber University, which we will do right now. So we say wallet create, we give it a name. Give it a name. We say it's Farber. And this one we want to do on occupy, right? So this has now created a wallet in occupy, not in, not in this platform, but in occupy, which you will see over here. So it should have created this. This is the log from, from occupy. And we need another wallet. Let's create that one. So wallet create, we need Alice's wallet, of course. Alice. And with this one, we see that it creates a Nessus wallet, which is, is the default, both in memory and they are listening on different ports. There's actually not listening for Alice, it's not listening just yet. We need to start the agent, agent start. So now it's, now it's listening and it actually started a camel endpoint. This is a little bit of over engineering, of course, you know, a simple HTTP endpoint would have been sufficient. But with this camel endpoint, what we're saying here is this thing is ready to receive did come messages and then apply all sorts of routing transformation and otherwise stuff that it necessary to, you know, to use, to do useful stuff with these incoming messages. Okay. So now we have, we have that created the wallets. We started the endpoint and that's now work with the first protocols. So we have these three protocols here implemented. We start with, we start with creating an invitation. So this one we want. So Farber creates the invitation, not Alice. Oh, you notice the prompt has changed. Yeah. The prompt now says Alice and then the two little arrows and this indicates that Alice is our context wallet. So all the operations, all the commands that we apply, they relate to Alice's wallet. But because we want Farber to send the invitation, we can overwrite this and we say the Inviter is Farber. It would be sufficient to say just Farb. Yeah. Because these are aliases and they can be abbreviated. There must be sufficiently unique and they can also be case insensitive. So we want to create an invitation from Farber. Need to concentrate a little. Don't do this wrong. Okay. So this created an invitation and we see on the right-hand side here at the right bottom, that we now have a contextual invitation. So this is actually not DidCom v2. We are still talking about DidCom v1 because otherwise we couldn't be talking to Akapai. I'm sure you. So we can now, we can now look at this thing. We can say invitation show. And because it's the contextual invitation. Oh, I'm sorry. Alice doesn't have an invitation. It's Farber who has an invitation. So we can say we want to see Farber's invitation. It's this one and we can do this verbosely. And here you see the version one, the message that has been passed to or can be used with Akapai. Right. So now Alice wants to receive the invitation. And we use the same protocol again. R-C-O-3 and we do receive invitation. We don't need to say which one because there's only one. This is the contextual invitation from the bottom right. And we can be a little geeky about it and do this verbosely. And there you see what is happening here is Alice received the invitation here. So this one is the invitation. And part of receiving the invitation is the auto-connect in this case. So we do an automatic invocation of the R-C-O-23 protocol. And do the whole thing. And here what we see at the bottom, this is the short form of an invitation. It has an ID. And it tells us what dits it uses. In this case it uses for Alice it uses ditsof. And for Farber it uses ditsof as well. And the connection is active. We can now use this connection to send other protocol messages. But Nessus also records what it has done. So we can look at the list of messages that actually got exchanged over this connection. We've now executed just two simple commands. But there are actually six messages going forth and back between Nessus and Akapai. And this is the protocol execution for RFC-434 and RFC-23, followed by I think it's RFC-45, the trust being at the end. So if you're interested, we can look at these messages in more detail because we missed those. We just said create an invitation, receive an invitation. But if you would like to know what the actual request did look like, so for example this one here, I can look at the request. So this is what actually was sent from Nessus to Akapai. And here we see the unpacked representation of this message. So we don't see the encrypted message on the wire. It's encrypted, of course, but here we see the human readable thing. And also what we see here, and this is the old style, did come with one, we see that in the requests, the did exchange request, there is a document attachment. Yeah, did document attachment as part of this protocol. Let me see, can I, right. Is it possible to share a different screen real quick or is this a hassle? Well, I do this in the end. So I think that the options are share a single screen or share your whole desktop so you can switch screens, but I could be wrong. Okay, so, no, I do this later. Okay. Yeah. Okay, so, so, and this concludes what I wanted to show you with regard to, to did come we want, you know, so the takeaway is you can work with wallets, wallets have, have invitations, connections, dids, so we can look at the dids that Alice has. Yeah, this or we can look at these verbose Lee and see those. And so what did I say we have, we have connections, we have invitations, we have dids, we have messages, all related to, to the wallet, we can work with various agents, and we can do this in connection with ACA PI, but the interesting stuff and what this talk is about is of course, did come to be two. So we want to do the same again. Now using did come to be two. And so we, we migrate father from from acupy to Nessus real quick. Yeah, and to do this migration from father from acupy to to Nessus, we, it's not actually a migration at all. We just kill it. Right. In this case, I deleted, I deleted the, the wallet at, at the acupy, at the acupy end. And just to be really safe and sure I'll do exit this thing. So I do control D and start it again. So I wanted to start on a, you know, clean thing. I could have continued from here, but just to be sure. In this case, we say again, wallet list. And here we see, we started the same thing. We have one acupy wallet and we have zero other wallets. And we do the same again. So we, we, sorry. Oh yeah, clear. I can do clear. It clears the screen. So wallet create name father. And it also supports history. So I can click up. I can do multiple apps, of course, and down. And so we do this, we look at the wallets again, list. There it is. We can, of course we can look at this also. We can show an individual wallet. I believe. Oh yeah. So this needs to be an alias. So I can say fab wallet. So this is the verbose representation of this wallet. It's a Nessus wallet in memory. Listens on this port, but actually it doesn't, as we know. So we start the endpoint real quick. Okay. So now we're ready to, to transmit and receive. Did come be two messages. And we do the same thing again. This time a little bit more geeky. So we say. Father as the invite her. Please create an invitation. Do this verbose Lee. And do this in did come be two. Right. So they, they, there you go. So father created an invitation. And in this case. In this case, you don't see the. You see a message style, which is obviously. Which father, which I could probably wouldn't understand. Right. And what you also see in this case is. This bit here. Yeah. So, so the RFC. 434 invitation from Nessus. Uses a bit of proprietary stuff. Yeah. Because it's not spec yet as far as I know. We need a, we need a way to, to transport the initial connection. Information to the invite. And in this case. It's, you know, taking a very short route. Simply attaching the ditch. The did document from father to the invitation. There are various other ways of doing this. We could have used it peer method one. We could have used the fabulous carry light thing. Yeah, but it's all the same. You know, we need to find some way of telling Alice. This is the port you need to send messages to. And this is the initial verification. This is the initial verification key. That I used for, for this invitation. Right. So. Let me. Chat. Let me real quick. Show you. So while I talk. There's a little link. So, so. So there are three protocols that you see and they all use proprietary extension. So if you, if you like, you can in parallel look at those and what's different to. The proper did come be too. Right, so we said Alice is ready to Alice is ready to receive this invitation. Yeah, so again, this is, this is the contextual and mutation we have now. We don't need to say that we want to, to use did come be too, because it's already a did come be to invitation and the CLI will hopefully recognize this. Right. So here it goes. This is the very short form of, of what happened. So Alice received an invitation. And she completed the did, the, the did exchange creating a connection, which is now here displayed on the bottom right. So instead of having a contextual invitation, we now have a contextual connection, which I think I didn't mention before, but we had one too. So there is a, is a contextual wallet and a contextual connection. And now we can again look at the messages that were sent across this connection. And here we see it's a bit shorter than we had before in, in did come be one, because the did exchange is not necessary anymore. Right. So, so what happened here is Alice received the invitation, and then Alice sends a trust ping. So let's look at this message show. This abbreviated alias for the message and we save a mostly, and it's kind enough to show us the, the message that what actually, there was actually sent. And so the first part here. So this, this one here. Yeah. This, this is the trust ping. Right. So, so we ping, we ping father with this message on the wire. You can see, you can see here the message records a plain Jason message, but on the wire. This is actually signed and encrypted. Right. That it's a bit hard to, you know, in the log file, we would see the, the, the actual wire format and the log file. You would see that this is an encrypted and signed message. And here again, a bit of proprietary stuff. Right. So, so the trust ping message does the same as, as the invitation message. Alice uses an attachment to the message to communicate her part of the did document. Right. So this is the information, the same information flowing from from Alice to father. So Alice tells father what what service endpoint it is using what protocols she accepts, you know, and details about the dates, the authentication and the encryption key for for this peer to peer connection. And when you look at the messages again, you see that father send a response to Alice. So let's look at this message show. So, response. There you go. So this is a, this is a very short ping response, which is also hiding. Unfortunately, it's, it's hiding in an important detail that is happening. You know, under the hood, and that this is that father use the from prior feature that we talked about last last week. Right. So it was actually very funny last week, because I, I did have the did exchange protocol implemented. And all those messages going forth and back and then I learned about from prior. And of course, this makes it a lot easier. Right. So when we now switch the wallet, we switch the wallet to to father. And we can now look at the dates. There you go. You know, father actually now uses two dates. Right. So, so it, it's What is the proper term for it. It rotated. Yeah, it rotated. It rotated the, the did and the keys that it uses for this peer to peer connection. So the invitation was based on, I suppose, the first one. And if we scroll up, we will probably find that the invitation uses this verification key and and this qualified did URL and then father receive the trust ping and in the response, father uses the from prior feature with with the original did from from the invitation and it created a new one. And in the message from you see this, yeah, the message from from from the trust ping response, father used the second did that that it created just for the response. Yeah, so this is the form of of did rotation as part of of the did come with you to protocol and it's, I think it's beautiful. You know, it's really really nice that that you can on on every message you can rotate the did and the keys of course. So we can switch back to Alice if we want. We say, let's switch back to to Alice and look at her did and there you go. She only uses the one. Yeah, this is the one did that Alice created for the trust ping message. Right. So, now we, we have some some more stuff to look at. If you like, we have a we have the connection I think the connection I have not showed you connection show. We're both. So, so this, this is the internal representation of, of a connections very similar to what you see in Faka pie. There's the roles invite invite and connection is active with it tells tells you the current did that it's using and the respective endpoint URLs and it also tells you the original, the original. I believe this is the verification key from from the original did that father used to to initiate the connection. Right and because we have other protocols as well. So we can do, we can do the commands again. Yeah, and there you see we have so we have seen, we've only worked with this one. No, we only worked with this one here. Yeah, so we, we created an invitation and we received an invitation. Oh yeah, here's the last one. This is also quite nice. So, so we can say because it's so common, right to to create an invitation and receive an invitation. There's a shortcut for it. So we can say, connect, and we want to connect father to Alice. Right. So, so everything we've seen before. It just says, you know, use this project for call, create a establish a connection, father is the invite and Alice is is the invite T. And this can be abbreviated because FAP is sufficiently unique that it knows, oh there is only one wallet this this will actually map right so if you if I had thousands of wallets I need to be more specific about this I could also have used the the wallet ID of course you know as as the unique identifier, but in this case I just use the wallet name and abbreviated and I also have a small F at the beginning it's sufficiently unique as I said before right. So, yeah, I think the rest is boring. We can send another trust ping message so we can say Alice wants to use protocol, the trust ping protocol to send a ping. Right. And if we look at so that happened and she received the response. And that's interesting now if you look at the messages. You will notice that that this has used the version one of the protocol and not version two. Right. So, we can say, so we can say uses protocol again. For three to send. No. Sorry. Send ping and we do this and did come be to have we do this verbose Lee and we get an error. Oh, I know what's going on because I did connect here. I did connect. The connection in v1 style. And yes, v1 style creates did sovereign. Did sovereign ideas and they are not created in. We cannot resolve their did documents so let me do this again. Do the connection in did come. We to I think this should work. Did come v2. Yeah. And did it work. Yes, it did work because we now have again we both parties use did key and we now have a different connection. Yes, we do have a different connection. And now we can send the ping message again. And there you go. Right. So this time, it worked. Okay, because the connection that it uses actually allowed did come v2 messages. And here you see the ping and and the pong and this time is perhaps noteworthy that the trust ping did not have an attachment. Right. So we established, we established a did come v2 connection with with the connect command. And as part of this command, there already was a trust ping exchange as part of establishing the connection. Right. And this trust ping that we sent here is actually the second one. Right. And the second one does not need to have the Alice's did document attached and father does not need to. It does not need to rotate its key. If it doesn't want to it could, of course, but I think I don't think it does in this case. Right. Last thing that I have is the IFC 95. So this is a simple, you know, send a message thing and we do this in did come v2. For example, we could say, I have sauerkraut in my leader hosen, and we want to see this verbose Lee, and there you go. I have a sauerkraut in my leader hosen. It was sent from from Alice to to father, and it used a plane. You know, it did come v2 plane message. We could also say something else, of course, but we could also do it does code completion when you put the options in the front of the final parameter. Yes. There we could also sign this message. And we could encrypt this message. So, although it says RFC 95 of C 90 95 it's it's not really 95 it's it's asynchronous of course, you know, like 95 as well, but it also supports signed and encrypted encrypted messages because that is already part of did come v2. Right. And then we have one more thing. So if I do commands, and then we have this thing here very fiber credentials with templates and policies and a whole lot, which I would like not to demo just yet. Yeah, in case you wonder, so there is a release you can download the release you can do all of this what what you've seen today you can do this at home. The very fiber credential stuff it's it's still work in progress, which I like to demo next time, if I may. And what else do we have. So yeah, I think I think that's it. And if you like to read about what we've just done. What did I start, stop sharing my screen. So, it's here so so this is this is a quick write up of, of what we've just seen. Yeah, so I hopefully I didn't miss anything from this and. Yeah, thanks for watching. Yeah. Best CLI I ever seen. Yeah, you're right. Yeah, wonderful. Excellent job. Yeah, thank you. Fantastic. I love how you organized it by RFC. That's really cool. And yeah, showing did come v1 and v2. The same demo fantastic. Which library did you use for did come is the SIGPA or yeah, I use it. No, no, no, I use SIGPA and and actually, actually today. Yeah, they, they accepted a large pull requests for me. So, so they have now multi SIG again because the, the, the nimbus. Josie, they use internally, they, they use nimbus to say and, and that was quite outdated. I think it was like, like almost two years old, because that would have pulled their multi SIG support out of it. But, but now we have multi SIG again, and we can use the latest, we can use the latest nimbus with with SIGPA. Great. Yeah, the, the, the, the, the, sorry, the Java version of this. Yes, yes. Yeah, it's Java. It's, it's actually, I think it's Kotlin. Yeah, it's Kotlin. Yeah, it's Kotlin. And, and so, so this is, you know, I couldn't have done this without the help of, you know, so much brilliant folks before me working on on the SIGPA library and and the other great library that I use is VaultID. Yes, it's from a, from a, I think it's an Austrian company working on, on EPC stuff and from from them, from them there is, I use it's a lot of support comes from, comes from that library as well. Right, so, so for example, all the various services that I use the, the crypto services, the storage for, for the model and so on and so on. Yeah, so, so I, I really just integrated. The SIGPAs did come to with Vault and put this CLI on top. Right. So, so this is the three things that I actually, after a year of learning what I actually, right. So a few more things that I'd like to mention. Yeah, first thing, ideally, I'd like to work with some other agent on true interoperability. Right. So, so I like to find friends who actually would like to try this out with me. Right. And maybe, maybe this is in preparation of the areas into our profile 30 right so so that we can already actually test some real real world interoperability. Right. So, so maybe the JavaScript agent or the go agent or whatever agent is is ready to to talk with me. Did come be to so I would be very happy to to work with whoever is interested in this. And then, you know, the, these necessary preview protocols that I posted. So, so they are pain in the neck, of course. Right. So, so I would like to get rid of them. Right. And replace them with with actual. Did come be to spec stuff. Right. So I'd like, I'd like us to, to find an agreement or consensus of, of how this initial did doc exchange should actually work and ideally this would find its way into the did come spec or one of the supporting specs. Right. So fill out the bits there. Right. So, verifiable credentials need to get added. This will come from Walt ID as well. They have the concept of a policy engine, open policy engine OPA. And so this uses this uses its own language regal, I think it's called, where you can in a very rich format, you can define your policies that you want to apply to your, to your did come be two messages, right. So, so you could take two credentials, two or more credentials and build a presentation out of this, these credentials aggregate a few attributes, and then you can use the legal language with with their policy engine to to validate that presentation of the very five five credentials. So it's very powerful, but it's not ready to demo just yet. Right. So this thing doesn't have it. This thing doesn't have a did resolver. There's an abstraction for it, of course, you know, and so we have seen, it's being resolved and to to documents but but this is all in memory. Right. So this thing is not, is not connected to to a ledger just yet. Right. So, the other thing that needs to get added is, is a persistent and secure key storage. Right. So, so the little trick that I've done earlier, you know, you just kill the thing and restart it and it, it starts from from a blank screen and this should perhaps not happen. Right. So it should remember the wallet state and should remember the keys that it used in the wallet. Right. And stuff from your wish list, of course, you know, and it's Walt ID, right. Yeah, WA LT. Yeah. Yeah. Yeah. Okay. And if you if you have the link to the pull request that you did with Sikpa. I'm happy to put that up there. No, you know, no pressure, but Yeah, I have it. It's got it's got a silly title, because they just used what the the commit message from from the very last thing. Yeah, but so so what I essentially did here with this pull request. I took out the stuff, the multi six stuff from from Nimbus and ported that over to to the did come code base. Right. So I needed to do a few changes, but it's, it's not that an original work here it's it's very complex still, you know, but it's not. But actually, it would require the review that it got was that all the tests in in in did come still pass with the updated numbers. Yeah, and the updated numbers didn't have multi sick anymore. So, so the multi signal comes from from Sikpa directly, and I didn't touch their test cases and so hopefully, hopefully that this is sufficient. So testing. Yeah. Fantastic. And then what is you've talked about camel in the past what is kind of your. I don't know if I want to say goal or roadmap. Yeah, so yeah for your work. Yes. So, so all of this, all of this work, you know, at one point, it needs to be product relevant, of course, right so so my, you know, due to the vision and generosity of my superiors I can can do all this work but, but eventually it needs to be product right so so my my vision in in this regard is that the stuff that you have seen now is, you know, preview at best. Right so so we can say we've seen a few did come be two messages going forth and back, but all of these messages messages use proprietary stuff from that I came up with. Right. So that needs to go. Right so so that needs to go. And of course, it's no good that Nessus can talk to Nessus, you know, so this thing needs to talk to someone to something else to be relevant. Right. So, so that needs to happen as well. And, and then to be product relevant. The persistence and secure storage needs to get fixed. Right. So, so what I do supports, if I've, if I've seen it correctly, they have support for secure cloud storage S3 and so on so they have various plugins that you can. You can secure your stuff with so that needs to get integrated. And, and once this is done. I'm happy to, I'm happy to, to put this to wrap this into a camel component. Right. So, so what will happen then is that camel has has a large variety of of protocol in endpoints that it can stand up. Yeah, it's not only HTTP it can connect to all sorts of messaging systems and so on and so on and so on. So, so all these, all, all these camel endpoints can then receive. Right. So, so they would get routed to this component. And this component would do all the, you know, unpacking of the message, the security stuff around it and, and all the protocol chit chat that that needs to happen. Right. And at the end of it. There would possibly be a message body, which has, which has some, you know, business orientated payload. Right. So it has a meaning in, in some sort of integration stuff. And the very long shot vision for this is, I know that camel is, is very, you know, integrated into, into the it of operations from, for example, shippel airport in Amsterdam. Right. So shippel runs on camel. Right. So to a very large degree. Right. So, so ideally, you know, let's say in a year from now or so. Shippel, which, which does a lot of relevant stuff and security related stuff and stuff that that we can, I can easily see would have a connection to, to did come be too. And, and in an ideal world, we would have a camel component that can talk did come be too. And shippel would perhaps be happy to, to look at it, you know, and do some of their, some of their critical stuff. You know, their security relevant stuff they do this via did come be too and because they already have camel and they already know Java and they do their stuff in Java is for them it would be easy, you know, to, to, to bridge that gap. So that would be the perfect world in a year from now or so, and in a year from now and so we would have the areas interoperable interoperability profile, right, there would be a number of agents. So, so that Nessus can. So this code base or whatever this code base will look like in a year in a year time will talk will be able to talk to a number of agents and and then yeah more adoption for did come be too. And in a business related relevant manner. So that, that's the idea. Yeah, that's fantastic. In terms of interropping with other agents, there is the movement within the did time v2 user group out of diff, etc, to begin hosting. There are services in a way that we can, you know, show did come v2 is alive, and people can, you know, begin, you know, testing against each other's instances so is there are. Are you interested in hosting this in a way that others can interface with it. Definitely. Yeah, and timing and like what does what does everyone think that looks like. It's just making mediators and agents available. Out there but can we do more like learning from the areas agent test harness to kind of advertise. Advertise the agents that exist and show, you know, maybe even the, you know, which agents work with each other ideas thoughts. I think in a, in a perfect world again, occupy would get ready soon to talk did come v2. Right. And then when when I get when occupy is ready, say at a basic level. Yeah, so so this is the the basic areas into our profile 30. And in occupy is ready. We can have did come v2 compliance at some basic level right and then we can leverage their work in in the test harness as well. So it would be very easy to to integrate this thing into the into the occupy. Right. And, and for occupy, of course, it would be very easy as well if not done already by default. What what is missing there are a few features and scenarios in that test harness that actually exercise did come v2 and why is it missing. Yeah, of course, because the reference implementation can't speak it just yet. Yeah, so poor I think that's part of the reason that the, well, so obviously this working group is focused exactly like you're saying, Thomas but at the same time in the diff did come v2 world. They, there's no dependency, right on Aries at all. They certainly support a IP three. Okay, I guess what I'm where there is concern because the as best as we know the AFJ and occupy did come v2 implementations are kind of on hold, Sikpa has their pull request with AFJ, but they have said that they have no more cycles to work on that specifically. That that pull request is kind of in this middle point because it was submitted right during the transition of AFJ point two and point three and that was a huge actual refactor and so the pull request was more geared towards point two but point three is is the focus because it makes things much more modular etc. In terms of occupy the work was being done by Hakan and his master students but he has transitioned to a new role a new position, we don't know the details of that he thought he might kind of return. That's that got spun up but we haven't seen him since that's happened so essentially they occupy did come v2 work is in kind of a middle ground so that's part of why I'm starting to gravitate towards is there an even simpler solution in terms of each kind of group who's doing did come v2 implementations standing up services and for us to have a way to kind of show the public. Oh, you know these services exist out there you know sometimes they might be down or whatever but there's multiple of them, and you can begin trying to message with these these services that exist. I think you need three people. You know, there's there's one for each agent. So you have me, I volunteer right so so somebody from some other agent, and you need a third guy who is agent agnostic who stands up a basic test compatibility test suite. Yeah, a compatibility test kit. And if you have those three people, right, then you can have, you can have inter of going pretty quickly. I don't, I don't, I don't think necessarily that this needs to be publicly hosted because this is so fast. It's moving so fast right, but but you can run it locally right so you can, you can run messes locally and it will only take you 10 minutes to do what I've done here and in the CLI you can do this at home right so so anybody can do this. But I think we should have, we should have at least three interested parties and one should be agent agnostic. Okay, yeah. What do we want to call that a test? What wording did you use for that one agent agnostic. In the Java world, it's called TCK. It's a test compatibility kit. Like it. Okay. Any other thoughts on that? I do think that the from the diff point of view, they want these agents to be hosted. I know that Sam has talked about having like a Amazon Lambda service. I don't know a ton about these, but it sounds like it just gets spun up when needed. So I don't know, maybe when a request comes in or whatever, it can somehow respond to it and then go back to sleep type thing. It just would seem it's, it's almost proof of life right instead of these implementations you know roots ID same thing, these implementations we have we have like a mediator service who that's sitting out there that has proven wildly useful just in terms of, you know, some mobile agent says, you know, okay I'm starting to do did come to things and you know they reach out to do our mediator. So no problem, you can have it next week I have the Nessus tech domain. Yeah, I have the Nessus tech domain so we can have it running there. All right, well, I think. Oh, yes, we're almost out of time wow that that flew by I mean amazing demonstration time is just for you, I feel like you're, you know, you kind of sit back and you know we don't see a ton from you, you know, and then wow you come with like amazing ideas, you know, you've obviously spent quite a bit of time on it. You're probably top 20 in the world and did come be to at this point so. So, yeah, but anyways thank you so much for sharing. I think it's the first station that talks be one and be two at the same time. So, right. That's a lot. Yeah. Yeah, amazing. Okay. All right, so you know let's chew on this and yeah just consider how we can show more proof of life give give more support for an ecosystem and that's our time. Thank you so much Thomas. Good to see everybody. Thank you. Thank you.