Notifications service

[mhluongo]

The notifications service should do two things

• [ ] Publish unread app-level notifications via Redux.
  • ... including notifications that have been pushed by the dev team, sourced from... somewhere.
  • It's unclear whether the service should keep track of what has been read / unread. I lean toward leaving that as a detail for the frontend / only storing read state in Redux.
• [ ] Publish browser-level notifications in addition to / sometimes to the exclusion of an app-level notification. It should do this following the existing additional entrypoint pattern of browser-ui.js, interacting directly with the browser, rather than passing this info through Redux.

The hardest part of writing this is figuring out what an app-level notification is, and deciding what sorts of things should be a browser-level notification. Currently, there's some consensus that the latter includes changes to any transaction that the wallet has sent (eg a failure, dropping from mempool, or a confirmation).

@VladUXUI if you can attach any / all notification screens and thinking on the UX here it'll make this one easier to figure out.

Refs #106.

[VladUXUI]

[VladUXUI]

I've used mostly dummy content for the notification itself. What i think should be app notifications are notifications that are: 1 - Not triggered by this user (receive, dao proposals, liquidations...) 2 - Triggered by user, but have an un-expected outcome. (Tx: failure, dropping from mempool...) I don't see tx confirmation in-app notification as being particularly useful.

Would it be safe/easy to show all notification as browser notifications? but keep the ones we think users will care about in our notification center?