FDC3 for Web Browsers Discussion group - 16th Feb 2023

kriswest commented 1 year ago

Group overview

Group convened to discuss how to enable FDC3 use in a web browser, without the use or a browser extension (such as fdc3-desktop-agent or a container).

Issue: https://github.com/finos/FDC3/issues/896 Mailing list discussion: https://groups.google.com/a/finos.org/g/fdc3/c/jCvlLjokBLs

In a recent email on the FDC3 mailing list, @kriswest wrote:

... I also want to add that there is clearly significant interest in the community in enabling FDC3 use on the web. There is a strong use case in that it would enable better onboarding journeys with less drop-off (where you use an app on the web with others before adopting a desktop container or similar).

and:

But there are also additional challenges such as how to make the API available reliably without importing a proprietary module from a particular vendor into every app, how to deal with more than one implementation of API/Desktop Agent in the browser at once, how to do this reliably and securely within the browser sandbox etc.. Work needs to be done in the Standard to solve these issues and to make web browser use possible in a future FDC3 Standard version - which I believe is possible (and likely to involve using a vendor-agnostic FDC3 NPM module to detect and connect to API implementation(s)). However, we're going to need to do that work to enable the aforementioned API implementations to be compliant and if we fail to hold the line now on compliance with the current version of the FDC3 Standard, that may never happen.

Hence, I strongly encourage any vendors or firms working on API implementations that would fall outside current compliance requirements to work with the FDC3 maintainers and community, in general, to help move the Standard forward! The first step will be to raise an issue to bring to the Standards Working Group, which might then move to a Discussion Group to develop a proposal for additions to the Standard and its software. The maintainers meet again next week and will discuss getting such an issue on the books.

Relevant issue tags

Current open issues that relate to the above concepts with the label:

Meeting Date

Thursday 16th Feb 11AM EST / 4PM GMT

WebEx info

Meeting link: https://finos.webex.com/finos/j.php?MTID=mc297e9962d73ad18f6539745ce79abf9
Meeting number: 2552 173 3304

More ways to join

Join by video system:
- Dial 25521733304@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: 255 217 33304

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 (5mins)
[x] Opening statements from interested parties (20 min)
[x] Exploring technical solutions (30 mins)
[x] Planning future meetings & Adjourn (5mins)

Minutes

@kriswest Introduced concept of FDC3 for the web. Laid out main issues around vendor-dependent implementations. Laid out issues with browser extensions. Said Finsemble as a company supported a standards-based way of enabling browser-based connectivity for FDC3.
@robmoffat Talked about dependency injection. Dependencies can't be injected into websites. Many FINOS members (including Wellington, a platinum board member) have asked for ways to avoid vendor lock-in with FDC3. Only way to achieve this is to standardize a library for providing connectivity.
@nkolba Argued that FDC3 for the web has already been implemented. Worried that we are too focused in the FDC3 spec on electron/websites to the detriment of Java/.net. Also argued that global variables are inherently insecure.
@bingenito Very supportive of FDC3-On-The-Web. It's a message bus; banks are always writing message buses. Desktop interop defining this message bus is key. We might not always want a single DesktopAgent instance within an app.
@hampshan Shouldn't enforce a particular Desktop Agent. Can PostMessage Work? You should be able to Bridge out still.
@novavi Has already implemented something along these lines. As an ISV, definitely wants the ability to ship an FDC3 app without a vendor-specific FDC3 implementation. Raised issue of window.fdc3 global - there is some detail around this, since we could have DAs injecting this, but also have a library giving you the DesktopAgent object themselves. His implementation tries multiple strategies.
- Desktop Agent Bridging is definitely needed to make all this work as it specifies a wire protocol and would allow for interop to older tools / other Desktop Agents. We can't guarantee all the apps in the same container.
@thorsent Our goal is to push adoption of FDC3. An ecosystem is vital. This proposal reduces friction. While we owe everything to the electron preload (to inject window.fdc3) we should now think beyond it. @novavi solution cleverly migrates the discovery problem from development time to delivery time.
@pbaize The interface is the standard. We need to separate the standard around the interface (DesktopAgent) from how to get it. I never refer to window.fdc3 directly.
Will Shotton @ RBC We're very interested in this at RBC. We have lots of internal apps on OpenFin and browser, as well as different elements within the same window that need to interop.
@nkolba Are we actually trying to change the standard?
@thorsent We should amend the standard to allow for an open-source, FINOS import. Then, as a developer, I can write an app that runs against any agent.
@nkolba We have this today.
@thorsent We don't: using is a proprietary import. I can't create an app that will run against multiple DA's.
@nkolba But every app has different functions, based on the DA's API that they're importing.
@kriswest We see plenty of vendor apps that just use the standard FDC3 API.
@timjenkel We should preserve the ability for an app developer to write vendor-agnositic code, or, if they want, they can get the API another (vendor-specific) way. Apps should have the option of being vendor agnostic.
@pbaize We need to split these two parts out: compliance to the API and discovery. You could easily have a situation with two react components using FDC3 api to talk to one another. The sooner we separate these out the better we'll be.
@novavi Should anything change? My POC has more strategies than I'd like. Reducing the number of ways to get the API would be better. (Talked about dynamic imports).
@robmoffat Perhaps FDC3-For-The-Web is just an extra "part" to the existing standard.
@nkolba Are we talking about removing window.fdc3? This changes everything.
@kriswest No. We may (just) need to add to the standard. But we need to approve a simple solution for (app) vendors. It's interesting to hear the ideas around scoping. The standard needs to support different types of scopes. It already differentiates 'web', native and hybrid apps. We appear to need to differentiate containers and browsers within web.
@thorsent I'd also be supportive of breaking the standard into "the interface" and "obtaining the interface". One risk is that app vendors may not understand the ramifications. If the distinction were clear, it would be easier for the app vendors.
Future Meetings: Agreed every 2 weeks at the same time slot (voted by >50% of attendees).

Action Items

[x] @Julia-Ritter & @kriswest Arrange future meetings
[x] All contact @kriswest or post on issue #896 if you want a specific agenda topic added to next meeting.
[x] @kriswest Invite contribution from those who could not attend on the issue.