FDC3 Standard WG Meeting - February 22nd, 2024

Date

Thursday 222nd Feb 2024 - 10am (US eastern timezone EST) / 3pm (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 [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

[x] Convene & roll call, review meeting notices (5mins)
[x] Review action items from previous meeting (5mins)
- #1147
[x] Announcements (<5mins)
- Buyside Roundtable
- Use cases discussion group
[x] Adoption of fdc3-dotnet as the official binding for FDC3 in .NET/C# (Vote!) (5-15mins)
New or updated issues: (20 mins)
- [x] #1068
- [x] #1136
- [x] #1138
- [x] #1142
[ ] Contribution opportunities (issues in need of a PR) (5mins):
- #564
- #591
- #674
- #719
- #1001
- #1006
- #1053
- #1057
- #1061
- #1105
- #1136
[ ] AOB & Adjourn (5mins)

Minutes

An action item was rolled over from the previous meeting.
Announcements
- Trying to get more involvement in FDC3 from Buy-side firms
  - A buyside roundtable was held to promote FDC3 involvement to buy side firms
  - FINOS board pushing for Sell-side & Buy-side firm integrations (sell-side as Software providers to buy-side orgs)
- It is proposed that we rebrand and rethink the Context & Intents Discussion group to focus on business use case discussions, as agreed use cases are what drive Intent and Context proposals.
  - A specific effort should be made to recruit buy-side stakeholders for these meetings
- Consent was sought and given to make the change to the group, which @mistryvinay will continue to chair.
.NET binding for FDC3
- A brief overview of the proposed .NET API signatures was again provided by @bingenito, with a summary of the agreed process for adoption provided by @kriswest
- Consent was sought and given to adopt fdc3-dotnet as the .NET/C# binding for FDC3
  - The PR to incorporate the new binding into the FDC3 documentation must now be completed and reviewed by the FDC3 maintainers for inclusion in the FDC3 documentation
    - Content for the 'Supported Platforms' page is the main outstanding item, which should include or link to documentation of any software tools provided.
    - A new Standard version need not be issued as the C# binding was written against FDC3 2.0 and work on a 2.1 update is underway.
    - Further representations or comments on the adoption maybe submitted and considered until the above PR is completed and merged by the FDC3 maintainers.
Open issues
- #1068
  - In need of review by maintainers and editor
- #1136
  - A summary of the proposed User Channel change event was provided
    - Relevant to recent conversation in #fdc3 channel
  - @bingenito: could we be more generic/future proof and make the function addEventListener, allowing it to be used for other future events?
    - @novavi: connection events might be needed in FDC3 for the Web
    - @julianna-ciq: What about make these Join & Leave channel events, rather than a change channel event?
      - Would help future proof if we ever decide to accept #242 - a number of FDC3 participants already support multi-channel and/or directional channel membership
    - Define an event object, with enum or union for types, some detail fields etc.
      - Sub types or specified values for specific event types
      - Possible to support custom/vendor specific events through the same mechanism
    - Channels created and other apps joining and leaving channels
      - @kriswest related past objections (that he doesn't necessarily agree with but thought should be referenced) from FDC3 maintainers related to data leakage and security by obscurity, when similar proposals were raised in the past
        
        Identity/authorisation features being discussed for FDC3 may help to resolve those objections (Desktop owner and Desktop Agent may be able to differentiate between apps that should have access to the information, and those that should not)
        
        PrivateChannels have specific features related to apps joining and leaving and are intended to help with data streaming lifecycles or controlled access to interop and should probably be used for this
    - The proposal should be updated along the lines discussed and brought back for further discussion
  - #1138
    - There was general agreement that the proposed changes are an improvement and that there are small use cases for including lists of standardized intent/context ids that are usable at runtime, in addtion to type definitions that include these. - There is no change to the Standard if the code is non-breaking (so existing enums should remain).
      - There was some discussion of the possibleContexts functionality for intents. This is less useful as the possibleContexts are not an actual restriction in the standard and don't really have a bearing on what contexts apps may accept for intents - that is usually defined in an appD by an app itself and the use of a proprietary type is absolutely allowed.
      - This content was likely provided to suggest valid Standard context types to use - i.e. it is just informative and could/should be removed from the PR to 'keep it simple' - unless the author wishes to support its addition with an additional use case.
  - #1142
    - @julianna-ciq provided an overview of the use case behind this proposal.
      - A number of participating firms picked up the discussion and related some past experiences as well as interest in making some form of enhancement to support.
      - There was some discussion of the name for an element or field as threadId was not popular, traceId was suggested.
      - @kriswest indicated that there are a couple of possible approaches to this: adding an element to the base context shcema, that could then be used with any derived context types OR introducing additional arguments to API functions (e.g. broadcast and raiseIntent) that would allow the DA to return the data in the optional ContextMetadata element which currently provides the originating app identity.
      - An additional use case was suggested, relating to providing analytics over FDC3 interactions, for example reported over OpenTelemetry or another analytics platform.
        
        Single user interaction or event can end up spanning multiple FDC3 API calls (broadcasts and raised intents etc.) to or from multiple applications. Better analytics can be provided if these events can be tied together, which a desktop agent can't do reliably on its own as different interactions can overlap in both time and the applications involved. Rather it is the applicaitons themselves that need to indicate that a particular broadcast or intent related to a particular interaction or follows on from a previous broadcast/intent. These might be immediate (I've received this, so I send that out) or delayed (some action was taken, the user is involved and then an unspecificed time later initiates another action/api call in response).
      - An FDC3 maintainer suggested that these use cases were sufficiently important and common that we should consider making this required (MUST) in future versions
        
        @kriswest indicated that such a change would be breaking and would therefore require an FDC3 3.0 version. We should instead introduce any such change as a SHOULD or MAY in the meantime.
      - There was general consensus that, by taking a view/providing a recommendation on how this, the standard can promote a common approach that will be more often usable across multiple applications.
    - Discussion of this issue was curtailed by the end of the meeting and it was resolved to pick it up at the next meeting. @julianna-ciq offered to update the issue based on the discussion.

Action Items

[ ] @finos/fdc3-maintainers Raise a PR to resolve FDC3 should avoid union types in contexts and other objects #1105
[ ] @mistryvinay & @robmoffat re-brand the Contexts & Intents discussion group and @fdc3-maintainers to recruit participants (particularly from buy-side firms)
[ ] @bingenito & @kriswest to complete PR #1108 and submit for review
[ ] @finos/fdc3-maintainers review #1068 and provide feedback
[ ] @finos/fdc3-maintainers review #1138 and provide feedback
[ ] @kriswest update the proposal for #1136 as discussed (generic addEventListener function for future proofing) and add to a future meeting agenda for further discussion.
[ ] Add #1136, #1138 and #1142 to the next meeting agenda - each PR or issue should be updated to reflect changes proposed.