Create User Notification System

[k9ert]

For different reasons, it might be usefull to notify users of events which are asnc, e.g.:

• Rescan UTXO
• Transactions arrived
• PSBT got created (e.g. via REST)
• ...

To implement this, we should create a Notificationsmanager which derives from the GenericManager so that it can persist notifications on disk. So field could be something like:

{ "date": "somedate", 
  "msgid": "some ID e.g. UUID or hashing the msg/user/date",
  "user":"the targetuser-ID",
  "deleted": "boolean which works as a deleted-marker",
  "category": "Maybe warning, error or so",
  "msg": "some message", 
  "firstRead": 
  "when it got read by the user" }

The NotificationManager should then have methods like:

def create_msg(...):

def msgs_for_user(user):
  # returns all the msgs for a specific user

def mark_read(msgid):

def delete_msg(msgid):

From a UI/UX perspective, we should implement this is stages. The easiest stage would be to check the NotificationManager with each and every request from the browser whether new notifications are there and immediately flash them (and delete them).
This could be done via @app.before_request (see controller.py).
In a second stage, we could let the browser poll via API.
In further stages, we could create a UI for managing notification to read older ones and delete them finally.

[relativisticelectron]

The NotificationManager (storing all notifications and managing their status) should ideally be separated from the Notification-UI-Manager (which display the notifications, e.g. Notifications_API (docs), flask -flash, Javascript Notifications). This separation would allow fall-back Notification-UI-manager if the default is not available, or even user-defined preferences.

The specter internal notification data structure could include include also fields like (icon, image, ...). We could stick close to the datastructure: https://notifications.spec.whatwg.org/#api

This NotificationManager and Notification-UI-Manager would be a great building block for: #778 which shows proof-of-concept Notifications_API and Javascript Notifications

[k9ert]

Good points. However, i'm not sure we should implement the full blown API-Spec. Let's start small here but try to stick to the conventions in the Spec as much as possible.

[relativisticelectron]

I started working on this: https://github.com/relativisticelectron/specter-desktop/tree/20220616_notification_system

I included several UINotifications, such as LoggingNotifications, JSLoggingNotifications, FlaskNotifications, JSNotifications.

• Messages can be sent to all or specific target_uis
• Messages can be created from javascript (createNotification) or python (create_and_show) with identical handling. createNotification then sends everything to python create_and_show
• the js_message_box has a callback function (pied back to python), when the close button is clicked
• if Notifications_API (or any other) is not available, it will automatically deactivate Notifications_API and rebroadcast on a lower prio ui_notifications
• Test flash notification (only shows after renter_template)
• callbacks on click and on close
• ui fallback
• delete notification after closed
• how about multiple users logged in at the same time? make it user aware
• change the design of the Javascript notifications
• change Notifications to a dict, and put most things in options sub dict. Allow in the creation to pipe all kwargs through

Call Graph:
This is the rough overview, that javascript createNotification calls python create_and_show, and it calls all relevant target_uis:

Here is shown how the fallback mechanism works:

Image in Notification

To implement this, we should create a Notificationsmanager which derives from the GenericManager so that it can persist notifications on disk.

@k9ert What do you mean by the GenericManager?

[k9ert]

@k9ert What do you mean by the GenericManager?

At some point i refactored all persisting functionality into the persistence-module and AFAIK all persisting functionality (should) use that (otherwise the SPECTER_PERSISTENCE_CALLBACK won't work).

Some managers also have their dedicated single json-file and it's worth sharing that functionality in the GenericDataManager.

    A GenericDataManager manages json-data in self.data in a json file. It's meant to
    be derived from. See OtpManager.
    Supports encrypting individual attributes rest. Expects a Fernet key that is unique
    to the user to encrypt/decrypt.

So currently have two of them using that:

• class ConfigManager(GenericDataManager)
• class DeviceManager:
• class NodeManager:
• class OtpManager(GenericDataManager):
• class ServiceManager:
• class UserManager:
• class WalletManager: