Desktop Agent Bridging Discussion group 22nd Feb 2023

[kriswest]

Group overview

Discussion group for developing proposals for producing bridges between FDC3 implementations (aka Desktop Agents), allowing applications running on one Desktop Agent, to integrate with FDC3 applications running on a second Desktop Agent for the same user.

The interop between applications running on different Desktop Agents aka Platforms would ideally cover

• Channels
• Raising and resolving Intents
• Launching Applications

Current proposal document

Relevant issue tags

• Current open issues that relate to the above concepts with the label:
  
• The original issue is now a github discussion where content can be added and this issue discussed:
  Desktop Agent Bridging Discussion group #544

Meeting Date

Thursday 22 Feb 2023 - 9am EST / 2pm GMT

WebEx info

• Meeting link: https://finos.webex.com/finos/j.php?MTID=m55d4aa79e148c948bf53163690e74fee
• Meeting number: 2558 920 8729

More ways to join

• Join by video system:
  • Dial 25589208729@finos.webex.com
  • You can also dial 173.243.2.68 and enter your meeting number
• Join by phone
  • +1-415-655-0003 US Toll
  • +44-20319-88141 UK Toll
• Access code: 2558 920 8729

Meeting notices

• FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

• All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

• FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.

• FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

• A Discussion Group has no direct decision-making power regarding the FDC3 standard - rather it is intended that anything they propose or work on will result in proposals (via Github issues and PRs) for the Standards Working Group participants to consider and vote on for inclusion in the standard.

Agenda

• Convene & roll call, review meeting notices (5mins)
• Review action items from previous meeting (5mins)
  • Desktop Agent Bridging Discussion group 25th Jan 2023  #897
• JsonSchema for messages, AsyncAPI, Socket.io, SignalR, ws (25mins)
  • Proposal is currently based on agent < - > bridge communication and doesn't use any higher level grouping or multiplexing concepts:
    • e.g. grouping of messages:

        Specific Agents 	-> RequestToBridge   		-> Bridge (request handler)
        Bridge (req handler) 	-> RequestToAllAgents 		-> All Agents
        Bridge (req handler)	-> RequestToSpecificAgents 	-> Specific Agents
        Specific Agents 	-> ResponseToBridge 		-> Bridge (resp handler)
        Bridge (resp handler) -> ResponseToSpecificAgents	-> Specific Agents
        Bridge (cnctd agents) -> ConnectAgentsUpdate 		-> All Agents
      

    • mapped to channel names (with {variables}):

        RequestToBridge = bridge/request
        RequestToAllAgents = agents/all/request
        RequestToSpecificAgents = agents/{destkopAgentId}/request
        ResponseToBridge = bridge/response
        ResponseToSpecificAgents = agents/{desktopAgentId}/response
        ConnectAgentsUpdate = agents/all/connectedAgentsUpdate
      

    • Frameworks may be quite specific - necessitating use of their specific client
    • SignalR Groups & Hubs/Socket.io rooms & namespaces/AsyncAPI channels
    • AsyncAPI can be used to document APIs produced with frameworks. Seems to abstract some details (e.g. connection protocol)
  • Are any grouping concepts actually needed?
  • Should a framework be adopted OR a raw websocket protocol?

    • SignalR/Socket.io provides features such as automatic reconnections, fallback transports, or the ability to broadcast messages to all connected clients, or only to specific groups of clients. With vanilla WebSockets, you don’t benefit from such features out of the box; you have to build all these capabilities yourself if they're relevant to your use case.
      https://ably.com/topic/signalr-vs-websocket
      https://ably.com/topic/socketio-vs-websocket

    • Another aspect to bear in mind is the degree of flexibility you need for your use case. Raw WebSockets provide more flexibility - you can design your own architecture and your own protocol on top (although this is incredibly difficult and time-consuming). In contrast, Socket.IO/SignalR comes with a pre-designed architecture and protocol, which may become restrictive at some point.
      https://ably.com/topic/signalr-vs-websocket
      https://ably.com/topic/socketio-vs-websocket

    • Note: we do not need to deal with issues of scale or auto-reconnection/QoS
• Updates from the BackPlane project (20mins)
• AOB & Adjourn (5mins)

Minutes

• Review of action items from previous meeting

  • @Vivek-NatWest
    • NWM looked into asyncAPI - it doesn't map fully to client/server type of communications like OpenAPI does
      • Seems to be more targeted for pub/sub type of data flow
    • Testing Framework milestone was created - Will need community help.
    • Documentation for single-machine is not separate from the multi-machine but documentation mentions steps that can be skipped if not applicable to multi-machine scenario
  • @Julia-Ritter Still needs to sync with the FO group (who have been busy with CDM release)

