Add fronend description.

README.md

@@ -13,7 +13,7 @@ In social recovery, the wallet owner must appoint trusted persons as guardians w
 However, not all such persons are necessarily Ethereum users.
 Our solution mitigates this constraint by allowing guardians to complete the recovery process simply by sending an email.
 In other words, any trusted persons can work as guardians as long as they can send emails.
-Using the ether email-auth SDK, we construct a library and tools for any AA wallet providers to integrate our email-based account recovery just by implementing a few Solidity functions!
+Using the ether email-auth SDK, we construct a library and tools for any AA wallet providers to integrate our email-based account recovery just by implementing a few Solidity functions and a frontend!
 
 ## Architecture
 In addition to a user and a smart contract employing our SDK, there is a permissionless server called Relayer.
@@ -111,26 +111,26 @@ As a representative example of applications using our SDK, we provide contracts
 
 Specifically, we expect the following UX. **Notably, the guardian only needs to reply to emails sent from the Relayer in every process.**
 1. (Requesting a guardian 1/4) A web page to configure guardians for email-based account recovery requests the wallet owner to input the guardian's email address and some related data such as the length of timelock until that guardian's recovery request is enabled. 
-2. (Requesting a guardian 2/4) The frontend script on the web page randomly generates a new account code and derives the guardian's Ethereum address from the input guardian's email address and that code. 
+2. (Requesting a guardian 2/4) The frontend on the web page randomly generates a new account code and derives the guardian's Ethereum address from the input guardian's email address and that code. 
 It then requests the wallet owner to broadcast a transaction to register the guardian request into the wallet contract, passing the derived Ethereum address and the related data (not the private data such as the email address and the account code).
-3. (Requesting a guardian 3/4) The frontend script also sends the wallet address, the guardian's email address, and the account code to the Relayer. 
+3. (Requesting a guardian 3/4) The frontend also sends the wallet address, the guardian's email address, and the account code to the Relayer. 
 4. (Requesting a guardian 4/4) The Relayer then sends the guardian an email to say "The owner of this wallet address requests you to become a guardian".
 5. (Accepting a guardian 1/3) If confirming the request, the guardian replies to the Relayer's email.
 6. (Accepting a guardian 2/3) The Relayer generates an email-auth message for the guardian's email and then broadcasts a transaction to pass it to the wallet contract.
 7. (Accepting a guardian 3/3) If the given email-auth message is valid, the wallet contract deploys an email-auth contract for the guardian and stores its address as the guardian.
 8. (Processing a recovery for each guardian 1/6) When losing a private key for controlling the wallet, on the web page to recover the wallet, the wallet owner inputs the wallet address to be recovered, the guardian's email address and a new EOA address called owner address derived from a fresh private key.
-9.  (Processing a recovery for each guardian 2/6) The frontend script on the web page sends the input data to the Relayer.
+9.  (Processing a recovery for each guardian 2/6) The frontend on the web page sends the input data to the Relayer.
 10. (Processing a recovery for each guardian 3/6) The Relayer then sends the guardian an email to say "Please rotate the owner address for this wallet address to this EOA address".
 11. (Processing a recovery for each guardian 4/6) If confirming the requested recovery, the guardian replies to the Relayer's email.
 12. (Processing a recovery for each guardian 5/6) The Relayer generates an email-auth message for the guardian's email and then broadcasts a transaction to pass it to the wallet contract.
 13. (Processing a recovery for each guardian 6/6) If the given email-auth message is valid, the wallet contract updates states for the recovery.
-14. (Completing a recovery 1/2) When the frontend script finds that the required condition to complete the recovery holds on-chain, e.g., enough number of the guardian's confirmations are registered into the wallet contract, it requests the Relayer to complete the recovery.
+14. (Completing a recovery 1/2) When the frontend finds that the required condition to complete the recovery holds on-chain, e.g., enough number of the guardian's confirmations are registered into the wallet contract, it requests the Relayer to complete the recovery.
 15. (Completing a recovery 2/2) The Relayer broadcasts a transaction to call a function in the wallet contract for completing the recovery. If it returns no error, the owner address should be rotated.
 
 ### Integration to your Wallet
 Using our SDK, you can integrate email-based account recovery into your wallet. 
 Specifically, it provides an abstract contract in `EmailAccountRecovery.sol` and a Relayer server compatible with that contract, agnostic to the specification of each wallet.
