 Hi everyone. My name is Tiag Pina and I'm a software engineer for Kaseyek and I work in the Finsomal product. And I'm Aaron Haynes, I'm the product owner for Desktop Platform in Networks Markets. And today we're going to be talking to you about Desktop Agent Bridging and its value to the FTC3 standard. So let's dive in. Leslie here already made a brief intro to the FTC3, so I'm probably going to repeat some of the stuff he said. Back in the day, the financial services desktop, they had many apps and they still have many apps. And these apps, they work pretty much with the same data. And there used to be big monoliths and the reason people would build these monoliths is because there was no interop. You would be able to achieve some kind of interop between parts of the monolith, but there was no interop between the monoliths themselves. And obviously nowadays it's not how software developers want to write software anyway. And like I said, you could achieve some degree of interoperability, but it was at the cost of very costly integration projects. And meaning that once a set of applications supporting a workflow was established, changing parts of that workflow without a very good reason was just a no-go. So the result of that was limited workflows, not very optimized. The data sharing was very error prone because of all the copy and pasting that occurred. And there was also the proliferation of proprietary interop APIs. And looking at that picture, it's easy to see, right? If my app knows what a security is or an icing or a ticker and they're all working on the same desktop, why is it so hard for them to talk to each other? So things have evolved. All the monoliths have been broken down into micro applications. We have now micro frontends, micro services. Some people would say that we have micro-liths, but that's another discussion. And there's also a proliferation of web applications because the tooling and the technology is so good now. The industry also evolved, not as much as the technology, but now we also have more feature rich and complex workflows. And they are composed of these modern web technologies and these modern applications. And again, Leslie, I'm sorry, but legacy applications I know that you don't like the term. So yeah, so now we have all of these things in place. And now it's a lot easier to make all these applications work each other. So why FTC3 came started? Because we needed a way to increase productivity and streamline workflows and be faster at decision making. And FTC3 proposes to standardize. It's the main word is to standardize. FTC3 standardizes data, standardizes actions, and standardizes application discovery. And this provides a universal connectivity between apps working under the same desktop. It offers plug-and-play app integration into complex workflows and tries to reduce or even remove completely manual interaction. And so the desktop agent was born and came and provided zero-friction inter-app integration. It offered out-of-the-box cross-application integration. And now we have workflows with context links and intent-based actions and streamlining and connecting multi-class applications together. Now, during this journey, and the desktop agent, it changed the way that we are developing software for the financial services industry. And ECOS, we love this, right? The rising tide lifts all boats and we are really committed to the FTC3. And an attestment to that commitment is that we shifted away from our proprietary inter-app API and we are constantly at the forefront of the standard. But during this journey, both us and our clients have realized that are some use cases that we're still not quite there yet and need to be addressed. Thanks, Tiago. So speaking from the perspective of NatWest, I think this is common to probably a lot of big banks, a lot of large organizations, right? FTC is great, but the reality is not this simple, right? You don't just have one platform with one desktop agent, right? For us, firstly, we have a lot of applications that sit outside the desktop agent context. And again, I'm not going to say legacy applications, but, you know, our desktop application estate is huge. It's grown up over a long period of time. We have a lot of applications built in lots of different technologies, you know, big old monoliths, Java swing applications, VB6 applications, .NET applications, you name it, we've probably got it somewhere. But we still want those applications to be able to participate in interrupt workflows. We also have more than one desktop agent, one more than one vendor platform, right? And again, we want to be able to somehow bridge communication between these things. Additionally, it's not even that simple because what we have is we have users who use more than one machine at the same time, right? So, you know, traders might have six screens connected to four different machines, and they see that all as one desktop, and they expect to be able to interrupt across all of those different applications. So, it's a complicated environment. And now, Wes, this is a question we were trying to answer, or questions. Firstly, how do we enable interoperability between applications running in different desktop agent contexts, applications running outside any desktop agent context, applications running in different contexts on different machines, and how do we make that transparent across in-house vendor-supplied and open-source desktop agents? So, we needed some kind of desktop agent bridging solution, which is what we built. And that project became known as Backplane at NatWest. So, that was implemented specifically to solve this use case where we have, you know, multi-hose broadcast of FTC3 context between desktop agents. So, around this time, a couple of other things happened. Firstly, there was an issue raised on GitHub FTC3 repo. I think it might have even been raised by yourself, Leslie. But that was proposing to extend the FTC3 standard to support this use case of bridging between desktop agents. And around that issue, a working group was formed to start to develop a standard for how this could be done. I think Tiago is going to now tell you a little bit about how that's shaping up. Thanks, Harry. So, before we talk about bridging, let's just analyze what bridging the desktop agent bridging problem is designed to solve, and what's the cost of not solving it. So, the FTC3 mission is to develop specific protocols and taxonomies to advance the ability of applications to interrupt between each other in a plug-and-play fashion and with no prior bilateral agreements. And this mission fails if applications in different desktop agents are siloed from each other. But this mission to be successful, any application, any FTC3-enabled application in any FTC3-enabled desktop agent needs to be able to communicate and to interrupt between each other in a plug-and-play fashion and with no prior bilateral agreements. And FTC3 is great, right? But the real problem that we have today is that the success of the standard falls outside the fact that there are already institutions that have multiple desktop agents running. And if we don't deliver this, then, in my opinion, the FTC3 mission falls a bit short because the customers won't get the true value of interoperability. Everything needs to be connected, right? We now have the same problem that we had in the beginning, but in a different format. We have multiple desktop agents. They all speak the same language. So why can't they speak to each other? So we want to go from this to this. Now, what are the requirements to build a desktop agent bridging solution? It needs to be invisible to the applications living in the desktop agent and to the app vendors. They've already done their work. They've already done their bit. They built their applications being FTC3-enabled. They just want to drop the applications into a desktop agent and they just wanted to work. The bridging protocol needs to be a part of the FTC3 standard. And I think this is a really important point. We want to avoid past mistakes of other protocols that didn't really take care of making parts of the interactions as standard and then diverging to incompatible implementations. And we have that problem in FICS nowadays, which we have all companies just being FICS aggregators and FNAP aggregators to trade on different venues. It needs to be easy for desktop agents to adopt as well. We want the desktop agent vendors to adopt the bridging because it's an integral part of the standard or must be an integral part of the standard. And all of this needs to be driven by the community. That's how FTC3 started and is the right path forward. So let's just recap. So the desktop agent API enables interoperability within the same desktop agent. The desktop agent bridging is only concerned with interconnection of desktop agents. It's not a desktop agent. It's not going to implement the FTC3 desktop agent API. It will provide a new contract between desktop agents and a piece of software called a bridge. And it's only concerned with the communication between them. So I want to give you just a quick overview of how this bridging proposal or how this bridging standard will work. So we've considered some topologies for the desktop agent bridging, but we decided that having a standalone bridge is the best solution. It's the most pragmatic one. Probably we don't need complex topologies on the desktop. There's only so many desktop agents. This makes the message routing quite simple because they all need to go through the bridge and we can move some of the complexities of this implementation into the bridge itself, being less intrusive in the desktop agents and being easier for the desktop agents to adopt bridging. And in this case, the bridge will just act as a server. It will receive requests from a desktop agent. It will forward requests to other desktop agents. It will get the responses, collate, and pass to the original requester. The connection protocol. So the proposal, the desktop agent bridging proposal outlines that desktop agents will connect to this bridge via WebSocket. It can be protected by authentication, driven by configuration even. There will be an uncheck in which during that uncheck there are going to be desktop agent name assignment. So a desktop agent can request a name for itself and it will be the bridge that will decide if that name is okay or otherwise will assign a name that the desktop agent must accept. There's also going to be channel state synchronization, which is one of the most complicated parts of the proposal because imagine if you have two desktop agents with two different applications on the same channel but with different contexts and then they want to get bridged, it needs to have some sort of synchronization so that we don't have two apps with different contexts on the same channel. And the last part of the connection protocol will be as soon as all of this is taken care, then the bridge will inform all connected agents of connection and disconnections of other agents. The messaging protocol. So the messages that flow from one desktop agent to the bridge. This will operate in a request response fashion and the bridge will act as a router and a message aggregator. And we have defined four types of messages or message format that will happen between the desktop agent and the bridges and I'll just give a quick summary of those. We have the request only, which is a type of request that a desktop agent will fire to the desktop agent bridge and the bridge will just broadcast that into other connected agents. It doesn't expect any kind of response, it's a fire and forget request. And the example of this is the broadcast message. We have the request response single, which is a type of message that expects a single response from a single desktop agent. The case for this is get up metadata or get or open, FTC3 open. An agent will just wants to open another application, sends the request to the bridge, the bridge at the target just sends the message to the right agent and sends the response back. The other type of messages that we have is the request response collated. So this is a type of response, it's a type of request that expects several responses from several desktop agents. These responses will get to the bridge, the bridge will collate them and make them a single response and will return that response to the original request. An example of this is the find intent and the last is the request multiple response single. So this is a type of request that expects multiple responses from a single desktop agent. And the case for this is the raise intent and again, it's a message that has a target, a request initiates the request, sends it to the bridge, the bridge goes to the target desktop agent and then just forward the responses from that. So what are the next steps for desktop agent bridging? The proposal draft is complete, there's just some minor details to finalize. And the next step is for the standard working group to consider and vote the proposal into the standard. And this is really important. Again, we don't want to have a bridge implementation that is not in the standard because if someone else decides to do another bridge implementation and implement certain details differently, then it's not going to work. We also need a bridge implementation, right? We need a bridge implementation that, like the FTC3 standard, is community driven. It needs to be the community to contribute to this proposal. And ideally, we would have a bridge implementation that would come from a real world case, a real world use case that already happened and already someone felt the need to have a bridging solution in place. And ultimately, we also need the desktop agent vendors to support it. It seems to be quite a lot and it is. However, we have had a great start on that and I'll let Aaron tell you more about it. Thanks, Tiago. So, I mentioned earlier on that at NowWest we had an implementation of a desktop agent bridge that we call Backplane. And please do announce that we've now open sourced that implementation and contributed it to FinOS as of now. So we now have FTC3 Backplane. The code is there in the FinOS repo. You can go and have a look at it, check it out. So, yeah, it's exciting. It's really great to get the code out there and start to build a community around it and hopefully we can continue to evolve it in line with the standard. So I'm going to go through a little bit of sort of high level overview of Backplane and how it works and what the various components are. But firstly, I just want to talk about the name. So Backplane is kind of similar to a motherboard in a computer. Essentially it's there to sort of transparently connect all the various components which is really what we're trying to do with the desktop agent bridge. I can't claim any credit for the name. I didn't come up with it, but I think it's pretty good. So the components of the system that we have, firstly is the Backplane itself which is a headless process, runs on the user machine and enables the WebSocket connections between all the various desktop agents that are connected to it. We also have a client library for .NET applications that handles setting up those connections between applications that don't have a desktop agent context. It enables them to connect to the desktop agent bridge. We also have a JavaScript client library for the same thing for JavaScript applications. And then we've also contributed a code snippet that essentially wraps that JavaScript client as a FinCemble server so it lets you connect the FinCemble desktop agent to the Backplane desktop agent bridge. In terms of the architecture, so as I said, Backplane itself runs on the user machine. At .NET West we have ways to install that so it starts up automatically on the user machines and we have things to monitor it and bring it back up if it goes down for some reason. Once it starts up, you can configure the port range and it enables WebSocket connections. So as I said there, you can have .NET applications connect to it. You can have FinCemble or other vendor platforms connect to it and it will deal with routing those messages across between those desktop agents. The other thing it does when it starts up is it actually registers itself under the logged-in user. It registers the host and port where it's running. So it basically starts to form a group of Backplanes that are running across different machines. This is as an interface there so you can implement that in different ways. Internally we use console for service discovery but you could implement it... I think in the default implementation is just some static configurations you can specify where the other Backplanes might be running. So what that means is when other Backplanes start up on different machines they can discover all of the Backplanes that are running for a given user, for the logged-in user. They form a cluster which then enables the routing of messages from connected desktop agents on one host across to the other Backplanes. So it's a WebSocket connection from the desktop agent to the Backplane but then they actually use REST calls between themselves. Again, that's something that could be implemented differently. You can swap that out if you wanted to maintain some other kind of connection between those Backplanes. Once those are all up and running see the further desktop agent can connect to those and then that lets you route from one desktop agent on one host across that REST connection and over the WebSocket to connected desktop agents on the other host. So at the moment, I guess a couple of things to call out here, so at the moment this is what we've outsourced, open-source is our implementation which is not currently in line with the proposed standard. We're currently continuing to work on it in the open-source version to bring it into line with the standard but we're obviously looking for contributions and help to maintain this now as an open-source project. So that was kind of one of the big reasons to come here today and talk about is to kind of ask people to get involved, help us evolve the product in line with the proposed specification. That's essentially the roadmap now for Backplane is to implement the various protocols that Tiago's been talking about and bring it in line with the desktop agent bringing the standard hopefully around the same time that we get the standard approved. Don't shy away to contribute, right? We're not asking specifically or only for code contributions. You and your own company might have a use case that either we've missed or we haven't validated yet and raising an PR and the get-up issue for the draft proposal, adding documentation to the Backplane that all other contributions and contributions that we will certainly have to have. Like I said, I cannot stress how important I think this is really important for the FPC 3 standard. We've made forward when FPC 3 came up with the desktop agent. Again, we need to be able to have it across multiple desktop agents and like Aaron's now at West use case across multiple machines at the same user. The next desktop agent bridging working group is early next year. Not quite sure of the date, we can check that. The plan is we're going to do a deep dive into some of the implementation details of Backplane. Please do come along if you're interested. We can talk through that with the team. That's it. Like I said, check the proposal. And add comments to it. Validate our use cases. Give us your use cases to validate. Contribute with code, documentation. Everything is valid. Thank you. So Backplane is implementation of the bridge. Because it's to cater for the case where the user has more than one machine so they want to bridge across multiple machines. So Backplane takes care of routing messages from desktop agents on one machine to desktop agents on another machine. Absolutely, yeah. So that's what we've done with that.net client library. So you can build that into your application. It essentially gives you a kind of desktop agent API in your application, but then routes those calls to the bridge. And I can imagine, I'll say it, that you're happy to collaborate with each other and each other's software is played nicely in this. But it begs the question, how do you think of all of this and how do you receive a letter from all of you as a general counsel that this bridge and protocol is trained or that it's a greener? Yes. I can imagine, I'll say it, that you're happy to collaborate with each other and each other's software is played nicely in this environment. But it begs the question, how do you think of all of this and how do you receive a letter from all of you as a general counsel that this bridge and protocol is trained or that it's a greener? Yes. Any other questions? We have not received such a letter. No. There would be nothing to stop if there was... I mean, we've got to happily engage with this stuff. So the source would be needed. There would be nothing stopping some of you who might have writing the piece that it brings between the bridge and the desktop API. Does this have to be an app running inside? Yes. It doesn't have any... How robust is that? Say again, how robust is that? How robust is it? Thank you very much. I wonder why the thing is being... This goes through the VR ads. Wait, is that it? Yeah. Cool. Thank you very much.