chore(docs): cli wallet (#8182)

### TL;DR

Added CLI Wallet reference documentation and a tutorial for creating a
FaceID wallet using Mac's Secure Enclave.

### What changed?

- Added a new file `cli_wallet_reference.md` with comprehensive
documentation on the CLI Wallet, including commands for account
management, deployment, transactions, and note management.
- Created a new tutorial `faceid_wallet.md` demonstrating how to use
Apple Mac's Secure Enclave to store private keys and interact with the
CLI Wallet.

### How to test?

1. Review the CLI Wallet reference documentation for accuracy and
completeness.
2. Follow the FaceID Wallet tutorial on a Mac:
   - Install and run the Aztec sandbox
   - Install Secretive and set up the SSH_AUTH_SOCK
   - Create a key in Secretive
   - Use the CLI Wallet to create an account with the secp256r1 curve
   - Deploy a token contract and interact with it using the new account

### Why make this change?

This change provides developers with detailed documentation on using the
CLI Wallet and demonstrates an advanced use case of Aztec's account
abstraction capabilities. The FaceID Wallet tutorial showcases how Aztec
can integrate with native security features, offering a unique and
secure way to manage private keys and interact with the network.

---------

Co-authored-by: Cat McGee <[email protected]>

docs/docs/reference/developer_references/sandbox_reference/cli_wallet_reference.md

@@ -0,0 +1,153 @@
+---
+title: CLI Wallet
+tags: [sandbox, wallet, cli]
+---
+
+For development, it may be useful to deploy, transact, or create notes in a non-programmatic way. You can use Aztec's CLI Wallet for thing such as:
+
+- Deploying contracts
+- Sending transactions
+- Bridging L1 [Fee Juice](../../../protocol-specs/gas-and-fees/fee-juice.md) into Aztec
+- Pushing arbitrary [notes](../../../guides/developer_guides/smart_contracts/writing_contracts/notes/index.md) to your PXE
+- Creating [authwits](../../../guides/developer_guides/smart_contracts/writing_contracts/authwit.md)
+- Aliasing info and secrets for further usage
+
+:::info
+
+At any time, you can get an updated version of the existing commands and subcommands by adding `-h`. For example:
+
+```bash
+aztec-wallet create-account -h
+```
+
+:::
+
+## Aliases
+
+The CLI wallet makes extensive use of aliases, that is, when an address, artifact, secret, or other information is given a name that can be later used to reference it.
+
+Aliases have different types like `address` or `artifact` or `contract`. You can see a list of these types by running the help command `aztec-wallet alias -h`. You can then specify a type with the `:` character whenever needed. For example `accounts:master_yoda` or `artifacts:light_saber`.
+
+:::tip
+
+The wallet writes to the `last` alias if it's likely that you use that same alias in the next command.
+
+It will also try to determine which type is expected. For example, if the alias `master_yoda` is an account, you don't need to prepend `account:` if, for example, you're deploying a contract.
+
+You can create arbitrary aliases with the `alias` command. For example `aztec-wallet alias accounts test_alias 0x2c37902cdade7710bd2355e5949416dc5e43a16e0b13a5560854d2451d92d289`.
+
+
+## Account Management
+
+The wallet comes with some options for account deployment and management. You can register and deploy accounts, or only register them, and pass different options to serve your workflow.
+
+### create-account
+
+Generates a secret key and deploys an account contract.
+
+#### Example
+
+```bash
+aztec-wallet create-account -a master_yoda
+```
+
+### Deploy account
+
+Deploy an account that is already registered (i.e. your PXE knows about it) but not deployed. Most times you should pass an alias or address registered in the PXE by passing the `-f` or `--from` flag.
+
+#### Example
+
+```bash
+$ aztec-wallet create-account --register-only -a master_yoda
+...
+$ aztec-wallet deploy-account -f master_yoda
+```
+
+### Deploy
+
+You can deploy a [compiled contract](../../../guides/developer_guides/smart_contracts/how_to_compile_contract.md) to the network.
+
+You probably want to look at flags such as `--init` which allows you to specify the [initializer function](../../../guides/developer_guides/smart_contracts/writing_contracts/initializers.md) to call, or `-k` for the [encryption public key](../../../aztec/concepts/accounts/keys.md#incoming-viewing-keys) if the contract is expected to have notes being encrypted to it.
+
+You can pass arguments with the `--arg` flag.
+
+#### Example
+
+This example compiles the Jedi Code and deploys it from Master Yoda's account, initializing it with the parameter "Grand Master" and aliasing it to `jedi_order`. Notice how we can simply pass `master_yoda` in the `--from` flag (because `--from` always expects an account):
+
+```bash
+aztec-nargo compile
+aztec-wallet deploy ./target/jedi_code.nr --arg accounts:master_yoda --from master_yoda --alias jedi_order
+```
+
+### Send
+
+This command sends a transaction to the network by calling a contract's function. Just calling `aztec-wallet send` gives you a list of options, but you probably want to pass `--from` as the sender, `--contract-address` for your target's address, and `--args` if it requires arguments.
+
+#### Example
+
+```bash
+aztec-wallet send --from master_yoda --contract-address jedi_order --args "luke skywalker" train_jedi
+```
+
+Again, notice how it's not necessary to pass `contracts:jedi_order` as the wallet already knows that the only available type for `--contract-address` is a contract.
+
+### Manage authwits
+
+You can use the CLI wallet to quickly generate [Authentication Witnesses](../../../guides/developer_guides/smart_contracts/writing_contracts/authwit.md). These allow you to authorize the caller to execute an action on behalf of an account. They get aliased into the `authwits` type.
+
+### In private
+
+The authwit management in private is a two-step process: create and add. It's not too different from a `send` command, but providing the caller that can privately execute the action on behalf of the caller.
+
+#### Example
+
+An example for authorizing an operator (ex. a DeFi protocol) to call the transfer_from action (transfer on the user's behalf):
+
+```bash
+aztec-wallet create-authwit transfer_from accounts:coruscant_trader -ca contracts:token --args accounts:jedi_master accounts:coruscant_trader 20 secrets:auth_nonce -f accounts:jedi_master -a secret_trade
+
+aztec-wallet add-authwit authwits:secret_trade accounts:jedi_master -f accounts:coruscant_trader
+```
+
+### In public
+
+A similar call to the above, but in public:
+
+```bash
+aztec-wallet authorize-action transfer_public accounts:coruscant_trader -ca contracts:token --args accounts:jedi_master accounts:coruscant_trader 20 secrets:auth_nonce -f accounts:jedi_master
+```
+
+### Simulate
+
+Simulates a transaction instead of sending it. This allows you to obtain i.e. the return value before sending the transaction.
+
+#### Example
+
+```bash
+aztec-wallet simulate --from master_yoda --contract-address jedi_order --args "luke_skywalker" train_jedi
+```
+
+### Bridge Fee Juice
+
+The wallet provides an easy way to mint the fee-paying asset on L1 and bridging it to L2. We call it Fee Juice and you can read more about it in the [protocol specs](../../../protocol-specs/gas-and-fees/fee-juice.md).
+
+Using the sandbox, there's already a Fee Juice contract that manages this enshrined asset. You can optionally mint more Juice before bridging it.
+
+#### Example
+
+This example mints and bridges 1000 units of fee juice and bridges it to the `master_yoda` recipient on L2.
+
+```bash
+aztec-wallet bridge-fee-juice --mint 1000 master_yoda
+```
+
+### Add Note
+
+The Add Note method makes it easy to store notes on your local PXE if they haven't been broadcasted yet. For example, if a JediMember note was sent to you, and you want to spend it on another transaction, you can use this method with the `--transaction-hash` flag to pass the transaction hash that contains the note.
+
+It expects `name` and `storageFieldName`. For example, if the `#[storage]` struct had a `available_members: PrivateMutable<JediMember>` property:
+
+```bash
+aztec-note add-note JediMember available_members -a master_yoda -ca jedi_order -h 0x00000
+```

docs/docs/tutorials/codealong/cli_wallet/_category_.json

@@ -0,0 +1,6 @@
+{
+    "label": "CLI Wallet Tutorial",
+    "position": 3,
+    "collapsible": true,
+    "collapsed": true
+}

docs/docs/tutorials/codealong/cli_wallet/faceid_wallet.md

@@ -0,0 +1,115 @@
+---
+title: FaceID Wallet (Mac Only)
+---
+
+In this tutorial, we will use Apple Mac's Secure Enclave to store the private key, and use it in Aztec's [CLI Wallet](../../../reference/developer_references/sandbox_reference/cli_wallet_reference.md). This enables fully private, native, and seedless account abstraction!
+
+:::warning
+
+Aztec is in active development and this has only been tested on MacOS. Please reach out if this tutorial does not work for you, and let us know your operating system.
+
+:::
+
+## Prerequisites
+
+For this tutorial, we will need to have the the [Sandbox](../../../reference/developer_references/sandbox_reference/index.md) installed.
+
+We also need to install Secretive, a nice open-source package that allows us to store keys on the Secure Enclave. You can head to the [secretive releases page](https://github.com/maxgoedjen/secretive/releases) and get the last release's `zip`, unzip and move to Applications, or use [Homebrew](https://brew.sh/):
+
+```bash
+brew install secretive
+```
+
+Open it from the Applications folder and copy the provided Socket Path (the one it tells you to add to your .ssh config). Export it as a terminal environment variable. For example:
+
+```bash
+export SSH_AUTH_SOCK="/Users/your_user/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/socket.ssh"
+```
+
+Let's also install `socat` which helps us manage the socket connections. If using Homebrew:
+
+```bash
+brew install socat
+```
+
+### Creating a key
+
+We will create our private key, which will be stored in the Secure Enclave. Open Secretive, click the "+" sign and create a key with authentication. You can give it any name you like. Secretive will then store it in the Secure Enclave.
+
+Make sure Secretive's "Secret Agent" is running.
+
+:::info
+
+The Secure Enclave is a protected chip on most recent iPhones and Macs and it's meant to be airgapped. It is not safe to use in production.
+
+Fortunately, Aztec implements [Account Abstraction](../../../aztec/concepts/accounts#what-is-account-abstraction) at the protocol level. You could write logic to allow someone else to recover your account, or use a different key or keys for recovery.
+
+:::
+
+### Using the wallet
+
+Now we can use the key in our wallet. Every account on Aztec is a contract, so you can write your own contract with its own account logic.
+
+The Aztec team already wrote some account contract boilerplates we can use. One of them is an account that uses the `secp256r1` elliptic curve (the one the Secure Enclave uses).
+
+Let's create an account in our wallet:
+
+```bash
+aztec-wallet create-account -a my-wallet -t ecdsasecp256r1ssh
+```
+
+This command creates an account using the `ecdsasecp256r1ssh` type and aliases it to `my-wallet`.
+
+You should see a prompt like `? What public key to use?` with the public key you created in Secretive. Select this. If you see the message `Account stored in database with aliases last & my-wallet` then you have successfully created the account!
+
+You can find other accounts by running `aztec-wallet create-account -h`.
+
+### Using the wallet
+
+You can now use it as you would use any other wallet. Let's create a simple token contract example and mint ourselves some tokens with this.
+
+Create a new Aztec app with `npx aztec-app`:
+
+```bash
+npx aztec-app new -s -t contract -n token_contract token
+```
+
+This creates a new project, skips running the sandbox (`-s`), and clones the contract-only box (`-t`) called token_contract (`-n`). You should now have a `token_contract` folder. Let's compile our contract:
+
+```bash
+cd token_contract
+aztec-nargo compile
+```
+
+Great, our contract is ready to deploy with our TouchID wallet:
+
+```bash
+aztec-wallet deploy --from accounts:my-wallet token_contract@Token --args accounts:my-wallet DevToken DTK 18 -a devtoken
+
+You should get prompted to sign with TouchID or password. Once authorized, you should see `Contract stored in database with aliases last & devtoken`
+```
+
+Check [the reference](../../../reference/developer_references/sandbox_reference/cli_wallet_reference.md) for the whole set of commands, but these mean:
+
+- --from is the sender: our account `my-wallet`. We use the alias because it's easier than writing the key stored in our Secure Enclave. The wallet resolves the alias and knows where to grab it.
+- token_contract@Token is a shorthand to look in the `target` folder for our contract `token_contract-Token`
+- --args are the arguments for our token contract: owner, name, ticker and decimals.
+- -a tells the wallet to store its address with the "devtoken" alias, this way we can just use it later like `contracts:devtoken`
+
+You should get a prompt to sign this transaction. You can now mint, transfer, and do anything you want with it:
+
+```bash
+aztec-wallet create-account -a new_recipient # creating a schnorr account
+aztec-wallet send mint_public -ca last --args accounts:my-wallet 10 -f accounts:my-wallet # minting some tokens in public
+aztec-wallet simulate balance_of_public -ca contracts:devtoken --args accounts:my-wallet -f my-wallet # checking that my-wallet has 10 tokens
+aztec-wallet send transfer_public -ca contracts:devtoken --args accounts:my-wallet accounts:new_recipient 10 0 -f accounts:my-wallet # transferring some tokens in public
+aztec-wallet simulate balance_of_public -ca contracts:devtoken --args accounts:new_recipient -f my-wallet # checking that new_recipient has 10 tokens
+```
+
+### What next
+
+In this tutorial, we created an account with the Aztec's [CLI Wallet](../../../reference/developer_references/sandbox_reference/cli_wallet_reference.md), using the Apple Mac's Secure Enclave to store the private key.
+
+You can use a multitude of authentication methods, for example with RSA you could use a passport as a recovery, or even as a signer in a multisig. All of this is based on the account contract.
+
+Next step is then to [code your own account contract!](../contract_tutorials/write_accounts_contract.md)