Desktop Agent Bridging Discussion group - Wed 6th April 2022

[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

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

Wednesday 6th April 2022 - 9am EDT / 2pm BST

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. As such, participation in a Discussion group is not required for contributing to any particular issue or FDC 2.0 as a whole.

Agenda

• Convene & roll call, review meeting notices (5mins)
• Review action items from previous meeting (5mins)
• Introduction to topology options for Desktop Agent Bridging (5mins):
  • Client & Server networks
  • Peer-to-peer
  • Standalone Bridge and Client
• Discuss the effect of topologies on protocols we need to design for Desktop Agent Bridging (35mins):
  • Locating other agents to connect to
  • Connecting securely to other agents
  • Interacting with other agents across the connection
  • Presentation deck: FDC3 Desktop Agent Bridging - The Effect of Different Topologies.pdf
• Plan next steps and action items (5mins)
• AOB & Adjourn (5mins)

Minutes

• @kriswest presented an intro to topology options for Desktop Agent Bridging and how they affect the various parts necessary for a proposal

  • PDF of deck presented: FDC3 Desktop Agent Bridging - The Effect of Different Topologies.pdf
  • Comments and clarifications on the topology options that were discussed:
    • peer2peer - this is only under the same firewall not cross-company?
      • @kriswest only on the same machine or within the same network.
    • (NWM team) In multi-machine use-cases, in the Client & Server topology if server goes down bridging stops for all agents, but with a standalone bridge (which would be running on multiple machines) if it goes down on one machine, its still up on the other and continuing to bridge agents on that machine.
    • (NWM team) With a standalone bridge, the bridge as a single point of failure can be mitigated if it is running like a process or service, which can be automatically restarted by the OS. Retry patterns can be implemented for DAs to reconnect.
    • @robmoffat Do you need a specific bridging API at all? If you had an app (proxy app) that runs on each DA and the App listens on one agent and transmits on another, could that work?
      • @kriswest explained the drawbacks of proxy app approach, as previously discussed: intents have to be configured in advance, restricts resolution options, you can't discover app channels to listen to so you need to know them in advance etc.. However, with bridging you could build a better procy app and solve some of those issues in one direction, or use a full bridging solution and fully interoperable Desktop Agents.
    • @robmoffat & (Citi team): all of these options have different trade-offs - people might want to do their own implementation - particularly for the standalone bridge format. Who would own the bridge implementation
      • @kriswest If we define an appropriate specification for a standalone bridge banks, vendors, or the community, can implement a bridge. As long as it is conceptually separated from the DA and it is conformant with the spec, ownership should not be a contentious point. If a vendor product included a bridge implementation in their product, on startup it could check if one was already present and connect to it, or start its own.
    • (NWM team) peer2peer every desktop agent must expose an endpoint for communication? Meaning that everyone has to do some work in order to connect to other DA.
      • @kriswest Talked about WS port clashes, and added complexities that do not exist when working with a single connection to a bridge.
    • (NWM team) Standalone bridge seems to be a more viable option. Asked about how the messages would be propagated across the bridge.
      • @kriswest Referenced the generic message formats that the Cosaic team have added to the proposal PR so far, and how they might be propagated. Additional work on these is required, but can't be completed until we settle the question of topology.
    • @robmoffat - Regarding single point of failure - who’s responsible for starting the bridge? What happens when the bridge goes down?
      • @kriswest The bridge isn't likely to be restarted (as a desktop agent might be), is likely to be a much simpler piece of software and it could be started as a system service (which can be configured to auto-restart). DA's could poll for it on a predefined standard port or a configured port. If it went down and was restarted DAs can poll for it and reconnect when its back. A similar set of procedures are necessary with the P2P topology, although there are a lot more connections to poll for or discover by other means.

• @kriswest Stated that to continue development of the bridging proposal, a decision on which topology to use was needed.

  • An informal poll of participants was taken: 7 participants were for selecting a standalone bridge, None were against and None wished to select the Peer2Peer format.
  • Further opinions and discussion of the options can happen on discussion: Desktop Agent Bridging Discussion group #544
  • The Cosaic team will continue development of the proposal on the assumption that we are proceeding with a standalone bridge topology.

Action Items

• @kriswest @tpina @WatsonCIQ @mhmcclung @thorsent Continue development of the bridging proposal on the assumption that we are proceeding with a standalone bridge topology.
• @kriswest prepare next meeting agenda based on review of updates to the bridging proposal
• Rolled over from the previous meeting:
  • @kriswest to raise issue proposing standardization of channel metadata
    • Recommended, but not required

Untracked attendees

Full name	Affiliation	GitHub username

[Julia-Ritter]

Julia / FINOS

[robmoffat]

Rob / FINOS

[mistryvinay]

Vinay / Symphony

[tpina]

Tiago / Cosaic

[kriswest]

Kris / Cosaic 🚀

[timjenkel]

Tim / Wellington

[sarahaislinnstone]

Sarah Stone / Cosaic

[donbasuno]

Johan / OpenFin - leaving at half-time

[ggeorgievx]

Georgi / Tick42

[dgeorgiev06]

Dimiter / Symphony

[Vivek-NatWest]

Vivek/Natwest

[jgavronsky]

Jane @ FINOS here

[MichaelMCoates]

Michael / OpenFin

[nkolba]

Nick / Kolbito

[Qiana-Citi]

Qiana / Citi

[hughtroeger]

Hugh / FactSet

[Qiana-Citi]

Thank you. From: [github.com] Kris West ***@***.***> Sent: Thursday, May 5, 2022 12:44 AM To: finos/FDC3 Cc: Chen, Qia Qiana [ICG-IT]; Comment Subject: Re: [finos/FDC3] Desktop Agent Bridging Discussion group - Wed 6th April 2022 (Issue #659) This Message is From an External Sender This message came from outside of your organization. Closed #659<https://urldefense.com/v3/__https:/github.com/finos/FDC3/issues/659__;!!Jkho33Y!3o8qA56p5kljWJOmArGgsSnyagj1XCwXFv1ihVXfM18OGM0LggtfB13wgjG26LeP6XE$>. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/finos/FDC3/issues/659*event-6550184596__;Iw!!Jkho33Y!3o8qA56p5kljWJOmArGgsSnyagj1XCwXFv1ihVXfM18OGM0LggtfB13wgjG2s2vpT7Q$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AVCUVSOHYMK2ZZ74AVLIWLTVIKSNNANCNFSM5STKQIYQ__;!!Jkho33Y!3o8qA56p5kljWJOmArGgsSnyagj1XCwXFv1ihVXfM18OGM0LggtfB13wgjG24jzOQ8Y$>. You are receiving this because you commented.Message ID: ***@***.***>

[Qiana-Citi]

Chen, Qia Qiana [ICG-IT] would like to recall the message, "[finos/FDC3] Desktop Agent Bridging Discussion group - Wed 6th April 2022 (Issue #659)".