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

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

[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?

[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.