Update email_based_account project

email_based_account/.gitignore

@@ -0,0 +1,43 @@
+# Dependencies
+/node_modules
+/**/node_modules
+.yarn/*
+!.yarn/patches
+!.yarn/plugins
+!.yarn/releases
+!.yarn/sdks
+!.yarn/versions
+
+# Build outputs
+dist/
+build/
+target/
+dest/
+
+# Debug logs
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+# Environment variables
+.env
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+# IDE and editor files
+.idea/
+.vscode/*
+!.vscode/extensions.json
+*.swp
+*.swo
+.DS_Store
+
+# Noir/Aztec specific
+artifacts/
+codegenCache.json
+.tsbuildinfo
+
+# Testing
+coverage/

email_based_account/.latest_aztec_cli_vars

@@ -0,0 +1,110 @@
+AZTEC_PORT
+ASSUME_PROVEN_UNTIL_BLOCK_NUMBER
+TEST_ACCOUNTS
+ENABLE_GAS
+API_PREFIX
+ETHEREUM_HOST
+L1_CHAIN_ID
+MNEMONIC
+ROLLUP_CONTRACT_ADDRESS
+REGISTRY_CONTRACT_ADDRESS
+INBOX_CONTRACT_ADDRESS
+OUTBOX_CONTRACT_ADDRESS
+AVAILABILITY_ORACLE_CONTRACT_ADDRESS
+FEE_JUICE_CONTRACT_ADDRESS
+FEE_JUICE_PORTAL_CONTRACT_ADDRESS
+ARCHIVER_URL
+DEPLOY_AZTEC_CONTRACTS
+L1_PRIVATE_KEY
+L2_QUEUE_SIZE
+WS_BLOCK_CHECK_INTERVAL_MS
+P2P_ENABLED
+P2P_BLOCK_CHECK_INTERVAL_MS
+P2P_PEER_CHECK_INTERVAL_MS
+P2P_L2_QUEUE_SIZE
+TCP_LISTEN_ADDR
+UDP_LISTEN_ADDR
+P2P_TCP_ANNOUNCE_ADDR
+P2P_UDP_ANNOUNCE_ADDR
+PEER_ID_PRIVATE_KEY
+BOOTSTRAP_NODES
+P2P_TX_PROTOCOL
+P2P_MIN_PEERS
+P2P_MAX_PEERS
+DATA_DIRECTORY
+TX_GOSSIP_VERSION
+P2P_QUERY_FOR_IP
+P2P_TX_POOL_KEEP_PROVEN_FOR
+TELEMETRY
+OTEL_SERVICE_NAME
+OTEL_EXPORTER_OTLP_METRICS_ENDPOINT
+OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
+NETWORK_NAME
+NETWORK
+API_KEY
+AZTEC_NODE_URL
+ARCHIVER_POLLING_INTERVAL_MS
+ARCHIVER_VIEM_POLLING_INTERVAL_MS
+ARCHIVER_MAX_LOGS
+SEQ_TX_POLLING_INTERVAL_MS
+SEQ_MAX_TX_PER_BLOCK
+SEQ_MIN_TX_PER_BLOCK
+SEQ_MIN_SECONDS_BETWEEN_BLOCKS
+SEQ_MAX_SECONDS_BETWEEN_BLOCKS
+COINBASE
+FEE_RECIPIENT
+ACVM_WORKING_DIRECTORY
+ACVM_BINARY_PATH
+SEQ_ALLOWED_SETUP_FN
+SEQ_ALLOWED_TEARDOWN_FN
+SEQ_MAX_BLOCK_SIZE_IN_BYTES
+ENFORCE_FEES
+SEQ_PUBLISHER_PRIVATE_KEY
+SEQ_REQUIRED_CONFIRMATIONS
+SEQ_PUBLISH_RETRY_INTERVAL_MS
+VERSION
+SEQ_DISABLED
+PROVER_DISABLED
+PROVER_REAL_PROOFS
+PROVER_AGENT_ENABLED
+PROVER_AGENT_POLL_INTERVAL_MS
+PROVER_AGENT_CONCURRENCY
+PROVER_JOB_TIMEOUT_MS
+PROVER_JOB_POLL_INTERVAL_MS
+PROVER_ID
+WS_L2_BLOCK_QUEUE_SIZE
+WS_PROVEN_BLOCKS_ONLY
+PROVER_PUBLISH_RETRY_INTERVAL_MS
+PROVER_PUBLISHER_PRIVATE_KEY
+PROVER_REQUIRED_CONFIRMATIONS
+PROVER_TEST_DELAY_MS
+TX_PROVIDER_NODE_URL
+TXE_PORT
+LOG_JSON
+BOT_PXE_URL
+BOT_PRIVATE_KEY
+BOT_RECIPIENT_ENCRYPTION_SECRET
+BOT_TOKEN_SALT
+BOT_TX_INTERVAL_SECONDS
+BOT_PRIVATE_TRANSFERS_PER_TX
+BOT_PUBLIC_TRANSFERS_PER_TX
+BOT_FEE_PAYMENT_METHOD
+BOT_NO_START
+BOT_TX_MINED_WAIT_SECONDS
+BOT_NO_WAIT_FOR_TRANSFERS
+BOT_MAX_PENDING_TXS
+PXE_BLOCK_POLLING_INTERVAL_MS
+PXE_L2_STARTING_BLOCK
+PXE_DATA_DIRECTORY
+BB_BINARY_PATH
+BB_WORKING_DIRECTORY
+BB_SKIP_CLEANUP
+PXE_PROVER_ENABLED
+BOT_FOLLOW_CHAIN
+BOT_FLUSH_SETUP_TRANSACTIONS
+VALIDATOR_PRIVATE_KEY
+VALIDATOR_DISABLED
+PROVER_NODE_DISABLE_AUTOMATIC_PROVING
+PROVER_NODE_MAX_PENDING_JOBS
+LOG_LEVEL
+DEBUG

email_based_account/.prompt

@@ -0,0 +1,111 @@
+Overall code structure and explanation:
+Project Structure:
+Your project is structured as a monorepo with the main application in the frontend directory. The root directory contains configuration files for the entire project, while the frontend directory has its own configuration and source files.
+Frontend Application:
+Built with React and TypeScript
+Uses Vite as the build tool
+Implements a basic wallet functionality for the Aztec Protocol
+Main Components:
+Home (frontend/src/pages/Home.tsx): The landing page with options to create an account or sign in
+CreateAccount (frontend/src/pages/CreateAccount.tsx): Handles the account creation process
+Wallet (frontend/src/pages/Wallet.tsx): Displays wallet information and balance
+State Management:
+Uses React Context (WalletContext) for managing wallet state across the application
+Routing:
+Utilizes React Router for navigation between different pages
+6. Styling:
+Uses CSS modules (styles/Common.module.css) for component-specific styles
+Has a global App.css file for general styling
+Testing:
+Jest is set up for unit testing
+SimpleTest.test.tsx contains tests for various components and functionalities
+Build and Configuration:
+Vite is used as the build tool (vite.config.ts)
+TypeScript configurations for both the app (tsconfig.json) and Node environment (tsconfig.node.json)
+ESLint for code linting (eslint.config.js)
+Dependencies:
+React and React DOM
+@aztec/aztec.js for Aztec Protocol integration
+Various development tools (TypeScript, Jest, ESLint, etc.)
+Key Features:
+Create a new Aztec account
+View account details (address, private key, transaction signing key)
+Basic wallet functionality
+11. Planned Features:
+Improved UI
+Token transfers
+Account abstraction features
+Fee management improvements
+Your project is a React-based frontend for an Aztec Protocol wallet. It's set up with modern tooling and practices, including TypeScript for type safety, Jest for testing, and Vite for fast builds. The application currently provides basic wallet functionality with plans for more advanced features in the future.
+The codebase is well-structured and follows React best practices, using functional components and hooks. It's set up to be easily expandable as you add more features to your wallet application.
+
+
+
+Frontend Code Structure and Explanation:
+An overview of my frontend code structure and explain the main components:
+Entry Point (frontend/src/main.tsx):
+This file is the entry point of your React application. It renders the main App component into the DOM.
+App Component (frontend/src/App.tsx):
+This is your main application component. It sets up the routing using React Router and wraps the entire application with the WalletProvider for state management.
+Home Page (frontend/src/pages/Home.tsx):
+This is the landing page of your application. It provides options to create an account or sign in.
+Create Account Page (frontend/src/pages/CreateAccount.tsx):
+This page handles the account creation process. It simulates creating a new wallet and redirects to the wallet page upon completion.
+Wallet Page (frontend/src/pages/Wallet.tsx):
+This page displays the wallet information, including the address, private key, and transaction signing key.
+Wallet Context (frontend/src/context/WalletContext.tsx):
+This file sets up the React Context for managing wallet state across your application.
+Key Features:
+The application uses React Router for navigation between different pages.
+State management is handled through React Context (WalletContext).
+The app simulates wallet creation and management without actual blockchain integration yet.
+There's a basic UI with buttons for creating an account and signing in.
+The wallet view shows sensitive information (private key, transaction signing key) with a warning.
+Styling:
+The app uses CSS modules for styling (styles/Common.module.css).
+There's also a global App.css file for some general styling.
+Testing:
+There's a test file (SimpleTest.test.tsx) that includes tests for various components and functionalities.
+Build and Configuration:
+The project uses Vite as the build tool, configured in vite.config.ts.
+There are separate TypeScript configurations for the app (tsconfig.json) and Node environment (tsconfig.node.json).
+Dependencies:
+The project uses React, React Router, and various development tools like TypeScript, Jest for testing, and ESLint for linting.
+Overall, this frontend provides a basic structure for a wallet application, with placeholders for future functionality like actual account creation and transaction management. The code is organized in a typical React application structure, with separate files for components, context, and pages.
+
+Logical flow for create account to put new account details display from wallet component to create-account component
+The main wallet functionality (display of address, private key, transaction signing key followed by the done button) that is now part of Wallet component,is logically a part of the create-account component. The user goes through this stage (if they dont yet have an account only. if they do then from the Home screen they click on 'Already have an account? Sign in' and go into a different flow which we dont need to consider here) when they click on 'Create Account' from the Home screen. The create-account component simulates this action and then displays the address, private key, and transaction signing key in the Wallet component. so can we just add the functionality of displaying the address, private key, and transaction signing key in the create-account component and then redirect to the wallet component? If yes, tell me how you will do it. If not, tell me what other changes need to be made. dont make any changes to the code yet till i ask you to.
+
+
+'Sign in if you have an account' story:
+on the home screen, on clicking 'Already have an account? Sign in', the user is redirected to the 'enter private key' screen. this screen has a form with 1 field 'Enter your private key'. once the user enters their private key which is essentially the encryptionSecretKey and another key, transaction signing key and clicks on 'Sign in', we fetch the account and wallet, when successfully done, user are redirected to the wallet component. if the credentials are not correct, show error and redirect to landing page/ component. salt=0
+
+
+implement createschnorr account functionality in the frontend. for real:
+As shown in @aztec.tsx there is a way to use @getSchnorrAccount.
+  @createSchnorrAccount has the details. we start in the create-account component. we want to create the schnorr account. first create the pxe client and return it as an object. once @pxe object is available in the function to create schnorr account,  then generate at random an @encryptionSecretKey   and @signingSecretKey . 
+now create new account by calling @getSchnorrAccount with the parameters we already have. get @Wallet  object for the account. return an object with 3 properties: the wallet @address (User Address) , @encryptionSecretKey (Private Key) and @signingSecretKey (Transaction Signing Key) . use salt=0
+
+separate creating pxe client and creating schnorr account in aztec.tsx. because pxe is used much more widely in in the lifetime of a user. user will use it to hold their private data including tokens, transactions, etc. the create schnorr account once at the beginning of their use.
+
+changes to make in getting real schnorr account:
+1. currently address, encryptionSecretKey, signingSecretKey are returned as strings, Fr, Fq to create-account component. we need to change this to the actual object for address. account object?
+2. we need to make changes in create-account component to handle the new objects.
+3. we need to make changes in the aztec.tsx file to handle the new objects.
+4. we need to make changes in the wallet component to handle the new objects.
+what is stored in context, where walletinfo is defined. walletinfo has address as string, encryptionSecretKey as string, signingSecretKey as string, balance, transactions as its properties. does this make sense. is it what we want? why dont we retain it as the wallet object as defined by aztec.
+Wallet component does not need to show EncryptionSecretKey and SigningSecretKey. it only needs to show the address and balance. the transaction signing key is only needed for signing transactions, which we currently do not support. the private key is only needed for creating public key and we do not need to show that. so we can remove all these from context. we are only left with address and balance.
+
+add initialization or waiting logic for pxe client in aztec.tsx.
+
+deploy a token contract name, symbol, total supply. transfer some tokens to address from terminal.
+
+add token feature to frontend. show token balance for hardcoded token contract. show token amount. put dummy value as 0 always for now. first log the balance quantity of tokens for token address for signed in user address. 
+
+email id as input in ui. hash it and use it as input in getSchnorrAccount method
+
+this error - fs/promises related in github codespaces. how to fix. 
+
+if an account with an email is already registered, then if user uses different signing key next time, it should not create a totally new and different account. it should throw up error saying wrong signing key! else if a new account for created everytime a different signing key is used for same email, that results in terrible user experience.
+
+version update of aztec to 0.57.0 is breaking smart contract tests. compiles well. but tests break. reference repo, aztec-starter on github works. 

email_based_account/.yarnrc.yml

@@ -0,0 +1 @@
+nodeLinker: node-modules

email_based_account/Nargo.toml

@@ -0,0 +1,9 @@
+[package]
+name = "use zkemail"
+type = "bin"
+authors = ["rajesh"]
+compiler_version = ">=0.35.0"
+
+[dependencies]
+aztec = { git = "https://github.com/AztecProtocol/aztec-packages/", tag = "aztec-packages-v0.57.0", directory = "noir-projects/aztec-nr/aztec" }
+zkemail = { tag = "v0.3.2", git = "https://github.com/zkemail/zkemail.nr", directory = "lib" }

email_based_account/README.md

@@ -0,0 +1,102 @@
+# Email Based Account
+
+Create an email based aztec account. That one can sign into using an email address (gmail) and a password. The user can sign transactions using the password.  
+
+This project uses zkemail.nr library for email verification on the user's device. The email ID and the password are kept private and do not leave the user's browser. 
+
+[watch the demo here](https://youtu.be/V_2vtAR1lzo)
+
+How to run the project locally:
+1. Clone the repo (either this or the parent repo: https://github.com/rajeshb62/ab2)
+2. From project root (email_based_account), run:
+```
+nargo compile
+```
+3. From project root, run:
+```
+yarn install
+cd frontend
+yarn install
+cd ..
+```
+4. From project root (email_based_account folder), run:
+```
+yarn workspace frontend dev
+```
+5. Run tests:
+```
+# to run both noir and frontend tests
+yarn test
+# to run only frontend tests
+yarn test:frontend
+```
+
+
+## Challenge Selection
+Read [this article](https://aztec.network/blog/unlocking-the-future-of-privacy-exploring-identity-and-social-use-cases-in-alpha-build-2-with-100k-in-prizes) that announces Alpha Build 2 to learn more about the challenges and get ideas on what to build!
+
+- [x] ZKEmail Guardian
+- [ ] Social Cipher
+
+**Note**: You can change which challenges you've selected during the competition if you'd like. You are not bound by your choices or descriptions entered during the one week check-in.
+
+## Team information
+
+[Rajesh ](https://github.com/rajeshb62)
+
+## Technical Approach
+### Questions/ approach
+- create an account for an email address abc@xyz.com based on .eml file:
+    - verify header is valid using dkim signature verification
+    - check sender is 'abc@xyz.com'
+    - (additional check) check if subject contains a specific random string shown in UI
+- hash email+password into sha256 hash, and use it as encryption key in getSchnorrAccount(..) function, hash the password and use it as signing key. Show the account wallet in UI (user can sign tx from this wallet using their password)
+Inspirations: 
+https://zkemail.shieldswap.org/
+https://docs.aztec.network/guides/developer_guides/smart_contracts/writing_contracts/authwit#usage
+Inspiration codebases: Loads account based on Face ID of user: loads account based on password: https://github.com/skaunov/aabch1_23
+
+## Expected Outcomes
+A wallet app (previously created in alpha build 1 https://github.com/rajeshb62/aztec-wallet) that now is modified to use email ownership proof to create aztec account
+
+## Lessons Learned (For Submission)
+
+- What are the most important takeaways from your project? 
+Creation of email based private blockchain accounts are a reality. 
+- Are there any patterns or best practices that you've learned that would be useful for other projects?Learning about zkemail.nr library will help improve readme/ other documentation for this library.
+- Highlight reusable code patterns, key code snippets, and best practices - what are some of the ‘lego bricks’ you’ve built, and how could someone else best use them?
+
+## Project Links (For Submission)
+
+Please provide links to any relevant documentation, code, or other resources that you've used in your project.
+
+## Video Demo (For Submission)
+
+[![Email Based Account Demo]](https://www.youtube.com/watch?v=V_2vtAR1lzo)
+
+A brief demo showing:
+- Email verification process
+- Account creation
+
+- How does your project leverage Aztec's unique features? (programmable cryptography, private/public state, etc.)
+While not directly within scope of AB2, the wallet is being built only because
+1. it allows fully private state and activities, most importantly:
+    - private transfers of stablecoins and eth
+    - assets can stay fully private for user, as absolutely esstial for card games 
+2. account abstraction features that make possible 
+    - user friendly encryption and signing key namely, email based hash for private key and Face ID for signing key
+    - email ID based token transfer (???)
+    - transaction rules like 'allow only transactions below $100 / day by email(???)'
+    - allow session ID based transaction approval
+3. fee abstraction features:
+    -allow for wallet provider to pay gas (needed for activities like card games)
+
+- What is the potential real-world impact of your project?
+- onboard web2 users using familiar account creation and signing methods like email ID and password
+- ( there are other features relevant for web2 users in wallet but that are not directly within scope of AB2)
+
+## Scope for future research, improvements and problems to solve
+- emails and aliases need to be studied. The goal is one email ID one aztec account (users have multiple aliases for one email ID, how does that work and how to handle that? Users can own domain name and have emails sent from and to all email ids using that domain name (a@joshcrites.com, b@joshcrites.com) be operated from the same inbox (??). there is lot of scope to better understand the email protocol)
+- current implementation has users sending emails to an inbox controlled by the developer. It defeats the purpose of user privacy. It needs a better solution (user sending verification email to themselves for the verification step???)
+- zkemail seems to support a limited number of domains currently. The app itself only supports emails sent from  icloud.com and that too emails of a small size. 
+- Replace password with touch/face ID for better UX and security