First couple sections

docs/build/apps/guestbook/README.mdx

@@ -5,6 +5,6 @@ sidebar_position: 57
 
 import DocCardList from "@theme/DocCardList";
 
-This section walks you through designing and building a decentralized application (dapp) that interacts with a smart contract guestbook, allowing users to read and write public messages. This tutorial also implements a passkey powered smart wallet for user authentication.
+This section walks you through designing and building a decentralized application (dapp) that interacts with a smart contract guestbook, allowing users to read and write public messages. This tutorial also implements a passkey-powered smart wallet for user authentication.
 
 <DocCardList />

docs/build/apps/guestbook/overview.mdx

@@ -21,10 +21,10 @@ Although Ye Olde Guestbook is a full-fledged application on Stellar's Testnet, i
 
 To build this guestbook application, we'll need a few pieces.
 
-- **Application framework:** we're using SvelteKit, opting for a type-checked project using TypeScript. SvelteKit (and Svelte on its own) is quite a capable framework, and we'll be using some of its features in this project. However, we will not be diving into those Svelte-specific areas very heavily in this tutorial. The source code of the project is freely open and available, and has some decent informational comments throughout, if you would like to peruse for those purposes.
+- **Application framework:** we're using SvelteKit, opting for a type-checked project using TypeScript. SvelteKit (and Svelte on its own) is quite a capable framework, and we'll be using some of its features in this project. However, we will not be diving into those Svelte-specific areas very heavily in this tutorial. The source code of the project is freely open and available and has some decent informational comments throughout if you would like to peruse it for those purposes.
 - **Frontend framework:** We're using [Skeleton](https://www.skeleton.dev/) to simplify the use of [Tailwind CSS](https://tailwindcss.com/).
-- **A way to interact with the network:** this is a TypeScript application, and we're using the `@stellar/stellar-sdk` for this. You could make traditional `fetch` requests if you wanted to, depending on your deployment decisions. In either case, we'll need the SDK to interact with Keypairs and transactions. We'll also be using a data indexer to access historical network events, and we'll cover more of this at a later point in the tutorial.
-- **A way to interact with a user's account:** we're foregoing the traditional wallets here, and we'll use `passkey-kit` to give our users a smart wallet to interact with. They can interact with this smart wallet (via passkey-kit) through methods their already familiar with (thumbprints, face ID, etc.).
+- **A way to interact with the network:** this is a TypeScript application, and we're using the `@stellar/stellar-sdk` for this. You could make traditional `fetch` requests if you wanted to, depending on your deployment decisions. In either case, we'll need the SDK to interact with keypairs and transactions. We'll also be using a data indexer to access historical network events, and we'll cover more of this at a later point in the tutorial.
+- **A way to interact with a user's account:** we're foregoing the traditional wallets here, and we'll use `passkey-kit` to give our users a smart wallet to interact with. They can interact with this smart wallet (via passkey-kit) through methods they're already familiar with (thumbprints, face ID, etc.).
 
 :::note
 
@@ -39,7 +39,7 @@ Some choices we've made during the course of development:
 - We're rolling our own passkeys service here. That means we'll set up and use `passkey-kit` (both client- and server-side components) in our own dapp. In the long run, this may not be the necessary usage pattern. It's likely that services will crop up to act as a "wallet factory" that can create smart wallets, and facilitate adding signers for various applications. Perhaps these services will be provided by existing wallets? Perhaps these services will be unknown to the user (and maybe even developers) in the future? Who knows! The sky's the limit! (But that's not the case yet, so we're doing it ourselves.)
 - It should be _relatively_ responsive, no promises, though
 - We've chosen a theme from Skeleton, so it looks nice right away.
