add page titles

docs/pages/index.mdx

@@ -1,3 +1,9 @@
+---
+title: Hyperbridge
+description: Hyperbridge Protocol Specification
+---
+
+
 # Introduction
 
 Secure interoperability requires the verification of consensus proofs, consensus fault proofs, and state transition validity proofs. Blockchains that want to securely communicate with each other must perform these operations onchain, so that they can be convinced of the finalized (irreversable) state of their counterparty. Finally, through the use of state of state proofs, they are then able to read the outgoing messages queue of their counter party.

docs/pages/network/node.mdx

@@ -1,3 +1,9 @@
+---
+title: Node Operators
+description: Running the Hyperbridge node
+---
+
+
 # Running a node
 
 We provide a variety of ways to obtain a node for running. For now we only officially support x86 linux environments.

docs/pages/network/relayer.mdx

@@ -1,3 +1,9 @@
+---
+title: Relayers
+description: Running the tesseract relayer
+---
+
+
 # Running a relayer
 
 Critical to the function of Hyperbridge are relayers who transmit requests & responses across it's connected chains. These relayers much like node operators earn rewards for relaying requests. Since requests are paid for ahead of time on the source chain by the initiating application. Relayers can relay these requests and redeem their fees on the source chain. This works by the relayer showing state proofs to the hyperbridge parachain of their successful delivery. Hyperbridge then authorizes the release of the fees to the relayer on the source chain.

docs/pages/protocol/requests.mdx

@@ -1,3 +1,8 @@
+---
+title: Requests
+description: The ISMP Request specification
+---
+
 <link href="https://cdn.jsdelivr.net/npm/katex@0.16.8/dist/katex.min.css" rel="stylesheet" />
 
 # Requests

docs/pages/protocol/responses.mdx

@@ -1,3 +1,8 @@
+---
+title: Responses
+description: The ISMP Response specification
+---
+
 # Responses
 
 A `PostResponse` can be seen as the result or return value of a `PostRequest` execution. `IsmpModule`s may choose not to emit `PostResponse` and instead employ an optimistic model where state is modified in a way that can be reverted when the request times out. This saves significant message round trip and verification costs and provides a better experience for application users.

docs/pages/protocol/router.mdx

@@ -1,3 +1,9 @@
+---
+title: Router
+description: The ISMP router interface
+---
+
+
 # ISMP Router
 
 The router lives in-between the ISMP message handlers and modules, the router provides access to a concrete implementation of an `IsmpModule` which a request or response is designated for based on the destination module Id. The interface for the router is

docs/pages/protocol/timeouts.mdx

@@ -1,7 +1,12 @@
+---
+title: Timeouts
+description: Request and Response timeouts
+---
+
 # Timeouts
 
 Blockchains may become incapable of processing transactions for to various reasons. These might include *liveness failures*, which can occur when the state transition function becomes unable to produce new blocks, consensus faults, transaction fee spikes that make transaction execution unprofitable, or a doomsday scenario such as a nation state sanctioned attack.
 
 Regardless of the reason, if the destination chain cannot process incoming ISMP requests, the framework provides a timeout mechanism. This feature allows for the safe reversion of state changes on the source chain that were executed prior to dispatching the request, as if no issue ever occurred.
 
-Within the ISMP framework, POST requests, POST responses, and GET requests can time out due to their `timeout_timestamp` value. This value defines the lifespan of a message. A `PostRequest` and `PostResponse` will time out when their destination's `host.timestamp()` surpasses the `timeout_timestamp`. Conversely, a `GetRequest` times out when its source's `host.timestamp()` surpasses the `timeout_timestamp`.
+POST requests, POST responses, and GET requests have the ability to time out due to their `timeout_timestamp` value. This value defines the lifespan of a message. A `PostRequest` and `PostResponse` will time out when their destination's `host.timestamp()` surpasses the `timeout_timestamp`. Conversely, a `GetRequest` times out when its source's `host.timestamp()` surpasses the `timeout_timestamp`.

evm/test/PingModule.sol → evm/examples/PingModule.sol

@@ -99,7 +99,7 @@ contract PingModule is IIsmpModule {
 
     function dispatchToParachain(uint256 _paraId) public {
         DispatchPost memory post = DispatchPost({
-            body: bytes("hello from ethereum"),
+            body: bytes("hello from evm"),
             dest: StateMachine.kusama(_paraId),
             timeout: 0,
             // timeout: 60 * 60, // one hour

evm/script/DeployGateway.s.sol

@@ -6,8 +6,8 @@ import "multi-chain-tokens/tokens/ERC20.sol";
 
 import "../src/modules/TokenGateway.sol";
 import "../src/modules/TokenFaucet.sol";
-import "../test/PingModule.sol";
-import "../test/CrossChainMessenger.sol";
+import "../examples/PingModule.sol";
+import "../examples/CrossChainMessenger.sol";
 
 contract DeployScript is Script {
     bytes32 public salt = keccak256(bytes("gargantua-v0.0.7"));

evm/script/DeployIsmp.s.sol

@@ -13,7 +13,7 @@ import "../src/hosts/Ethereum.sol";
 import "../src/hosts/Arbitrum.sol";
 import "../src/hosts/Optimism.sol";
 import "../src/hosts/Base.sol";
-import "../test/PingModule.sol";
+import "../examples/PingModule.sol";
 import {BscHost} from "../src/hosts/Bsc.sol";
 import {PolygonHost} from "../src/hosts/Polygon.sol";
 

evm/test/BaseTest.sol

@@ -4,7 +4,7 @@ pragma solidity 0.8.17;
 import "forge-std/Test.sol";
 import {TestConsensusClient} from "./TestConsensusClient.sol";
 import {TestHost} from "./TestHost.sol";
-import {PingModule} from "./PingModule.sol";
+import {PingModule} from "../examples/PingModule.sol";
 import {HandlerV1} from "../src/HandlerV1.sol";
 import {FeeToken} from "./FeeToken.sol";
 import {HostParams} from "../src/EvmHost.sol";