Merge pull request #555 from Jonny-Ringo/patch-3

Patch 3

Author: twilson63

docs/build/devices/application-features/auth-ecosystem-at-1-0.md

@@ -131,4 +131,4 @@ Single-click access to blockchain applications with traditional web experience.
 
 - [`~process@1.0`](../foundational/process-at-1-0.md) - Process communication signing
 - [`~query@1.0`](./data-discovery-at-1-0.md) - Authenticated data queries
-- [`~snp@1.0`](./source-code/dev_snp.md) - Trusted execution environment
+- [`~snp@1.0`](../source-code/dev_snp.md) - Trusted execution environment

docs/build/devices/application-features/data-discovery-at-1-0.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-The [`~query@1.0`](./source-code/dev_query.md) device provides flexible search capabilities over cached messages in HyperBEAM. It enables efficient data discovery through multiple matching strategies and return formats, making it the central hub for searching and retrieving messages stored in the node's cache.
+The [`~query@1.0`](../source-code/dev_query.md) device provides flexible search capabilities over cached messages in HyperBEAM. It enables efficient data discovery through multiple matching strategies and return formats, making it the central hub for searching and retrieving messages stored in the node's cache.
 
 ## Core Concept: Message Discovery
 
@@ -145,9 +145,9 @@ Applications built on query device respond instantly even offline. Once data rep
 
 ## See Also
 
-- [`~cache@1.0`](./source-code/dev_cache.md) - Primary data source for query operations
-- [`~store@1.0`](./source-code/dev_store.md) - Underlying persistent storage
-- [`~message@1.0`](./source-code/dev_message.md) - Message format handling
-- [`~copycat@1.0`](./source-code/dev_copycat.md) - Data replication device
+- [`~cache@1.0`](../source-code/dev_cache.md) - Primary data source for query operations
+- [`~store@1.0`](../source-code/dev_store.md) - Underlying persistent storage
+- [`~message@1.0`](../source-code/dev_message.md) - Message format handling
+- [`~copycat@1.0`](../source-code/dev_copycat.md) - Data replication device
 
-[query module](./source-code/dev_query.md)
+[query module](../source-code/dev_query.md)

docs/build/devices/application-features/data-replication-at-1-0.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-The [`~copycat@1.0`](./source-code/dev_copycat.md) device replicates data from external sources into HyperBEAM node caches. It fetches messages from GraphQL endpoints and Arweave nodes, enabling offline-first applications through local data caching.
+The [`~copycat@1.0`](../source-code/dev_copycat.md) device replicates data from external sources into HyperBEAM node caches. It fetches messages from GraphQL endpoints and Arweave nodes, enabling offline-first applications through local data caching.
 
 ## Core Concept: Data Ingestion
 
@@ -124,8 +124,8 @@ Applications using copycat load faster and work offline. Once data replicates to
 
 ## See Also
 
-- [`~query@1.0`](./source-code/dev_query.md) - For querying replicated data
-- [`~cache@1.0`](./source-code/dev_cache.md) - Storage target for replicated data
-- [`~arweave@2.9-pre`](./source-code/dev_arweave.md) - Arweave node communication
+- [`~query@1.0`](../source-code/dev_query.md) - For querying replicated data
+- [`~cache@1.0`](../source-code/dev_cache.md) - Storage target for replicated data
+- [`~arweave@2.9-pre`](../source-code/dev_arweave.md) - Arweave node communication
 
-[copycat module](./source-code/dev_copycat.md)
+[copycat module](../source-code/dev_copycat.md)

docs/build/devices/building-devices.md

@@ -4,9 +4,9 @@ We encourage you to extend HyperBEAM with devices for functionality that is gene
 
 ## What are Devices?
 
-As explained in the [introduction](./devices/hyperbeam-devices.md), devices are the core functional units within HyperBEAM. They are self-contained modules that process messages and perform specific actions, forming the building blocks of your application's logic.
+As explained in the [introduction](./hyperbeam-devices.md), devices are the core functional units within HyperBEAM. They are self-contained modules that process messages and perform specific actions, forming the building blocks of your application's logic.
 
-HyperBEAM comes with a set of powerful [built-in devices](./devices/hyperbeam-devices.md) that handle everything from process management (`~process@1.0`) and message scheduling (`~scheduler@1.0`) to executing WebAssembly (`~wasm64@1.0`) and Lua scripts (`~lua@5.3a`).
+HyperBEAM comes with a set of powerful [built-in devices](./hyperbeam-devices.md) that handle everything from process management (`~process@1.0`) and message scheduling (`~scheduler@1.0`) to executing WebAssembly (`~wasm64@1.0`) and Lua scripts (`~lua@5.3a`).
 
 ## Creating Your Own Devices (Coming Soon)
 

