Specialization to Email-based Account Recovery

[SoraSuegami]

This issue proposes to build new contracts, circuits, and a relayer implementation specialized to email-based account recovery by removing/modifying the current Email Wallet codes.

After launching Email Wallet, we found a huge demand to use email-triggered transactions to recover existing AA wallets. Although extensions can already cover such use cases, the generic nature of Email Wallet forces guardians to do additional processes that are not intuitive, e.g., sending an email to install the account recovery extension. Besides, if the wallet provider operates the current relayer as it is, the guardians can also request the wallet provider to process transactions that are not related to account recovery, imposing unnecessary costs and regulation risks on the provider. For these reasons, I think we should make new protocols and codes specialized to email-based account recovery.

Instead of building the email-based account recovery from zero, we can do that by removing and modifying the specs of Email Wallet. This approach not only reduces the implementation costs but also allows the specialized protocol to keep the same security model. Specifically, we modify the current specs as follows:

1. Simplify the account creation, initialization, and transport as @saleel proposes here.
2. No unclaimed funds/states.
3. No extensions.
4. No RelayerHandler.
5. No guardian's wallet contract.
6. No fee mechanism from the email sender's wallet. It should be implemented by each wallet provider out of the account recovery protocol.
7. No PSI.
8. No price oracle.
9. The supported types in the subject template are only {string}, {uint}, {int}, {amount}, and {address}. The email address in the subject is not supported because unclaimed funds and states are disabled. Note that {amount} can be renamed to {decimal}.
10. The default command is only Guard {address}. It sets {address} to the guarding wallet address for the guardian's Ethereum address, i.e., guardingWallet[guardianAddr] = walletAddr. Note that we assume the guardian uses different account keys (= guardianAddr) for each walletAddr even when the same email address and the relayer are used.
11. The user's wallet contract that can be recovered by the guardian works similarly to the current extensions. In more detail, the wallet contract must implement the following variables and functions. The dkimRegistry variable is used to specify the DKIM registry contract for its guardian.
    • string[][] subjectTemplates
    • address dkimRegistry
    • recover(uint8 templateIndex, bytes[] memory subjectParams, address guardianAddr, bytes32 emailNullifier)
12. When the command in the email, i.e., the first word of the subject, is not Guard, the Email Wallet core contract calls the recover function defined in the wallet contract of guardingWallet[guardianAddr]. Therefore, each wallet can customize subject patterns and parameters by defining its own subjectTemplates and recover.
13. We can also simplify the relayer implementation, e.g., removing codes for unclaimed funds/states, PSI, and the fee mechanism.
14. Our new relayer code will allow the wallet provider to customize the email contents in the relayer's replys, while using the same codes of imap/smtp clients and proof generation. Although the current relayer is implemented in Rust, we can provide typescript APIs for the customization using neon.
15. The relayer will be stateless by requiring the guardian to always contain the account key in the email. To do that, the wallet user stores a pair of the guardian's email address and its account key in the local storage and sends the guardian an email with a mailto link to the email that contains the account key and a specific subject for the account recovery.

[SoraSuegami]

In the above spec, the wallet provider will need to implement the following things:

• (Contract) The subjectTemplates and the process of the recover function for each template.
• (Contract) The mechanism for the wallet user to set and update dkimRegistry.
• (Relayer) The email contests in the relayer's replies.
• (Frontend) A frontend to generate a fresh account key, store it in the local storage, and create a mailto link to the email sent to the guardian.
• (Frontend) A frontend to copy the stored account keys to a new device when the wallet user switches the device.

[Divide-By-0]

Is this done with ether-email-auth? @SoraSuegami