feat: encrypt send data and save it locally to (1) show a history of sends, and (2) help debugging

[mds1]

Once a user sends funds to someone, there is currently no way for the sender to see who the funds were sent to. The only available information is the stealth address it what sent to. There are two main benefits to letting users see a history of where they sent funds:

1. It's very helpful for users to have a history of their sends so they can remember who they've sent funds to
2. When users are unable to receive funds, this helps debug as we can verify what the sender did

To do this, we'd need to encrypt the following data and save it in locally in the browser:

1. The recipient ID entered in the form
2. Whether advanced mode was used (i.e. recipient's pubkey or stealth key registry)
3. The random number?

Options to do the encryption:

1. Require users to sign the message before sending, so we can use their normal Umbra-specific private key for the encryption
2. Only support this feature for wallets that support eth_getEncryptionPublicKey and eth_decrypt RPC methods. Then we'd get their encryption pub key, generate a random private key, and save the corresponding random pubkey along with the encrypted data

For completion, I'll mention the option of storing the data unencrypted in local storage but this seems like a very bad idea. A browser extension could probably just read from local storage and de-anonymize all your transactions

[alexkeating]

I can pick this up. Would we potentially want to store these messages outside of the browser in order to provide a consistent experience across browsers?

[mds1]

@garyghayrat looks like you assigned yourself to this, do you still want to work on it or should we reassign to @alexkeating?

Re implementation, some thoughts:

1. Having a database store the encrypted sends would definitely be better UX across browsers, and more robust since it persists when browser storage is cleared. If we go this route, let's discuss with @apbendi to see if there's any concerns around us having a DB with (encrypted) user info + any tooling preferences
2. Until then, we can save everything locally to start. Local storage might fill up quick (I forget the size limit offhand) so we might want to use IndexedDB instead, but not all browsers support that and some use WebSQL. localForage is a wrapper around all browser storage APIs to make that easy, but it also hasn't been updated in a year
3. We should probably go with option (1) above, i.e. have them sign and use their viewing key to encrypt. But some users might not care about storing their history, and maybe don't like the UX of now having to sign before sending? So two options are (a) make signing the message behave like "logging in" on any page, or (b) give users the option to turn it off and keep the current behavior. I think I lean towards (a) right now to keep it simpler, curious to get thoughts from @apbendi too

[garyghayrat]

@mds1 Let's assign it to @alexkeating . Thanks for picking it up!

[alexkeating]

That makes sense, go with option 1 for now. I am a little unclear by what you mean by "make signing the message behave like "logging in" on any page" in terms of UX.

[mds1]

Ah sorry, to clarify I mean:

• Right now, signing a message only happens when you view a page that requires it, and I believe it happens lazily (i.e. we don't prompt for a signature until it's needed, on the Receive and Setup pages)
• But perhaps we change this to just requesting a signature at the same time a wallet is connected. But on second thought this might be bad UX because if your wallet it autoconnects its not great to ask for your signature right away.

So maybe we stick with requesting signature lazily, and just request when they click the send button. This might be confusing for existing users though since it wasn't required previously, so we should also add a corresponding FAQ question and maybe som info/help text?