Provide Notification API's

[lspiro-Tick42]

Enhancement Request

Use Case:

Now that most platforms support Notifications, it seems sensible to allow FDC3 Application raise and participate in Notifications using FDC3 API calls, which of course container agnostic,

If we do not have FDC3 API calls, FDC3 applications will need to use Platform specific API calls, which limits the usefulness of FDC3.

For example:
An Application may wish to raise a Notification to attract the user's attention to some event that has occurred. There are of course multiple ways in which a Notification can be displayed, by providing an FDC3 API to raise the Notification , all Notifications can be managed by the Desktop Agent, ensuring concistency between applications.

[lspiro-Tick42]

We would also propose adding an optional mechanism in which an Intent could be registered to handle certain types of Notification, one way to do this would be to associate a notification with a data context when it was being raised.

[kriswest]

Although, the Web Hypertext Application Technology Working Group (WHATWG) has developed a very capable Notifications standard for web browsers](https://notifications.spec.whatwg.org/), more details on which are available on MDN, we also see use-cases for standardized notifications features in FDC3, where FDC3 can add value through its existing standardized functions and types:

1. FDC3 should be language agnostic. By relying on an external browser standard for notifications we exclude other languages that might be supported by a desktop agent (mainly Java and .Net).
2. Notifications should be actionable. In the web API, the application creating a notification can add an event listener to it to handle clicks on particular actions. However, with access to an FDC3 Desktop Agent we might raise an actionable notification and use interop to have other applications resolve any clicks on actions or have multiple applications receive context from it.
3. Applications may wish to receive a filtered feed of notifications to process or allow the user to interact with, in addition to the default notification UI.
4. Applications may wish to dismiss notifications they did not issue, but have handled already (e.g. a new order notification raised by one system might be dismissed by another after the order has been handled.

Hence, three of the four main concepts in FDC3 can be applied to notifications, allowing applications to interoperate through notifications: The Desktop Agent API for submitting them and broadcasting to a channel as an action, intents to describe actions you might wish to perform and context to pass to the actions as data.

Regarding the form that any such addition to the API would take, the web API for notifications would be good to draw on for inspiration. To write something in a similar form would necessitate coming up with a new object to describe a notification. This would likely contain a context Object as data. If it is also a context object that would allow us to use to channels to share information about/feeds of notifications (use-case 4 above)

Raising an intent to submit a notification may not be a natural thing to do as we don't expect other applications to handle notifications directly or the user to use a resolver UI to select which application should handle the notification (although we would do this for handling an action specified as an intent). Hence, I would suggest a new Object describing a notification and a new Desktop Agent call for submitting one. Overall the surface area of the proposal could be lower than the web API as FDC3 already standardizes many action functions (e.g. fdc3.raiseIntent, fdc3.raiseIntentForContext, channel.broadcast etc.) that can be reused.

How about something along the lines of:

interface Notification extends Context {
  id: string;
  type: "fdc3.notification"
  title: string;
  body?: string;
  source?: string //could be filled out by desktop agent automatically
  icon?: URL;
  image?: URL;
  actions?: Array<NotificationAction>;
  isRead: boolean;
  isSnoozed: boolean;
  requireInteraction?: boolean;
}

enum ActionType {
  "raiseIntent",
  "raiseIntentForContext"
  "broadcast",
  "dismiss",
  "snooze"
}

interface NotificationAction {
  action: ActionType;
  title: string;
  context: Context;   //Context to be used by action - placed here in case different actions should use different types
  intent?: string;       //required for raiseIntent
  channel?: string;   //required for broadcast
}

interface DesktopAgent {
  ...
  raiseNotification(notification: Notification): Promise<void>;
  ...
  }

To share feeds of notifications we could use channels - however, we may wish to complete discussion of the concept of feeds first as its likely that applications would want to filter notifications. Hence, it would make sense to request a notifications feed, rather than simply connect to a firehose of all notifications.

[kriswest]

• Balance of opinion at Standard WG Meeting - Oct 28th, 2021 #481 is that this issue is within the FDC3 charter and there is interest in proceeding with it.
• Proposals to be raised or further commentary on issue before adding to a future meeting agenda (as there are several ways to approach implementation).
• Can be raised at the Channels, Feeds and Transactions discussion group