Standard WG Meeting - April 25th, 2024

[kriswest]

Date

Thursday 25th April 2024 - 10am (US eastern timezone EDT/EST) / 3pm (London, GMT/BST)

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 [email protected] 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.

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)
  • Standard WG Meeting - February 22nd, 2024 #1160
• Summary of current topics in Discussion group meetings (5mins)
  • Upcoming meetings :
    • FDC3 Use cases discussion group: Thurs 2nd May
      • Understanding the FDC3 End-User Personas #1173
      • FDC3 Trader Persona #1183
    • FDC3 Identity & Threat Modelling discussion group: Thurs 9th May
    • FDC3 for Web Browsers discussion group: Thurs 16th May
    • FDC3 Desktop Agent Bridging discussion Group: Wed 22nd May
• Updated proposal for: Add event listeners (for non-context events) to the Desktop Agent API (e.g. for changes to the current User channel) #1136 (10mins)
• Merged PR overview for: Refactoring ContextTypes to union type (instead of enum) #1138 (5mins)
• Continue discussion of Adding debugging information to help app developers trace broadcast storms #1142 (20mins)
  • This is a similar request to others raised in the past, e.g. Question: App-specific context metadata #829
    • Multiple app developers have asked for ways to send some additional metadata with a context message, for ancillary purposes (debugging, tracking sequences of interactions for analytics purposes, providing some additional that might be used in a response)
  • There are two ways to solve for this - allow it to be sent through the API as an additional, optional, argument OR create a standard place to attach it directly to a context message.
• Other issues or PRs under review for the community to be aware of (5mins):
  • Context Clearing #1197
  • Replace tsdx use in build of the FDC3 NPM module #1061
    • Remove TSDX from build system #1175
  • Update Use Cases #1096
    • Marketing Update #1181
  • Correcting an error in the fdc3.country docs as they differ from the schema #1194
  • Add openssf scorecard action and readme badge displaying score #1188
• Contribution opportunities (issues in need of a PR) (5mins):
  • Add vendor agnostic default window size and position settings to the App Directory app definition format #564
  • Intent Proposal: Create or Update Profile #591
  • Allow an AppD application record to reference other apps that are *required* for it to run #674
  • Add /intents and /contexts endpoints to the AppD API #719
  • Improve OpenAPI (REST) documentation for the website with a docusaurus plugin #1001
  • Custom application config, retrievable via a standardized function #1006
  • Remove defunct version field from IntentResolution #1053
  • Missing desktopAgent from ImplementationMetadata #1057
  • Replace tsdx use in build of the FDC3 NPM module #1061
  • FDC3 should avoid union types in contexts and other objects #1105
  • Add event listeners (for non-context events) to the Desktop Agent API (e.g. for changes to the current User channel) #1136
• Adjourn

Minutes

• @mistryvinay Provided a summary for the FDC3 Use Cases discussion group:
  • rebranded contexts & intents group, which has pivoted to working with business stakeholders to understand financial workflows and help build a roadmap for future context and intent types needed to support them.
  • The group is currently working to understand the main user personas: Understanding the FDC3 End-User Personas #1173
  • And to break them down into day-to-day activities: FDC3 Trader Persona #1183
  • Which will then prompt issues to create the context and intent types needed to support each workflow.
    • if the necessary type don't exist developers will most likely use custom intents/contexts and unwinding that will be difficult
  • The group is keen to recruit additional participants with knowledge of relevant workflows
• @Yannick-Malins Provided a summary for the Identity & Theat modelling discussion group
  • Please join if at any point you had any questions raised about safety, compliance, guarantees around privacy of communication, security audit, etc.
  • The group is working on identifying core use cases and how we can add notions of trust and encryption without breaking
    compatibility.
  • FDC3 began with a very open model of interoperability that is ideal for context sharing use case, but there exist other, more transactional, use cases that require a greater level of trust & communication security to support through FDC3
  • The group is keen to recruit members that have thought "i wanted to do this with FDC3 but could not because of x, y z"
• @kriswest provided a short summary for the FDC3 for web Browsers discussion group
  • The group is working on extending the FDC3 Standard to Web Browsers, such that application providers will be able to write to FDC3 alone and work with a multiple desktop agents (i.e. eliminating the need for to include proprietary libraries)
  • The group is keen to recruit members that are implementing Desktop Agents both in containers and in Web Browsers.
• ... and the FDC3 Desktop Agent Bridging discussion group:
  • FDC3 Desktop Agent Bridging allows Desktop Agents to connect to each other so that multi-app platforms can interoperate with each others apps, greatly simplifying integration.
  • The group is supporting those implementing Desktop Agent Bridges (including the Backplane project) or support in a Desktop Agent for connecting to one and is open to anyone interested in working with a bridge.
  • The Backplane project is also keen to recruit maintainers to help complete the implementation - the availability of an opensource bridge will be advantageous to larger organisations that may wish to adapt it to their own IT systems.
• Add event listeners (for non-context events) to the Desktop Agent API (e.g. for changes to the current User channel) #1136 - Add event listener support to the Desktop Agent API for changes to the current User channel
  • @kriswest recapped the discussion from last time and an overview of the updated proposal in the issue for a generic addEventListener function.
  • @bingenito suggested some small improvement to the suggested patterns (enum name should be singular, allow filtering by event type); there was consensus among participants that they should be applied
  • @novavi noted a difference between this and addIntentListener which takes intent as a string parameter. Will we expect a specification change when vendors add their own event types? Important to not constrain for intents; there is a need for agents that are cloud-based to have events around connectivity.
  • @robmoffat also cited the need for events on the loss of connectivity between API and implementation
  • @kriswest to apply changes to the issue and raise a PR before we discuss again
    • @bingenito will that be for 2.2? @kriswest - yes?
