FDC3 For Web browsers

[robmoffat]

Enhancement Request

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.

This is therefore a placeholder issue where we can begin to discuss how to solve this problem and potentially open up FDC3 to a wider audience.

[robmoffat]

This is a problem with some prior art:

• @ggeorgievx @ksgeorgieva @flashd2n from Tick42 have already implemented "Glue 42 Core" which provides a vendor-implementation of "FDC3 over the web"
• @nkolba has been working on Connectifi, which is adjacent to this.
• @nkolba has also been working on FDC3-Sail, which contains some of the parts to solve this problem (I think)
• I have been thinking about for several months as part of project planning for FINOS for 2023 - I will share my thoughts in the comment below.

As @kriswest says in the quote above, he thinks there is interest within the community. I have personally talked to a number of App vendors who are confused as to why this isn't a thing already.

I am hoping we can have a discussion on this at the next maintainers' meeting and move this forwards

[robmoffat]

Here is my thinking so far on the subject (more to seed a debate rather than anything else).

1. Glue Core uses PostMessage to allow FDC3 to communicate within-browser but across tabs. This is a promising line of inquiry and I'm hoping we can learn more from that team about how this works. There are security concerns here that I would like us to think through.

2. In discussing this with @kriswest yesterday, we agreed that it would be nice to rally around a well-written Use Case. Perhaps this is where we should start?

3. A further point we discussed is the need for what I am calling an FDC3 "wire protocol":

• FDC3 Sail implements a bus for FDC3 messages between apps, with the agent acting as router (and converting between FDC3 versions as needed).
• Desktop Bridging is also essentially the same thing - providing a sockets-based messaging protocol between different desktop agents.
• At some level, Connectifi must be implementing a bus also.

[novavi]

Hi @robmoffat thanks for raising this issue.

Related this this, on the point @kriswest raised (which you cited) about the possibility of using a 'vendor-agnostic FDC3 NPM module to detect and connect to API implementation(s)', I have something to share.

I have implemented this fdc3-installer library:

https://github.com/novavi/fdc3-installer

