Docs redesign and reorg (#60)

* flattened architecture of the docs for SDK reference, ecosystem, and support. Core concepts at top level folders for Access Control, PKP, and Lit Actions.

---------

Co-authored-by: debie <[email protected]>
Co-authored-by: sarahzdev <[email protected]>
Co-authored-by: sarah z <[email protected]>

.husky/pre-commit

@@ -3,4 +3,4 @@
 
 yarn install
 yarn update-chains
-git add docs/support/supportedChains.md
+git add docs/resources/supportedChains.md

README.md

@@ -1,7 +1,9 @@
-# Website
+# Lit Protocol Developer Docs 📚
 
 This website is built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
 
+## 💻 Setup
+
 ### Installation
 
 ```
@@ -31,3 +33,71 @@ $ GIT_USER=<Your GitHub username> USE_SSH=true yarn deploy
 ```
 
 If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.
+
+<br/>
+
+## ✨ Workflow
+
+When adding new content or re-organizing existing content, please be sure to update the sidebar file `sidebars.js`.
+
+To create a top-level, **noncollapsible** category like `Getting Started`, add the following to the `docs` array:
+
+```js
+docs: [
+  // ...
+  {
+    type: 'category',
+    label: 'Tea Drinks',
+    collapsible: false,
+    className: 'category-not-collapsible',
+    items: [
+      // Add the IDs of your new category's pages here
+      'tea-drinks/intro',
+    ],
+  }
+]
+```
+
+To add a subcategory, add the category object to the `items` array:
+
+```js
+docs: [
+  // ...
+  {
+    type: 'category',
+    label: 'Tea Drinks',
+    collapsible: false,
+    className: 'category-not-collapsible',
+    items: [
+      'tea-drinks/intro',
+      // Add your new subcategory here
+      {
+        type: 'category',
+        label: 'Hot Drinks',
+        collapsed: true,
+        items: [
+          // Add the IDs of your new subcategory's pages here
+          'tea-drinks/hot-drinks/intro',
+        ],
+      },
+    ],
+  }
+]
+```
+
+To create a top-level, *collapsible* category like `Access Control`, add the following to the `docs` array:
+
+```js
+docs: [
+  // ...
+  {
+    type: 'category',
+    label: 'Coffee Drinks',
+    collapsed: true,
+    items: [
+      // Add the IDs of your new category's pages here
+      'coffee-drinks/intro',
+    ],
+  }
+]
+```

docs/coreConcepts/LitActionsAndPKPs/bestPractices.md → docs/LitActions/bestPractices.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 5
+sidebar_position: 2
 ---
 
 # Best Practices
@@ -11,9 +11,9 @@ It is NOT recommended to use the Lit JS SDK within a Lit Action due to the poten
 
 ## Ideal Use Cases
 
-- [Generating proofs](/coreConcepts/LitActionsAndPKPs/litActions#proofs)
-- Looking up permitted actions, addresses and [auth methods](/SDK/Explanation/LitActions/authHelpers.md) associated with a PKP
-- Checking access control conditions with [conditional signing](/SDK/Explanation/LitActions/conditionalSigning.md)
+- [Generating proofs](/LitActions/intro#proofs)
+- Looking up permitted actions, addresses and [auth methods](/pkp/authHelpers) associated with a PKP
+- Checking access control conditions with [conditional signing](/LitActions/conditionalSigning)
 
 ## Think Twice Use Case
 - POST request that inserts a new SQL row (as the Lit Action will be executed by *every* node in parallel, you will end up with n number of rows, where n is no less than two-thirds the number of total nodes in the Lit network) 

docs/coreConcepts/LitActionsAndPKPs/actions/conditionalSigning.md → docs/LitActions/conditionalSigning.md

@@ -1,13 +1,13 @@
 ---
-sidebar_position: 2
+sidebar_position: 5
 ---
 
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
 # Conditional Signing
 
-Lit Actions inherit the powerful condition checking that Lit Protocol utilizes for Access Control. This means that you can easily check any on-chain condition inside a Lit Action, which can be useful for [generating proofs](/coreConcepts/LitActionsAndPKPs/litActions#proofs). This system can be harnessed to uphold the integrity of data on the open web, in its function as a decentralized notary. 
+Lit Actions inherit the powerful condition checking that Lit Protocol utilizes for Access Control. This means that you can easily check any on-chain condition inside a Lit Action, which can be useful for [generating proofs](/LitActions/intro#proofs). This system can be harnessed to uphold the integrity of data on the open web, in its function as a decentralized notary. 
 
 The below example will check if the user has at least 1 Wei on Ethereum, only returning a signature if they do.
 

docs/ToolsAndExamples/Tools/getlitCli.md → docs/LitActions/getlitCli.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 5
+sidebar_position: 2
 ---
 
 # GetLit CLI

docs/SDK/Explanation/LitActions/helloWorld.md → docs/LitActions/helloWorld.md

@@ -1,11 +1,11 @@
 ---
-sidebar_position: 1
+sidebar_position: 3
 ---
 
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-# Installation
+# Hello World
 
 :::note
 
@@ -20,11 +20,11 @@ Need some Polygon Mumbai Tokens to mint a PKP? Fill out this [form](https://form
 
 :::
 
-Lit Actions are JavaScript programs used to define arbitrary signing conditions for [PKPs](/coreConcepts/LitActionsAndPKPs/PKPs.md). In other words, they are the immutable "rules" that dictate _what_ or _who_ has permission to sign using a particular PKP.
+Lit Actions are JavaScript programs used to define arbitrary signing conditions for [PKPs](/pkp/intro). In other words, they are the immutable "rules" that dictate _what_ or _who_ has permission to sign using a particular PKP.
 
 To create a Lit Action, all you need to do is write some JavaScript code that will accomplish your goals. The Lit Protocol provides JS function bindings to do things like request a signature or check an arbitrary condition. If you need to include dependencies like NPM packages, use a bundler like Webpack or ESBuild to create a single JS file and provide that bundle as your Lit Action.
 
-In order to collect the responses from the Lit nodes, you'll also need to write some client side JS. This will allow you to combine the collected key shares [above the threshold](/Introduction/howItWorks.md) to form the complete signature.
+In order to collect the responses from the Lit nodes, you'll also need to write some client side JS. This will allow you to combine the collected key shares [above the threshold](/resources/howItWorks) to form the complete signature.
 
 In the example below, we will write a simple Lit Action that requests a signature from the Lit nodes on the string "Hello World".
 

docs/coreConcepts/LitActionsAndPKPs/actions/litActions.md → docs/LitActions/intro.md

@@ -2,13 +2,13 @@
 sidebar_position: 1
 ---
 
-# What are Lit Actions
+# Introduction
 
 :::note
 
 Lit Actions are still heavily in development and things may change. We're grateful for [feedback](https://forms.gle/4UJNRcQspZyvsTHt8) on how to improve the docs and examples!
 
-To start developing with Lit Actions, check out examples [here](/SDK/Explanation/LitActions/helloWorld). For an in-depth review of the functionality provided by the Lit Actions SDK, take a look at our [API docs](https://actions-docs.litprotocol.com/).
+To start developing with Lit Actions, check out examples [here](/LitActions/helloWorld). For an in-depth review of the functionality provided by the Lit Actions SDK, take a look at our [API docs](https://actions-docs.litprotocol.com/).
 
 :::
 
@@ -56,6 +56,6 @@ No, but without it, Lit Actions lose their capabilities of signing and decryptio
 
 ## Getting started with Lit Actions
 
-Get started with Lit Actions [here](/SDK/Explanation/LitActions/helloWorld).
+Get started with Lit Actions [here](/LitActions/helloWorld).
 
-More [examples](/coreConcepts/usecases#programmatic-signing-lit-actions-and-pkps).
+More [examples](/startHere/usecases#programmatic-signing-lit-actions-and-pkps).

docs/SDK/Explanation/LitActions/logAndReturn.md → docs/LitActions/logAndReturn.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 3
+sidebar_position: 4
 ---
 
 import Tabs from '@theme/Tabs';

docs/SDK/Explanation/LitActions/usingEIP.md → docs/LitActions/usingEIP.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 2
+sidebar_position: 5
 ---
 
 import Tabs from '@theme/Tabs';

docs/coreConcepts/LitActionsAndPKPs/actions/usingFetch.md → docs/LitActions/usingFetch.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 3
+sidebar_position: 4
 ---
 
 import Tabs from '@theme/Tabs';

docs/coreConcepts/LitActionsAndPKPs/intro.md → docs/LitActions/usingPKPsAndActions.md

@@ -1,8 +1,8 @@
 ---
-sidebar_position: 2
+sidebar_position: 3
 ---
 
-# Introduction
+# Using PKPs and Lit Actions Together
 
 :::note
 
@@ -18,27 +18,6 @@ Need some Polygon Mumbai Tokens to [mint](https://explorer.litprotocol.com/mint-
 
 As a distributed key management network, Lit provides developers with the ability to add programmable signing to their applications and wallets. These distributed wallets are known as Programmable Key Pairs (PKP) and the application logic that dictates when and why that key-pair will sign is known as a Lit Action.
 
-## Programmable Key Pairs (PKPs)
-
-PKPs are public/private key-pairs generated in a process called Distributed Key Generation. This allows each node in the Lit network to custody a share of the underlying keypair. Currently, ownership of a given PKP is represented by the ownership of a NFT. Only those with authorized access (such as holding the PKP NFT) can sign or delegate signing to a Lit Action.
-
-Development is underway to add support for additional authorization and authentication methods, such as Google oAuth, Discord oAuth, and Apple Passkey. This will allow users to login to the decentralized Web with distributed multi-factor authentication, helping facilitate more seamless onboarding experiences for non crypto natives by abstracting away the complexities present in the current UX surrounding web3 wallets. You can learn more about these updates in the [docs](/coreConcepts/LitActionsAndPKPs/actions/authHelpers) or on our [blog](https://spark.litprotocol.com/wallet-abstraction-with-google-oauth/).
-
-PKPs can also be used for additional use-cases beyond user wallets. For example, using a PKP as an immutable serverless signer that adheres to predefined rules (a Lit Action).
-
-Continue reading about PKPs [here](/coreConcepts/LitActionsAndPKPs/PKPs.md).
-
-## Lit Actions
-
-When someone holds a PKP, they can delegate the rights to sign via the wallet to some application logic, this logic is specified in a Lit Action.
-
-Lit Actions are immutable JavaScript programs that run across the network to sign data via a PKP. In this way they can be thought of as the permissionless rules that govern each PKP’s signing automation.
-Actions are blockchain agnostic, giving them the inherent capacity to communicate data across blockchains. This facilitates interoperability between previously disconnected ecosystems.
-
-They can also use off-chain data sources in their computation by making arbitrary [HTTP requests](/SDK/Explanation/LitActions/usingFetch). For example, calling an off-chain price feed (via API) for potential oracle or [conditional signing](/SDK/Explanation/LitActions/conditionalSigning) use cases.
-
-Get started with Lit Actions [here](/coreConcepts/LitActionsAndPKPs/litActions.md).
-
 ## How do Lit Actions and PKPs work together?
 
 A user can create a new PKP and grant a Lit Action the right to sign using it. This means the distributed key has the ability to sign and decrypt arbitrary data based on pre-defined logic and conditions.
@@ -65,7 +44,7 @@ We do not recommend storing anything of value on the Serrano Testnet.
 
 ## Sending the PKP to itself
 
-Sending a PKP to itself is possible, because the PKP is an NFT and also a wallet. This is useful if you want to make sure that only the PKP itself can change it's auth methods. To learn how auth works, read more [here](/coreConcepts/LitActionsAndPKPs/actions/authHelpers). You can also use our handy auth helper contract on Polygon Mumbai [here](https://github.com/LIT-Protocol/LitNodeContracts/blob/main/contracts/PKPHelper.sol) and you can find the contract addresses [here](https://explorer.litprotocol.com/contracts), and if you use that contract there is a parameter called `sendPkpToItself` in the `mintNextAndAddAuthMethods` function that you can set to true to send the PKP to itself.
+Sending a PKP to itself is possible, because the PKP is an NFT and also a wallet. This is useful if you want to make sure that only the PKP itself can change it's auth methods. To learn how auth works, read more [here](/pkp/authHelpers). You can also use our handy auth helper contract on Polygon Mumbai [here](https://github.com/LIT-Protocol/LitNodeContracts/blob/main/contracts/PKPHelper.sol) and you can find the contract addresses [here](https://explorer.litprotocol.com/contracts), and if you use that contract there is a parameter called `sendPkpToItself` in the `mintNextAndAddAuthMethods` function that you can set to true to send the PKP to itself.
 
 ## What is Mint/Grant/Burn?
 

docs/SDK/Explanation/tests.md

@@ -77,7 +77,7 @@ Errors are thrown as exceptions when something has gone wrong. Errors are object
 |NodeResourceIdNotFound|Invalid resourceId param.|
 |NodeRpcError|Error making the call to RPC url for the passed chain param. Please ensure that the contract call that you're making is correct including the contract address & it's passed params. Especially ensure the correctness of the functionAbi if you're using Custom Contract calls.|
 |NodeStorageError|An error occured while storing the encryption condition. Please look at the returned error for more info.|
-|NodeWrongNetwork|Either you didn't pass a chain param or it's invalid/not supported yet. Please see all the supported chain here: https://developer.litprotocol.com/support/supportedchains/|
+|NodeWrongNetwork|Either you didn't pass a chain param or it's invalid/not supported yet. Please see all the supported chain [here](/resources/supportedchains/)|
 |NodeHTTPConversionError|Internal error with the RPC url for the provided chain param. Please try again. If this error persists contact us on Discord.|
 |NodeUnknownError|An unknow error occured. Please try again. If this error persists contact us on Discord.|
 |NodeParserError|Error parsing a provided param. Please look at the returned error for more info.|
@@ -86,7 +86,7 @@ Errors are thrown as exceptions when something has gone wrong. Errors are object
 |NodeSIWESigConversionError|Invalid SIWE capability's sig param. Please look at the returned error for more info.|
 |NodeSIWESessionKeySignatureInvalid|session.pubkey isn't signed in the wallet-signed SIWE message.|
 |NodeBlockchainError|Error making an on-chain call. Please look at the returned error for more info.|
-|NodeBlockchainChainUnknown|Invalid chain value for the provided Authsig.sig param. Please see all the supported chain here: https://developer.litprotocol.com/support/supportedchains/|
+|NodeBlockchainChainUnknown|Invalid chain value for the provided Authsig.sig param. Please see all the supported chain [here](/resources/supportedchains/)]|
 |NodeWalletSignatureJSONError|Error parsing Authsig. Please look at the returned error for more info.|
 |NodePOAPJSONError|Internal error parsing POAP as a JSON. Please try again. If this error persists contact us on Discord.|
 |NodeCosmosJSONError|Error parsing Cosmos result. Please ensure that the Cosmos condition passed is correct.|

docs/SDK/_category_.json

@@ -1,4 +1,4 @@
 {
-  "label": "SDK",
+  "label": "SDK Reference",
   "position": 4
 }

docs/Support/faq.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 1
+sidebar_position: 2
 ---
 
 # FAQ
@@ -34,7 +34,7 @@ An authentication method refers to the specific credential (i.e a wallet address
 Authorization is through auth signatures - an auth sig is always required when making a request to Lit, whether it be decrypting some piece of content or sending a transaction with a PKP.  
 
 ### Is it possible to define an access control condition that requires a signature generated by a Lit Action?
-You can start by minting a PKP and granting permission to your Lit Action to sign using it. Since each PKP is a valid Ethereum wallet, your Access Control Condition should be checking for ownership of a particular wallet address. For this context, the public address of the PKP should be passed in as your [parameter](https://developer.litprotocol.com/coreConcepts/accessControl/EVM/basicExamples#a-specific-wallet-address). You can configure your Lit Action to create an SIWE AuthSig using the PKP, only if your conditions have been met. 
+You can start by minting a PKP and granting permission to your Lit Action to sign using it. Since each PKP is a valid Ethereum wallet, your Access Control Condition should be checking for ownership of a particular wallet address. For this context, the public address of the PKP should be passed in as your [parameter](/accessControl/EVM/basicExamples#a-specific-wallet-address). You can configure your Lit Action to create an SIWE AuthSig using the PKP, only if your conditions have been met. 
 
 We are currently working on implementing a more direct solution for using Lit Actions and ACCs together, allowing users to define ACCs that provision access based on the result of any Lit Action. This will enable the generation of more complex ACCs and the use of off-chain data in your conditions.
 Before this solution has been released (ETA ~1 month) make sure you set the expiration time in the SIWE Auth Sig to something short so that the user can't take it and pass it around to others who shouldn’t have access.
@@ -60,7 +60,7 @@ Yes, you most certainly can. The following link provides an example of how this
 
 ### 5. Can more than one condition be added for access control?
 
-Yes! See https://developer.litprotocol.com/docs/AccessControlConditions/booleanLogic for examples.
+Yes! See [boolean logic](/accessControl/conditionTypes/booleanLogic) for examples.
 
 ### 6. Can I delete or edit a published resourceId?
 

docs/Introduction/stateOfNetwork.md → docs/Support/stateOfNetwork.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 3
+sidebar_position: 1
 ---
 
 # State of the Network
@@ -12,4 +12,4 @@ Right now, Lit Protocol is in an alpha mainnet state (the "Jalapeno Mainnet") an
 
 The Lit Actions and PKP network (the "Serrano Testnet") is in a developer preview state.
 
-The data on the Serrano Testnet is not persistent and may be erased at any time. Therefore, we do not recommend storing anything of value on the Serrano Testnet. You may use the Serrano Testnet by installing the latest `@lit-protocol/lit-node-client` package and specifying `litNetwork: "serrano"` in your `LitNodeClient` config.
+The data on the Serrano Testnet is not persistent and may be erased at any time. Therefore, we do not recommend storing anything of value on the Serrano Testnet. You may use the Serrano testnet by installing the latest `@lit-protocol/lit-node-client` package and specifying `litNetwork: "serrano"` in your `LitNodeClient` config. You can find more info in the [Lit Actions](/LitActions/intro) sections of the docs.

docs/ToolsAndExamples/Integrations/bundlrxarweave.md

@@ -62,7 +62,7 @@ Turn the static content into a `String` format (you can use the [utilities](http
 
 The symmetricKey is necessary to decrypt content and is meant to be private. Exposing the key to the public means anyone may be able to use it to decrypt private information. Luckily, with Lit Protocol, we can encrypt it and store it in the lit nodes, so that only the person who meets the access control conditions could retrieve the original symmetric key. In order to do this, we will need to pass in the following:
 
-`chain (String)`: ethereum (see other [supported blockchains](https://developer.litprotocol.com/support/supportedChains))
+`chain (String)`: ethereum (see other [supported blockchains](https://developer.litprotocol.com/resources/supportedChains))
 
 `authSig (Object)`: authentication signature, which can be collected from calling await LitJsSdk.checkAndSignAuthMessage({chain}) which will call up your web 3 wallets for you to sign the message
 

docs/coreConcepts/accessControl/EVM/basicExamples.md → docs/accessControl/EVM/basicExamples.md

@@ -6,7 +6,7 @@ sidebar_position: 2
 
 This page defines some basic access control conditions (referred to as `accessControlConditions` in the code) based on standard contract types like ERC20, ERC721, and ERC1155 for EVM (Ethereum) chains. Also included are some conditions like wallet address ownership, proof of humanity, and POAP possession. You may set your conditions, and define the `returnValueTest` under which access should be granted.
 
-If you would like to use a contract call for a contract type that is not here, refer to the [custom contract calls](/coreConcepts/accessControl/EVM/customContractCalls) page, which will let you pass a function ABI and call any smart contract function. These are referred to as `evmContractConditions` in the code.
+If you would like to use a contract call for a contract type that is not here, refer to the [custom contract calls](/accessControl/EVM/customContractCalls) page, which will let you pass a function ABI and call any smart contract function. These are referred to as `evmContractConditions` in the code.
 
 ## Must posess at least one ERC1155 token with a given token id