• Refactoring ContextTypes to union type (instead of enum) #1138/Refactors ContextTypes&Intent to union type instead of enum #1139 Refactoring ContextTypes to union type (instead of enum)
  • @kriswest summarized what changed in this contribution from @andreifloricel (which is not a change to the Standard, rather to the library and will be released with the final 2.1.0 NPM module), including:
    • the type of intent and (context) type parameters to addContextListener, raiseIntent, addIntentListener from string to the new Intent and ContextType unions which do not change the type of the parameter (still reduces to string) but allows IntelliSense to suggest/autocomplete standard values in an IDE.
      • @kriswest / @bingenito discussed the need for an ESLint ignore on those new types, see: https://github.com/InteropIO/FDC3/blob/c2cb9d51e8644ac64e3640b1eb0cb95bb9cc8d5b/src/context/ContextType.ts#L46-L49
    • New util functions and constants that can be used for Standard types
• Adding debugging information to help app developers trace broadcast storms #1142 Adding debugging information to help app developers trace broadcast storms
  • @kriswest provided an overview of the issue and recapped the discussion from last time, which included the fact there are several use cases for being able to attach some small amount of additional metadata to a context message (broadcast or raised intent):
    • Suppress broadcast loops (easy enough to do when the same type is rebroadcast by other apps, less easy when the loop involves translations through other types)
    • Tracking for multiple different API calls, from different apps, as relating to the same interaction or workflow
    • Additional 'app-specific' metadata Question: App-specific context metadata #829
  • ...and there are two possible proposed solutions:
    • Add additional, optional metadata arguments to relevant API calls (broadcast, raiseIntent etc.) allowing the Desktop Agent to send along the extra data in the (again optional) ContextMetadata object
    • Standardize an property in the Context schema that is inherited by/composed with all other Context types.
  • @kriswest brought attention to the initial objections raised via comments on the issue from other maintainers.
  • There was some further discussion of the use cases, which included:
    • The fact that all the use cases & objections fall outside of the Desktop Agent's domain - i.e. a DA can't solve for them without input from the applications - e.g. a DA generally can't tell if a fdc3.instrument broadcast or raised intent to View Chart relates to a prior call to create an order, but the applications involved usually can and could indicate that if passed data. Several participants recognized that particular analytics use case and issue.
    • There was consensus that it is important for FDC3 to push for the adoption of standardized context messages (if the goals of a standard are to be achieved), however, if they (or the API standard) don't make a place for this then it will encourage the use of more proprietary types (which is not the goal, particularly where these use cases involve multiple apps from different vendors).
    • There was also consensus that a proposal of a standard location in the context schema for additional data would be easier for the community to adopt and implement than the API proposal.
    • Multiple participants stated that the analytics use case was stronger than the others.
    • @kriswest suggested he and @julianna-ciq take an action to rewrite/retitle the issue to be inclusive of all use cases.
    • @novavi recommended that we remove any mention of MUST in the discussion in future versions as it may be confusing to some. @kriswest agreed and stated that any generic metadata property would be optional on Context anyway.
    • @novavi and @bingenito pointed out that the property shouldn't be called metadata as this would get confused with the ContextMetadata type (optionally) passed to context and intent handlers by the DA.
• The meeting end with a discussion of the testing of the 2.1.0-beta.8 NPM module by @bingenito and the interop.io team, after applying the proposed changes to build system by @julianna-ciq in Remove TSDX from build system #1175 - no issues were found. @kriswest asked if there were any objections to merging the change and releasing 2.1.0 and none were received.

Action Items

• @finos/fdc3-maintainers Raise a PR to resolve FDC3 should avoid union types in contexts and other objects FDC3 should avoid union types in contexts and other objects #1105
  • Don't use union types in context and API definitions #1200
• @bingenito & @kriswest to complete PR Adding .NET signatures to FDC3 documentation #1108 and submit for review - to include at least a basic version of supported platforms content (to be improved later)
• @kriswest & @mistryvinay look at 1068 Generating context docs from schema files #1151 and consider taking over final changes (which include deleting existing context docs, hooking up script to auto-generate as part of build and making sure existing URLs do not break)
• @kriswest Apply changes discussed to Add event listeners (for non-context events) to the Desktop Agent API (e.g. for changes to the current User channel) #1136 and raise a PR before bring back for further discussion.
• @kriswest & @julianna-ciq rework issue Adding debugging information to help app developers trace broadcast storms #1142 to reflect the other use cases and update the proposed change based on the discussion
• @kriswest merge Remove TSDX from build system #1175 and release npm module 2.1.0

Untracked attendees

Full name	Affiliation	GitHub username

[Yannick-Malins]

Yannick Malins / Symphony

[robmoffat]

Rob / FINOS 🐰

[kriswest]

Kris West / interop.io 🚀

[bingenito]

Brian Ingenito / Morgan Stanley

[mistryvinay]

Vinay Mistry @ Symphony 🎵

[timjenkel]

Tim Jenkel / Wellington

[novavi]

Derek Novavi / S&P Global

[pvoznyuk]

Pavlo Vozniuk @ RBC CM 🦁

[hughtroeger]

Hugh Troeger / FactSet

[julianna-ciq]

Julianna Langston / interop.io