FDC3 for Web Browsers Discussion group 19th December 2024

[kriswest]

Group overview

Group convened to work on proposals to enable FDC3 use in a web browser, without the use of a browser extension.

The main proposal is now part of the current draft of FDC3 2.2 on the mina branch of the FDC3 repo and website (main/unreleased version), see:

• https://fdc3.finos.org/docs/next/api/ref/GetAgent
• https://fdc3.finos.org/docs/next/api/specs/browserDesktopAgents

Open Pull Requests:

• FDC3 For Web Browsers Implementation DON'T REVIEW YET #1309
• Updating SessionStorage data format to additionally scope data #1442
• Fdc3 for web impl commonjs #1452
• Match event listener names to event type names in fdc3 for web schemas #1459
• Fdc3 for web impl get agent refactor #1466

Relevant issue tags

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

Meeting Date

Thursday 19 MMM 2024- 11am (US eastern timezone /EST) / 4pm (London, GMT)

Zoom info

• Join Zoom Meeting
• Meeting ID: 969 4029 4948
• Passcode: 636931
• Dial-in:

  Country	International Dial-in	Toll-free Dial-in
  US	+1 929 205 6099 (New York)	877 853 5247
  UK	+44 330 088 5830	0800 031 5717
  France	+33 1 8699 5831	0 800 940 415
  Find your local number	https://zoom.us/u/ad2WVnBzb8

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.

Participation Requirements

Note: Meeting participants are expected to accept the terms of the FDC3 license (Community Specification License), understand the governance process and have a CLA in place.

Please click the following links at the start of the meeting if you have not done so previously.

• View the CSL
• View the GOVERNANCE of the Project
• Click here to start a PR.
  • Edit the page to add your details.
  • Hit the save button.
  • Click "Create Pull Request".
  • Click "Accept" on the EasyCLA dialog in the PR's discussion section.
• Click here to send email to become a voting participant on the FDC3 Project

Tracking Attendance

Note: Meeting participants are expected to add a comment to this GitHub issue in order that we can track attendance of FDC3 project meetings. Please do this at the start of the meeting.

Agenda

• Convene & roll call, review meeting notices (5mins)
• Review action items from previous meeting (5mins)
  • FDC3 for Web Browsers Discussion group 21st Nov 2024 #1443
• Update on the current status of implementation and opening the implementation PR for review
• Timeouts needed within the implementation:
  • Default API call timeout
  • Custom timeouts needed for open, raiseIntent and raiseIntentForContext
  • Do timeouts need to be customizable by DAs?
• Q&A + Next Steps
• AOB & Adjourn

Minutes

• Action items from previous meeting
  • Updating SessionStorage data format to additionally scope data #1442 @novavi to review
• Update on the current status of implementation and opening the implementation PR for review
  • getAgent refactor PR
    • will hopefully be ready to merge soon. Just a few open items
    • once that's merged into fdc3-for-web-impl, we should be ready for a public review
  • Goal to reach 100% in OpenSSF best practices
    • We're missing the test policy item
    • Question: Should we have a coverage threshold around 80%? If you use the policy that code coverage can't go down, that can get really annoying in practice
      • It's nice to see if a line of code loses code coverage though. Maybe not a hard limit, but as informative.
    • Review of the current code coverage levels
      • PR's from forks are different
      • Need to run checks against main?
  • Reviewed monorepo restructure applied in FDC3 For Web Browsers Implementation DON'T REVIEW YET #1309
  • Switching to ES6 only module with new commonjs module (@finos/fdc3-commonjs) for backwards compatibility
• Question from a participant looking to publish an FDC3 utility app: For the AppD directory, is there a sense of how much usage it's getting? Are people connecting to it? Just want to understand the usage overall of AppD
  • @kriswest: It's a standard, rather than an implementation, so we don't get stats, per se, on usage. imo, it's not used enough. It might be used as a config file instead of a REST endpoint API, the way it should be used. It has been implemented by all 3 of the Desktop Agent vendors. There's also another team or 2 present that have implemented support
  • @Roaders: We are in the process of implementing of implementing support.
  • @kriswest: The goal was that AppD records would be hosted by the publishers of apps, but thats not been as common firms adopting a Desktop Agent hosting an AppD with apps that they use.
  • Further discussion clarified the difference between the FINOS appD (which has two endpoints: exmaple apps and confogrmance test apps), hosting your own appD and advertizing your app in the FDC3 community page
  • @Roaders: In the current AppD (FINOS appD, conformance endpoint), none of the apps use getAgent. I can't add them in a web-based application. When will apps and conformance tests be updated to support getAgent?
    • @kriswest : We'll take an action item to look into this and get back to you - @robmoffat has already worked on implementing the necessary changes.
