Notification Center High Level Spike

[NeOMakinG]

Open questions:


• Should we handle any TX in coming or only ShapeShift interface actions?

• Should we order by updated date or created date?

• Should we change notifications background depending on if users have seen the notifications (aka opening the notification center)

• Can we end up in a state where we spam our nodes to get txs update because we need to fetch a lot of TXs for some reasons?
• Do we want notifications push? It would clearly require a backend to track any TXs and sending back updates from push channels

If we want to handle every actions:



We could handle them using the transactions websocket, the same way we push TX to the historySlice, we could create or update notifications at this point.
Thought it would mean we would need to be extra careful at parsing absolutely every TXs or we might end up with TXs we don't really know

If we want to handle ShapeShift actions only:



We could push the notifications in a granular way, where every actions are executed, push or update any notifications:



Example:

inside useTradeExecution, inside any execution events, create or update notifications.
Inside any claiming methods, create the notifications, when claim is successful or fail, update it
Inside any deposit actions, create the notification, update the status on execution update


Streaming handling:



Those could be looking like easy, but they are effectively hard to manage:


• If the user wait for the stream to be executed, useStreamingProgress would give the data to update the notifications

• If the user close the app or navigate somewhere else in the app, we will loose update for this particular notifications

• If a swap tx status isn't completed, but the notification drawer is closed, we need to update the notification regardless

