fun with conflicts

docs/docs/aztec/aztec/concepts/accounts/keys.md

@@ -1,26 +1,26 @@
 # Keys
 The goal of this section is to give app developer a good idea what keys there are used in the system.
-For a detailed description head over to the [protocol specification](../../../protocol-specs/addresses-and-keys/keys#cheat-sheet).
+For a detailed description head over to the [protocol specification](/protocol-specs/addresses-and-keys/keys#cheat-sheet).
 
 Each account in Aztec is backed by 4 key pairs:
 
 - A **nullifier key pair** used for note nullifier computation, comprising the master nullifier secret key (`nsk_m`) and master nullifier public key (`Npk_m`).
 - A **incoming viewing key pair** used to encrypt a note for the recipient, consisting of the master incoming viewing secret key (`ivsk_m`) and master incoming viewing public key (`Ivpk_m`).
 - A **outgoing viewing key pair** used to encrypt a note for the sender, includes the master outgoing viewing secret key (`ovsk_m`) and master outgoing viewing public key (`Ovpk_m`).
-- A **tagging key pair** used to compute tags in a [tagging note discovery scheme](../../../protocol-specs/private-message-delivery/private-msg-delivery#note-tagging), comprising the master tagging secret key (`tsk_m`) and master tagging public key (`Tpk_m`).
+- A **tagging key pair** used to compute tags in a [tagging note discovery scheme](/protocol-specs/private-message-delivery/private-msg-delivery#note-tagging), comprising the master tagging secret key (`tsk_m`) and master tagging public key (`Tpk_m`).
 
 :::info
-All key pairs above are derived from a secret using a ZCash inspired scheme defined in [protocol specification](../../../protocol-specs/addresses-and-keys/keys#cheat-sheet).
+All key pairs above are derived from a secret using a ZCash inspired scheme defined in [protocol specification](/protocol-specs/addresses-and-keys/keys#cheat-sheet).
 :::
 
 :::note
 Additionally, there is typically a signing key pair which is used for authenticating the owner of the account.
-However, since Aztec supports native [account abstraction](../accounts/main#what-is-account-abstraction) this is not defined in protocol.
+However, since Aztec supports native [account abstraction](../accounts/index#what-is-account-abstraction) this is not defined in protocol.
 Instead it's up to the account contract developer to implement it.
 :::
 
 ## Public keys retrieval
-The keys can either be retrieved from a key registry contract or from the [Private eXecution Environment (PXE)](../../../learn/concepts/pxe/main).
+The keys can either be retrieved from a key registry contract or from the [Private eXecution Environment (PXE)](/aztec/aztec/concepts/pxe/index.md).
 
 :::note
 The key registry is a canonical contract used to store user public keys.
@@ -40,7 +40,7 @@ Below are some ways how we could instantiate it after getting the information in
 
 #include_code instantiate-complete-address /yarn-project/circuits.js/src/structs/complete_address.test.ts rust
 
-Then to register the recipient's [complete address](#complete-address) in PXE we would call `registerRecipient` PXE endpoint using [Aztec.js](../../../developers/aztecjs/main.md):
+Then to register the recipient's [complete address](#complete-address) in PXE we would call `registerRecipient` PXE endpoint using [Aztec.js](/developers/aztecjs/index.md):
 
 #include_code register-recipient /yarn-project/aztec.js/src/wallet/create_recipient.ts rust
 
@@ -71,7 +71,7 @@ If that happens, only the nullifier secret for that application is compromised (
 Above we mentioned that the notes typically contain `Npk_m`.
 It might seem like a mistake given that the notes are nullified with `nsk_app`.
 This is intentional and instead of directly trying to derive `Npk_m` from `nsk_app` we instead verify that both of the keys were derived from the same `nsk_m` in our protocol circuits.
-If you are curious how the derivation scheme works head over to [protocol specification](../../../protocol-specs/addresses-and-keys/example-usage/nullifier#diagram).
+If you are curious how the derivation scheme works head over to [protocol specification](/protocol-specs/addresses-and-keys/example-usage/nullifier#diagram).
 
 ## Protocol key types
 All the keys below are Grumpkin keys (public keys derived on the Grumpkin curve).
@@ -88,7 +88,7 @@ An application in Aztec.nr can request a secret from the current user for comput
 
 Typically, `Npk_m` is stored in a note and later on, the note is nullified using the secret app-siloed version (denoted `nsk_app`).
 `nsk_app` is derived by hashing `nsk_m` with the app contract address and it is necessary to present it to compute the nullifier.
-Validity of `nsk_app` is verified by our [protocol kernel circuits](../../../protocol-specs/circuits/private-kernel-tail#verifying-and-splitting-ordered-data).
+Validity of `nsk_app` is verified by our [protocol kernel circuits](/protocol-specs/circuits/private-kernel-tail#verifying-and-splitting-ordered-data).
 
 ## Incoming viewing keys
 The app-siloed version of public key (denoted `Ivpk_app`) is used to encrypt a note for a recipient and the the corresponding secret key (`ivsk_app`) is used by recipient during decryption.
@@ -100,7 +100,7 @@ For example, during a token transfer, the token contract may dictate that the se
 If these keys were not used and a new device would be synched there would be no "direct" information available about notes that a user created for other people.
 
 ## Tagging keys
-Used to compute tags in a [tagging note discovery scheme](../../../protocol-specs/private-message-delivery/private-msg-delivery#note-tagging).
+Used to compute tags in a [tagging note discovery scheme](/protocol-specs/private-message-delivery/private-msg-delivery#note-tagging).
 
 :::note
 Tagging note discovery scheme won't be present in our testnet so we are intentionally not providing you with much info yet.