-By 1) having your wallet contract inherit the abstract contract, which requires you to implement five functions, and 2) building your frontend scripts to call the contract and the Relayer, your wallet can support the email-based account recovery described above. 
+By 1) having your wallet contract inherit the abstract contract, which requires you to implement five functions, and 2) building your frontend to call the contract and the Relayer, your wallet can support the email-based account recovery described above. 
 Notably, our SDK **does not** specify concrete wallet specifications and the logic **after** verifying the email-auth messages for accepting a guardian and processing a recovery.
 Our SDK cannot ensure security and privacy in the entire process without your careful implementation.
 
@@ -142,13 +142,6 @@ You can integrate the email-based account recovery into your wallet in the follo
 3. (Contracts 3/5) Before implementing the remaining functions in `EmailAccountRecovery`, you implement a requesting function for the wallet owner to request a guardian, which is expected to be called by the wallet owner directly. Our SDK **does not** specify any interface or implementation of this function. For example, it can simply take as input a new guardian's Ethereum address, which will be the contract address of the guardian's email-auth contract to be deployed later, and store the given address as a guardian candidate. If you want to set a timelock for each guardian, the requesting function can additionally receive the timelock length from the wallet owner. 
 4. (Contracts 4/5) You implement the `acceptGuardian` and `processRecovery` functions. These two functions are, respectively, called by your wallet contract itself after verifying the email-auth messages for accepting a guardian and processing a recovery. Each of them takes as input the contract address of the guardian's email-auth contract, an index of the chosen subject template, the values for the variable parts of the message in the Subject, and the email nullifier. You can assume these arguments are already verified. In the `acceptGuardian` function, for example, the wallet contract stores the given guardian's address as the confirmed guardian. In the `processRecovery` function, for instance, it stores the given new owner address or sets a timelock.
 5. (Contracts 5/5) You finally implement the `completeRecovery` function. It should rotate the owner address in the wallet contract if some required conditions hold. Notably, it does not take any arguments. Therefore, this function should only depend on the storage data.
-
-<!-- The above life cycle can support various practical implementations of account recovery. For example, if your wallet contract requires confirmations from multiple guardians and sets a timelock if only less than three guardians confirm the recovery, you can implement such functions as follows:
-1. (Setting a guardian) Your wallet contract stores a list of multiple guardians' Ethereum addresses. When the wallet approves a new guardian’s email, it deploys a new 
- adds the guardian’s Ethereum address to that list.
-2. When the wallet approves one guardian’s email for the first time, it sets the status of the wallet to a recovering mode and stores the new signer address in the email, the guardian’s ethereum address, and the block timestamp. After that, every time the wallet approves a guardian’s email, it adds the guardian’s ethereum address to the confirming guardians list.
-3. If the size of the confirming guardians list is two, the wallet updates the signer address if and only if the timelock is expired. Otherwise, i.e., the number of the confirming guardians are more than two, the wallet immediately updates it.
--->
-
-
-
+6. (Frontend 1/3) Next, you build a frontend for the account recovery. You prepare a page where the wallet owner configures guardians. It receives the wallet address (`wallet_eth_addr`) and the guardian's email address from the wallet owner (`guardian_email_addr`), generates a random account code (`account_code`), constructs an expected subject (`subject`) for the subject template whose index is `template_idx` in the output of the `acceptanceSubjectTemplates()` function. It then requests the wallet owner to call the requesting function in the wallet contract. After that, it calls the Relayer's `acceptanceRequest` API with those data.
+7. (Frontend 2/3) You also prepare a page where the wallet owner requests guardians to recover the wallet. It receives the wallet address (`wallet_eth_addr`) and the guardian's email address from the wallet owner (`guardian_email_addr`) and constructs an expected subject (`subject`) for the subject template whose index is `template_idx` in the output of the `recoverySubjectTemplates()` function. It calls the Relayer's `acceptanceRequest` API with those data.
+8. (Frontend 3/3) It simulates off-chain if the `completeRecovery` function in the wallet contract will return true at regular time intervals. When it holds, the frontend calls the Relayer's `completeRequest` API.