docs/build/devices/foundational/json-at-1-0.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-The [`~json@1.0`](./source-code/dev_json_iface.md) device provides a mechanism to interact with JSON (JavaScript Object Notation) data structures. It allows treating a JSON document or string as a stateful entity against which queries can be executed.
+The [`~json@1.0`](../source-code/dev_json_iface.md) device provides a mechanism to interact with JSON (JavaScript Object Notation) data structures. It allows treating a JSON document or string as a stateful entity against which queries can be executed.
 
 This device is useful for:
 
@@ -36,7 +36,7 @@ This retrieves the node configuration from the meta device and serializes it to
 
 ## See Also
 
-- [Message Device](./source-code/dev_message.md) - Works well with JSON serialization
-- [Meta Device](./source-code/dev_meta.md) - Can provide configuration data to serialize
+- [Message Device](../source-code/dev_message.md) - Works well with JSON serialization
+- [Meta Device](../source-code/dev_meta.md) - Can provide configuration data to serialize
 
-[json module](./source-code/dev_codec_json.md)
+[json module](../source-code/dev_codec_json.md)

docs/build/devices/foundational/lua-at-5-3a.md

@@ -2,18 +2,18 @@
 
 ## Overview
 
-The [`~lua@5.3a`](./source-code/dev_lua.md) device enables the execution of Lua scripts within the HyperBEAM environment. It provides an isolated sandbox where Lua code can process incoming messages, interact with other devices, and manage state.
+The [`~lua@5.3a`](../source-code/dev_lua.md) device enables the execution of Lua scripts within the HyperBEAM environment. It provides an isolated sandbox where Lua code can process incoming messages, interact with other devices, and manage state.
 
 ## Core Concept: Lua Script Execution
 
-This device allows processes to perform computations defined in Lua scripts. Similar to the [`~wasm64@1.0`](./source-code/dev_wasm.md) device, it manages the lifecycle of a Lua execution state associated with the process.
+This device allows processes to perform computations defined in Lua scripts. Similar to the [`~wasm64@1.0`](../source-code/dev_wasm.md) device, it manages the lifecycle of a Lua execution state associated with the process.
 
 ## Key Functions (Keys)
 
-These keys are typically used within an execution stack (managed by [`dev_stack`](./source-code/dev_stack.md)) for an AO process.
+These keys are typically used within an execution stack (managed by [`dev_stack`](../source-code/dev_stack.md)) for an AO process.
 
 *   **`init`**
-    *   **Action:** Initializes the Lua environment for the process. It finds and loads the Lua script(s) associated with the process, creates a `luerl` state, applies sandboxing rules if specified, installs the [`dev_lua_lib`](./source-code/dev_lua_lib.md) (providing AO-specific functions like `ao.send`), and stores the initialized state in the process's private area (`priv/state`).
+    *   **Action:** Initializes the Lua environment for the process. It finds and loads the Lua script(s) associated with the process, creates a `luerl` state, applies sandboxing rules if specified, installs the [`dev_lua_lib`](../source-code/dev_lua_lib.md) (providing AO-specific functions like `ao.send`), and stores the initialized state in the process's private area (`priv/state`).
     *   **Inputs (Expected in Process Definition or `init` Message):**
         *   `script`: Can be:
             *   An Arweave Transaction ID of the Lua script file.
@@ -48,14 +48,14 @@ The `sandbox` option in the process definition restricts potentially harmful Lua
 
 ## AO Library (`dev_lua_lib`)
 
-The `init` function automatically installs a helper library ([`dev_lua_lib`](./source-code/dev_lua_lib.md)) into the Lua state. This library typically provides functions for interacting with the AO environment from within the Lua script, such as:
+The `init` function automatically installs a helper library ([`dev_lua_lib`](../source-code/dev_lua_lib.md)) into the Lua state. This library typically provides functions for interacting with the AO environment from within the Lua script, such as:
 
 *   `ao.send({ Target = ..., ... })`: To send messages from the process.
 *   Access to message tags and data.
 
 ## Usage within `dev_stack`
 