over the last few weeks. It aims to provide a solution to the problem in browser-based environments of tight coupling between FDC3-enabled apps and FDC3 Desktop Agents, by providing a mechanism to dynamically discover and install an agent within an app at runtime. This approach allows an app to run both in a desktop container (using the container's built-in agent) and also in a browser-based micro-frontend container (using a dynamically-installed agent) with zero code changes to the app. The library supports multiple strategies for the areas of agent discovery, creation and bootstrapping - with the ability to easily add and try out additional strategies based on any subsequent discussion / ideas.

The library does not claim to have all the answers by any means, but demonstrates some of the options that could potentially be used for a solution in this area. I hope this will help in the wider discussion that needs to be had within the FDC3 community about how we can best overcome the tight-coupling problem for browser-based FDC3 Desktop Agent implementations - and help move us towards standardized approach in the future.

I was originally aiming to publish this library more like sometime next month rather than now but after seeing that you'd raised the issue, I brought this forward in the interest of the discussion and just published what I have now. Because of this, I haven't actually even proof-read the stream-of-consciousness that I turned into a README yet, so parts of the description might still be a bit rough round the edges.

[kriswest]

@novavi many thanks for sharing your work on this issue. While I suspect/hope we'll end up adopting a subset of what you propose, it nevertheless represents a tour-de-force in exploring the options and related issues. I look forward to reviewing (and hunting for the strategies I intend(ed) to propose within your implemented set). K

…

On Mon, 23 Jan 2023, 10:08 Derek Novavi, ***@***.***> wrote: Hi @robmoffat <https://github.com/robmoffat> thanks for raising this issue. Related this this, on the point @kriswest <https://github.com/kriswest> raised (which you cited) about the possibility of using a 'vendor-agnostic FDC3 NPM module to detect and connect to API implementation(s)', I have something to share. I have implemented this fdc3-installer library: https://github.com/novavi/fdc3-installer over the last few weeks. It aims to provide a solution to the problem in browser-based environments of tight coupling between FDC3-enabled apps and FDC3 Desktop Agents, by providing a mechanism to dynamically discover and install an agent within an app at runtime. This approach allows an app to run both in a desktop container (using the container's built-in agent) and also in a browser-based micro-frontend container (using a dynamically-installed agent) with zero code changes to the app. The library supports multiple strategies for the areas of agent discovery, creation and bootstrapping - with the ability to easily add and try out additional strategies based on any subsequent discussion / ideas. The library does not claim to have all the answers by any means, but demonstrates some of the options that could potentially be used for a solution in this area. I hope this will help in the wider discussion that needs to be had within the FDC3 community about how we can best overcome the tight-coupling problem for browser-based FDC3 Desktop Agent implementations - and help move us towards standardized approach in the future. I was originally aiming to publish this library more like sometime next month rather than now but after seeing that you'd raised the issue, I brought this forward in the interest of the discussion and just published what I have now. Because of this, I haven't actually even proof-read the stream-of-consciousness that I turned into a README yet, so parts of the description might still be a bit rough round the edges. — Reply to this email directly, view it on GitHub <#896 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM7PBGQKMDQ7S3S72MXK53WTZKALANCNFSM6AAAAAAUAFXPPQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[novavi]

@kriswest no probs. Yes tbh I'd be very much in favour of narrowing down to a subset of the options if this type of approach was to be standardized. The strategies you intend(ed) to propose might not even be amongst the ones I came up with actually! I'm sort of hoping that there might be more options on the table to choose from when standardizing this. The main constraint I applied when listing out and implementing those discovery strategies was that the container-based ones *must* work on a cross-origin basis. I think it's sensible to make any standardized solution work for the more restrictive cross-origin scenario, and then it will automatically work for the (simpler) same-origin scenario. From my experience of large organisations who hope to provide a more unified customer experience for their existing brownfield apps, those apps are typically built by separate teams on separate tech stacks in separate repos with separate release schedules and deployed on separate subdomains. That is to say, if an organisation has apps that are commonly on the same subdomain as their container (and as each other) then they are quite probably heavily down the road towards a module federation approach, and may have less requirement for FDC3 interop in their apps in any case (except perhaps for third-party app integration). There's more freedom on the app-based discovery strategies of course, because you don't have to worry about the cross-origin issue e.g. even reading from a previously-defined global variable would be possible. I did avoid a few other things like reading from meta tags e.g. that requires SSR of the host page in order to prevent it just being a pointless exercise in moving hard-coding from one place to another. That said, the general risk with app-based discovery strategies (as opposed to container-based ones) is that it could be quite easy to misuse them if one did not fully understand their purpose (e.g. again using an installer, but simply moving hard-coding from the app's code into the app's config). In terms of the range of strategies supported, the whole concept certainly becomes less usable by casual FDC3 app devs and less supportable as a library if it aims too wide (indeed, supporting corner cases sometimes encourages requests to support further corner cases). Laying out the options in this library was partly intended as a mechanism to help test them and discuss them - because without a concrete implementation it can sometimes be hard to see the relative merits and pitfalls of different approaches. Having said that, it's worth pointing out that we should really distinguish between a *generic* installer library that can load pretty much any arbitrary browser-based FDC3 Desktop Agent *today* (which is sort of what I just about implemented) and a future standardized installer that only needs to load a future FDC3 Desktop Agent adhering to a future spec version (2.1 or above?) which is clear about how agents are to be provided. For example, if a future version of the FDC3 spec mandated that an agent *must* be provided by a factory function and exported via an ES Module with a specific name, then one should be able to easily dispense with the different creation strategies - although one would still need to offer support to pass args to that function in a config of some sort (whether to provide a WebSockets url for a cloud-based approach, or simply just more mundane options applying to all browser-based implementations e.g. whether fdc3.open() should open apps in tabs / windows / iframes). The issue of bootstrapping is more involved than that of creation because as I alluded to in the README for this repo there is (currently at least) a relationship between agent bootstrapping and window.fdc3 installation in terms of the overall agent lifecycle... which is a subject for another email thread I think! - Derek

…

On Mon, Jan 23, 2023 at 12:42 PM Kris West ***@***.***> wrote: @novavi many thanks for sharing your work on this issue. While I suspect/hope we'll end up adopting a subset of what you propose, it nevertheless represents a tour-de-force in exploring the options and related issues. I look forward to reviewing (and hunting for the strategies I intend(ed) to propose within your implemented set). K On Mon, 23 Jan 2023, 10:08 Derek Novavi, ***@***.***> wrote: > Hi @robmoffat <https://github.com/robmoffat> thanks for raising this > issue. > > Related this this, on the point @kriswest <https://github.com/kriswest> > raised (which you cited) about the possibility of using a 'vendor-agnostic > FDC3 NPM module to detect and connect to API implementation(s)', I have > something to share. > > I have implemented this fdc3-installer library: > > https://github.com/novavi/fdc3-installer > > over the last few weeks. It aims to provide a solution to the problem in > browser-based environments of tight coupling between FDC3-enabled apps and > FDC3 Desktop Agents, by providing a mechanism to dynamically discover and > install an agent within an app at runtime. This approach allows an app to > run both in a desktop container (using the container's built-in agent) and > also in a browser-based micro-frontend container (using a > dynamically-installed agent) with zero code changes to the app. The library > supports multiple strategies for the areas of agent discovery, creation and > bootstrapping - with the ability to easily add and try out additional > strategies based on any subsequent discussion / ideas. > > The library does not claim to have all the answers by any means, but > demonstrates some of the options that could potentially be used for a > solution in this area. I hope this will help in the wider discussion that > needs to be had within the FDC3 community about how we can best overcome > the tight-coupling problem for browser-based FDC3 Desktop Agent > implementations - and help move us towards standardized approach in the > future. > > I was originally aiming to publish this library more like sometime next > month rather than now but after seeing that you'd raised the issue, I > brought this forward in the interest of the discussion and just published > what I have now. Because of this, I haven't actually even proof-read the > stream-of-consciousness that I turned into a README yet, so parts of the > description might still be a bit rough round the edges. > > — > Reply to this email directly, view it on GitHub > <#896 (comment)>, or > unsubscribe > < https://github.com/notifications/unsubscribe-auth/AAM7PBGQKMDQ7S3S72MXK53WTZKALANCNFSM6AAAAAAUAFXPPQ > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#896 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2PIF2NEGCEAVBWP7JUIXDWTZ4B3ANCNFSM6AAAAAAUAFXPPQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nkolba]

