Docs fix spelling issues (#2242)

Hello
While I looking through your docs I found and fixed several spelling
issues.
Br, Elias.

contracts/README.md

@@ -50,7 +50,7 @@ forge test
 
 You can add verbosity to the tests by adding `-vvvv` (1-4 levels) to the command
 
-<b>To start a local ethereum blockchain:</b>
+<b>To start a local Ethereum blockchain:</b>
 
 ```shell
 anvil

core/README.md

@@ -12,7 +12,7 @@ There are two local environments available:
 - multi_ne - no entitlements
 - multi - entitlements are enabled
 
-Environment name always needs to be provided through RUN_ENV variable.
+The environment name always needs to be provided through RUN_ENV variable.
 
 Config, build and start in background:
 
@@ -30,7 +30,7 @@ Just build:
 
     just RUN_ENV=multi build
 
-Just start with existing config and binary:
+Just start with the existing config and binary:
 
     just RUN_ENV=multi start
 
@@ -53,7 +53,7 @@ MLS lib needs to be built for some tests to run, there are just commands that bu
 # Running the archiver service locally against different environments
 
 To run a local archiver service that downloads from various public networks, use the `run.sh` command
-for that environment and pass in specific configuration to store the data in the local database, which
+for that environment and pass in a specific configuration to store the data in the local database, which
 is written in `core/env/local/archiver/config.yaml`.
 
 ## Example: Running against omega nodes
@@ -124,7 +124,7 @@ Run node tests:
 
 Build is incremental, as such it may get confused when packages are updated or branches are switched.
 
-Clean build artificats and rebuild:
+Clean build artifacts and rebuild:
 
     yarn csb:clean
     yarn csb:build

packages/docs/build/delegate-key-signing.mdx

@@ -13,7 +13,7 @@ The rules and construction of the delegate key signature are the topic of this p
 
 ### Delegate Signature Protocol Rules
 
-The logic dictating how a Towns Stream Node should process delegate signatures on the critical path of a request are described in `protocol.proto` and defined in `delegate.go`.
+The logic dictating how a Towns Stream Node should process delegate signatures on the critical path of a request is described in `protocol.proto` and defined in `delegate.go`.
 
 Events sent over RPC to a Towns Stream Node are sent with a message `Envelope` that includes several fields used to validate the sender.
 
@@ -32,7 +32,7 @@ Each event on a Towns Stream Node is parsed and validated as follows.
 <Steps>
   <Step title="Unmarshal Bytes">
     Events are stored as bytes in Towns Stream Node storage and transmitted as bytes over the wire.
-    All events are unmarshalled first then parsed to run a series of validity checks prior to storing those events.
+    All events are unmarshalled first and then parsed to run a series of validity checks prior to storing those events.
     ```go
     // stream_view.go example unpacking and parsing of events
     var env Envelope
@@ -68,7 +68,7 @@ Each event on a Towns Stream Node is parsed and validated as follows.
     ```
   </Step>
   <Step title="Check Delegate Signature">
-    Once the hash is confirmed as valid for the event, the hash along with the envelope signature are used to recover the signer public key.
+    Once the hash is confirmed as valid for the event, the hash along with the envelope signature is used to recover the signer public key.
     ```go
     // parsed_event.go
     func ParseEvent(envelope *Envelope) (*ParsedEvent, error) {
@@ -150,4 +150,4 @@ func NewWallet(ctx context.Context) (*Wallet, error) {
 		},
 		nil
 }
-```
+```

packages/docs/build/towns-encryption.mdx

@@ -35,7 +35,7 @@ encryption and decryption operations to the
 [`olm` library from the Matrix.org foundation](<https://www.npmjs.com/package/@matrix-org/olm>).
 This library implements the Double Ratchet algorithm. See notes on [supported algorithm](#supported-algorithm) for future plans.
 
-The Towns Encryption Protocol uses this libray to create a group session, and
+The Towns Encryption Protocol uses this library to create a group session, and
 perform device-to-device encryption using the session keys.
 
 The `GroupEncryptionCrypto` creates a `GroupEncryption`, a

packages/docs/build/towns-messaging-datastructures.mdx

@@ -38,7 +38,7 @@ message StreamEvent {
       * delegate_sig allows event to be signed by device keypair
       * which is linked to the user's primary wallet.
       *
-      * delegate_sig constains signature of the public key of the device keypair.
+      * delegate_sig contains signature of the public key of the device keypair.
       * User's primary wallet is used to produce this signature.
       *
       * If present, for the event to be valid:
@@ -312,4 +312,4 @@ Group direct message messages are supported by the Towns protocol as their own s
 
 Media files are supported as separate streams in Towns protocol associated with a parent `channel_id`. Messages added to a Towns node containing media must pass validation criteria that proves the `creator` is a member of that `channel_id` to prevent man-in-the-middle type attacks.
 
-Media files can be quite large in size and as such are chunked in byte arrays on nodes and therefore support pagination by clients.
+Media files can be quite large in size and as such are chunked in byte arrays on nodes and therefore support pagination by clients.

packages/docs/introduction/what-is-towns.mdx

@@ -14,8 +14,8 @@ At its core, the ecosystem seeks to empower people to create, manage, and partic
 Towns’ goal is ambitious. To secure freedom of communication for a sustainable permissionless future.
 Key features
 An app chain purposefully built for social networking – Towns secures Read/write entitlements separately on Base, allowing our app chain to make liveliness tradeoffs and send messages to thousands of participants as fast as any existing centralized social network.
-Ownable communication – Space creators truly own the space they created as an onchain asset.
-Programmable spaces – Spaces are deployed onchain with programmable interfaces allowing the rules, like who can read and write, to be customized to integrate with any other external EVM-compatible contract.
+Ownable communication – Space creators truly own the space they created as an on chain asset.
+Programmable spaces – Spaces are deployed on chain with programmable interfaces allowing the rules, like who can read and write, to be customized to integrate with any other external EVM-compatible contract.
 On-chain memberships with built-in protocol fees – Users are required to hold a valid membership token to send and receive messages in a Space. Pricing for membership enforces a protocol fee used to pay for the operation of the network.
 On-chain social graph – Membership tokens and Spaces are discoverable on chain.
 Extendable reputation system – Towns’s communication spaces can be programmed to allow members peer-based, Space-specific ratings discoverable on chain.

packages/docs/towns-smart-contracts/contracts.mdx

@@ -13,7 +13,7 @@ This section provides an overview of the current deployment of key Towns smart c
 
 Towns smart contracts are deployed using the Diamond Pattern (see [EIP-2525](https://eips.ethereum.org/EIPS/eip-2535)), which improves upon modularity and upgradeability.
 
-The following are the current list of deployed diamond contracts on Base and a link to their associated facet addresses.
+The following is the current list of deployed diamond contracts on Base and a link to their associated facet addresses.
 
 | Diamond      | Network | Address                                    | Facet Addresses |
 | ------------ | ------- | ------------------------------------------ | --------------- |

packages/docs/towns-smart-contracts/roles-entitlements.mdx

@@ -9,7 +9,7 @@ description: ""
 
 In the Towns ecosystem, `Permissions` are defined actions that users can undertake within a `Space`. These permissions are fundamental to governing user interactions and activities within the ecosystem. The Towns system includes a range of permissions, each tailored to specific functionalities:
 
-- `ModifyChannels`: This permission allows those who hold to to create, delete, edit, and assign roles to a given channel within a Space.
+- `ModifyChannels`: This permission allows those who hold to create, delete, edit, and assign roles to a given channel within a Space.
 - `ModifyRoles`: This permission enables users to create and modify roles and entitlements within a Space.
 - `MintMembership`: The `Mint` permission grants users the ability to mint a membership token for a given Space.
 - `Read`: The `Read` permission allows users to access and view message content within a Space.

packages/docs/towns-smart-contracts/space-membership.mdx

@@ -15,7 +15,7 @@ Space Membership revolves around the concept of Membership Tokens, a pivotal ele
 
 **Access Control Mechanisms:** Membership Tokens can be gated based on the possession of specific [ERC-20](https://eips.ethereum.org/EIPS/eip-20) or [ERC-721](https://eips.ethereum.org/EIPS/eip-721) tokens across multiple networks including Ethereum Mainnet, Optimism, Polygon, Arbitrum, and Base. This creates a flexible and inclusive gating system.
 
-**Custom Entitlement Logic:** In addition to standard ERC20/721 and address gating mechanisms, Membership Tokens can also incorporate custom logic. For example channels rules can be composed based on the current score of an on-chain game or the liquidity in a defi protocol. Combining this with on-chain oracles allows for even greater flexibility to gate based on real world events. This logic can be coded and deployed on any of the supported chains, offering a higher degree of customization for access control. For more information, see [Entitlement Modules].
+**Custom Entitlement Logic:** In addition to standard ERC20/721 and address gating mechanisms, Membership Tokens can also incorporate custom logic. For example channels rules can be composed based on the current score of an on-chain game or the liquidity in a defi protocol. Combining this with on-chain oracles allows for even greater flexibility to gate based on real-world events. This logic can be coded and deployed on any of the supported chains, offering a higher degree of customization for access control. For more information, see [Entitlement Modules].
 
 **Reputation System:** Within a Space, Membership Tokens have the unique ability to accrue reputation from other members. This feature fosters a community-driven environment where member interactions contribute to one’s standing in the Space. For detailed insights, refer to the [Reputation] section.