-Like [`~wasm64@1.0`](./source-code/dev_wasm.md), the `~lua@5.3a` device is typically used within an execution stack.
+Like [`~wasm64@1.0`](../source-code/dev_wasm.md), the `~lua@5.3a` device is typically used within an execution stack.
 
 ```text
 # Example Process Definition Snippet
@@ -67,4 +67,4 @@ Sandbox: true
 
 This device offers a lightweight, integrated scripting capability for AO processes, suitable for a wide range of tasks from simple logic to more complex state management and interactions.
 
-[lua module](./source-code/dev_lua.md)
+[lua module](../source-code/dev_lua.md)

docs/build/devices/foundational/message-at-1-0.md

@@ -2,14 +2,14 @@
 
 ## Overview
 
-The [`~message@1.0`](./source-code/dev_message.md) device is a fundamental built-in device in HyperBEAM. It serves as the identity device for standard AO-Core messages, which are represented as Erlang maps internally. Its primary function is to allow manipulation and inspection of these message maps directly via HTTP requests, without needing a persistent process state.
+The [`~message@1.0`](../source-code/dev_message.md) device is a fundamental built-in device in HyperBEAM. It serves as the identity device for standard AO-Core messages, which are represented as Erlang maps internally. Its primary function is to allow manipulation and inspection of these message maps directly via HTTP requests, without needing a persistent process state.
 
 This device is particularly useful for:
 
 *   Creating and modifying transient messages on the fly using query parameters.
 *   Retrieving specific values from a message map.
 *   Inspecting the keys of a message.
-*   Handling message commitments and verification (though often delegated to specialized commitment devices like [`httpsig@1.0`](./source-code/dev_codec_httpsig.md)).
+*   Handling message commitments and verification (though often delegated to specialized commitment devices like [`httpsig@1.0`](../source-code/dev_codec_httpsig.md)).
 
 ## Core Functionality
 
@@ -44,7 +44,7 @@ The `message@1.0` device reserves several keys for specific operations:
 *   **`remove`**: Removes one or more specified keys from the message. Requires an `item` or `items` parameter.
 *   **`keys`**: Returns a list of all public (non-private) keys present in the message map.
 *   **`id`**: Calculates and returns the ID (hash) of the message. Considers active commitments based on specified `committers`. May delegate ID calculation to a device specified by the message's `id-device` key
-*   **`commit`**: Creates a commitment (e.g., a signature) for the message. Requires parameters like `commitment-device` and potentially committer information. Delegates the actual commitment generation to the specified device (default [`httpsig@1.0`](./source-code/dev_codec_httpsig.md)).
+*   **`commit`**: Creates a commitment (e.g., a signature) for the message. Requires parameters like `commitment-device` and potentially committer information. Delegates the actual commitment generation to the specified device (default [`httpsig@1.0`](../source-code/dev_codec_httpsig.md)).
 *   **`committers`**: Returns a list of committers associated with the commitments in the message. Can be filtered by request parameters.
 *   **`commitments`**: Used internally and in requests to filter or specify which commitments to operate on (e.g., for `id` or `verify`).
 *   **`verify`**: Verifies the commitments attached to the message. Can be filtered by `committers` or specific `commitment` IDs in the request. Delegates verification to the device specified in each commitment (`commitment-device`).
@@ -71,4 +71,4 @@ GET /~message@1.0&hello=world&k=v/k
 
 ```
 "v"
-``` 
+``` 

docs/build/devices/foundational/meta-at-1-0.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-The [`~meta@1.0`](./source-code/dev_meta.md) device provides access to metadata and configuration information about the local HyperBEAM node and the broader AO network.
+The [`~meta@1.0`](../source-code/dev_meta.md) device provides access to metadata and configuration information about the local HyperBEAM node and the broader AO network.
 
 This device is essential for:
 
@@ -30,7 +30,7 @@ While the `info` key is the primary interaction point, the `NodeMsg` managed by
 *   `operator`: The address designated as the node operator (defaults to the address derived from `priv_wallet`).
 *   `initialized`: Status indicating if the node setup is temporary or permanent.
 *   `preprocessor` / `postprocessor`: Optional messages defining pre/post-processing logic for requests.
-*   `routes`: Routing table used by [`dev_router`](./source-code/dev_router.md).
+*   `routes`: Routing table used by [`dev_router`](../source-code/dev_router.md).
 *   `store`: Configuration for data storage.
 *   `trace`: Debug tracing options.
 *   `p4_*`: Payment configuration.
@@ -40,7 +40,7 @@ While the `info` key is the primary interaction point, the `NodeMsg` managed by
 
 ## Utility Functions (Internal/Module Level)
 
-The [`dev_meta.erl`](./source-code/dev_meta.md) module also contains helper functions used internally or callable from other Erlang modules:
+The [`dev_meta.erl`](../source-code/dev_meta.md) module also contains helper functions used internally or callable from other Erlang modules:
 
 *   `is_operator(<RequestMsg>, <NodeMsg>) -> boolean()`: Checks if the signer of `RequestMsg` matches the configured `operator` in `NodeMsg`.
 
