FDC3 for Web Browsers Discussion group - 4th May 2023

kriswest commented 1 year ago

Group convened to discuss how to enable FDC3 use in a web browser, without the use of 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.

Relevant issue tags

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

Meeting Date

Thursday 04 May 2023 - 11am EST / 4pm BST

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] Review action items from previous meeting (5mins)
- 958
[x] Discuss and agree a set of requirements and design goals for a solution/installer library
[ ] Explore code samples for the use of an installer lib
[ ] Return to discussing solutions for particular use cases (steps 2-4 in proposal)
[x] AOB & Adjourn (5mins)

Minutes

The meeting re-reviewed use-cases as an introduction and resolved to adjust the names of the use-cases slightly:
1. Container or Browser Extension
  - unmodified
2. Web container -> Child Web Application
  - To better represent the parent/child relationship between windows (which is the key component of this use case).
    - Windows opened in response to FDC3 API calls (open/raiseIntent) or a 'launcher' integrated into a web-based FDC3 Desktop Agent
    - To include both new windows realised via window.open and iframes - similar techniques would be used in both cases, via window references provided as window.opener or window.parent
  - Also, Web container has a different meaning (relating to WASM).
3. Independent web app -> Independently opened web app
  - Better represents the difference to the above case
4. Micro-frontend Container
  - unchanged
  - multiple separate apps running in the same DOM, but wishing to interop (both within the window and with outside) via FDC3
A productive discussion on requirements and design goals for a solution was held and the following agreed by the meeting participants:
- FDC3 Installer /Bootstrapper / Discover library A library that enables an app to retrieve a FDC3 Desktop Agent Implementation (and will generally be independent of it) - allowing an app developer to avoid tying their implementation to a specific implementation of FDC3.
- Requirements: (Note 'this solution' / 'any solution' refers to the overall proposal not just an installer library of API changes etc. as different things maybe needed to solve for each case)
  1. Don't break FDC3 for existing applications (use case 1 apps).
  2. Any solution should aim to support all 4 proposed use cases
  3. It should be possible to write applications that can run under any of the 4 uses without code modifications (preserve WORA).
  4. An app developer should be able to control / limit what implementations of an FDC3 Desktop Agent it will load.
    - Note: Implies a requirement for being able to authenticate a Desktop Agent…
  5. A solution to 'install' or 'retrieve' an FDC3 implementation should work across different versions of FDC3 / be independent of the FDC3 Desktop Agent version - particularly on the same major version. I.e. An app should not have to update its installer library version to retrieve / work with a different FDC3 Desktop Agent version.
  6. Apps using an installer that are started by a particular Desktop Agent should prefer retrieving that implementation (unless prevented by configuration as per requirement 4).
- Design Goals:
  - There SHOULD be feedback to the end user and the app developer if the loading of an FDC3 implementation is blocked (e.g. by configuration) - particularly for container and web container.
  - Any solution should be lightweight (don't increase bundle size unnecessarily and doesn't create make it harder to adopt FDC3)
  - Any solution should avoid FDC3/FINOS/the library etc. having to maintain a list of all implementations? However specific applications might supply such info as part of a configuration.
  - Should enable, rather than limit innovation in the design and build of Desktop Agents as much as possible.
There was consensus that there are both further requirements and design goals that need to be unpacked. Hence, the next meeting should pick up where this one left off.
- @pbaize Design goal: Prefer code over configuration?
- @kriswest authentication?
- @hampshan (from a previous meeting) requesting a particular FDC3 version.
- What are some examples of how this might be used within an application.