Light-client: I want to get receiving deactivated if the SVT in the UDC is not high enough to monitor my transfers

[christianbrb]

Description

As Chris, I want to get receiving deactivated if the SVT in the UDC is not high enough to monitor my transfers so that I don't run into a risk of losing tokens.

Acceptance criteria

• If the SVT in the UDC is not high enough I cannot receive any more transfers until I have minted and deposited more SVT in the UDC.
• Receiving is enabled by default
• The SDK informs if receiving is enabled or disabled (see https://github.com/raiden-network/light-client/issues/1473#issuecomment-627350833)
• The user sees a warning

User flow

1. The SDK is monitoring if the SVT in the UDC is high enough
2. If the SVT is not high enough
   2a. Receiving will be deactivated
   2b. The user gets a warning, that receiving is deactivated and he needs to deposit tokens to the UDC
   

Design

• Modal popup, with the warning

Monitoring Reward

• raiden.config.monitoringReward: BigNumber | null = null
• raiden.updateConfig({ monitoringReward: parseUnits('5', 18) })

Tasks

• [x] Design (before iteration starts)

[christianbrb]

@andrevmatos I was thinking about implementing this in the SDK. I would like to avoid people using the SDK withouth the monitoring service.

[andrevmatos]

Not sure, I think we can't implement it in the SDK. There're usecases where MS can't be enforced, like always-online cli instances, and on those, there's actually no way to notify the user about it (there's no UI, at most some log.warn spamming), and shutting down the SDK is even worse, as it shuts down the other, unrelated functionality (like sending) and could give bigger problems.
OTOH, we do can implement notifying mechanisms, and then the client's implementation (if possible, e.g. dApp) can react on it by showing notifications or even triggering SDK's shutdown.
Additionally, we could have a config value to enable receiving only if MS is operational (i.e. UDC deposit and params set); this way, incoming transfers would be rejected (as they're today) and the UI is then responsible for bothering the user about depositing if it wants to receive them.

[christianbrb]

@andrevmatos Thanks for your answer :)

We need to ensure, that the SDK is not getting used without receiving transfers getting monitored.

If I understand your comment correctly we would go with:

Additionally, we could have a config value to enable receiving only if MS is operational (i.e. UDC deposit and params set); this way, incoming transfers would be rejected (as they're today) and the UI is then responsible for bothering the user about depositing if it wants to receive them.

In addition, we would need to check if the deposit is high enough.

[christianbrb]

Please assign the "Ready" label after the design has been done, thanks :)

[taleldayekh]

Sure thing!

[taleldayekh]

This would fix #1489 as well.

@christianbrb @andrevmatos @nephix @kelsos

[andrevmatos]

This is done in #1494
https://github.com/raiden-network/light-client/pull/1494/files#diff-dcc43c7ef66fb249deff95ea1ee84c4bR90
This enables receiving by default only if monitoringReward >= udcBalance, and rateToSvt is populated.
We can look into exposing it to the dApp if wanting to notify the user the receiving is enabled or disabled.

[christianbrb]

@taleldayekh Looks nice

I would move this snippet to #1489 and keep the left screen in this issue to keep the discussions focused

[kelsos]

Do we need a new screen for this? Checking the MintDepositDialog it seems that it is self-contained so we could reuse that instead.

[taleldayekh]

I think it needs to be accessible at any time since the UDC token balance is critical. The user should be able to top it up whenever. I don't think it would be a nice solution to have that dialog appear all over the place.

[taleldayekh]

Mockup:
https://xd.adobe.com/view/247b287e-eb36-4445-7fb4-024fdaa71e71-524a/