feat(docs): Note discovery concepts page

docs/docs/aztec/concepts/advanced/storage/note_discovery.md

@@ -0,0 +1,45 @@
+---
+title: Note Discovery
+tags: [storage, concepts, advanced, notes]
+sidebar_position: 3
+---
+
+Note discovery refers to the process of a user identifying and decrypting the [encrypted notes](../../storage/notes.md) that belong to them.
+
+## Existing solutions
+
+### Brute force / trial-decrypt
+
+In some existing protocols, the user downloads all possible notes and tries to decrypt each one. If the decryption succeeds, the user knows they own that note. However, this approach becomes exponentially more expensive as the network grows and more notes are created. It also introduces a third-party server to gather and trial-decrypt notes, which is an additional point of failure. Note that this note discovery technique is not currently implemented for Aztec.
+
+### Off-chain communication
+
+Another proposed solution is having the sender give the note content to the recipient via some off-chain communication. While it solves the brute force issue, it introduces reliance on side channels which we don't want in a self-sufficient network. This option incurs lower transaction costs because fewer logs needs to be posted on-chain. Aztec apps will be able to choose this method if they wish.
+
+## Aztec's solution: Note tagging
+
+Aztec introduces an approach that allows users to identify which notes are relevant to them by having the sender *tag* the log in which the note is created. This is known as note tagging. The tag is generated in such a way that only the sender and recipient can identify it.
+
+### How it works
+
+#### Every log has a tag
+
+In Aztec, each emitted log is an array of fields, eg `[x, y, z]`. The first field (`x`) is a *tag* field used to index and identify logs. The Aztec node exposes an API `getLogsByTags()` that can retrieve logs matching specific tags.
+
+#### Tag generation
+
+The sender and recipient share a predictable scheme for generating tags. The tag is derived from a shared secret and an index (a shared counter that increments each time the sender creates a note for the recipient).
+
+#### Discovering notes in Aztec contracts
+
+This note discovery scheme will be implemented by Aztec contracts rather than by the PXE. This means that users can update or use other types of note discovery to suit their needs.
+
+### Limitations
+
+- **You cannot receive notes from an unknown sender**. If you do not know the sender’s address, you cannot create the shared secret, and therefore cannot create the note tag. There are potential ways around this, such as senders adding themselves to a contract and then recipients searching for note tags from all the senders in the contract. However this is out of scope at this point in time.
+
+- **Index synchronization can be complicated**. If transactions are reverted or mined out of order, the recipient may stop searching after receiving a tag with the latest index they expect. This means they can miss notes that belong to them. We cannot redo a reverted a transaction with the same index, because then the tag will be the same and the notes will be linked, leaking privacy. We can solve this by widening the search window (not too much, or it becomes brute force) and implementing a few restrictions on sending notes. A user will not be able to send a large amount of notes from the same contract to the same recipient within a short time frame.
+
+## Further reading
+
+- [How partial notes are discovered](./partial_notes.md#note-discovery)

docs/docs/aztec/concepts/advanced/storage/partial_notes.md

@@ -2,7 +2,7 @@
 title: Partial Notes
 description: Describes how partial notes are used in Aztec
 tags: [notes, storage]
-sidebar_position: 3
+sidebar_position: 4
 ---
 
 Partial notes are a concept that allows users to commit to an encrypted value, and allows a counterparty to update that value without knowing the specific details of the encrypted value.
@@ -154,6 +154,10 @@ This ensures that the refund partial note will be completed for the user.
 
 #include_code complete_refund noir-projects/noir-contracts/contracts/fpc_contract/src/main.nr rust
 
+## Note discovery
+
+Note discovery is detailed [here](./note_discovery.md). Partial notes are handled very similarly, where the partial note creator will add a tag to the beginning of the encrypted log, like a regular note, but the contract knows that it is a partial note and is missing a public component. The contract puts the unfinished note and the public log that will be emitted to complete the note into the PXE's database. When the public log is emitted, the recipient's PXE has all of the info about the note and the partial note is completed. This method of discovery allows partial notes to be started and completed in separate transactions.
+
 ## Future work
 
 This pattern of making public commitments to notes that can be modified by another party, privately, can be generalized to work with different kinds of applications. The Aztec labs team is working on adding libraries and tooling to make this easier to implement in your own contracts.

docs/docs/aztec/concepts/pxe/index.md

@@ -67,11 +67,7 @@ The database stores various types of data, including:
 - **Capsules**: External data or data injected into the system via [oracles](#oracles).
 - **Address Book**: A list of expected addresses that a PXE may encrypt notes for, or received encrypted notes from. This list helps the PXE reduce the amount of work required to find notes relevant to it's registered accounts.
 
-### Note discovery
-
-Note discovery helps solve the problem of a user parsing the chain for their encrypted notes.
-
-There is a note tagging scheme that allows users to register an expected note sender in their PXE, which tells the PXE to expect notes coming from that expected sender. This helps the PXE more efficiently discover the encrypted notes being created for its registered accounts.
+The PXE is not in charge of note discovery, ie finding the notes that are owned by the user. This is handled by Aztec contracts, and you can learn more [here](../advanced/storage/note_discovery.md)
 
 ### Authorization
 

docs/docs/aztec/concepts/storage/notes.md

@@ -20,10 +20,26 @@ When a note is updated, Aztec nullifies the original commitment in the note hash
 
 Notes are comparable to cash, with some slight differences. When you want to spend $3.50 USD in real life, you give your $5 note to a cashier who will keep $3.50 and give you separate notes that add up to $1.50. Using private notes on Aztec, when you want to spend a $5 note, you nullify it and create a $1.5 note with yourself as the owner and a $3.5 note with the recipient as the owner. Only you and the recipient are aware of $3.5 transaction, they are not aware that you "split" the $5 note.
 
+## Sending notes
+
+When creating notes for a recipient, you need a way to send the note to them. There are a few ways to do this:
+
+### On-chain (encrypted logs):
+
+This is the common method and works well for most use cases. You can emit an encrypted log as part of a transaction. The encrypted note data will be posted onchain, allowing the recipient to find the note through [note discovery](../advanced/storage/note_discovery.md).
+
+### Off-chain (out of band):
+
+In some cases, if you know the recipient off-chain, you might choose to share the note data directly with them. The recipient can store that note in their PXE and later spend it.
+
+### Self-created notes (not emitted):
+
+If you create a note for yourself, you don’t need to broadcast it to the network or share anything. You will only need to keep the note somewhere, such as in your PXE, so you can prove ownership and spend it in future transactions.
+
 ## Abstracting notes from from apps & users
 
 When using the Aztec protocol, users may not be aware of the specific notes that they own. Their experience should be similar to Ethereum, and should instead see the amount of their assets inside their account.
 
-This is accomplished through the smart contract library, Aztec.nr, which abstracts notes by allowing developers to specify custom note types and also helps users discover all of the notes that have been encrypted to their account and posted to the chain. This means they can specify how notes are interacted with, nullified, transferred, and displayed.
+This is accomplished through the smart contract library, Aztec.nr, which abstracts notes by allowing developers to specify custom note types. This means they can specify how notes are interacted with, nullified, transferred, and displayed. Aztec.nr also helps users discover all of the notes that have been encrypted to their account and posted to the chain, known as [note discovery](../advanced/storage/note_discovery.md).
 
 To understand note abstraction in Aztec.nr, you can read the [Build section](../../../developers/guides/smart_contracts/writing_contracts/notes/index.md).

docs/docs/developers/getting_started.md

@@ -223,17 +223,4 @@ Simulation result:  25n
 
 ## What's next?
 
-Now you have a development network running, so you're ready to start coding your first app with Aztec.nr and Aztec.js!
-
-<div className="card-container full-width">
-  <Card shadow='tl' link='./tutorials/codealong/contract_tutorials/counter_contract'>
-    <CardHeader>
-      <h3>Write your first contract</h3>
-    </CardHeader>
-    <CardBody>
-     Write and deploy a simple private counter smart contract on your local sandbox
-    </CardBody>
-  </Card>
-</div>
-
-If you'd rather clone a repo, check out the [Aztec Starter](https://github.com/AztecProtocol/aztec-starter).
+Click the Next button below to continue on your journey and write your first Aztec smart contract.

docs/docs/developers/tutorials/codealong/contract_tutorials/uniswap/_category_.json

@@ -1,6 +1,6 @@
 {
     "label": "Uniswap Bridge",
-    "position": 0,
+    "position": 7,
     "collapsible": true,
     "collapsed": true
 }