• • The only thing we need is the txHash and status, for this we could poll outside of this scope (having a hook like the useTransactionSubscriber one, having a service worker?

For simplicity, I would probably go without the service worker, to avoid pushing an extra layer of complexity to the app regarding the current workforce of the engineering team, and I don't see any downside for a global service polling for streamings and pulling pending txs as long as current polling tx queue shouldn't be so big. 
Also it fixes a known problem where pending TXs that users didn't see and has gone out of the last tx history page are not updated, this system would update them naturally with the poller.

Storage growing over time



We will end up with tons of notifications as local storage, and those will end up filling the memory as hell, making the store super big



As a decentralized interface, we probably want to avoid adding a new backend layer specially for the purpose of notifications (looking at the pita of the tx history slice), but having a backend for both could add great benefits:

• Being able to use Push notifications (mobile and whatever)
• Update notifications status without the need to be on the interface (reduce the polling weight)
• Store notifications regardless of your device (phone, desktop, new phone...) (we could use a "decentralized" protocol for that such as Push Protocol)

I think our role is not to store them for years, we could probably introduce a pruning system, removing old TXs after a certains amount of time + tx number


Architecture proposal schema

[gomesalexandre]

Great spike @NeOMakinG 🐐! Wall of text incoming - touching on the main points, disambiguating things and bringing a few more qs in.

Replies to open qs.

• Should we handle any TX in coming or only ShapeShift interface actions?


As we've discussed, there is potentially more to that than just Txs (things like new features, app updated, etc), but indeed, swaps are the guts of this.
I'm not sure yet whether or not we want Txs there, though the direction @reallybeard and @twblack88 seem to have went on on this is this would also exist as a drop-in replacement for the Tx drawer. To be confirmed, but I'd personally be in favour of ditching the Tx drawer and not having Txs here, only swaps. The whole intent of this feature is to make things more user friendly, and to represent actual actions instead of Txs in that new drawer (e.g for a swap, you'd see it as one entity, vs. many Txs which may come back at diff times and are not linked together, which just look off and not integrated).

Also, push notifications for things like new features would be amazing to have!

Just to disambiguate things here, a swap is not a Tx, and may not even contain an inbound one for observability purposes, e.g a CoW swap is a message signing. We should ensure that we don't store things by Txid but rather by swapId as far as swaps are concerned.

• Should we order by updated date or created date?


Definitely in favour of the latter, from a user perspective an updated notification is effectively akin to a new notification (just represented as a single one with updated state)

• Should we change notifications background depending on if users have seen the notifications (aka opening the notification center)


Not sure what we mean with this one, can you add more deets? 🙏🏽

• Can we end up in a state where we spam our nodes to get txs update because we need to fetch a lot of TXs for some reasons?

Ideally not - we should be able to reuse existing logic for most things, and most of swaps status logic is actually happening with swapper APIs themselves, though there is a fair share of introspecting Txs themselves (checkEvmSwapStatus) which we do it for some swappers on simple single-chain swaps

• Do we want notifications push? It would clearly require a backend to track any TXs and sending back updates from push channels

See first point, think that would be amazing to have for mobile users as discussed 🙏🏽

re: we should be able to reuse existing logic for most things

Adding a bit more details on this one, at the end of the day we already have the logic for all that we're going to do here, but we're going to have new callsites and pollers.

If things get spewy and rate-limited/affected by perf, we could potentially think about making the notification a source of truth for things, meaning instead of polling/fetching from current callsites, we would rely on the notification center.

re: If we want to handle ShapeShift actions only:



Example:

inside useTradeExecution, inside any execution events, create or update notifications.
Inside any claiming methods, create the notifications, when claim is successful or fail, update it
Inside any deposit actions, create the notification, update the status on execution update


re: the point above, do we want the current callsites to have full responsbility for the notification polling, or do we want to rather go in a service direction, which would be responsible for long-polling (or ws) notifications? Think the latter makes a lot more sense, precisely because of the fact that users may close whichever modal/tab/change route and lose polling, but also as mentioned above to avoid duplicating callsites if we were to use this as a source of truth (e.g for swapper, for swap statuses)

re: Streaming handling:



If the user close the app or navigate somewhere else in the app, we will loose update for this particular notifications

For simplicity, I would probably go without the service worker, to avoid pushing an extra layer of complexity to the app regarding the current workforce of the engineering team, and I don't see any downside for a global service polling for streamings and pulling pending txs as long as current polling tx queue shouldn't be so big. 
Also it fixes a known problem where pending TXs that users didn't see and has gone out of the last tx history page are not updated, this system would update them naturally with the poller.

I think the app close is the main thing product-wise, though I agree, for simplicity purposes, may not make sense at first. Though if we go with push notifications, that would be a requirement.

That also echoes the service idea I mentioned above, which you seem to be aligned on. If we don't leverage existing callsites to push (which assume you keep the thing open and negates the benefits of notifications) but rather let a polling service handle this, then navigating somewhere isn't an issue.
Same thing as above though, we may or may not want to use notifications as new source of truth (i.e there would be no need for something like useStreamingProgress() anywhere else then in the service)

re: Storage growing over time



• How bad do we think it would be to store many notifications in terms of perf? Say 100, or 1000 swaps (assuming swaps only)
• Do we want to introduce an idea of expiration for a given notification?

Think the perf killer would be if we got that wrong and kept polling things we shouldn't, so instead of polling active, we'd poll all the historical notifications, so we'll have to ensure the logic is solid and really polls what's relevant - if we do so, I don't think storage is a concern, though I'm not opposed to the idea of pruning either, if we find good heuristics!

[NeOMakinG]

but I'd personally be in favour of ditching the Tx drawer and not having Txs here

I would probably not add absolutely every TXs to the notification center too or we will spam the notification center making it less readable and user friendly

Definitely in favour of the latter, from a user perspective an updated notification is effectively akin to a new notification (just represented as a single one with updated state)

Would make sense, we would probably need for some different kind of notificiations then : Swap broadcasted, Swap validated, Swap errored

Should we change notifications background depending on if users have seen the notifications (aka opening the notification center)


Some more precisions: we need kind of a way to show from a UX perspective that the said notifications hasn't been read yet, if you open the drawer, notifications you didn't see yet should differ a little bit

I think the app close is the main thing product-wise, though I agree, for simplicity purposes, may not make sense at first. Though if we go with push notifications, that would be a requirement.

It would only be a requirement if we decide to send notifications outside of shapeshift but how much users are enabling notifications on their computer?

Push notifications makes sense from a mobile point of view (from my own opinion), having notifications on desktop looks like an edge case, meaning the service worker would be so useful considering we can query notifications from the backend at shapeshift load time

I'm curious about the shape of the service you are thinking about, as we don't have any source of truth for pulling notifications outside of shapeshift

[gomesalexandre]

I would probably not add absolutely every TXs to the notification center too or we will spam the notification center making it less readable and user friendly

Point is, we can probably do with skipping Txs altogether and keeping only actions there (e.g but not limited to swaps, which may or may not identified by a Tx, though swapIds do not even contain a txId FWIW). Think that becomes more of a product q. at this point, but I don't see any benefit in having Txs in a notifications drawer personally, that's very spewy and the responsibility of Tx drawer.

Would make sense, we would probably need for some different kind of notificiations then : Swap broadcasted, Swap validated, Swap errored

If we take swaps as a starting point, it could be even easier than having variant notifications: a "notification" in this case could just mean a swapId existing, meaning that then we'd be free to do whatever we want with it and be reactive (i.e react to progress).
Simpler notifications could obviously be represented with a shape like {type: Type, message: string} of sorts but then for more complex ones like swapper, the shape doesn't have to be more complex, all it would take is some notification-specific properties {type: SwapNotification, message: 'Swap 1 ETH for FOX', swapId: 'uuid1234'}, and we would use the combination of type (SwapNotification) and swapId to:

• introspect the status of the swap using polling or store react
• decide which component to render
• render different states (doesn't have to even be in the notification itself, since we'd be able to get that from the swap)

Point is, if we can keep the notifications simple silly and discriminate/switch to move the logic to relevant bits for each notification type, that'd probably be a win

Some more precisions: we need kind of a way to show from a UX perspective that the said notifications hasn't been read yet, if you open the drawer, notifications you didn't see yet should differ a little bit

Absolutely aligned with that yeah! Though one point is we'll want to ensure not all notifications have the concept of "unread" i.e longer-lived ones that can take different stages like swap are not "notifications" by itself in all stages: we probably don't want to notify of swap started (it was triggered by a user action), OTOH, swap complete is a notification! We'll probably want to ensure it is considered as one unit, i.e not every stage of a swap should trigger a notification IMO - you should always be able to access the in-progress swap from the notification center, but only completion (or something needing action) should be a notification in the usual sense.

Which also prompts for "What is a notification (2022)". Think there are two kinds here, those that are actual notifications (should have a matching toast and eventually go into the drawer as "Read") and those that don't toast an actual notification and are more representative of an in-progress action you can quickly go back to.

It would only be a requirement if we decide to send notifications outside of shapeshift but how much users are enabling notifications on their computer?

I think that's a perfect transition from the previous point: if we want to do push notifications, that's a total architecture change as, AFAIK, we would have to have them from a backend of sorts, and all the assumptions re: us building some service in the app that can handle notification responsibility is basically useless?

I do agree that it would be much better to have, although would only really ever be the actual notifications (e.g swap complete). I'm wondering if moving such logic away to a back-end isn't just too crazy of a lift?