@novavi - this is great work! Thanks for sharing.

Just want to note that this is a code project and exactly the kind of work that is vital to the ecosystem. It also underscores that there isn't anything missing from the standard to solve this problem. In fact, as @robmoffat alludes to, Connectifi already provides secure and seamless support across all environments including web and cross-origin in full conformance with the 1.2 spec.

Keeping the standard simple, accessible, and focused only on those problems that truly address interoperability is the best way to continue to drive adoption as well as the innovation of FDC3.

[kriswest]

It also underscores that there isn't anything missing from the standard to solve this problem.

That is not the case @nkolba - it demonstrates that the problem, of establishing standardized ways of retrieving a reference to an API implementation, is solvable. It absolutely doesn't eliminate the need to adopt a standard for how to do so that app developers can write a single way of doing so/single version of their apps. Further, @novavi's write-up on it clearly indicates several areas that would specifically benefit from standardization, or already do, in order to reduce complexity for the app developer. These include the installation of the API reference into window.fdc3, all 3 of the discovery, creation and bootstrapping strategies and the use of internal & external provider directories.

If we don't provide a clear standardized approach we are not keeping the Standard simple or accessible - quite the opposite as application vendors will still have to choose approaches, configure for individual providers, test widely etc. and hence we again encourage the ecosystem to become fragmented and factional. Whereas, with a little work we can likely reduce complexity for app developers significantly, aiming for as close to zero configuration and variation in code as possible. That is quite obviously addressing problems that affect interoperability and ease of adoption, where attempting to block the community from doing so is not.

[nkolba]

As discussed in the standards meeting last week, it may helpful to split this (and the previous email thread) into three separate topics:

• Whether 1.2 Conformance tests should require FDC3 to be exposed as a global or if this should be optional (as the 1.2 spec states)
• Whether the global requirement should be continued going forward in 2.x
• What additional standards (if any) are needed for Web.

