Desktop Agent Bridging Discussion group 26th Oct 2022

kriswest commented 2 years ago

Group overview

Discussion group for developing proposals for producing bridges between FDC3 implementations (aka Desktop Agents), allowing applications running on one Desktop Agent, to integrate with FDC3 applications running on a second Desktop Agent for the same user.

The interop between applications running on different Desktop Agents aka Platforms would ideally cover

Channels
Raising and resolving Intents
Launching Applications

Relevant issue tags

Current open issues that relate to the above concepts with the label:
The original issue is now a github discussion where content can be added and this issue discussed:
544

Meeting Date

Wednesday 28th Sept 2022 - 9am EST / 2pm BST

WebEx info

Meeting link: https://finos.webex.com/finos/j.php?MTID=m55d4aa79e148c948bf53163690e74fee
Meeting number: 2558 920 8729

More ways to join

Join by video system:
- Dial 25589208729@finos.webex.com
- 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: 2558 920 8729

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.

Agenda

[x] Convene & roll call, review meeting notices (5mins)
[x] Review action items from previous meeting (5mins)
- 822
[x] Brief update on the status of the Backplane contribution and discussion of next steps (5mins)
[x] Review updates to the proposal (35mins)
- Current proposal #634
- Preview: https://github.com/finos/FDC3/blob/544-Desktop-Agent-Bridging-Proposal/docs/api-bridging/spec.md
- Changes from last time:
  - Changed meta.source -> meta.sources and errorSources in response messages to allow messaging to user when DAs don't respond
  - Adjusted pseudocode for bridge message handling for cases where we receive a timeout but also have responses from other agents to process.
  - Exempted PrivateChannels from some cases where bridge messages are not normally generated (but should be for PrivateChannels).
  - Classified message exchanges by type.
  - Completed message exchanges for broadcast, findIntent, findIntentsForContext and raiseIntent.
- New changes:
  - Completed message exchanges for open & findInstances.
  - Added advice on whether other agents report to users on connect/disconnect events? (SHOULD)
  - Added/consolidated advice on handling error responses from Desktop Agents in Messaging protocol section
- Open questions:
  - Confirm handling of error responses: Desktop Agent API should always return JavaScript errors. However, you can't recreate an error object in javascript - do just send the error message? (It should be possible to find the stack trace in the Desktop Agent in which the error occurred)
  - On a findIntent call, should the requesting Desktop Agent send its own findIntentResult to the bridge and receive its own response back (collated with other findIntent responses), or should it receive the responses from the bridge and augment its own response without sending it to the bridge?
[x] Work outstanding to complete draft/contribute to FDC3 (5mins)
- Message exchanges for PrivateChannels
- Expand on how the DAB should create the JWT token (and its claims, which must change to avoid replay attacks) which it sends out in the hello message for DAs to validate.
- Validation of message exchanges by participants
- Prepare final PR
- Create JSON schema/generated Typescript types for message exchanges
- Add new terms and acronyms to FDC3 glossary and ensure they are defined in this spec's introduction
- Add new errors to Error enumerations specified in this proposal
- Add RFC 4122 - https://datatracker.ietf.org/doc/html/rfc4122 to FDC3 references page
- Upgrade FDC3 website to docusaurus 2 (or export diagrams to PNGs to go in docusaurus v1 site
[x] AOB & Adjourn (5mins)

Minutes

A brief was provided on the status of the Backplane contribution into FINOS (recommended for acceptance by FDC3 maintainers and FINOS TSC).
- @robmoffat and @Aaron-Haines /NWM will be meeting regarding the acceptance of the contribution and next steps soon.
@kriswest briefly demoed how participants can add comments to the current PR by commenting on specific topics or lines
@kriswest gave an overview of changes to the proposal over the last two months
- Error handling
- For collated responses from the bridge, errors from a subset of desktop agents may not result in an error from the bridge back to requesting agent - this is because errors (e.g. NoAppsFound) may be a normal response, but once collated with responses from other agents there may be options to return. Desktop Agents returning errors are logged in the errorSources element of the response message.
  - @timjenkel Asked if the proposal is considering forwarding on the actual error messages in these cases.
  - @kriswest agreed that adding more error details may be useful for debugging - we'll add an errorDetails: string[] to response messages to record these.
  - AlexD (Citi) asked why, for findIntent, we are returning errors instead of an empty array.
  - @kriswest: I believe that is what is defined and intended in the FDC3 spec for findIntent, to match the same error returned by raiseIntent in that situation (ResolveErrors.NoAppsFound). However, this isn't super clear in the specification currently.
  - Group discussion - However, there is probably a discussion to be had in the Standards Working Group on this, as its not clear and could be interpreted multiple ways - this has an impact on conformance testing and implementations within apps.
    - @kriswest Noted that the wording of the findIntent in the spec could be clarified (more aligned with the raiseIntent wording)
    - @nkolba Noted that for raiseIntent it does makes sense for an error to be returned since there is a UI resolver that must be shown. findIntemt could probably return an empty array if nothing is found, however, it would require a revision to the standard.
- A message exchange for getAppMetaData is needed.
- A recommendation (SHOULD) for Desktop Agents to provide a visual notification to the user on connection to/disconnection from the bridge (for any agent, including themselves).
- @Vivek-NatWest This "SHOULD" might be better as a "MUST"
  - use-cases mentioned: state may get corrupted when a user does not wait (on startup of their DA) for connection to bridge and interacts with Desktop Agent resulting in channel state changes - a connection to the bridge happens in the background and a user can have 2 DAs working independently before the bridge starts.
  - @kriswest The requirement for the bridge to handle steps 3-6 of the connection protocol atomically, and a DA to process the ConnectedAgentUpdate message atomically should state is NOT corrupted.
  - @kriswest Requiring notifications to user may be a good idea, which the proposal makes a strong recommendation for. However, turning it into a requirement is difficult:
  - Legacy apps (modelled as DAs and connecting to the bridge, as demonstrated in the Backplane contribution demo) may have some issues providing visual notifications (or even being updated to that effect)
  - Notifications are hard to validate without manual compliance validations
  - Consent was given to leave this as a SHOULD
- @kriswest asked the group if there are strong feelings on DAs making requests also having to forward their own answers to the bridge. E.g. for a findIntent call, should the requesting Desktop Agent send its own findIntentResult to the bridge and receive its own response back (collated with other findIntent responses), or should it receive the responses from the bridge and augment its own response without sending it to the bridge, the latter being the current proposal.
- No objections to current approach (bridge does not forward request back to requestor, requestor consolidates responses from bridge with its own locally).

Action Items

[x] @kriswest @tpina Add an errorDetails; string[] to the response message schema to collect up error messages returned by Desktop Agents (ordering to match errorSources) for collated message workflows
[x] @kriswest Raise an issue for the SWG to consider clarifying expected behavior of findIntent (in documentation) when no apps are found.
[x] @kriswest @tpina Add a message exchange for getAppMetaData to proposal
[ ] @kriswest @tpina complete PrivateChannel message exchanges
[ ] ALL review message exchanges completed and provide any necessary feedback

Untracked attendees

Full name	Affiliation	GitHub username

tpina commented 2 years ago

Tiago Pina / Cosaic

kriswest commented 2 years ago

Kris / Cosaic 🚀

Julia-Ritter commented 2 years ago

Julia / FINOS

timjenkel commented 2 years ago

Tim / Wellington

pierreneu commented 2 years ago

Pierre Neu / Symphony

mistryvinay commented 2 years ago

Vinay Mistry / Symphony

WatsonCIQ commented 2 years ago

Chris Watson / Cosaic 👋

manish-nwm commented 2 years ago

Manish / NWM

RandallDang-Citi commented 2 years ago

Randall / Citi

Vivek-NatWest commented 2 years ago

Vivek / Natwest

luiemilio commented 2 years ago

Luis / OpenFin

Aaron-Haines commented 2 years ago

Aaron / Natwest

Julia-Ritter commented 2 years ago

Untracked attendees:

Nick k / Connectifi
Alexandru Dumitru / Citi
Qiana Chen/ Citi
Dimiter Georgiev / Symphony

kriswest commented 1 year ago

FYI the findIntent docs were clarified by the Standard Working Group last month:

https://github.com/finos/FDC3/issues/841

If the resolution fails, the promise MUST be rejected with an Error Object with a message chosen from the ResolveError enumeration. This includes the case where no apps are found that resolve the intent, when the ResolveError.NoAppsFound message should be used.

https://fdc3.finos.org/docs/api/ref/DesktopAgent#findintent

finos / FDC3