Resolved build warnings (with explicit header ids)

TODO.md

@@ -15,4 +15,5 @@ TODO:
 * rename repo landing-page -> website
 * archive old documentation website
 * What to do with drafts etc?
-* Check Docusaurus warnings
+* Check Docusaurus warnings
+* Removed current landing page folder "old"

blog/2023-09-19-tlsnotary-updates/index.md

@@ -95,7 +95,7 @@ In this configuration, the Verifier acts as a proxy and simply records the encry
 
 This approach is quite viable and is one which other teams are pursuing. However, it comes with a different set of security assumptions. Rather than relying just on cryptographic assumptions, the proxy approach also makes _network topology_ assumptions. It assumes that the Verifier has a direct connection to the Server, and that a malicious Prover can not bypass or otherwise insert themselves in-between the Verifier and Server. As the Prover holds the full TLS session keys, if they are able to invalidate this assumption it completely breaks the integrity of the protocol.
 
-As explained in the above [section on Notaries](#General-purpose-Verifier-Notary), we find the ability to hide the identity of the Server from the Verifier important. This is clearly not possible with this model.
+As explained in the above [section on Notaries](#general-purpose-verifier-notary), we find the ability to hide the identity of the Server from the Verifier important. This is clearly not possible with this model.
 
 To be fair, there are viable mitigations to network attacks and in many scenarios these assumptions are acceptable. We look forward to seeing what is unlocked with the application of this model, as the simplicity and efficiency of this approach is enticing.
 

docs/faq.md

@@ -79,7 +79,7 @@ knows the secret key the `Server` uses to authenticate data and can trivially ge
 
 The `Verifier` collaborates with the `Prover` using secure multi-party computation (MPC). There is no requirement for the `Verifier` to monitor or to access the `Prover's` TLS connection. The `Prover` is the one who communicates with the server.
 
-### What are the trust assumptions of the TLSNotary protocol? 
+### What are the trust assumptions of the TLSNotary protocol? {#faq2}
 
 The protocol does not have trust assumptions. In particular, it does not rely on secure hardware or on the untamperability of the communication channel.
 
@@ -127,7 +127,7 @@ If you are experiencing slow performance or server timeouts, make sure you are b
 ```
 cargo run --release
 ```
-### How to run TLSNotary with extra logging? 
+### How to run TLSNotary with extra logging? {#faq11}
 
 To get deeper insights into what TLSNotary is doing, you can enable extra logging with `RUST_LOG=debug` or `RUST_LOG=trace`. This will generate a lot of output, as it logs extensive network activity. It’s recommended to filter logs for better readability. The recommended configuration is:
 ```

docs/mpc/mac.md

@@ -2,14 +2,13 @@
 sidebar_position: 5
 sidebar_label: MAC
 ---
+import TOCInline from '@theme/TOCInline';
+
 # Computing MAC in 2PC
 
-1. [What is a MAC](#section1)
-2. [How a MAC is computed in AES-GCM](#section2)
-3. [Computing MAC using secure two-party computation (2PC)](#section3) 
+<TOCInline toc={toc} maxHeadingLevel={2} />
 
-
-## 1. What is a MAC <a name="section1"></a>
+## 1. What is a MAC
 
 When sending an encrypted ciphertext to the Webserver, the User attaches a
 checksum to it. The Webserver uses this checksum to check whether the ciphertext
@@ -26,7 +25,7 @@ malicious actor to modify the **plaintext** by flipping certain bits of the
 **ciphertext**.
 
 
-## 2. How a MAC is computed in AES-GCM <a name="section2"></a>
+## 2. How a MAC is computed in AES-GCM
 
 In TLS the plaintext is split up into chunks called "TLS records". Each TLS
 record is encrypted and a MAC is computed for the ciphertext. The MAC (in
@@ -76,7 +75,7 @@ Standard math properties hold in finite field math, viz. commutative: $a+b=b+a$
 and distributive: $a(b+c)=ab+ac$.
 
 
-## 3. Computing MAC using secure two-party computation (2PC) <a name="section3"></a>
+## 3. Computing MAC using secure two-party computation (2PC)
 
 The goal of the protocol is to compute the MAC in such a way that neither party
 would learn the other party's share of $H$ i.e. the `GHASH key`

docs/notary_server.md

@@ -58,7 +58,7 @@ docker run --init -p 127.0.0.1:7047:7047 ghcr.io/tlsnotary/tlsn/notary-server:<v
 ```
 
 ## API Endpoints
-Please refer to the list of all HTTP APIs [here](../../swagger-ui/notary_server_api.html), and WebSocket APIs [here](https://github.com/tlsnotary/tlsn/tree/main/crates/notary/server#websocket-apis).
+Please refer to the list of all HTTP APIs [here](pathname:///swagger-ui/notary_server_api.html), and WebSocket APIs [here](https://github.com/tlsnotary/tlsn/tree/main/crates/notary/server#websocket-apis).
 
 ## PSE Development Notary Server
 

docs/quick_start/README.md

@@ -32,7 +32,7 @@ Visit [demo.tlsnotary.org](https://demo.tlsnotary.org) to try the different step
 
 Learn how to use TLSNotary in a React/Typescript app with the `tlsn-js` NPM module.
 
-[Proving and Verifying Data in a React/Typescript App](tlsn-js.md#browser)
+[Proving and Verifying Data in a React/Typescript App](tlsn-js.md#react-ts-webpack)
 
 ### Browser Extension
 

docs/quick_start/browser_extension.md

@@ -8,7 +8,7 @@ In this quick start we will prove ownership of a Twitter account with TLSNotary'
 
 Optionaly you can [install](#install) and configure a local [websocket proxy](#proxy) and local [notary server](#notary-server).
 
-## Install Browser Extension (Chrome/Brave) <a name="install"></a>
+## Install Browser Extension (Chrome/Brave) {#install}
 
 The easiest way to install the TLSN browser extension is to use **[Chrome Web Store](https://chromewebstore.google.com/detail/gcfkkledipjbgdbimfpijgbkhajiaaph)**.
 
@@ -29,7 +29,7 @@ Alternatively, you can install it manually:
 
 ![](images/extension_pin.png)
 
-## Websocket Proxy <a name="proxy"></a>
+## Websocket Proxy {#proxy}
 
 Since a web browser doesn't have the ability to make TCP connection, we need to use a websocket proxy server. You can either run one yourself, or use a TLSNotary hosted proxy.
 
@@ -54,7 +54,7 @@ Note the `api.x.com:443` argument on the last line.
 
 Next use  `ws://localhost:55688` as **proxy API** in Step 3 above.
 
-## Notary Server <a name="notary-server"></a>
+## Notary Server {#notary-server}
 
 To create a TLSNotary proof, the browser extension needs a TLSNotary notary server. In a real world scenario, this server should be run by a neutral party, or by the verifier of the proofs. In this quick start, you can either run the server yourself or use the test server from the TLSNotary team. Notarizing TLS with Multi Party Computation involves a lot of communication between the extension and notary server, so running a local server is the fastest option. 
 
@@ -74,7 +74,7 @@ If you plan to run a local notary server:
 
 <img width="478"  src="images/extension_proxy.png" />
 
-### Run a Local Notary Server <a name="local-notary"></a>
+### Run a Local Notary Server {#local-notary}
 
 1. Clone the TLSNotary repository (defaults to the `main` branch, which points to the latest release):
    ```shell
@@ -88,7 +88,7 @@ If you plan to run a local notary server:
 
 The notary server will now be running in the background waiting for connections.
 
-## Notarize Twitter Account Access <a name="notarize"></a>
+## Notarize Twitter Account Access {#notarize}
 
 1. Open the extension, you should see the Twitter plugin:  
    <img width="477" src="images/extension_plugins.png" />

docs/quick_start/rust.md

@@ -16,7 +16,7 @@ Before we start, make sure you have cloned the `tlsn` repository and have a rece
     ```
 2. If you don't have Rust installed yet, you can install it using [rustup](https://rustup.rs/). If your Rust version is outdated, update it with `rustup update stable`.
 
-## Simple Interactive Verifier: Verifying Data from an API in Rust<a name="interactive"></a>
+## Simple Interactive Verifier: Verifying Data from an API in Rust {#interactive}
 
 ![](../../diagrams/light/overview_prover_verifier.svg#gh-light-mode-only)
 ![](../../diagrams/dark/overview_prover_verifier.svg#gh-dark-mode-only)
@@ -26,7 +26,7 @@ This example demonstrates how to use TLSNotary in a simple interactive session b
 Follow the instructions from:
 https://github.com/tlsnotary/tlsn/tree/main/crates/examples/interactive#readme
 
-## Simple Attestation Example: Verifying Data from an API in Rust with a Notary<a name="attestation"></a>
+## Simple Attestation Example: Verifying Data from an API in Rust with a Notary {#attestation}
 
 ![](../../diagrams/light/overview_notary.svg#gh-light-mode-only)
 ![](../../diagrams/dark/overview_notary.svg#gh-dark-mode-only)

docs/quick_start/tlsn-js.md

@@ -12,7 +12,7 @@ This quick start uses the react/typescript [demos in `tlsn-js`](https://github.c
 2. [`interactive-demo`: prove data interactively to a Verifier](#interactive-demo)
 3. [`web-to-web-p2p`: prove data between two peers, in the browser](#web-to-web-p2p)
 
-## `tlsn-js` in a React/Typescript app<a name="react-ts-webpack"></a>
+## `tlsn-js` in a React/Typescript app {#react-ts-webpack}
 
 In this demo, we will request JSON data from the Star Wars API at https://swapi.dev. We will use `tlsn-js` to notarize the TLS request with TLSNotary and store the result in a *proof*. Then, we will use `tlsn-js` again to verify this *proof*.
 
@@ -58,7 +58,7 @@ In this demo, we will request JSON data from the Star Wars API at https://swapi.
 8. Click the **Start demo** button
 9. Open **Developer Tools** and monitor the console logs
 
-## Interactive verification with `tlsn-js` <a name="interactive-demo"></a>
+## Interactive verification with `tlsn-js` {#interactive-demo}
 
 ![](../../diagrams/light/overview_prover_verifier.svg#gh-light-mode-only)
 ![](../../diagrams/dark/overview_prover_verifier.svg#gh-dark-mode-only)
@@ -66,18 +66,18 @@ In this demo, we will request JSON data from the Star Wars API at https://swapi.
 Follow the instructions from:
 https://github.com/tlsnotary/tlsn-js/blob/main/demo/interactive-demo/README.md
 
-## Web-to-web proofs with `tlsn-js`<a name="web-to-web-p2p"></a>
+## Web-to-web proofs with `tlsn-js` {#web-to-web-p2p}
 
 This demo showcases peer-to-peer communication between a web prover and a web verifier using TLSNotary. The prover fetches data from swapi.dev and proves it to the verifier.
 
 Follow the instructions from:
 https://github.com/tlsnotary/tlsn-js/blob/main/demo/web-to-web-p2p/README.md
 
-## Run a local notary server and websocket proxy <a name="local"></a> (Optional)
+## Run a local notary server and websocket proxy (Optional) {#local}
 
 The instructions above, use the [PSE](https://pse.dev) hosted notary server and websocket proxy. This is easier for this quick start because it requires less setup. If you develop your own applications with `tlsn-js`, development will be easier with locally hosted services. This section explains how.
 
-### Websocket Proxy <a name="proxy"></a>
+### Websocket Proxy {#proxy}
 
 Since a web browser doesn't have the ability to make TCP connection, we need to use a websocket proxy server.
 
@@ -92,7 +92,7 @@ wstcp --bind-addr 127.0.0.1:55688 swapi.dev:443
 
 Note the `swapi.dev:443` argument on the last line, this is the server we will use in this quick start.
 
-### Run a Local Notary Server <a name="local-notary"></a>
+### Run a Local Notary Server {#local-notary}
 
 For this demo, we also need to run a local notary server.