@@ -52,4 +52,4 @@ The `~meta` device applies the node's configured `preprocessor` message before r
 
 Before a node can process general requests, it usually needs to be initialized. Attempts to access devices other than `~meta@1.0/info` before initialization typically result in an error. Initialization often involves setting essential parameters like the operator key via a `POST` to `info`.
 
-[meta module](./source-code/dev_meta.md)
+[meta module](../source-code/dev_meta.md)

docs/build/devices/foundational/process-at-1-0.md

@@ -2,15 +2,15 @@
 
 ## Overview
 
-The [`~process@1.0`](./source-code/dev_process.md) device represents a persistent, shared execution environment within HyperBEAM, analogous to a process or actor in other systems. It allows for stateful computation and interaction over time.
+The [`~process@1.0`](../source-code/dev_process.md) device represents a persistent, shared execution environment within HyperBEAM, analogous to a process or actor in other systems. It allows for stateful computation and interaction over time.
 
 ## Core Concept: Orchestration
 
 A message tagged with `Device: process@1.0` (the "Process Definition Message") doesn't typically perform computation itself. Instead, it defines *which other devices* should be used for key aspects of its lifecycle:
 
-*   **Scheduler Device:** Determines the order of incoming messages (assignments) to be processed. (Defaults to [`~scheduler@1.0`](./source-code/dev_scheduler.md)).
-*   **Execution Device:** Executes the actual computation based on the current state and the scheduled message. Often configured as [`dev_stack`](./source-code/dev_stack.md) to allow multiple computational steps (e.g., running WASM, applying cron jobs, handling proofs).
-*   **Push Device:** Handles the injection of new messages into the process's schedule. (Defaults to [`~push@1.0`](./source-code/dev_push.md)).
+*   **Scheduler Device:** Determines the order of incoming messages (assignments) to be processed. (Defaults to [`~scheduler@1.0`](../source-code/dev_scheduler.md)).
+*   **Execution Device:** Executes the actual computation based on the current state and the scheduled message. Often configured as [`dev_stack`](../source-code/dev_stack.md) to allow multiple computational steps (e.g., running WASM, applying cron jobs, handling proofs).
+*   **Push Device:** Handles the injection of new messages into the process's schedule. (Defaults to [`~push@1.0`](../source-code/dev_push.md)).
 
 The `~process@1.0` device acts as a router, intercepting requests and delegating them to the appropriate configured device (scheduler, executor, etc.) by temporarily swapping the device tag on the message before resolving.
 
@@ -28,7 +28,7 @@ These keys are accessed via an HTTP path relative to the Process Definition Mess
 *   **`GET /<ProcessID>~process@1.0/compute/<TargetSlotOrMsgID>`**
     *   **Action:** Computes the process state up to a specific point identified by `<TargetSlotOrMsgID>` (either a slot number or a message ID within the schedule). It retrieves assignments from the Scheduler Device and applies them sequentially using the configured Execution Device.
     *   **Response:** The process state message after executing up to the target slot/message.
-    *   **Caching:** Results are cached aggressively (see [`dev_process_cache`](./source-code/dev_process_cache.md)) to avoid recomputation.
+    *   **Caching:** Results are cached aggressively (see [`dev_process_cache`](../source-code/dev_process_cache.md)) to avoid recomputation.
 *   **`GET /<ProcessID>~process@1.0/now`**
     *   **Action:** Computes and returns the `Results` key from the *latest* known state of the process. This typically involves computing all pending assignments.
     *   **Response:** The value of the `Results` key from the final state.
@@ -63,10 +63,10 @@ This defines a process that uses:
 
 ## State Management & Caching
 
-`~process@1.0` relies heavily on caching ([`dev_process_cache`](./source-code/dev_process_cache.md)) to optimize performance. Full state snapshots and intermediate results are cached periodically (configurable via `Cache-Frequency` and `Cache-Keys` options) to avoid recomputing the entire history for every request.
+`~process@1.0` relies heavily on caching ([`dev_process_cache`](../source-code/dev_process_cache.md)) to optimize performance. Full state snapshots and intermediate results are cached periodically (configurable via `Cache-Frequency` and `Cache-Keys` options) to avoid recomputing the entire history for every request.
 
 ## Initialization (`init`)
 
 Processes often require an initialization step before they can process messages. This is typically triggered by calling the `init` key on the configured Execution Device via the process path (`/<ProcessID>~process@1.0/init`). This allows components within the execution stack (like WASM modules) to set up their initial state.
 
-[process module](./source-code/dev_process.md)
+[process module](../source-code/dev_process.md)