Bri content (#9)

* update some docs links

* update welcome page

* added fundamentals and concepts and deleted old start directory

* new tools and sdks docs

* new glossary

* glossary -> encyclopedia

* updated encyclopedia

* Added code blocks (#10)

* Added code blocks

Please look at why it won't tab out the code blocks!

* added json5 and missing python library

Co-authored-by: Tyler van der Hoeven <hi@tyvdh.com>

* Added code blocks (#13)

* Added missing information to operations (#11)

* Added missing information to operations

Including: LPs, clawbacks, claimable balances

* Update list-of-operations.mdx

Co-authored-by: Tyler van der Hoeven <hi@tyvdh.com>

* Added code blocks (#14)

* delete some dupe content

* Added code blocks (#15)

* Added code blocks

Please look at why it won't tab out the code blocks!

* added json5 and missing python library

* Added code blocks

* spaces matter apparently

* nvm

Co-authored-by: Tyler van der Hoeven <hi@tyvdh.com>

* Added code blocks (#16)

* Added code blocks & missing link (#17)

* Added code block (#20)

* Added code blocks, edited some content (#22)

Removed Example 5 (to be added later)

* spacing tweaks

* Added code blocks (#21)

* omit CodeExample block on non code blocks

* Added code blocks (#18)

* Added code blocks

* encyclopedia

* space tweak

Co-authored-by: Tyler van der Hoeven <hi@tyvdh.com>

* Added code blocks (#19)

* Added code blocks

* removed some spaces

Co-authored-by: Tyler van der Hoeven <hi@tyvdh.com>

* missed a couple imports

* glossary -> encyclopedia

* lint

* format mdx

* no cache on the make

* case fix step 1

* case fix step 2

* fixed a link

* added another link from the hash

* Update sponsored-reserves.mdx

* Glossary-Encyclopedia network passphrases

* Anchoring assets-xborder payments links

* Update setting-up-test-server.mdx

* Update withdraw-anchored-assets.mdx

* Update custom-assets.mdx

* Update first-deposit.mdx

* Update project-setup.mdx

* Update setup-custodial-account.mdx

* Update anatomy-of-an-asset.mdx

* Update control-asset-access.mdx

* Issuing assets - control asset access

* Issuing assets - publishing asset info

* run core node - configuring links

* Update monitoring.mdx

* Tutorials - create account

* Update setting-up-production-server.mdx

* tutorials - follow received payments links

* tutorials - send and receive payments links

* run a core node - index links

* Added community (#25)

Add and update community channels

* link tweaks

* couple more tweaks

* glossary links

* issuing assets - anatomy of an asset link

* encyclopedia - claimable balance links

* encyclopedia - error handling links

* encyclopedia - fee bump links

* Update fees-surge-pricing-fee-strategies.mdx

* Update ledger-headers.mdx

* encyclopedia - flags links

* Update claimable-balances.mdx

* Update error-handling.mdx

* Update fee-bump-transactions.mdx

* encyclopedia - liquidity on stellar links

* encyclopedia - memos links

* encyclopedia - path payments links

* encyclopedia - pooled accounts links

* encyclopedia - signatures and multisig links

* encyclopedia - sponsored reserves links

* fundamentals & concepts - data strctr - accts links

* f&c - data structures - assets links

* f&c - data structures - ledgers links

* f&c - data structures - operations & transactions links

* f&c - operations links

* f&c - lumens links

* f&c - testnet&pubnet links

* updated link in pooled accounts

* added sdk library link

* minor link tweaks

* minor styling update for h4s

* oops

* updates

* Added run a core node link

* Remove link to Lumens, not relevant anymore

* Fixed a couple of links (#26)

Removed .mdx from two links to testnet/pubnet section

* Removed unnecessary )

* Added claimable balances link

* fix issuing assets link

* fixed sep1 link

* fixed links to info file and issuing assets

* attempt at the first 302

* move nginx conf stuff around

* Update redirects.conf

* Update redirects.conf

* Update nginx.conf

* Update nginx.conf

* try that?

* Update redirects.conf

* added SCP link & run api server link

* Update redirects.conf

* no need for this block

* Updating footer (#27)

* Updating footer

Change developers-community and add community links
All tools to link to dev docs tools page 
Remove get started from resources

* update footer content

Co-authored-by: Tyler van der Hoeven <hi@tyvdh.com>

* noop

* Changed links to tables for parameters&errors

* Incorporating a few suggestions to the new docs. (#28)

* Small improvements to link naming and math rendering

* add KaTeX

* Change math to use TeX

* don't update this

Co-authored-by: Tyler van der Hoeven <hi@tyvdh.com>

* tiny lint tweaks

* Update list-of-operations.mdx

* updated table links

* Updating ledgerkey definition (#29)

* move Lumens under the Stellar Data Structures directory

Co-authored-by: Bri <92327786+briwylde08@users.noreply.github.com>
Co-authored-by: George <Shaptic@users.noreply.github.com>

Dockerfile

@@ -22,4 +22,4 @@ RUN yarn build
 FROM nginx:1.17
 
 COPY --from=build /app/build/ /usr/share/nginx/html/
-COPY --from=build /app/nginx.conf /etc/nginx/conf.d/default.conf
+COPY nginx /etc/nginx/

docs/anchoring-assets/enabling-cross-border-payments/setting-up-production-server.mdx

@@ -13,7 +13,7 @@ The **RA** server code deployed to each environment should be the same, and addi
 
 Make sure to keep the test server up, and deploy the production (mainnet) system in a separate environment. Having two deployments allows you to validate new features on the testnet before deploying to production.
 
-To switch to Stellar's public (mainnet) network, all you have to do is change the network [passphrase](../../glossary/network-passphrase.mdx) (for authenticating requests) and the [Horizon URL](https://horizon.stellar.org/). Stellar SDKs have all the built-in logic to switch from test to public with minor changes to the codebase.
+To switch to Stellar's public (mainnet) network, all you have to do is change the network [passphrase](../../encyclopedia/network-passphrases.mdx) (for authenticating requests) and the [Horizon URL](https://horizon.stellar.org/). Stellar SDKs have all the built-in logic to switch from test to public with minor changes to the codebase.
 
 If you're issuing your own asset in addition of offering an on/off ramp, make sure you follow [best practices for asset issuance](../../issuing-assets/how-to-issue-an-asset.mdx) by creating a distribution account that is separate from the issuing account before distributing real assets on the public network. The issuing account secret key should be highly secured via means such as cold storage or multi-signature, and should only be used to send (and, consequently, issue) assets to the distribution account. The distribution account will be used by the **RA** server to receive assets from other accounts programmatically.
 

docs/anchoring-assets/enabling-cross-border-payments/setting-up-test-server.mdx

@@ -6,11 +6,11 @@ sidebar_position: 30
 import { CodeExample } from "@site/src/components/CodeExample";
 import { Alert } from "@site/src/components/Alert";
 
-Before setting up a server that connects to live banking rails and real money, you should build out a test rig connected to the [Stellar test network](../../glossary/testnet.mdx). The testnet works just like the main Stellar network, but it uses test data and allows you to fund test accounts for free using a tool called [Friendbot](../../glossary/testnet.mdx#friendbot).
+Before setting up a server that connects to live banking rails and real money, you should build out a test rig connected to the [Stellar test network](../../fundamentals-and-concepts/testnet-and-pubnet). The testnet works just like the main Stellar network, but it uses test data and allows you to fund test accounts for free using a tool called [Friendbot](../../fundamentals-and-concepts/testnet-and-pubnet#friendbot).
 
 <Alert>
 
-Note: the testnet is reset every three months, so when building on it, make sure you have a plan to recreate necessary accounts and other data. For more info, check out the [best practices for using the testnet](../../glossary/testnet.mdx#best-practices-for-using-testnet).
+Note: the testnet is reset every three months, so when building on it, make sure you have a plan to recreate necessary accounts and other data. For more info, check out the [best practices for using the testnet](../../fundamentals-and-concepts/testnet-and-pubnet).
 
 </Alert>
 
@@ -22,8 +22,8 @@ You can also find an outline of the basic steps anchors need to complete in the
 
 Before you start building infrastructure to connect a Stellar-network token to banking rails, you need to:
 
-1. Issue an asset on the network – which you can find out how to do in the [Issue Assets](../../issuing-assets/index.mdx/) section — or find another trustworthy issuer and coordinate with them to broker their asset.
-1. Add meta-information about the asset (if you issue one) and define the location of your `DIRECT_PAYMENT_SERVER` in your `stellar.toml` so that wallets know where to find the server and relevant endpoints. You can consult [this guide](../../issuing-assets/index.mdx/) for help completing your `stellar.toml`.
+1. Issue an asset on the network – which you can find out how to do in the [Issue Assets](../../issuing-assets) section — or find another trustworthy issuer and coordinate with them to broker their asset.
+1. Add meta-information about the asset (if you issue one) and define the location of your `DIRECT_PAYMENT_SERVER` in your `stellar.toml` so that wallets know where to find the server and relevant endpoints. You can consult [this guide](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md) for help completing your `stellar.toml`.
 
 Once you've taken those steps, you're ready to implement an `/info` endpoint.
 
@@ -91,7 +91,7 @@ The only information needed to request a challenge is the client's public key, p
 
 ### Exchanging the Signed Challenge
 
-Once the client signs the challenge transaction on behalf of the user using standard [Stellar SDK tools](../../software-and-sdks/index.mdx), it sends the signed transaction back to the provider. Using those same Stellar SDKs, the provider then checks to see if the transaction is properly signed, and if it is, offers the client a JWT.
+Once the client signs the challenge transaction on behalf of the user using standard [Stellar SDK tools](../../tools-and-sdks#sdk-library), it sends the signed transaction back to the provider. Using those same Stellar SDKs, the provider then checks to see if the transaction is properly signed, and if it is, offers the client a JWT.
 
 This JWT should be created with the claims that are appropriate given the account that signed the challenge. It can be created with any existing JWT library.
 

docs/anchoring-assets/enabling-deposit-and-withdrawal/setting-up-production-server.mdx

@@ -9,7 +9,7 @@ Once the test server is live and you have tested both deposit and withdraw flows
 
 Make sure to keep the test server up, and deploy the production (mainnet) system in a separate environment. Having two deploys allows you to validate new features on the testnet before moving them to the final production deploy. You can also have a third staging environment if there's a big team working on this codebase and/or there will be many pushes to be tested internally before sharing with other institutions.
 
-To switch to Stellar's public (mainnet) network, all you have to do is change the network [passphrase](../../glossary/network-passphrase.mdx) (for authenticating requests) and [Horizon URL](https://horizon.stellar.org/). Stellar SDKs have all the built-in logic to switch from test to public with minor changes to the codebase.
+To switch to Stellar's public (mainnet) network, all you have to do is change the network [passphrase](../../encyclopedia/network-passphrases.mdx) (for authenticating requests) and [Horizon URL](https://horizon.stellar.org/). Stellar SDKs have all the built-in logic to switch from test to public with minor changes to the codebase.
 
 If you're issuing your own asset in addition of offering an on/off ramp, make sure you follow [best practices for asset issuance](../../issuing-assets/how-to-issue-an-asset.mdx) by creating a distribution account that is separate from the issuing account before distributing real assets on the public network. The issuing account secret key should be highly secured via means such as cold storage or multi-signature, and should only be used to send (and, consequently, issue) assets to the distribution account. The distribution account will be used by your server to send (and receive) assets to other accounts programmatically.
 

docs/anchoring-assets/enabling-deposit-and-withdrawal/setting-up-test-server.mdx

@@ -6,11 +6,11 @@ sidebar_position: 30
 import { CodeExample } from "@site/src/components/CodeExample";
 import { Alert } from "@site/src/components/Alert";
 
-Before setting up a server that connects to live banking rails and real money, you should build out a test rig connected to the [Stellar test network](../../glossary/testnet.mdx). The testnet works just like the main Stellar network, but it uses test data and allows you to fund test accounts for free using a tool called [Friendbot](../../glossary/testnet.mdx#what-is-the-stellar-testnet-good-for).
+Before setting up a server that connects to live banking rails and real money, you should build out a test rig connected to the [Stellar test network](../../fundamentals-and-concepts/testnet-and-pubnet.mdx). The testnet works just like the main Stellar network, but it uses test data and allows you to fund test accounts for free using a tool called [Friendbot](../../fundamentals-and-concepts/testnet-and-pubnet.mdx#friendbot).
 
 <Alert>
 
-Note: the testnet is reset every three months, so when building on it, make sure you have a plan to recreate necessary accounts and other data. For more info, check out the [best practices for using the testnet](../../glossary/testnet.mdx#best-practices-for-using-testnet).
+Note: the testnet is reset every three months, so when building on it, make sure you have a plan to recreate necessary accounts and other data. For more info, check out the [best practices for using the testnet](../../fundamentals-and-concepts/testnet-and-pubnet.mdx).
 
 </Alert>
 
@@ -22,8 +22,8 @@ You can also find an outline of the basic steps anchors need to complete in the
 
 Before you start building infrastructure to connect a Stellar-network token to banking rails, you need to:
 
-1. Issue an asset on the network – which you can find out how to do in the [Issue Assets](../../issuing-assets/index.mdx/) section — or find another trustworthy issuer and coordinate with them to broker their asset.
-1. Add meta-information about the asset (if you issue one) and define the location of your `TRANSFER_SERVER_SEP0024` in your `stellar.toml` so that wallets know where to find the server and relevant endpoints. You can consult [this guide](../../issuing-assets/index.mdx/) for help completing your `stellar.toml`.
+1. Issue an asset on the network – which you can find out how to do in the [Issue Assets](../../issuing-assets) section — or find another trustworthy issuer and coordinate with them to broker their asset.
+1. Add meta-information about the asset (if you issue one) and define the location of your `TRANSFER_SERVER_SEP0024` in your `stellar.toml` so that wallets know where to find the server and relevant endpoints. You can consult [this guide](../../issuing-assets/publishing-asset-info) for help completing your `stellar.toml`.
 
 Once you've taken those steps, you're ready to implement an `/info` endpoint.
 
@@ -97,7 +97,7 @@ The only information needed to request a challenge is the client's public key, p
 
 ### Exchanging the Signed Challenge
 
-Once the client signs the challenge transaction on behalf of the user using standard [Stellar SDK tools](../../software-and-sdks/index.mdx), it sends the signed transaction back to the provider. Using those same Stellar SDKs, the provider then checks to see if the transaction is properly signed, and if it is, offers the client a JWT.
+Once the client signs the challenge transaction on behalf of the user using standard [Stellar SDK tools](../../tools-and-sdks.mdx#sdk-library), it sends the signed transaction back to the provider. Using those same Stellar SDKs, the provider then checks to see if the transaction is properly signed, and if it is, offers the client a JWT.
 
 This JWT should be created with the claims that are appropriate given the account that signed the challenge. It can be created with any existing JWT library.
 

docs/building-apps/connect-to-anchors/withdraw-anchored-assets.mdx

@@ -289,7 +289,7 @@ First thing we’ll see is the use of a Promise. This allows us to respond to an
 
 </CodeExample>
 
-Otherwise if the transaction status is `pending_user_transfer_start` and we haven’t yet submitted a transaction to the Anchor, we attempt that. We load up the user's account to get the next valid sequence number, and build a Stellar [transaction](../../glossary/transactions.mdx) consisting of a [payment operation](../../glossary/operations.mdx) with all the details from the transaction object that the anchor is expecting. Once we have a valid transaction built, we’ll sign it with the keypair, submit the transaction to the network, and wait for a response. If the transaction is successful, we save that value to `submittedTxn` and reload the anchor popup to observe the pending status. Make sure to set the `submittedTxn` to a truthy value or else you run the risk of submitting the transaction multiple times, as the anchor may take a moment to realize you’ve successfully submitted a transaction to them.
+Otherwise if the transaction status is `pending_user_transfer_start` and we haven’t yet submitted a transaction to the Anchor, we attempt that. We load up the user's account to get the next valid sequence number, and build a Stellar [transaction](../../fundamentals-and-concepts/stellar-data-structures/operations-and-transactions.mdx#transactions) consisting of a [payment operation](../../fundamentals-and-concepts/stellar-data-structures/operations-and-transactions.mdx#operations) with all the details from the transaction object that the anchor is expecting. Once we have a valid transaction built, we’ll sign it with the keypair, submit the transaction to the network, and wait for a response. If the transaction is successful, we save that value to `submittedTxn` and reload the anchor popup to observe the pending status. Make sure to set the `submittedTxn` to a truthy value or else you run the risk of submitting the transaction multiple times, as the anchor may take a moment to realize you’ve successfully submitted a transaction to them.
 
 <CodeExample>
 

docs/building-apps/custom-assets.mdx

@@ -18,7 +18,7 @@ In this section of the tutorial, we'll add the ability to hold and transfer cust
 
 Stellar allows anyone to easily issue an asset, and all assets can be held, transferred, and traded just like XLM, the network token. Every asset _other_ than XLM exists on the network in the form of trustlines: an asset holder explicitly agrees to allow a balance of a specific token issued by a specific issuing account by creating a persistent ledger entry tied to the holding account. You can find out more in the guide to [creating custom assets](../issuing-assets/index.mdx).
 
-Each trustline increases the user's [base reserve](../glossary/minimum-balance.mdx) by 0.5 XLM, and in this tutorial, we'll go over how to set up your wallet to create trustlines and manage the base reserve on behalf of a user.
+Each trustline increases the user's [base reserve](../fundamentals-and-concepts/lumens#base-reserves) by 0.5 XLM, and in this tutorial, we'll go over how to set up your wallet to create trustlines and manage the base reserve on behalf of a user.
 
 ## Add Trustlines Button
 

docs/building-apps/first-deposit.mdx

@@ -5,7 +5,7 @@ sidebar_position: 65
 
 In this section, we will go over the new user account creation flow between non-custodial wallets and anchors with SEP-24 and/or SEP-6 implementations. Before we dive into the flow, it’s important to understand how Stellar accounts are created in the first place.
 
-The first step in creating a Stellar account is to generate a keypair. This keypair includes public and private keys. However, an account does not exist and does not warrant space on the ledger until it’s funded with the minimum balance of 1XLM by a [Create Account](../start/list-of-operations.mdx#create-acccount) operation. This requirement was created to minimize unused accounts from bloating the ledger. For a more in-depth look at this topic, check out this [page](../tutorials/create-account.mdx).
+The first step in creating a Stellar account is to generate a keypair. This keypair includes public and private keys. However, an account does not exist and does not warrant space on the ledger until it’s funded with the minimum balance of 1XLM by a [Create Account](../fundamentals-and-concepts/list-of-operations.mdx#create-account) operation. This requirement was created to minimize unused accounts from bloating the ledger. For a more in-depth look at this topic, check out this [page](../tutorials/create-account.mdx).
 
 ## Who creates the new user accounts?
 
@@ -28,7 +28,7 @@ For this option, the wallet needs to allow users to initiate their first deposit
 
 ![anchor creates account flow](/assets/first-deposit-anchor-flow.png)
 
-With the flow described above, the wallet and the anchor have to facilitate listening for and responding to the trustline status, which can create user experience frictions when waiting for the trustline to be established. To address this issue, Protocol 15 introduced [Claimable Balances](../glossary/claimable-balance.mdx), which enhance the flow by allowing users to start using the wallet without having to secure XLM wait to create the trustline after they made their first deposit. Both the wallet and the anchor have to implement Claimable Balance support in order to make this flow work.
+With the flow described above, the wallet and the anchor have to facilitate listening for and responding to the trustline status, which can create user experience frictions when waiting for the trustline to be established. To address this issue, Protocol 15 introduced [Claimable Balances](../encyclopedia/claimable-balances.mdx), which enhance the flow by allowing users to start using the wallet without having to secure XLM wait to create the trustline after they made their first deposit. Both the wallet and the anchor have to implement Claimable Balance support in order to make this flow work.
 
 The flow with Claimable Balances looks like this:
 
@@ -44,7 +44,7 @@ The flow with Claimable Balances looks like this:
 
 ### Option 2: The wallet creates and funds the Stellar account upon user sign-up
 
-For this option, the wallet creates and funds the Stellar account upon every new user sign-up with the minimum requirement of 1XLM, plus the .5XLM reserve for establishing the first trustline, plus a bit more to cover transaction fees. For more information on minimum balances, check out the [glossary entry](../glossary/minimum-balance.mdx).
+For this option, the wallet creates and funds the Stellar account upon every new user sign-up with the minimum requirement of 1XLM, plus the .5XLM reserve for establishing the first trustline, plus a bit more to cover transaction fees. For more information on minimum balances, check out the [Lumens section](../fundamentals-and-concepts/lumens.mdx#minimum-balance).
 
 The flow looks like this:
 
@@ -57,4 +57,4 @@ The flow looks like this:
 
 ![wallet creates account flow](/assets/first-deposit-wallet-flow.png)
 
-**Note**: In the examples above, we suggest having the anchor or wallet cover minimum balance and trustline XLM requirements by depositing funds directly into a user's account. We made that suggestion for the sake of simplicity, but in all cases, the anchor or wallet could instead use [Sponsored Reserves](../glossary/sponsored-reserves.mdx) to ensure that when a user closes a trustline or merges their account, the reserve reverts to the sponsoring account rather than to the user's account.
+**Note**: In the examples above, we suggest having the anchor or wallet cover minimum balance and trustline XLM requirements by depositing funds directly into a user's account. We made that suggestion for the sake of simplicity, but in all cases, the anchor or wallet could instead use [Sponsored Reserves](../encyclopedia/sponsored-reserves.mdx) to ensure that when a user closes a trustline or merges their account, the reserve reverts to the sponsoring account rather than to the user's account.

docs/building-apps/project-setup.mdx

@@ -488,5 +488,5 @@ $ npm start
 
 [View the full setup code on GitHub][2]
 
-[1]: ../software-and-sdks/index.mdx
+[1]: ../tools-and-sdks.mdx#sdk-library
 [2]: https://github.com/stellar/docs-wallet/tree/setup