• Discussions about AsyncAPI vs OpenAPI and how the different technologies would apply to doc generation of the bridging protocol

  • @tpina has made progress on producing JSON Schema defs for each message exchange and object (inc. converting API Typescript Objects to JSONSchema, for use in payloads.

• Discussions SignalR vs SocketIO vs raw Web Socket

  • Socket frameworks add layers of abstractions that cause challenges to the way client are server code can be generated from the documentation.
  • @kriswest mentioned the different concepts brought in by frameworks - SignalR: Groups & Hubs | Socket.io: rooms & namespaces | AsyncAPI: channels
  • At the moment, it is not clear how to model the connection flow, message exchanges are easier.
  • As designed, the DAB protocol doesn't require multiplexing (making it easier to send messages to multiple parties) and may not benefit for the abstraction provided by these frameworks.
  • Code generation from definitions (AsyncAPI) might have some shortcomings for different languages - e.g. no generators for .Net.
  • @kriswest - Should a framework be adopted OR a raw websocket protocol?
    • Use of SignalR in an implementation has an effect on the protocol (as its an abstraction over the websocket transport) - a SignalR client would be needed to implement bridging client.
    • @Vivek-NatWest - Bridge should not be bound to singalR. A server implementation with a framework should not impact client implementations that use raw websocket implementation or other frameworks.
  • In summary, the Bridge implementation should not be bound to SignalR in a way that would force or bind clients to use a SignalR client implementation. It was agreed that raw websocket protocol is a better idea.
    • The protocol as designed doesn't need multiplexing / channels / namespaces as coms is always DA(s) <-> DAB with the DAB doing aggregation and application of source desktop agent labels (to prevent spoofing)
  • From attendees the only experience in generating docs from schemas is with OpenAPI and Swagger (@robmoffat)

• @kriswest Reported that FDC3 API types are just TS types and there are no schemas generated, whereas Context definitions have schemas.

  • However, class and type definitions generated by quicktype fro the schemas as sometimes sub-optimal (e.g. merging definitions rather than using inheritance)

• Bridging and FDC3 on the Web

  • @novavi - Bridging protocol interaction with FDC3 on the web - protocol designed as part of bridging it would be usable on the web and on desktop?
    • @kriswest yes as the proposal is based on a local websocket, code running in a web browser would be able to use a javascript client to connect to a bridge and through that to container-based Desktop Agents and other web-based agents.
  • @robmoffat - Mentioned the specificity in the protocol and how the bridge should be "dumb" and just relay messages and having 121 relationships between DA.
    • @kriswest - Mentioned the foundational thought of the bridging protocol and why the bridge needs to be able to do routing and manage some state - to provide security (anti-spoofing) and to keep implementation complexity for DA vendors down.

• does bridging serve as a general FDC3 protocol?

  • not really as its designed for DA <-> DA (via bridge) comms and doesn't define a message for every FDC3 API call (as some don't require contact between agents), although the message payloads would be common - and were extracted from the API call parameters and response types, which could be considered generic.

    • @kriswest - Regarding message format - In message exchanges, especially in requests, payload usually is analogous to the DA API function arguments. Bridging just adds the DesktopAgent field (to prevent spoofing).
      • The details relevant to bridging sit outside the payload (meta, type) - inside meta: source, destinations, guides

  • @kriswest/@robmoffat - Discussion about the role of the bridge in collating and augmenting responses (eg. findIntent) - Sample scenario, 2 bridged DAs that have the same app.

  • @novavi - Asked about the use-case where a DA is connected to 2 bridges.

    • @kriswest - A DA should only connect to one bridge, and that the protocol was designed to be single-user hence a single bridge (can be multi-machine - internal concern of the bridge).

Action Items

• Finsemble to connect with NWM and provide with some info about testing
• @Julia-Ritter - Ask the FO maintainers what are they using to automatically generate documentation from JSON Schema or other formats
• @kriswest @tpina Decide whether to continue with AsyncAPI exploration to document exchanges or to take another approach to documentation (hand-maintained exchange documentation? - as used in the proposal).
• @kriswest @tpina Complete JSON Schema definitions for message exchanges and explore the generation of Typescript types and .NET classes/interfaces from them via quicktype.

Untracked attendees

Full name	Affiliation	GitHub username

[tpina]

Tiago Pina / Finsemble

[robmoffat]

Rob / FINOS

[novavi]

Derek Novavi / S&P Global

[Julia-Ritter]

Julia / FINOS

[kriswest]

Kris West / Finsemble

[manish-nwm]

Manish / NWM

[Vivek-NatWest]

Vivek/ NWM

[mistryvinay]

Vinay Mistry / Symphony