• Timeouts needed within the implementation
  • We've addressed timeouts for connecting to an agent via getAgent, but not internal timeouts to be used when communicating with a DesktopAgent for FDC3 API calls
  • Message exchanges are generally resolved in milliseconds, and are generally handled on local machines, but it's possible for a DA to be cloud-based and hence slow of congested network connections should be accounted for.
  • All API calls are request/response and generally resolved very quickly - however responses to open, raiseIntent and raiseIntentForContext are delayed by starting an application and waiting for it to add a context or intent listener.
    • The Standard requires DAs to allow a minimum of 15 seconds for an app to add a context/intent listener), but gives no upper bound...
  • @kriswest Recommend a short 10s timeout for most API calls, but noted that .open, .raiseIntent, and .raiseIntentForContext need much longer (likely around 90-120s)
    • One group uses 90s for a launcher timeout.
    • Some DAs allow apps to configure launcher timeouts.
    • @Roaders: If timeouts are customizable, that's the answer. Set reasonable defaults, and let timeouts be added to the handshake
    • @kriswest: We'll need different timeouts for different types of API call
    • @Roaders: I think that could be up to the Desktop Agent, which can allow different kinds of timeouts or handle things on a per-application basis
      • @kriswest: The Desktop Agent would need to communicate an appropriate timeout, for example in a WCP connection flow message (timeout is applied in getAgent on client side)
      • @watson-ew What about the AppD level? If you know your app is going to be long-standing, you could create a field in the AppD record to put it in
      • @kriswest [reviews appd metadata] We could add something to the interop element, or something else, like a launchTimeout. That feels reasonable, but could be a separate addition. It's a fairly light addition if we make it an optional field. We don't want to make it so complex that we're adding stages to app launching, we don't have a mandate for something like that.
  • @Roaders: The defaults of 10s, 90s, for different things, that makes sense to me.
    • Kris: 10s for regular API call. 90s for an API call related to launching. Then allow a DA to send its own values back during one of the connection flow messages. Are there any objections to that as an approach?
      • No objections
• Q&A
  • Should the desktop agent support both unqualified appIds and fully qualified ones? #1475
  • The API doesn't do anything special with fully qualified appIds - they're just a string identifier. If your DA always uses fully qualified AppIds then you'll have trouble with the conformance framework which does not and will make calls with unqualified ids.
    • Discuss in January at SWG
    • @Roaders asked about control of debug logging in getAgent via g a parameter in the DA initialization.
    • @kriswest: We implemented a logging utility in getAgent to simplify logging customisation.
    • Debug level produces a lot of noise, which is useful for debugging, but is chatty when you aren't. However, in most javascript consoles, the verbose level (which is what debug maps to) is turned off, so you'd have to turn it on yourself anywhere.
    • This is all client side logging. I think the application should be in control, rather than the desktop agent, since it's in their console.
      • @Roaders: We have some very chatty apps that produce a lot of logs. If I wanted to turn off logging from the desktop agent, so that I can focus only on my own app's logs, it'd be nice to turn off logging from the DA.
      • @kriswest: Note that the getAgent logs only happen during the connection phase, if that changes your mind
      • Giles: That makes it better, but I'd still like to turn things off.
      • There was general agreements (including @novavi and @Roaders) that control over logging was needed
      • @Lecss : Is there anything stopping us from logging all of the other messages coming through?
      • @kriswest & @robmoffat: That would come from the fdc3-agent-proxy package... specifically the abstract messenger
        • Pretty much everything passes through this exchange function, so we could implement a log right there fairly easily. Right now we only log errors from within the exchange. But it'd be easy to log every request/response, which is likely to be useful for someone along the way.
      • There was general agreement that you should be able to turn debug logging on/off for startup, general messaging and heartbeat messages

Action Items

• Updating SessionStorage data format to additionally scope data #1442 @novavi to review then merge
• @robmoffat @kriswest Ensure all conformance test apps + FDC3 workbench are updated to use getAgent()
  • FDC3 2.2 Conformance Implementation #1455
• Add Should the desktop agent support both unqualified appIds and fully qualified ones? #1475 to next SWG agenda
• @kriswest to complete Fdc3 for web impl get agent refactor #1466, @robmoffat to review and merge it, then open FDC3 For Web Browsers Implementation DON'T REVIEW YET #1309 for public review
• @kriswest Look at WCP connection flow messages and propose where a Desktop Agent could specify custom timeouts to be used.
• @kriswest Look at getAgent arguments for enabling debug logging for the connection flow, general messaging and heartbeats

Untracked attendees

Full name	Affiliation	GitHub username

[novavi]

Derek Novavi / S&P Global

[robmoffat]

Rob Moffat / FINOS

[Roaders]

Giles Roadnight / Morgan Stanley

[kemerava]

Elizabeth Kemerava / BlackRock

[Lecss]

Alex Dumitru / Citi

[kziemski]

Kryspin Ziemski/ QCOMPUTE

[watson-ew]

Chris Watson / Elgin White 🎅

[psmulovics]

Peter Smulovics / Morgan Stanley

[julianna-ciq]

Julianna Langston / interop.io