FDC3 for Web Browsers Discussion group - 1st June 2023

[kriswest]

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: #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 01 June 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

• Convene & roll call, review meeting notices (5mins)
• Review action items from previous meeting (15mins)
  • FDC3 for Web Browsers Discussion group - 18th May 2023 #991
  • Recap requirements and design goals agreed so far. Google doc link
• Continue requirements and design goal discussion (15mins)
• Explore how a solution might be used in an app via code examples (20-25mins)
• Discuss implementation options (if time)
• AOB & Adjourn

Minutes

• @kriswest noted an apology for absence from @lspiro-Tick42, who's firm is keen to engage with the topic, but unable to attend on this occasion
• The meeting was opened by re-reviewing progress so far on requirements and design goals.
• A number of refinements were made to the requirements:
  • It was noted that:
    • the order of the use cases does not reflect their priority - but rather the order that they would likely need to be addressed by an installer implementation
    • the 'child web app' use case might apply within a container, where an iframe has been embedded within another application, which several desktop agent implementors working with containers raised as an issue they had encountered.
    • the limitations app developer will be allowed to place on the selection of a desktop agent include 'security / type of implementation' which was clarified as relating to whether 3rd party code is injected, limitations on where injected code might be retrieved from or whether a postMessage proxy is used.
  • A number of minor wording corrections were applied.
  • The requirement that a Desktop Agent should be able to decide whether to accept an app for interop was clarified, and that this should be based on the retrieval of configuration data (such as an app directory record) necessary to make a decision
    • It was noted that the app URL should always be available (to the installer) which might form part of a lookup...
• The design goals were discussed and refined:
  • It was noted that:
    • The goal of not having to update the installer library for different FDC3 versions might conflict with the ability for apps to use Typescript types appropriately - and hence any solution might have to latch to a requested major version and minimum minor version (there should be no breaking changes in minor versions of FDC3 and subsequent releases should only contain additive changes.)
    • A couple of participants are keen to see the goal of not having FDC3/FINOS /the library maintain a list of all Desktop Agents upgraded to a requirement - due to practical concerns
      • It was agreed to note this request but leave it where it is for now until we can establish that doing so doesn't simply move the requirement to app developers as this might impact the ability to interoperate 'without prior bilateral agreements'
    • The installer being quiet on failure does not mean there should be no output, but rather just no repeated output on each attempt.
  • The goal of allowing two independently started web apps to establish that they both support a common DA and may select that, was moved to 'ideas for the future' to ensure that the initial implementation is kept simple (Minimum Viable Product) and doesn't require, for example, hidden iframes on a common domain to act as a proxy.
    • Hence, initial implementations should allow an independently started app to express a preference for an agent to retrieve and load, or no agent (by default)
• Discussion of usage examples in fdc3-enabled apps was started.
  • It was agreed that:
    • The installer function should be async
    • Status of retrieval will be provided via the promise returned (pending/resolved/rejected) and hence it may be awaited or a then clause applied to it.
    • The installer should only return an fdc3 instance when it is ready to use (i.e. no separate step waiting for the ready event, although that may be used internally by the installer)
  • The current example implies that there is only one desktop agent that you connect (as a promise only resolves once)
    • The primary use case for repeat use discussed was re-retrieval on failure/disconnect/restart of a DA)
    • It was suggested that client code could/should handle such cases internally without needed to resort to the installer again.
  • There was consensus that the next meeting should continue to look at/refine usage examples, including how options are passed or retrieved, how types are applied, how information on the application is passed to the DA and how use case 4 is dealt with (via FDC3 API additions).

Google docs with current draft: https://docs.google.com/document/d/14UzHDuR8TkDyyx00WKWj9Sdx2TzpoWlH61eaIZqgtko/edit#

Action Items

• (ALL) Consider usage examples and how/what options should be passed to the installer for discussion at the next meeting.

Untracked attendees

Full name	Affiliation	GitHub username

[pbaize]

Pierre Baize / OpenFin

[tpina]

Tiago Pina / Finsemble

[robmoffat]

Rob / FINOS 👾

[kriswest]

Kris West / Finsemble 🚀

[timjenkel]

Tim / Wellington

[WatsonCIQ]

Chris Watson / Finsemble 👋

[dcj99]

David Jones / ipushpull

[openfin-johans]

Johan / OpenFin 🎁

[novavi]

Derek Novavi / S&P Global

[Julia-Ritter]

Untracked Attendees:

• Hugh Troeger
• Julia / FINOS
• Naveen Y