-
Notifications
You must be signed in to change notification settings - Fork 164
Description
Date
Thursday 27th Feb 2025 - 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 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.
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)
- Update on impending 2.2.0, adoption vote and release
- FDC3 for Web merged
- FDC3-dotnet / .Net binding updates: addEventListener
- Pending PRs to review:
- Maintainer and Editor recruitment
- Reviewing GoLang contribution
- Kicking off discussions for the 2.3 scope
- Should the desktop agent support both unqualified appIds and fully qualified ones? #1475
- Add property to support analytics across apps #1290
- Clarify that Context types are defined in JSON and may be handled differently in specific API bindings #1486
- No defined behaviour when incorrect arguments are passed to API calls #1490
- AOB & Adjourn (5mins)
Minutes
- Actions items from previous meeting
- Still in need of reviewers for GoLang contribution - @kriswest recommends acceptance as @experimental
- Rolled over actions relating to JSON/Typescript bindings for context
- 2.2. release status
- Open PRs accepted and merged before and during the meeting - including FDC3 for the Web implementation, we are just about content complete!
- Thanks to @robmoffat for restoring release system to working state and performing beta release: Release 2.2.0-beta.1 #1520
- Some additional work is warranted to simplify the publishing of prereleases - currently requires support from FINOS due to access to NPM account being required
- Docusaurus site updated to current and versioning script fixed (thanks to @patrocinio , @robmoffat , @kriswest)- eliminating vulnerable dependencies
- Thanks to @robmoffat for restoring release system to working state and performing beta release: Release 2.2.0-beta.1 #1520
- NPM module Beta releases available for testing: https://www.npmjs.com/package/@finos/fdc3/v/2.2.0-beta.1?activeTab=versions - with provenance
- Additional NPM modules available for constituent parts for the first time
- Missing readmes for some of the new NPM modules noted, fix needed for final release
- fdc3-dotnet an docs contain signatures for addEventListener, but there is much still to do to implement the rest of 2.2 support (context type updates)
- @kriswest requested and received consent to open the adoption vote for 2.2 via email, upon completion of minor tasks (readmes, website release version created)
- Open PRs accepted and merged before and during the meeting - including FDC3 for the Web implementation, we are just about content complete!
- Kickoff: 2.3 scope
- Strategic initiative
- @robmoffat provided details of the FINOS boards promotion of a strategic initiative in 2024 for developing better identity and security support in FDC3, the goal of signing up executive sponsors for the initiative
- A meeting will be held Friday with prospective executive sponsors for the initiative
- @robmoffat will be spending a significant portion of his time on this initiative in 2024
-
At OSFF NY last year, there was a presentation between Morgan Stanley and Wellington and Symphony, and we looked at FDC3 and encryption. I'd like to expand beyond that, lots of firms interoperating with each other, using secure FDC3.
- @bingenito: As long as we want to facilitate between selll side and buy side, it's a show stopper until we have identity figured out.
- @kriswest: We also need to make sure we confirm user identities, especially for workflows that spread across multiple identities. If one person can send things to another user, you need to be able to confirm those users. We have to figure out both APP identities and USER identities.
- @robmoffat: Doing things in the browser makes things so much more public than just keeping things on the desktop.
- @kriswest: There are more FDC3-supported environments being released in 2024. FDC3 is being heavily used inside firms, but there are various firms releasing Desktop Agents and whole suites of apps that use FDC3. These will need to integrate with other DAs and apps on the Desktop, which is likely to make both Desktop Agent Bridging and Identity far more important concepts than they are today.
-
- OSFF London CFP is open
- https://events.linuxfoundation.org/open-source-finance-forum-london/
- @robmoffat: By the time we get to OSFF London, we need to have decided what the 2.3 scope is. I'd also like to have a completed, agreed white paper.
- Ideally that white paper should focus on the use cases to be solved, rather than the specific solutions.
- Strategic initiative
- Should the desktop agent support both unqualified appIds and fully qualified ones? #1475
- The definitions of unqualified (e.g.
myApp) and fully-qualified (e.g.myApp@appd.example.comappIds, and the problem they present was discussed- including the impact of that issue on the FDC3 conformance framework, which hard-codes unqualified IDs and will not pass (correctly written) DAs that fully qualify its apps without supporting some form of resolution between the two types.
- Method proposed in Resolving Fully-qualified and unqualified AppId values #1523: first atetmpt simple string match, then split input fq-appIds on
@symbol, match against first section., OR for uq-appId input, split known fq-appIds on '@' and match. - Where uq-appIds were given as input that can result in some edge cases where they match multiple known fq-appIds.
- Perhaps resolve with a resolver UI as we do with intents? Less clear on other API calls, like
.open()andgetAppMetadatathat don't already use resolver UIs.- A number of participants noted that intent resolver dialogs are often not popular
- Perhaps resolve with a resolver UI as we do with intents? Less clear on other API calls, like
- Need reviewers to look at Resolving Fully-qualified and unqualified AppId values #1523 and comment on it ready for next month's meeting
- The definitions of unqualified (e.g.
- No defined behaviour when incorrect arguments are passed to API calls #1490
- Relatively simply issue for creating some additional error messages to return when bad inputs are passed to API calls
- A participant whether this addition would create new conformance tests?
- @kriswest: I'm not sure we NEED to have this in conformance, but it should be possible to define a small set of tests. We would not want to test every API call and parameter combination.
- A participant posited that this wouldn't be an issue in a compiled language like Java - another stated that you could still provide (for example) meaningless string parameters in some cases...
- Next step: participants review PR and comment ready for next month
- Add property to support analytics across apps #1290
- Multiple proposed solutions - a number of participants expressed a preference for passing separate params with metadata (rather than adding them to context messages), and it was noted that this might work well for message signatures
- @Davidhanson90 drew attention to his additional proposal that we consider switching API calls to accepting a single parameters object as input, as this can soften breaking changes as we add or change parameters on functions. Including the ability to pass multiple contexts to some calls. Could be achieved in a non-breaking way via a function override.
- @kriswest: There is already a defined way of passing arrays of context, by defining a context type that contains the array - e.g.
fdc3.contactandfdc3.contactList- part of the original context design. There were thoughts in the past of using generics. We'd also need to explore the existing function overrides to make sure there are no conflicts. - The proposed metadata parameter does at least allow future extension with additional metadata fields, e.g.
broadcast(context, metadata)orraiseIntent(intent, context, metadata) - Next steps: DA implementors to review and comment then bring it back for a decision on direction.
Action Items
- Participants to review and comment on Resolving Fully-qualified and unqualified AppId values #1523 for discussion at next meeting
- Participants to review and comment on Add property to support analytics across apps #1290 for discussion at next meeting
- @kriswest to refer Support for Multiple Application Scopes (Agents) within a single window process #1250 back to fdc3-for-web discussion group to update the proposal to include a tear-down function for 'subAgents'.
- @robmoffat & @kriswest Some new refactored packages as part of the monorepo are missing readme #1526
- @kriswest raise issue for further customisation of release CI task (package.yml) to simplify prereleases
- Validate package numbers are all in sync
- Process version num to extract/detect prerelease details (2.2.0-beta.1), if found automatically tag as
prereleaseinstead oflatest
Rolled over from previous meetings:
- @finos/fdc3-maintainers and @finos/fdc3-editors to review and feedback on Adding language binding for golang #1483 - any FDC3 community members with Go experience were requested to provide feedback.
- @Roaders and @kriswest to explore comparisons between string encodings of Dates and Date objects in JavaScript/TypeScript + any other deviations of the TypeScript binding from JSON and to report back on issue Clarify that Context types are defined in JSON and may be handled differently in specific API bindings #1486 - then propose clarifying language to be added to the FDC3 API and Context specifications.
- @kriswest add Add property to support analytics across apps #1290 to a future meeting agenda to determine what solution to select for the 2.3 scope
- @bingenito create an issue and PR to add the advice about consistent use of pascal case in enums in the API (implementation language and context docs (The Context Interface section after advice on union types).
Untracked attendees
| Full name | Affiliation | GitHub username |
|---|---|---|