Note: while points 2 & 3 are somewhat related, the global issue doesn't just impact web. It is a blocker for conformance support on other tech stacks such as Java, .NET, Python, and many others and forces FDC3 conformance into a very specific type of implementation.

[kriswest]

As discussed in the standards meeting last week, it may helpful to split this (and the previous email thread) into three separate topics: - Whether 1.2 Conformance tests should require FDC3 to be exposed as a global or if this should be optional (as the 1.2 spec states <https://fdc3.finos.org/docs/1.2/api/spec#api-access>)

As discussed at the meeting (and minuted), I agree that the 1.2 spec allows for the FDC3 API reference to be provided by other means (MAY), but does recommend (SHOULD) that it is provided as a global. The SWG voted to change this in 2.0 such that the global is required (MUST) as it was widely agreed that a standard way to retrieve the FDC3 API reference was essential to the Standard as a whole and its uptake with the industry. Further, it is somewhat awkward that, in order to run the tests on a 1.2 implementation without the API being provided via window.fdc3, the test framework has to be modified with proprietary dependencies and bootstrapping code for each implementation that needs testing - providing an example of the type of challenge that this creates.

- Whether the global requirement should be continued going forward in 2.x - What additional standards (if any) are needed for Web.

I think it an odd suggestion that these two items should be dealt with separately as both relate to the code an app developer must write in order to get at a copy of the FDC3 API. If we don't provide an answer that spans both the web and containers, then this fractures the ecosystem and is likely to result in app developers having to provide different implementations, deployments and appD records not just for browser/container deployments, but also for working with different FDC3 implementations. Whereas, if we work to move the standard forward we can provide a standardized approach that works for all cases. The value in doing so for app vendors, desktop agent vendors and FDC3 adopters is obvious - so I'll refrain from restating it here again. I have, however, yet to hear a decent argument for why not moving the Standard forward on this issue would benefit the community in any way.

Note: while points 2 & 3 are somewhat related, the global issue doesn't just impact web. It is a blocker for conformance support on other tech stacks such as Java, .NET, Python, and many others and forces FDC3 conformance into a very specific type of implementation.

This is not the case as those global requirement has always been scoped to web applications: API access in 2.0 <https://fdc3.finos.org/docs/api/spec#api-access>:

The FDC3 API can be made available to an application through a number of different methods. *In the case of web applications*, a Desktop Agent MUST provide the FDC3 API via a global accessible as window.fdc3.

API Access in 1.2 <https://fdc3.finos.org/docs/1.2/api/spec#api-access>

The FDC3 API can be made available to an application through a number of different methods. *In the case of web applications*, a Desktop Agent SHOULD provide the FDC3 API via a global accessible as *window.fdc3*.

This is expanded on in the supported platforms section in both versions, e.g. in 1.2 <https://fdc3.finos.org/docs/1.2/supported-platforms#native>:

The FDC3 standard does not define wire formats for communication. Hence, for native applications to be FDC3-enabled, they need to make use of a library (e.g. a DLL in .Net or JAR file in Java) that provides them with an implementation of the FDC3 API. FDC3-enabled native applications are therefore specific to particular desktop container frameworks (or other suitable environments) that provide the necessary libraries. Despite this limitation, implementing support for FDC3 in a native application can allow it to interact with a wide variety of FDC3-enabled web applications.

I.e. the Standard's documentation acknowledges that the lack of a standardized approach to getting an API reference in other languages is a significant limitation, linking the value that can still be provided without one to interop with web (in this case container apps built with web technologies) where there is an answer. We also lack interface definitions in other languages - although I'm aware of at least a couple of community members working on that problem. Again, it's rather obvious that the lack of standardisation is what's limiting native implementations and making it difficult to test them for conformance. The assertion that it is the requirements placed on web (which enable its conformance testing) that limit native, is daft. K P.S. I'm back in the office tomorrow and will work on arranging the proposed meeting to further the discussion.

[novavi]

Just on the issue of the provision of the window.fdc3 global going forward, for the benefit of anyone reading this who didn't already see the separate (longer) 'FDC3 Desktop Agents vs. API implementations and using FDC3 on the Web' thread, I would like to reiterate here a few key points that I made as part of that discussion:

• Regardless of one's views on making APIs available in the global scope in the general sense, providing the FDC3 API on the window.fdc3 object has the clear benefit of making all DAs consistent in terms of how they provide the API. Additionally, it's not too difficult to draw a distinction between an API that an application always imports for itself (e.g. like a grid or a utility library where it is always better to use the more modern module mechanism than to use a global) and an API which may well in a number of circumstances be pre-installed on behalf of the app by the container environment (e.g. in the case where an FDC3-enabled app optionally runs in a desktop container which provides a DA).
• The fdc3Ready() function implementation in @finos/fdc3 uses the availability or non-availability of window.fdc3 when deciding whether to resolve or reject (https://github.com/finos/FDC3/blob/master/src/api/Methods.ts), so I believe changing the requirement around window.fdc3 would also imply a change to the behaviour of fdc3Ready().
• window.fdc3 has a dual use. The first use is simply as a mechanism for an app to obtain a reference to the DA's FDC3 API. The second use, although less obvious, is actually very important – this is the use of the global as a mechanism for a standardized installer library (or even just app-level conditional logic) to determine whether a DA is already provided/pre-installed. If the FDC3 standard did move away from requiring DAs to be installed in window.fdc3 then there would probably need to be an agreed, standardized, new mechanism for desktop containers to provide a reference to their built-in DAs (and of course if that mechanism ended up just using a different global to provide a factory function or factory class, then the proposed change wouldn't be eliminating globals in the general sense - it would simply be removing one specific global).
• Requiring a new way to discover whether a DA is already installed in an environment (in a newer version of the FDC3 standard) is further complicated by the fact that ISV apps would then need to worry about handling both the old (window.fdc3) and the new (as yet unspecified) mechanisms to test for a DA. This is because an app might need to run in existing versions of desktop containers (which support window.fdc3) and newer versions of those same desktop containers (which might support a different mechanism) and also have the ability to run in a browser by installing a browser-based DA.

Of course, there may be some valid counter-arguments to the ones I made above which could make a compelling case for the removal of the global from the standard (and which actually outweigh the disruption caused by the removal). I'd be interested to hear of any. The main one I can think of off the top of my head is if there was a requirement to install more than one DA in a given environment (although I believe this would go beyond what the current FDC3 spec provides for, and I would also have thought that any potential need to do that would likely be significantly undercut by the availability of a Desktop Agent bridge a.k.a. Backplane solution for interop between apps running in different ecosystems / containers that used different DAs).

For reference, the full 'FDC3 Desktop Agents vs. API implementations and using FDC3 on the Web' discussion thread I was referring to is here:
https://groups.google.com/a/finos.org/g/fdc3/c/jCvlLjokBLs

[kriswest]

Great summary @novavi

[kriswest]

At the last FDC3 Standards Working Group meeting (#899) it was resolved that a discussion group should be set up to discuss what changes need to be made to how the FDC3 API is accessed, to enable its use in a Web browser (rather than a container or browser extension that makes the API available at window.fdc3).

This is currently only possible through the import of an implementation from a proprietary module (allowed, but not recommended in standard version <=1.2, but not in 2.0), which has significant downsides for the FDC3 ecosystem as it requires an application to be adapted for each desktop agent that it may be used with (which is not the case when working with an injected window.fdc3). A lively discussion of possible ways forwards, and their impacts on the FDC3 ecosystem has already started over email, which should continue in the discussion group.

• Email thread: https://groups.google.com/a/finos.org/g/fdc3/c/jCvlLjokBLs/m/TBoK6lZYAQAJ

To help us organise the discussion group at a time suitable for all those who wish to participate, please indicate your interest and dates you could attend below (by clicking on the relevant emojis):

• 😄 Monday 13th Feb 11:30AM EST / 4:30PM GMT
• 🎉 Wednesday 15th Feb 10AM EST / 3PM GMT
• ❤️ Thursday 16th Feb 11AM EST / 4PM GMT
• 👎 Nothing works I need other options!

---

Poll Closed: result: