Question: App-specific context metadata

[pierreneu]

Question Area

[ ] App Directory
[ ] API
[X] Context Data
[X] Intents
[ ] Use Cases
[ ] Other

Question

Right now Symphony raises intents such as ViewInstrument, with a fdc3.instrument context, allowing the action to be performed in another app that is configured to handle that intent and context pair.

However, we'd like to include more information (metadata about the interaction) in the context data, such as the chat room id, message id, user email/id etc. as this might be useful to the receiving app. However, adding it to the instrument object is not semantically correct (it doesn't relate to the instrument.

This additional metadata might be added not only to the ViewInstrument intent, but any outgoing intents coming from out application.

Options we think of:

1. Add custom properties to the fdc3.instrument e.g. com.symphony.originatingchatroomid. This is not semantically correct as custom properties in the standard are reserved to identifiers and the metadata relates to the interaction rather than the instument/security.
2. Add an optional object nested in the fdc3.instrument. It can be either something specific to the type of context such as fdc3.chatinfo or something much more generic such as fdc3.appcontext. However, this has the same issue as the first suggestion.
3. Change the context type to a new context type that would wrap a fdc3.instrument. This however breaks interoperability with apps that are only listening to ViewInstrument(fdc3.instrument)
4. Add properties to the ContextMetadata that the receiving app MAY receive (Originating App Metadata). ContextMetadata is currently supplied by the Desktop Agent, we would need a way to supply additional information to the Desktop Agent to augment it.

Based on a side discussion with Kris, it seems that the current standard may not provide a perfect solution.

[kriswest]

This seems like a use-case that others would run into (wanting to provide additional, optional metadata about an interaction). Wrapping context types to do this does indeed break the coupling between apps (which is based on specific intent/context type pairs) and adding the metadata into context types affects any that you use (including non-standard proprietary types) and does not seem practical.

Hence (as discussed off to the side), what I'd propose is that we extend ContextMetadata so this can contain some additional fields (we wrapped the only field it currently carries, AppIdentifier, in ContextMetadata for exactly this sort of future-proofing). We could then extend other functions with a new optional argument to include that metadata, e.g.
broadcast(context: Context): Promise<void>;
changes to:
broadcast(context: Context, sourceMetadata?: Context): Promise<void>;

raiseIntent(intent: string, context: Context, app?: AppIdentifier): Promise<IntentResolution>;
changes to:
raiseIntent(intent: string, context: Context, app?: AppIdentifier, sourceMetadata?: Context): Promise<IntentResolution>;

and ContextMetadata changes from:

interface ContextMetadata {
  /** Identifier for the app instance that sent the context and/or intent. 
   *  @experimental 
   */
  readonly source: AppIdentifier;
}

to

interface ContextMetadata {
  /** Identifier for the app instance that sent the context and/or intent. 
   *  @experimental 
   */
  readonly source: AppIdentifier;
  /** Additional optional metadata that an app may choose to send with a broadcast context or raised intent.
   *  For example to provide source information from within the source application (e.g. from which chat room
   *  (in a chat app) or order (in an OMS) did the message originate from.
   *  @experimental
   */
  readonly sourceMetadata: Context;
}

You could then pass in your ChatRoom context as the sourceMetadata.

ContextMetadata/Originating app metadata is currently an optional feature (there is an issue open to consider whether that should be required, see #735). But it looks like adding this wouldn’t break anything and could make it more useful… The additional §sourceMetadata§ would become available but the interaction is not dependent on it - making it optional.

However, it is an API change so it’d have to happen in an FDC3 2.1…

[nemery-flextrade]

+1 on this as a concept. Especially useful for case Pierre mentioned whereby downstream systems can pick up chat IDs for subsequent messaging but I can see it being useful in other situations as well.

[robmoffat]

It's not really clear from the description exactly what the use case is here. It just says that there might be extra data useful to the receiving app. It would be really handy to have an exact example of this so that I can think about it the same way. At the moment, I am wondering a bit why a charting application would want to know anything about chat rooms, for instance.

Leaving aside any changes to FDC3, I think this is what you could do at the moment:

setup

1. ChartIQ exports the ViewInstrument intent for a fdc3.instrument context.
2. Symphony exports a PublishToChat intent for the fdc3.chart context.

in action

user wants to turn a ticker into a chart and publish that chart into a chat room

3. Symphony is set up to broadcast context of the fdc3.chat.initSettings that the user is currently in, as the user navigates between chats.
4. A user is looking at an instrument ticker in a Symphony chat, and raises the ViewInstrument intent, with the fdc3.instrument context for that ticker.
5. ChartIQ shows the instrument's chart.
6. The user then raises the PublishToChat intent, which uses the fdc3.chart and also the last broadcast fdc3.chat.initSettings context.

There are a few problems with this:

• First, symphony is going to be broadcasting chat/room contexts information a lot. I'm not entirely sure this is a bad thing, since it would let other applications know which chat the user is engaged with.
• Second, there is no linkage from the chat room to the instrument, so you don't necessarily know if the instrument is coming from the latest broadcast chat.
• Third, the latest broadcast chat might change while you're viewing the instrument in ChartIQ. So, PublishToChat is going to do different things depending on which chat you're looking at when you call it.

Am I on the right track understanding this?