FDC3 Standard WG Meeting - August 25th, 2022

Date

Thursday 25 Aug 2022 - 10am EST / 3pm BST

WebEx info

Meeting Link Meeting number: 665 568 411

More ways to join

Join by video system:
- Dial [email protected]
- You can also dial 173.243.2.68 and enter your meeting number
Join by phone
- +1-415-655-0003 US Toll
- +44-20319-88141 UK Toll
Access code: 665 568 411

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.

Agenda

[x] Convene & roll call, review meeting notices (5mins)
[x] Review action items from previous meeting (5mins)
- #784
[x] Maintainers update (5mins)
- FDC3 2.0 was released as the current version (22nd August)
- (Beta) release of NPM module
- Pending release tasks: https://github.com/finos/FDC3/milestone/8
- Post-release tasks: https://github.com/finos/FDC3/milestone/7
- Volunteers always welcome!
- Are any Q&A sessions needed for 2.0 implementation or general FDC3 questions?
Discussion of open issues (40 mins) (will not get to all, the remainder to roll over to future meetings):
- [x] #719
  - [x] #311 (included as loosely related)
- [x] #312
- [x] #674
- [ ] #242
- [ ] #301
- [ ] #559
- [ ] #563
- [ ] #735
- [ ] #386
- [ ] #387
- [ ] #564
[x] AOB & Adjourn (5mins)
- Please raise issues for any topic that you'd like discussed at future meetings.

Minutes

Maintainers update
- Are any Q&A sessions needed for 2.0 implementation or general FDC3 questions?
  - Implementation questions can be:
    - posted as a github discussion: https://github.com/finos/FDC3/discussions/803
    - discussed on the #fdc3 channel on the FINOS slack
Discussion of open issues:
- #719
  - A number of participants (including @nkolba and @kriswest) felt that the proposed /intents and /contexts appD endpoints are useful for both development and governance use (at least one firm has demonstrated a web UX based on similar endpoints).
  - However, adding API endpoints that pass through this information was not considered necessary or wise as it makes it easier for an application to gather and leak information about the desktop environment (@nkolba @kriswest @openfin-johans).
    - Similar, but more limited, functionality is already available in the form of the findIntentsByContext and raiseIntentForContext API calls, which will return intent and resolution to app options for a specific context (adding a list of all know contexts makes mining information with these calls trivial, however, the calls as they stand serve a valid usecase.
    - The same thought applies to an API call to retrieve the details of the appD URLs in use. Apps running in the context of a Desktop Agent generally do not need this information (although vendors would value the information, firms using the agents are unlikely to want that information to leak).
  - (Silent) consent was sought and received to move forward with proposing new appD API endpoints for `/intents' and '/contexts' and to NOT make any additions the Desktop Agent API.
- #311
  - This issue was revised as related to the above - the same thoughts apply:
    - Adding an fdc3.applications() function makes it trivially easy for information about the desktop environment to be leaked to any and all applications running in its context.
    - It is possible to gather similar information when interoperating with applications or using findIntent calls, doing so requires knowledge of all the intents and context types in use. While it is easy to enumerate standard types, It isn't possible to do so for proprietary types - it also requires a more concerted effort to gather the information.
  - (Silent) consent was sought and received to close this issue for the time being.
- #312
  - The AppIntent interface only allows for a single display name to be returned. However, the main source for the display name is the interop/intents configuration of apps that can resolve the intent - hence, multiple different display names maybe returned, forcing the desktop agent to pick one.
  - This was less of a problem in FDC3's early days when a Desktop Agent would typically be working with a single appD in the control of the desktop developer, allowing them to ensure consistency in the names.
  - However, in situations where the Desktop Agent develop, (multiple) app developers and the desktop owner all differ it becomes far more challenging.
  - Proposed solutions:
    - Alter the AppIntent type to allow a display name per app returned
      - Challenging for a resolver UI or applications using findIntent as they are likely to need a single display name
      - Also a breaking change...
    - Advise that display names are drawn from the 'standard intents.json' file in the standard
      - The display names in that file have not been well curated and vary in form
      - Does not provide a solution for proprietary intents.
    - Deprecate the displayName field and rely on the intents name instead.
      - Intents are already required to be 'recognizable' and their meaning to be 'generally self-evident'
      - Non-breaking (until field is removed in a later version)
  - However, there is a use-case for some descriptive information about a specific apps handling of an intent: describe the precise behavior of the application.
    - This could be handled through by allowing an app to configure a description field in its interop.intents.listensFor metadata (breaking change) and a type that extends AppMetadata in the Desktop Agent API to add the description field (non-breaking).
    - A breaking change after the 2.0 release is undesirable.
  - PR for the change (deprecate display name, explain in documentation that intent name should be used for display) to be worked up and brought back for further review
- #674
  - Discussed use cases for both 'required' apps and 'related' apps in appD config
    - E.g. a micro-frontend related to a larger application, such as a 'CreateOrder' form and an OMS, might express a required relationship for the form to the OMS and a related (optional) relationship for the OMS to the form.
    - Some participants felt that this could also be handled through a 'grouping' field, although it was observed that this loses some of the nuances of teh relationship
    - Some participants expressed concerns that we might be wandering into NPM style dependency relationships.
      - @kriswest argued that such relationships would be far more limited and this metadata is only intended to allow a UI to implement a 'guard rail', rather than any form of hard contract.
      - It was also suggested that this could be achieved via existing interop data (show a warning that no other app is listening for or can raise an intent specified in the apps interop config
        
        @kriswest it is not required that there exist an app to raise or resolve an intent that another app supports, so I believe this is outside the use-case for that configuration.
  - The end of the meeting curtailed discussion, however, it was agreed to table this issue for the time being but to leave it open to revisit later.

Action Items

[ ] @kriswest or volunteer: raise PR to resolve #719
- Add optional/recommended API endpoints for /intents and /contexts to the appD API.
[x] @kriswest close #311
[ ] @kriswest or volunteer: raise PR to resolve #312
- deprecate interop.intents.listensFor[<intentname>].displayName field in appD and AppIntent.intent.displayName in the API types and add explanation of using intent name for display to documentation.
[x] @kriswest prep next meeting agenda to include next issues on list + #807 (added after meeting)

Rolled over from the previous meeting:

[ ] @hampshan Review appD 2.0 record properties and raise an issue to add a link to an app's help documentation (if the moreInfo link is not sufficient). This might be used, for example, to add a help link to window chrome in a desktop agent.