fix: some things

doc/book.toml

@@ -3,7 +3,12 @@ authors = ["distractedm1nd", "sebasti810"]
 language = "en"
 multilingual = false
 src = "src"
-title = "prism-doc"
+title = "Prism Documentation"
 
 [preprocessor.katex]
-after = ["links"]
+after = ["links"]
+
+[output.html]
+git-repository-url = "https://github.com/deltadevsde/prism"
+default-theme = "ayu"
+no-section-label = true

doc/src/README.md

@@ -44,19 +44,13 @@ Prism is web2 friendly from day 1 with WASM compatibility, allowing existing mes
 Beyond messaging apps, Prism opens doors to potential improvements in nascent technologies and challenges in today's web. We envision a system for transparent, seamless authentication, where every human, website, app or other digital property is verified on a blockchain.
 Prism's verifiable encryption standard opens up possibilities for secure communication across various digital platforms, which can enable exciting use cases like:
 
-1.  A user controlled global identity layer
-2.  Keystore Rollups - allowing users to securely store and manage their cryptographic keys across multiple chains
-3.  A sandbox environment for testing Trusted Execution Environment (TEE) trust assumptions, ensuring even the most advanced security features are bulletproof.
-4.  A new trustless, decentralized model for web certificate authority and public key infrastructure (PKI) systems.
+1. A user controlled global identity layer
+2. Keystore Rollups - allowing users to securely store and manage their cryptographic keys across multiple chains
+3. A sandbox environment for testing Trusted Execution Environment (TEE) trust assumptions, ensuring even the most advanced security features are bulletproof.
+4. A new trustless, decentralized model for web certificate authority and public key infrastructure (PKI) systems.
 
 Welcome to a new era of digital privacy, where the only person listening is the one you're talking to.
 
 ## Getting started
 
