 Awesome. Welcome everyone to the 21st of June, 2023 areas working group call. Got some cool stuff to talk about today. I'm pretty excited about it. This is a hyper ledger call. And so the antitrust policy and the code of conduct are in effect here in the notes that are links. Please reach out to Stephen or I or any hyper ledger leadership if you have issues and we will get them sorted so they can not get in the way of our work. So the agenda is in the chat agenda link. You're welcome to make any changes useful to the community. Is there anyone new today that would like to introduce themselves are glad you're all here announcements. It looks like there's a new announcement here for the areas of marketing working group. Hi, good morning everyone. My name is Helen Garno. I do marketing for DCO I also chair the marketing committee for hyper ledger with the membership here at hyper ledger. And I've been working with Alex Metcalf and some other folks in the community talking a little bit about kind of the outcome of the last few areas calls where it sounds like there is a need to update the messaging branding descriptions, the whole the whole kitten caboodle when it comes to Aries brand so we are going to get together in a kind of a working group maybe it's a task force I don't know whatever the appropriate languages for for this type of group but get together and start working through some of the updates regarding branding. So if you have an interest in contributing to the discussions interest in adding, you know, change anything from everything's on the table anything from descriptions whatever you think would be helpful. Please attend if there's somebody else on your teams from your organization that is a marketer who might be interested in joining we, you know, open arms for anybody who wants to roll up their sleeves and help out with this, these items. So I put the information there for the group that we're going to meet next Tuesday 90 and Pacific. There's the zoom link. I am on discord so if you have any questions or thoughts or whatever ahead of time please don't hesitate to tag me there in the Aries groups, or direct message. Alex did you have any other thoughts or call outs at this time for that the announcement of the group. Not for the group this activities going behind the scenes but I'll probably save that for the working group meeting. So yeah, please come if you're interested in contributing at any level, it could be very high level as well. I think I was going to get out the chain not just deaf specific stuff so all input is welcome on talking about and sharing the great work that is being done here. Also lurking is welcome. If you're just interested in listening. Oh yeah lurky we love lurker. Yeah, please do. We have a bunch of folks in the community that are speak up a lot and we have a bunch that just listen and every type of interaction that you desire is perfectly appropriate so Thank you, Helen and Alex and anyone else involved for your work putting that together and your work on the marketing stuff. For sure for sure. Oh I saw john came off me john did you have any kind of thoughts on this. I just, my, no, my wife puts it on mute because I can't unmute myself. Oh, no worries. So I just sit, I lurk quietly with mute off. Hey, we love a lurker. As we said, okay thank you. Bye. Awesome. Very cool. Any projects want to highlight any updates to their work. I don't know if I already shared it here but it isn't updated in the. In the notes I see stephanies is doing the work we have released Arizona JavaScript zero four zero I think two weeks ago with a lot of new features have now completely removed the need for dependency on any SDK. Everything is pluggable support like diagnostic analysts and also hopefully for PCI issuance. So, yeah, big release. Awesome. Excited to hear that and good work thank you for your efforts. Other updates. All right, we'll have some some cool stuff along. 082 and occupy is ready to go probably I'll do an RC one today and get that out. So we did we did an RC zero, have a couple of things we wanted to get in it so they'll be another release of occupy in the near future. Very cool. Thank you Steven. Okay, here's topics for today. Alex, we may not need to do the areas marketing update unless you wanted to additionally given the presence of the call. But I wanted to at least call attention there is there anything you want to say in this meeting specifically about that or which I'll give you. I'll give you like a one minute update for sure and then we can carry on with the majority of that material through to the working group call. You've got a minute. Okay. To say that just to update the view that things are moving forward. Really well I spoke to several of you in the week. You could self this and Helen and to pass this and looking at the link there is going to be a working document, which is going to work sort of bottom up on some of the materials we need but just suffice to say that there's going to be interesting questions as to to do this exercise and to think how we present ourselves and how we have a better wiki landing page and how we have a better page on the hyper ledger and all those kind of things. It's been a questions as to what areas need to be presenting itself as as a designer there what are the three things it does great, for example, that would be amazing highlights of people coming in that would be differentiators. So it's going to be some exercises around that Helen's got a great questions that will probably use come next week. But if I say you're welcome to look at that document updates and be putting some more things in every working off dog need to go back into there. But if you've got any interest in how you present ourselves or if you are any parts of like of things that we could say better, or materials that we need or videos we should highlight or any aspects of this. Either you can reach out to me or you can use this document or come along even better to the first meeting that I just mentioned. So, moving along with a focus on what's the low hanging fruit to get some more accurate information up first, and then we might refine that later so let's get some things up to say what areas is doing now because a lot of information out there is is 2019 era from, you know, announcements of what this is and things that moved along a lot since then, and now's our time to shine so yeah thank you for all the people I reached out to, and hope to see you know if you next week. Thank you, Alex I will credit Alex for making me think about things like how to properly articulate what is different about areas than than other agent projects that would need to be questioned because they're kind of weren't any other agent projects. And so that is that's something that's made me think a lot. So, so they're they're doing fantastic work. So, quick update there. The stuff we have on the, I guess next week is not mediators because this week is mediators. We have a couple of main topics. Oh, one that's not in the list but but is another quick update is the open wallet foundation update. And then we want to talk about mediators and the the did peer unqualified did mediation update there's now a migration doc, which would be awesome. So, so yes, that is the that's the goal there. Any any adjustments we want to make before yeah, any adjustments we want to make to the agenda before we get going. So, uh, WF update last week, we, you know, I shared a link for a sort of a proposed collaboration type of a statement. And we're still working through, I say we Alex has volunteered to be involved in that more directly. And so we are still having conversations with WF leadership to figure out the sort of the right thing and path forward there. And it's happening, although a little slower. There's a little bit of confusion in there and we are working to resolve that. So yes, and Timo, any other comments on WF. Yeah, maybe to one question on like, you said like still in discussion I think. Oh, WF, like, was in like they're already partners with hype legend arise and so I think it was kind of finished right the discussion as least that's what I heard from Oh, WF site. But that's not true. No, well, it's, it's, let me try and explain a little bit. There was a little bit of a misunderstanding about the purpose of the sort of a joint statement that we were proposing. There isn't any legal changes actually necessary between the organizations. There wasn't any actually in the beginning anyway, because of the compatible licenses being used by the different organizations. The point of the statement was more of a signal of like collaboration, not necessarily the establishment of anything like legal necessarily. And so there's a little bit of confusion early on about what the intent was or whether something was actually needed. And that's that confusion is being resolved and unraveled a little bit as we go. So, the, their response was based on a legal perspective when they're not wrong, but the, but our goal wasn't really to establish something legal either. And so it also wasn't really completely the thing that we were trying to do. And so trying to resolve the confusion there and I think we're based on emails yesterday evening that I think we had even up to yesterday evening we have some increased understanding there. I hope Timo, or any other comments there helps. Yeah, yeah, so I had one other comment like, I think I'm not 100% happy at I think with outcome. And that's okay I think because we don't have to all agree on like the outcome but I do think it's still interesting to pursue and I think I would also and this is something we would have to discuss for example in for example, Ericsson with JavaScript community, but if there's like, if the Open Wallet Foundation as a whole isn't ready yet to host a whole project like Erics, like we could try moving single projects over for example and see how that works and if we can make that work and do that one by one. And so, like I can't speak for the whole AFJ community here of course but something that I would be interested to in for example seeing it like being a guinea pig project that that we can try things out with. I think, because I think the main thing we have said here like, oh WF is not ready to like it's very not mature, I think I heard from oh WF also there, they've offered to to basically hire everyone on the hyperledger. I think that can help and that helps with hyperledger on infrastructure and operational site that they have offered to hire them so I think that that should get quite a lot of assurance. But yeah, just wanted to throw it out here for to consider when we continue to discussions. One thing that I want to highlight there is that I wouldn't really consider what we've proposed is sort of a final outcome in any way, but rather an intermediate step that can be something that we do and get done. But that doesn't necessarily preclude any future actions there, either. The nature of these things is, as I've heard Steven say a lot is a duocracy in the sense that the people who do have the most control over what's going on. And so the maintainers of any individual project or library matter the most when it comes to sort of what actually happens individually there. We are a voluntary coalition of projects that are together, etc. And I think that there's some, there's some helpful pieces there. Definitely some discussion to be had. And I think that any, I think the progress that doesn't move forward would be substantially easier if it's a little bit more gradual. And that allows for the change to be metabolized in an easier way. I think there are some open questions there. And so definitely there's ongoing things I don't really consider this to be like a done and and and no more discussion, but rather the change the nature of the discussion in a way that allows us to to accomplish things in a more targeted way, as we desire. So what you described there Timo was not really at least in my brain out of scope for what's possible in the future. Any, any other comments or questions from anyone on that particular topic. I will be having it's john have a discussion with Daniel tomorrow if there's points people need to cover or not cover I'm happy to receive those. Cool. Yes please reach out thanks john for for being involved and and you can reach out to john for anything that you would like to share. John you're on discord, I do believe. Yep. And so john is reachable there. Cool. Any other questions comments. Okay. Next up on the agenda here today is mediators. And I wanted Stephen brought up the concept of a of having a sort of a mediator status update roundup thing and so I'm going to check this over to him. For an intro there. Alright, I'll just do an intro to the problem is my thought just so we have a foundation for for discussion, and we'll go from there and see how things hopefully this helps. What I am is a messenger of the problems I don't have great solutions so not going to help there but I'll show you where we've got to and our and our talking about it. Everyone knows what mediator is mediators are used for wallets in particular they can be used elsewhere actually we're, we're, had a brief talk this week about whether we can use mediators to get rid of the developer problem with them because we're finding some of our developers work for companies that don't allow the use of and rock, and we can actually use mediators for so many years aren't just for wallets but that's the biggest use for scalability we want to be able to use a container for an illustration platform some horizontally scalable platform for using it scale the number of instance of a mediator as the load growth increases or decreases support migration of instances. So, from time to time a platform scheduler like OpenShift will suddenly say hey, I'm going to shut down this node so everything that's on it needs to get migrated somewhere else so instances would be shut down and started up elsewhere. We need queued messages. So that when a instance is shut down or started up, or when wallets are not connected queued messages are not lost so they're not sitting in a in a memory queue associated with the instance and then get lost when that instance disappears for whatever reason. And then the other thing is we want to understand what scalable means for any particular solution. How many wallets can we actually support. What are the assumptions about how many active wallets there's likely to be for a given use case we've had lots of discussions around the BC wallet on that case well if we add, you know, a population of 50,000 users well how many are going to be active in any one time how many, how many messages are we going to be able to process for those. What does it mean for there to be 50,000 wallets out in the wild. In terms of how scalable the mediators. So I've got pictures to follow an areas example and then mediator examples and the complications. So, the naive approach is on an areas agents is everything's talking HTTPS. You can simply increase the instances and scale up by load. And so, as, as things get busier you add another areas instance and another areas instance whether that be Acropy or AFJ or whatever it is. You've got agents out in the wild talking through this endpoint and then that gets load balance across these. You also have the controller whoops, didn't mean to do that but you also have the controller that's sitting out there. Hang on one sec I gotta move that. You also have the controller that is talking to the various instances. So, big issue there, if the instances are lost messages are queued on these instances, if things get really busy the instances start to queue messages if the instances fail or more precisely when the instances fail because it will happen queued messages are lost so that's no good. The next approach that we've taken is we add a Redis queue. The way it was done in the first cut of this group from Kiva's first began this work, or a person from Kiva began this work was to add a relay that basically received messages stuck them on the queue and then areas instances stuck out down messages on to the queue and those relays would send them back out and this was all good when all we talked to were HTPS all of the agents the controller could talk to the endpoints. The messages would go in and out of the queue so Redis is just an example of a queue you could use Kafka or other other items, other persistent queue mechanisms for that messages are not lost when areas instances go away or when relays go away. All of these instances can process any inbound message any relay can send any outbound message. As noted the relay is it required the areas instances could perform all of the tasks could push and pull messages from the queue. And basically everything is stateless which is exactly what we want. Yay. There's no state involved and so things that's sufficient. If all we have is HTPS. So mediator adds more complexity so the mediator picture is slightly different. First of all I left out the controller just to make it simpler. We talked about this we can configure the mediator to be auto accept it. I'm willing to mediate for anybody that asks, or you can even make it a plug into, you know, a fj or occupy or whatever you're doing as your mediator. So that doesn't have to be external. An external entity so just to make it simpler I got rid of the controller agents send in messages that are sorry wallets and messages directly to agents so a wallets wallets are over here. Agents are over here obviously wallets are agents to they're always but they the way the agents use the mediator is different from how the wallets use it so wallet send messages directly to agents. So that means when a wallet needs to do an outbound message it can send it directly it does not have to flow through the mediator and that's generally what's done. So messages do not flow through the mediator when this happens. Inbound messages are all outbound to a specific wallet after mediator instance processing so the wallet may be offline, so it has to get queued. So we probably need read us again so this idea that we're sitting here with no queue that's probably naive so that's we're going to have to address that. And then the next thing though is wallet to mediator instances are sticking so, so what I'm saying there is basically a shoot a, a, a message from an agent coming in is bound for a wallet, but it has to be sent through mediator instance that interprets the message figure out the wallet that it's for and then sends it to that wallet. What, what happens is the wallets mediator instance connections are sticking so that means when a message comes in after the connections been established between a mediator and a wallet, the next message has to flow outbound to the wallet through that mediator. So now if the load balancer receives the message sends it to the media to the first mediator instance, it has to send it over to the second mediator instance, and then over to the wallet. So that means basically, we're no longer stateless. That's where the problems come in. Note that the connected instance this mediator instance is talking to this wallet until one of them disconnects, and then the wallet has to reconnect so this mediator could disappear this wallet could stop for a while and then start again. What happens this wallet is going to go through the load balancer again and establish a connection to some, any of the mediators could be the same one could be a different one so that's where we also get into handling issues. I see there's a chat. Hope this is helpful. I mean, this wallet is talking to this wallet from each of the wallets perspective they're just agents they have no idea that they're, they're each other's wallets, or they are, are fellow wallets. So, if a wallet is talking to another wallet, each of them perceives the other is just some external agent and it doesn't care or know that it's another wallet. That's a, that's a circumstance that I would detail that it's not really relevant to this. Both of them have to do it but it's not, it's not a special case in other words that's not really a special case. So, just on your second point where I said wallet sends message directly to agents. I guess that's how what you're making the distinction agent can say that a wallet is in a conversation with another wallet. It thinks of it as just some other agent it doesn't care that it to wallet, and it might even, you know, it could be a wallet that doesn't share the same mediator even. Right. So, but to generalize mobile wallets do not send a message directly that's what if they send it to whatever the endpoint, the other agent tells it to whatever, whatever endpoint this agent has said, if that's a mediator that's a mediator if it's directly to the agent doesn't matter. I could I could say to what this should say I guess directly to the agents endpoint to be more precise. Not quite because in a wallet to wallet situation where they have peer did. Yes, you're right it's always directed by the peer that defines the endpoint, but I'm just making a point that outgoing message can also go through the mediator if directed so it's not a rule. I don't know of any case where it would go through the mediator unless like if the two wallets don't have the same mediator it wouldn't go back through the same mediator would go to a different mediator. Okay, we'll figure out we can put that on the we can keep going is just like is not clear the mobile to mobile agent situation. There's two. I think I think as far as I understand and maybe from my FJ or from from backup I can listen better. There's a communication through the mediator. Yeah, so basically the the endpoint of the other agent happens to be a mobile agent. And so it would also have a mediator and it might be the same mediator. As the other mobile agent is using so from mobile to mobile communication, the outbound communication may also go to the same mediator. But again, I. Yeah, I mean I that's totally true what I'm saying is it's, I don't think it's relevant to the use case because the wallet sends it to wherever the the other other party says to send messages. It doesn't say to the mediator hey I need you to send this message over to this other place for me. It's sending it to where the other agent, whether it be a wallet or not tells it to. I think a bit of clarification here the mediator cluster that's being referred to in this diagram is the individual wallets mediator when it is communicating to an agent that agent may be high or maybe behind its own mediator which is separate from the wallets mediator. Stephanie one question regarding this, the cluster. So that means that the all those instance mediator have a share database or share storage have all persist the message but also persist the keys or share the keys. Yes. Yes, these I took that detail out but yes there's a shared database here that all are using so. As in the, as in the previous diagram there isn't you know an Oscar or a, you know, secure storage that is shared amongst them. And then with this I'm adding. Now we've got to have read us because we have to have read us so that messages for wallets that are not connected or, or the loss of mediator instances you have to have some sort of persistent queue so you don't lose that. Again, relay isn't necessarily required. It could be a mechanism so again a relay is simply just something that is receives messages puts them on the queue takes things off the queue and sends them along. Oh, the other thing that I have a new map I have a new track that the other thing that I didn't highlight is that inbound messages all come in via HTTPS outbound message or messages to wallets between the mediator wallet or Web sockets so these are persistent they're they're, they're done over HTTP but the connection remains and multiple messages go back and forth across them. And that's the stickiness that that is that is there. So, once a wallet. And actually I'll get into that in the next in the next slide so so how do how do wallets connect to relays. Is this level of hopefully this level is right so the starting point is the wallets are not connected to the mediator at all. They're just live they activate and then and they created did calm request to send the wallet and that request is going to be one of three things one is will you be my mediator so the wallet has never connected to the mediator and wants to have the mediator be its have that have that mediator instance be its mediator so will you be my mediator is one type. And a second one is, oh, I've got a new connection that I want to establish, will you mediate a new connection for me. So this is where it's establishing a peer to peer connection with some other agent and that agent could be a another wallet or anything. And then finally, a wallet that perhaps just disconnected or just came online is going to connect is going to create a request that says you have any messages for me. So one of those three messages are going to come in they're going to send the mediator is going to send that request. The load balancer on the instance is going to route that to a receiver, whether that be a mediator relay I'm just calling it a receiver the wallet and the receiver from then on remain connected until something causes that connection to be lost. And while they're connected any messages between the entire mediator cluster and the wallet. All are all must be sent through that particular receiver. So coming back here if this wallet connects with our three any messages destined for this wallet must be sent by our three because it's got an established connection WebSocket connection that our two can't initiate a connection and wall and the wallet. So therefore it can't send a message to this specific wallet so that's, that's the stickiness that's involved. New messages come in for the wallet to the mediator. So again, any, any agent sends the messages in to the to the mediator. It must be routed through whatever is connected to that wallet, be it you know our three or if there's a drop connection, we start back with the do you have any messages for me, and that's likely to go to a different receiver. So we wind up with, you know, it gets load balance it gets sent to a different receiver instance and that receiver now has the connection. So the challenges you wind up with that. Each mediator instance is connected to a bunch of wallets. So each has a wallet ID and each has a, you know, some sort of has a WebSocket connection. So one question is how many WebSockets can each instance handle. What does it need to handle so if you've got, you know, province of British Columbia has 4 million residents that may get a BC wallet how many, how many are going to be active at any one time will have an active WebSocket and how many instances will we need to handle that many WebSockets distributed across a thousand 10,000, you know what's the number we don't really know. Agents send in messages addressed to a wallet ID so inbound messages coming to the mediator that are destined to a wallet aren't they don't know the the to address of the wallet until the messages been processed by a mediator instance so in the case of a relay, the relay won't be able to interpret the message relay is just passing on messages inbound and outbound so we're assuming it doesn't decrypt the message and therefore it can't determine the destination wallet did. So that has to be done after a mediator instance has processed it. This is the tricky part how do the messages get to the right instance, given that there's. If there's no connection. It just goes into a pending queue to be picked up when the wallet connects that should be a question mark that should be a statement. So how does an instance query the queue for all its messages so suppose an instance has 10,000 WebSockets, you know 10,000 wallets connected via WebSockets. How does it find all the messages for all those 10,000 wallets, presuming it can't go polling through to say you have any messages for wallet one, what about wallet two, what about wallet three can't do polling it needs to pick it up somehow. What happens to all those cute messages when a wallet disconnects and then disconnects first of all so now whoever was handling that whichever instance was handling it no longer is talking to that wallet so it can't send it any more messages. Whether when the wallet reconnects it may reconnect. You know a minute later or a half a minute later because it just went out of cell range and then, and then switched over to another, you know, another network instance well it's going to reconnect presumably to another instance and now that instance has to find all those messages. Probably what happens to the huge messages with an instance shuts down. So an instance is handling the messages it's sending messages along to the wallets it's connected to it shuts down. All of those messages have to be recued and then, or at least picked up when, when the wallets reconnect. So we certainly need to add state. So, you know, we've got some sort of table of shared state here that says oh wall, you know wallet one did is currently connected to our one using Web, Web socket one wallet two is using Web socket two on our one. That's a mistake there wallet three used to be connected to our two but then it disappeared so now it's not connected to anything. And so on. So, some sort of state has to be managed somehow to enable those to pass. And with that I sort of leave it. That I don't have any more and Kim's got a question or a comment. There's one more problem that would need to be addressed and that is what happens if there's two Web sockets for the same wallet connected. There you go didn't know that one. And there's a couple of different stories there that could be handled it's a more advanced use case that we could table for now, but it's definitely worth keeping on. Stephen, you're still sharing. I don't know if you knew that. Stephen, you're still sharing. Yeah, I know I lost it now my machines. There you go. You got. So your hands up. Yeah, Stephen, how you saw that instead of using Web sockets use HTTPS with that sort of pulling mechanism. Can you hear me. Yes, we can. Okay, using HTTPS with a pulling mechanism or maybe push notifications to go down and find the messages because that maybe you're going to avoid the Web sockets that is messy with millions of wallets. We, that is possible. Although I, we have a good answer here in a second. So hold that thought. I think so I want to hear from from animal but I happen to know that Stephen asked a bunch of questions and I know that we had there's some cool stuff that we would like to share. So I'd love to throw it over to I don't either either Micah or Colton from the DCO team I don't know who is going to be driving. I think I will go ahead and start the conversation and pass it off to Colton here in a moment. Let me figure out zoom screen share. Okay. Can everybody see this. So, we are talking about a repo that we have called socket doc. And it's not public just yet, but we'll be making it public here later today I think we just have a couple of cleanup items before we do that. But essentially, it's, it can be stood up in front of a cloud based mediator. And what it does is it holds web sockets for arbitrary agents wallets. And will forward WebSocket traffic across HTTP. You can set up arbitrarily many behind a load balancer. WebSocket will be associated with a specific instance of socket doc. And so when Alice, for example, send the message up to another connection through the mediator. It'll go to this this first specific instance of socket doc. And that will sort of convert it into an HTTP message with enough metadata to associate that message that connection with this specific instance of socket doc. So that in the cloud mediator needs to respond to Alice. It knows which instance of socket doc to send it to. That there's no shared state between the socket doc instances. The state that's necessary is passed alongside the inbound message to the to whatever back end it is a cloud mediator in this diagram. And then that state includes a back end API endpoint that is not run through the load balancer that links to the specific socket doc instance. And when a return message is sent, it knows exactly which instance to reach out to to pass it over the to the already, or the still connected WebSocket. So no shared state between socket doc instances means a horizontally scalable without limitation at that level. And, and if Alice were to disconnect and reconnect, you know, she wouldn't need to know which instance of socket doc she was connected to initially. And so can the load balancer can can reconnect her with any instance of socket back. And, and that'll be fine. And we, we recently ran some tests with this setup and all. Before moving on there to the test I do want to go ahead and add on that when because you mentioned when Alice disconnects. So when Alice disconnects the socket doc process will go ahead and send off a message saying hey, Alice has disconnected, giving the mediator a method to potentially start queuing the messages instead of trying to send like forward them on in live delivery mode. And Stephen I see your hand up. The question I had coming back to that is, is messages coming from other agents going into the mediator. How do those get associated with the doc, the socket doc. So they don't. So what happens with those. Yeah, so, so you're asking the right question socket doc doesn't actually care it does no evaluation of the messages. Yeah. And so what matters is the software on the other side. So if you are, if you're using socket doc with an agent and you want to keep track of, you know, which, which agent is connected then on an inbound message the first inbound message from that agent you're going to record the socket doc identifier which basically contains the URI for every return message. And it, you're going to associate that with whoever actually sent the did com message that you process socket doc doesn't do the processing, which means that if you then want to send a message back out at any time whether it's a live delivery or just a message that the mediator wants to send, then it's capable of, of looking that up in state in that and then when you'll see there's a post a message URI and a post to disconnect URI. So when, when the socket is disconnected, a message just with the disconnect URI sent to the, or just with the idea sent to the cloud mediator. So that the cloud mediator or whatever agent is behind it is capable of cleaning up their state and knowing that that a current socket doesn't yet exist for that party. Does that make sense. So all the state is actually held by whatever agents is behind it. Socket doc just handles the problem of holding on to the Web socket and allowing for messages to be able to be sent back to the back to Alice in this diagrams case via the the external host and port, you know, send, you know, send URI that's actually passed. So basically that diagram that I showed her that trivial table that I just just made up is basically going to consist of a wallet did and a URL. Yes. So we use as an ID we use the URL and in the URL isn't good. Sorry. So that that state is going to be maintained in the cloud mediator. Here's, here's all the wallets that I support that that I've agreed to mediate and here is their current URL to send them to whenever a message comes in. That's correct. Okay. Yep. So the socket doc is as simple as possible. We say cloud mediator or other agent because socket doc doesn't actually care. What is important is that if you have an agent that is receiving messages, it needs to understand the format being sent because it's not just a did com message. It has a little bit of metadata alongside it, which contains that that URL which services ID for the socket. And so there may be a little bit of stuff put in front of it to make that happen. There's the good news is and there's code here on the screen. And again, this will be open later today. So this is what the message actually looks like. There's a there's a metadata that has a struct in it with the callback URIs and then and then the and then the actual messages passed alongside there as well. And so this isn't a lot of code, but it performs a really important role that allows for an abstraction to occur architecturally speaking between the maintenance of sockets and the and then a back end processing engine that doesn't have to be capable of sockets at all. I have a minor understanding of how to use socket doc as its front end, if you will, but that's pretty minor and and everything else. So we've, we've had this and we've used it, but we wanted to verify that it performed the way that we hoped it would and we ran some performance tests. Yep. And just to clarify, like in this scenario here, where you now have the wallets connecting through socket doc. The wallets, as far as they're concerned, they're still talking to the mediator via web sockets. But now as the media as far as the mediators concerned, it is only communicating via HTTP get or HTTP post requests inbound and outbound. Now moving on to the performance metrics that Sam mentioned. If one of the instances of socket doc fails. What happens. If it fails then all of those agents will need to reconnect there by associating their new Web socket with the new mapping inside the cloud mediator. Right, so but their state I guess is held by the mediators. No problem. The post would fail right the post the post would fail. So if the socket doc came back up and we tried to post a message but Alice was no longer associated with the socket doc instance here. The post to socket doc would fail saying hey we don't have that guy connected to us at which point the cloud mediator would say oh hey my post failed. We have to queue that message instead and wait for her to connect. Yep. Okay. So we ran a few tests just kind of scaling up the system this test here. We ran it with 3000 users. And we were getting just you know the user all these users are just establishing a connection to the mediator and then doing a ping continual ping every about a minute or two. To the mediator. And we noticed that there weren't really any failures. And everything was going smoothly. So we changed from and the system use on both the nodes was fairly minimal. So what you're indicating here Colton is that we have to socket doc nodes in front of the cloud mediator of some type. Yes. And actually so what we're doing here is we have the Amazon AWS load balancer in front of two T two micro nodes which have one gigabyte of RAM. And so we're currently just doing using or performing these tests with these two nodes. And then we have a cloud mediator behind that right. Yep. Okay. And so fairly minimal RAM usage and CPU usage here throughout that test. Next up we decided to bump up the numbers by quite a bit. And we bumped up the number of users to 10,000 users. The drop here is because we were. So I actually think that this is a statistics issue with the 95 percentile started to take into account the pings. The 95 percentile here includes the AFJ startup time. But as soon as you have enough things that may cause the 95 percentile to drop lower there. And so that's due to a statistic function. I also thought that the drop off was due to the fact that we were starting up those. AFJ agents, or wallets in this case. We slowed down the spin up. Just due to a limitation on the test machine of the test machine itself that was sending these requests out. So that's due to the CPU limitation. But again, it's a statistic issue if you look up above the percentiles inside of the different functions here. You'll see that the ping stayed relatively consistent. And the on start time was relatively consistent. If you look at the different percentiles here. And the startup was dragging that percentile way up compared to where the pink. And again, like 10,000 users. No big deal. We're still going ahead and handling everything. All of those socket communications being load balanced. And we're still we're only at 436 megabyte RAM usage on these two nodes. CPU usage is still relatively small. So we decided to bump it up even further to 12,500 simultaneously connected users over Web sockets. All of those pings still for all intents and purposes chugging along just fine across these two load balanced. T2 micro instances on Amazon. And our RAM usage is still below 500 megabytes on both of these two nodes. And our CPU usage with these active pings is still relatively small. And so what this means is that all of these agents they are all of these agents that we have connected and running these pings. They are live active agents in a sense just waiting for messages. And so if they were mobile agents, this would be like 12,500 people all at once just opening the app and having it open on their screen. As soon as they would close the app, it would close that Web socket communication. But our tests here are without that whole close of the app. These are all active Web socket connections. So Charles got a beginner question why the focus on Web sockets. It shouldn't be transported Gnostic a mediator could use SMTP the preferred. The reason why it's preferred for mobile agents is that you want a message to arrive really soon without necessarily polling. You can also rely on on push notifications for this. But when you're, if the app is open, the likelihood that the person is going to be receiving a message goes up substantially as opposed to any other time, which means that maintaining a live Web socket connection produces a really, really fast user experience for inbound messages. But we've had a challenge up to this point about scaling the number of Web sockets that you can maintain easily. So these T2 micro instances cost 10 bucks a month on AWS. I realize on different platforms that will be different, but just to give you kind of a sense of what the cost is. And we're making an educated guess that that at this point we can support 10,000 sockets per T2 micro instance, given this behavior. Obviously some some more real world experience will be helpful and evaluating that number, but we feel like this is a really great way to cost effectively provide that that connected Web socket experience. Kim. I did want to mention that the load testing could go much higher. It was a limitation of the load testing configuration at the time, not the micro instances or the cloud mediator. Yes, totally. We we had a single instance driving this and we have the capability of doing clustered test driving boxes and that's what we'll need to do to drive it above that we were running a very large instance to run this number of sockets and what was happening. And that test by the way Kim mentioned this was using AFG underneath. So unfortunately we have like one minute left. This has been fantastic. But hopefully so this falls Stephen into your your relay in the diagrams that you were showing and can perform that relay really really well and it doesn't care what's behind it. It can actually feed those messages. Of course, into into a queuing system or any other mechanism that would be useful for that. And we also have a proxy mediator that that that Kim just dropped a link to that allows this is what we use to avoid the the. Oh shoot, I just blanked on this. Oh, you can see this openly later today. We almost had it open. I think it would work with AFJ as the mediator as long as AFJ was able to process the inbound posts. So there may be a tiny shim in front of that of that. Timo, in order to use AFJ as that there's no there's no pre processing of the did come messages done. It's just that we're posting that with some additional metadata. So really quick. In the agenda. There is a link that I that I need to share because we need review on it. Timo has produced a legacy did transformation document that needs review so that we can use this. The proposals that we use this as a way of transitioning off of the legacy dids given sort of what was pioneered inside of AFJ. And so Timo created this this does need review and we can bring it up and talk about it online and in our next meeting. But I wanted to highlight that as well. We will be posting the socket doc repo link inside of the the areas channels on discord. And for your perusal and we would love some questions feedback bug issues, all of those other things. If the community is acceptable to it we would we can transfer that repo into the hyper ledger organization. It'll first be made public as a as an in DC or repository. With the license file etc in there but but we would love to transfer that we just want to make sure that it's desirable by the community to do so. And I apologize for going over. But thank you and we can talk about this and then please reach out. I'm Colton and and Micah are the are the experts on this code and and they would be happy to answer any questions they are also on discord. Any, any final comments since we're two minutes over. Great stuff. Thank you. Fantastic awesome work guys thank you. Thanks everyone.