-- There's a mix of client- and server-side logic. This is due to the fact that we'll need to keep some authentication credentials secret, and we want to avoid leaking these to the user-facing code. Some of these techniques are a bit SvelteKit specific, but it should ultimately be understandable.
+- There's a mix of client- and server-side logic. This is due to the fact that we'll need to keep some authentication credentials secret, and we want to avoid leaking these to the user-facing code. Some of these techniques are a bit SvelteKit-specific, but it should ultimately be understandable.
 - We're deploying to a free-tier Vercel project. We've had really good success in getting SvelteKit and Stellar projects deployed easily and quickly, and with very little configuration. Your mileage may vary, but this should be a pretty decent starting point.
 - The application is likely not as performant as it could be. Neither is it as optimized as it could be. We've tried to encapsulate the various functionalities in a way that makes sense to the developer reading the codebase, so there is some code duplication and things could be done in a "better" way.
 - We do _some_ error handling, but not nearly as much as you would want for a real-world application. If something seems like it's not working, and you're not seeing an error, open your developer console, and you might be able to figure out what has gone wrong.
@@ -54,8 +54,8 @@ This tutorial is probably best viewed as "_nearly_ comprehensive." We aren't goi
 ### Dev helpers
 
 - [Passkey Kit](https://github.com/kalepail/passkey-kit): A TypeScript SDK for creating and managing Stellar smart wallets.
-- [Launchtube](https://launchtube.xyz): Similar to a [Paymaster](https://eips.ethereum.org/EIPS/eip-4337#extension-paymasters) in the EVM world, the Launchtube service aims to alleviate all of the challenges and complexities of getting a transaction on-chain by giving you an API which accepts Soroban ops and then handles getting those entries successfully submitted to the network.
-- [Stellar Lab](https://lab.stellar.org): an experimental playground to interact with the Stellar network
+- [Launchtube](https://launchtube.xyz): Similar to a [Paymaster](https://eips.ethereum.org/EIPS/eip-4337#extension-paymasters) in the EVM world, the Launchtube service aims to alleviate all of the challenges and complexities of getting a transaction on-chain by giving you an API that accepts Soroban ops and then handles getting those entries successfully submitted to the network.
+- [Stellar Lab](https://lab.stellar.org): An experimental playground to interact with the Stellar network.
 
 ## Getting started
 

docs/build/apps/guestbook/smart-contract.mdx

@@ -76,7 +76,7 @@ First things first, we need a function that will allow a message to be written i
 
 - We're using a helper function called `check_string_not_empty` to ensure that a non-empty value has been passed for both the `title` and `text` arguments. More on this function later on.
 - We're requiring authentication from the author's address, to ensure they've authorized the message entry to be associated with them.
-- We're utilizing a `save_message` utility function to do the actual storage entry reading/writing. More on the specifics of this function [later on](#save_message), but for now just know it's storing the the `new_message` struct, and returning the ID of the stored message.
+- We're utilizing a `save_message` utility function to do the actual storage entry reading/writing. More on the specifics of this function [later on](#save_message), but for now just know it's storing the `new_message` struct, and returning the ID of the stored message.
 
 ```rust
 /// Write a message to the guestbook.
@@ -259,7 +259,7 @@ pub fn claim_donations(env: Env, token: Address) -> Result<i128, Error> {
 
 ### Utility functions
 
-We have some utility functions, too that aren't exposed to be invoked by the smart contract in a transaction. These functions exist so we don't have to code the same logic over and over (i.e. reading a message from the contract's storage). This is a fairly common approach to reduce contract size and make contract logic more consistent.
+We have some utility functions, too that aren't exposed to be invoked by the smart contract in a transaction. These functions exist so we don't have to code the same logic over and over (i.e., reading a message from the contract's storage). This is a fairly common approach to reduce contract size and make contract logic more consistent.
 
 #### `check_string_not_empty`
 
@@ -376,6 +376,6 @@ pub enum Error {
 
 #### Tests
 
-We've written some tests that work through many (foreseen) usage patterns for this smart contract. It's too lengthy to dive into here, but it's worth checking out the [source code](https://github.com/ElliotFriend/ye-olde-guestbook/blob/main/contracts/ye_olde_guestbook/src/test.rs) to understand the logic about how the various contract functions are meant to work together.
+We've written some tests that work through many (foreseen) usage patterns for this smart contract. It's too lengthy to dive into here, but it's worth checking out the [source code](https://github.com/ElliotFriend/ye-olde-guestbook/blob/main/contracts/ye_olde_guestbook/src/test.rs) to understand the logic of how the various contract functions are meant to work together.
 
 Up next, we'll look at how we go from this deployed contract to an NPM package that can be imported and used in a frontend project easily, and with full type-safety.