Desktop Agent Bridging Discussion group 24th May 2023

kriswest commented 1 year ago

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

PR: https://github.com/finos/FDC3/pull/968 PR preview Specification link

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:
544

Meeting Date

Wednesday 24 May 2023 - 9am EST / 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.

Agenda

[x] Convene & roll call, review meeting notices (5 mins)
[x] Review action items from previous meeting (5 mins)
- 969
[x] Overview of the Use cases for Desktop Agent Bridging + discussion (15 mins)
[x] Protocol overview and Q&A (20 mins)
- Preview link
[ ] Updates from the Backplane project / asyncAPI exploration (10 mins)
[x] AOB & Adjourn (5mins)

Minutes

@kriswest opened the meeting and summarized objections to merging the Desktop Agent Bridging PR into FDC3 2.1 as primarily about questioning whether it should be part of FDC3 or an adjacent standard (although at least one maintainer does not believe a single method of bridging should be standardized).
@mattjamieson provided an overview of the use cases for Desktop Agent Bridging (which can now be found in the introduction to the DAB spec in the PR)
@sarahstone-cosaic stated that support for these use cases in FDC3 has become the single most common request from Finsemble clients, particularly for any that redistribute the Desktop Agent implementation/container with their apps to other firms, but also from those looking to adopt similar platforms alongside their own.
@kriswest added that bridging had been referenced in conversations about FDC3 for Web browsers, and that support for FDC3 in Webbrowsers was likely to increase the number of Desktop Agents running on a user's desktop and hence the need for a way for the Desktop Agents to interoperate.
@lspiro-Tick42 Stated that Tick42/Glue42 has offered a bridging feature (between versions of their product owned by different organisations) for around 10 years and that it is very important to clients. They support the addition of a Standard for Bridging to FDC3 as it would extend support to multiple vendors, and might encourage major terminal vendors to also participate in FDC3 (where they currently offer proprietary mechanisms).
@rfinter13 Stated that Factset is buy-side heavy, while FDC3 adoption is quite bank heavy at the moment. They are interested in streamlining workflows for both types of user, but without some form of bridging protocol for FDC3 its difficult for them to interoperate with everybody - particularly as they adopt (and prefer to) a single desktop agent.
@Aaron-Haines Stated: Bridging is not a theoretical problem for NatWest Markets, rather its a real and current production issue. They currently have multiple containers/DAs, Symphony and a number of monoliths on each desktop. Point-to-point integrations only go so far - an agreed standard for Bridging desktop agents would provide a much more satisfactory solution.
@Vivek-NatWest added that NatWest Markets would prefer that everything work in a plug-and-play fashion, whatever technology or vendor codebase they are based on. Interop should be possible without any bilateral agreements - and to achieve that standardization is essential. It is a need.
@openfin-johans raised the issue of identity, data leakage and licensing which worries some vendors and worries might be amplified where bridging is enabled.
- @kriswest and @mattjamieson both commented that this is a significant problem that exists in FDC3 regardless of whether bridging is supported or not and needs solving. Any such solution will need to be added to the main FDC3 API and will then be carried over to any bridging solution as a requirement.
- @robmoffat flagged that this is the topic for the FDC3 roundtable at the FINOS members meeting in London on the 15th June
- Open House Panel on FDC3 generally: 14th June 15:20 - 15:50
- FDC3 Identity Roundtable: 15th June 13:50 - 14:45
- Desktop Agent Bridging talk: 15th June 16:15 - 17:15
@rikoe addressed why people (a subset of FDC3 maintainers) are against this being in the standard,
- This has been the most popular feature request in FDC3 almost from the beginning.
- However, I believe that the complexity of FDC3 should be kept to the minimum, i.e. it should be as lightweight and have as low a barrier to entry as possible.
- The proposal has worked hard to make it transparent to app developers - however, those aren't the only stakeholders in FDC3, we also have to consider interop solution providers,
- @kriswest as an optional Part of FDC3, it doesn't not create complexity or a barrier to entry if you don't want or need to implement it. However, if you do and need your solution to work with others, the existence of a standard is greatly simplifying and eliminates specific custom work you'd have to do with different partners.
- @kriswest Also, by doing it in the standard we can remove any impact on app developers - the very minor addition of a field to attribute an AppIdentifier to a Desktop Agent enables usage with no code changes in most cases. The two added error messagess are generally just going to be logged or reported, while AppIdentifiers are intended to be retrieved from various API calls and used in full - there are few if any use cases that require you to construct one yourself. We lose the ability to do that outside the standard and app developers start having to integrate things or write additional code to handle bridging, which is a big downside.
- What happens after it stops being experimental, does it become required?
- Not a fan of experimental, I think it makes sense in a library, less so in a standard.
- We are expanding what it means to be a provider of the FDC3 standard/understanding what it does - the more it does harder to wrap your head around.
- Given how important this use case is - should it be experimental in the beginning? or have a confirmed compliance status? Should it be its own entity alongside FDC3/used with it? Does it make it more flexible?
- Yes the maintenance burden increases, along with governance processes etc..
- What happens with conformance, do you have to support this to use FDC3?
- @lspiro-Tick42 @robmoffat @kriswest all responded to this by referring to the fact that FDC3 already has multiple parts and states that you only need to comply with the parts that you use. Conformance testing currently only tests required parts of the standard and only for the API Part.
@kriswest We are very often asked to demonstrate something in use before adding it to FDC3.
- However, and as discussed when we added @experimental to FDC3's governance, that can be hard to do when up to 4 stakeholders are involved in every interop exchange (two app vendors, a desktop agent vendor and a user/adopter). Hence, we created that designation to allow a design to be agreed before multiple firms invest a lot of time in implementing it - its very hard to get something like this done without 'putting a stake in the ground'.
- Is the @experimental label part of whats generating resistance? Would explicitly setting an optional compliance requirement and dropping @experimental make the addition easier to accept?
- @rikoe I prefer a contrib area to experimental, but experimental is wahts there.
@Vivek-NatWest We should ensure there is a requirement for UI feedback to the user on connection to the bridge (of this agent / other agents) to ensure they know what might have access to their context data.