Notification types

[Dexagod]

Notification types

Not all notifications are the same.

• Essential
  • Important that message is received and processed.
  • e.g. chess game moves in a chess application using LDP.
• Email
  • Can be filtered, …, but user normally reads relevant information.
• Desktop notification
  • Quick popup with information
  • Can be clicked away / ignored without consequence
• ...

There are many kinds of notification, and different kinds of notifications will require different actions.

• Can the notification be deleted after processing / showing?
• Should the notification be processed?
• Should the notification be shown to the user?
• Should the notification be kept indefinitely as backlog?
• ...

Concrete questions

• How do we handle the importance of a notification?
  • Tagging notifications?
    • May be deleted
    • Must be processed
    • Can be show to user
    • Contains sensitive informations that should not be readable for other applications?
    • ...
  • Using multiple inboxes
    • Have different applications utilize different inboxes
      • Application itself responsible for its own notifications.
      • No danger of other applications interfering with its notifications.
      • No danger of other applications snooping in on the contents of its notifications!!!!
      • BUT: other applications can not? use these notifications
        • It may be useful for multiple calendar apps to process a notification that needs to be added to the calendar!
        • Maybe these notifications should then be sent to the inbox of all relevant applications?
  • Using inbox rules (filters)
    • Rule based classification of notifications
    • Applications can retrieve their own / relevant notifications with specific rules.
    • issue of Ordering of processing
      • What one application processes notifications and removes the rest.
      • Next application will never be able to retrieve relevant notifications.
    • Again issue of Sensitive information in notifications.

[pietercolpaert]

An important aspect seems to be “when can I safely delete a notification”? Probably we should standardardize retention policies?

• Type 1: can always be deleted after a TTL
• Type 2: can be deleted when processed by an app that’s part of a WAC
• ... More?

[RubenVerborgh]

For me, notifications are ephemeral. They are nudges or pings. They are alarms. They go off to point you into the direction of something else—and it's that something else that should have the retention policy.

First of all, I think behavior should be customizable for sure. So there are different strategies for dealing with notifications.

Second, the strategy that I recommend, and the one I want to investigate, is "delete after reading" AKA the "inbox zero" policy. A notification should trigger a (simple or compound) action, and the moment that action has been triggered, the notification is removed. Every notification should only be processed once.

If multiple actions are required, then new notifications should be spun off (likely, but not necessarily, to other inboxes).

Such a message-passing design avoids a lot of headaches where things linger around, the drawbacks of which we have already experienced in the past.

Third, purely for GUI (or debugging) purposes, notifications could be archived to display the act of having been notified. Kind of when you click the bell icon here in GitHub. However, then they are rather a past action log than notifications, and there is no inherent need to keep them in notification form.

[pietercolpaert]

Agreed! On top of that vision, it would be interesting to see a LDN as just any other resource, and standardize a description of what you can expect from a certain container. E.g., what is now known as a notification inbox may be “this ldp:Container is open for any agent to write towards, and a notification can be removed from the moment any application marks it as being read or processed”.

Another ldp:Container, for example for an air quality sensor in your home, may decide to remove the data from the moment its 1 day old, regardless of whether the data has been processed by an agent.