-We will introduce some basic concepts of cryptography that are essential for understanding the content. For more information and deeper explanations, we will provide links to relevant literature and texts. If you encounter errors or have suggestions for improvement, please feel free to [contact us](/contact).
-
-[See the bib](/paper)
-
-[Quickstart](/quickstart)
-
-[Architecture](/architecture)
+We will introduce some basic concepts of cryptography that are essential for understanding the content. For more information and deeper explanations, we will provide links to relevant literature and texts. If you encounter errors or have suggestions for improvement, please feel free to [open an issue](https://github.com/deltadevsde/prism/issues).

doc/src/datastructures.md

@@ -27,30 +27,30 @@ Prism uses Jellyfish Merkle Trees (JMT) instead of indexed Merkle trees. JMTs ar
 
 Key features of Jellyfish Merkle Trees include:
 
-1.  Version-based Node Key: JMT uses a version-based key schema, which facilitates version-based sharding, reduces compaction overhead in LSM-tree based storage engines, and results in smaller key sizes on average.
+1. Version-based Node Key: JMT uses a version-based key schema, which facilitates version-based sharding, reduces compaction overhead in LSM-tree based storage engines, and results in smaller key sizes on average.
 
-2.  Simplified Structure: JMT has only two physical node types - Internal Node and Leaf Node.
+2. Simplified Structure: JMT has only two physical node types - Internal Node and Leaf Node.
 
-3.  Concise Proof Format: The number of sibling digests in a JMT proof is less on average than that of the same Addressable Radix Merkle Tree (ARMT) without optimizations, requiring less computation and space.
+3. Concise Proof Format: The number of sibling digests in a JMT proof is less on average than that of the same Addressable Radix Merkle Tree (ARMT) without optimizations, requiring less computation and space.
 
-4.  Efficient for Sparse Trees: JMT is particularly efficient for sparse trees, which is often the case in blockchain applications.
+4. Efficient for Sparse Trees: JMT is particularly efficient for sparse trees, which is often the case in blockchain applications.
 
-[More about Merkle trees](/quick-crypto#merkle-trees)
+[More about Merkle trees](./crypto-intro/merkle-trees.md)
 
 ## Account Creation
 
 Prism introduces a `CREATE_ACCOUNT` operation that allows for decentralized account creation. This operation supports various account sources, not just email addresses. The process works as follows:
 
-1.  Users prove ownership of a resource (e.g., a social media account, email address) using services like TLSNotary or zkEmail.
-2.  The proof is generated off-chain and then submitted as part of the `CREATE_ACCOUNT` operation.
-3.  The Prism protocol includes validity rules for each supported external protocol's proof system.
-4.  Full nodes verify the `CREATE_ACCOUNT` operation according to the corresponding proof system's ruleset before applying the state transition in the Jellyfish Merkle Tree.
+1. Users prove ownership of a resource (e.g., a social media account, email address) using services like [TLSNotary](https://tlsnotary.org/) or [zkEmail](https://prove.email/).
+2. The proof is generated off-chain and then submitted as part of the `CREATE_ACCOUNT` operation.
+3. The Prism protocol includes validity rules for each supported external protocol's proof system.
+4. Full nodes verify the `CREATE_ACCOUNT` operation according to the corresponding proof system's ruleset before applying the state transition in the Jellyfish Merkle Tree.
 
 This approach allows for:
 
--   Addition of arbitrary account sources
--   Decentralized account creation without relying on a single trusted entity
--   Flexibility for applications to use various types of accounts for registration
+- Addition of arbitrary account sources
+- Decentralized account creation without relying on a single trusted entity
+- Flexibility for applications to use various types of accounts for registration
 
 > **Note**: The `CREATE_ACCOUNT` operation enhances the security and decentralization of the account creation process in Prism. It mitigates the risks associated with centralized account creation while allowing for diverse account sources.
 

doc/src/labels.md

@@ -2,18 +2,18 @@
 
 Using Prism, we run into an interesting problem:
 
-Once a new user is added to the IMT, we know that all updates to a hashchain are valid by construction- updates must be signed by an already existing key in the hashchain. But who gets to add the first key for a user? Why should we trust that the first key added actually comes from the user?
+Once a new user is added to the JMT, we know that all updates to a hashchain are valid by construction - updates must be signed by an already existing key in the hashchain. But who gets to add the first key for a user? Why should we trust that the first key added actually comes from the user?
 
 ## Labels
 
 The entries in the transparency dictionary are indexed by labels. These labels are arbitrary strings, and in the majority of the documentation we simplify the type of label to an email address.
 
 But to add a new email address for a user, the owner of that email address must be able to prove that they own it. In Stage 1 of the architecture, this is done by means of a centralized service that verifies resource ownership. Once a user has verified ownership of an email address, the sequencer adds an entry to the hashchain.
 
-We must move away from this, as it is both not scalable and not trust-minimized. In Stage 2, we will use services such as zkEmail and TLSNotary to provide resource ownership proofs that can be verified by any client. This will allow us to move to a trust-minimized system where the user can add their own account to the state directly by posting to the DA layer.
+We must move away from this, as it is both not scalable and not trust-minimized. In Stage 2, we will use services such as [zkEmail](https://prove.email/) and [TLSNotary](https://tlsnotary.org/) to provide resource ownership proofs that can be verified by any client. This will allow us to move to a trust-minimized system where the user can add their own account to the state directly by posting to the DA layer.
 
 See more in [adr-002 (Account Sources)](https://github.com/deltadevsde/prism/blob/main/adr/adr-002-create-account-op.md).
 
 ## Protocols
 
-This construction allows for some interesting application-layer protocols that can be added. For example, in the future we may add a transaction type for registering a service. These services register with a public key and service identifier. Then, a validity rule is added for full nodes that new entries to the IMT, if preceded by the service identifier, must be signed by the service provider's keypair.
+This construction allows for some interesting application-layer protocols that can be added. For example, in the future we may add a transaction type for registering a service. These services register with a public key and service identifier. Then, a validity rule is added for full nodes that new entries to the JMT, if preceded by the service identifier, must be signed by the service provider's keypair.

doc/src/quickstart.md

@@ -1,6 +1,6 @@
 # Quickstart
 
-This guide will introduce you to the ideas behind prism. We will go through the necessary cryptography and provide further links in many places to deepen the knowledge and not to completely interrupt the reading flow on the topic.
+This guide will introduce you to the ideas behind _Prism_. We will go through the necessary cryptography and provide further links in many places to deepen the knowledge and not to completely interrupt the reading flow on the topic.
 
 > **Note**: If you have no or only little previous knowledge, you can get a short overview with partly simplified explanations [here](/explainers/crypto-intro/intro.md).
 
@@ -16,18 +16,18 @@ Key transparency is a security system designed to make the distribution and mana
 
 We provide the first key-transparency solution to enable automatic verification of the service provider. This is achieved by providing constant size succinct proofs to WASM light clients over Celestia. These WASM light clients are integrated into chat clients to have a direct connection to the DA layer without trusting an RPC.
 
-## What is prism?
+## What is _Prism_?
 
-From a high level, Prism is simply a trust-minimized service that manages data - more precisely, a label-value-map - that produces evidence that it has acted correctly and honestly. Correct and honest here refer to application-specific policies by which it purports to act. In the following, we are in principle dealing with a system that does not need to be trusted because it is provably honest. Incidentally, the proofs save us some computational effort, but we will come to that later.
+From a high level, _Prism_ is simply a trust-minimized service that manages data - more precisely, a label-value-map - that produces evidence that it has acted correctly and honestly. Correct and honest here refer to application-specific policies by which it purports to act. In the following, we are in principle dealing with a system that does not need to be trusted because it is provably honest. Incidentally, the proofs save us some computational effort, but we will come to that later.
 
 ## A practical application
 
-Prism originiated as a toy implementation of a paper from [Tzialla et al.](https://eprint.iacr.org/2021/1263.pdf), from which it has significantly diverged. In this paper, _"Keypal"_ is described as a concrete application example, which serves as a POC of an application that could run on Prism. _Prism_ can be thought of as a service that manages a two-column table. The first column stores unique identifiers, which we will simplify to just e-mail addresses in this documentation, and the corresponding column on the right stores a hashchain of values. For most Prism applications, the values stored in this hashchain are the public keys associated with the identifier.
+Prism originiated as a toy implementation of a paper from [Tzialla et al.](https://eprint.iacr.org/2021/1263.pdf), from which it has significantly diverged. In this paper, _"Keypal"_ is described as a concrete application example, which serves as a POC of an application that could run on _Prism_. _Prism_ can be thought of as a service that manages a two-column table. The first column stores unique identifiers, which we will simplify to just e-mail addresses in this documentation, and the corresponding column on the right stores a hashchain of values. For most Prism applications, the values stored in this hashchain are the public keys associated with the identifier.
 
 ## What's next?
 
 Great, we now have an overview of the basic function of _Prism_. The fact that we don't understand any details yet and that everything will only make more sense later, we have to accept for the moment. Here's a quick overview of what we'll look at next:
 
--   [Let's understand the data structures](/datastructures)
--   [Ready for the first little proofs?](/merkle-proofs)
--   [Zero knowledge to save time and resources](/zkp-basics)
+- [Let's understand the data structures](./datastructures.md)
+- [Ready for the first little proofs?](./merkle-proofs.md)
+- [Zero knowledge to save time and resources](./zkp-basics.md)