fix: all image links can no longer rely on the remark hack

Author: CMCDragonkai

docs/README.md

@@ -19,7 +19,7 @@ The documentation is structured using
 - [Reference](./reference/) - these are useful when you need remember how to use
   a particular command or function
 
-<img src="/images/divio_quadrant.png" width="100%" />
+<img src={require('@site/images/divio_quadrant.png').default} width="100%" />
 
 ## Introduction
 

docs/reference/polykey-core/audit.md

@@ -1,16 +1,22 @@
 # Audit
 
-The Audit system in Polykey provides a way to track and retrieve events that occur within the Polykey agent. This feature is essential for security monitoring, troubleshooting, and compliance purposes.
+The Audit system in Polykey provides a way to track and retrieve events that
+occur within the Polykey agent. This feature is essential for security
+monitoring, troubleshooting, and compliance purposes.
 
 ## Overview
 
-The Audit system records various events that occur during the operation of a Polykey node. These events are stored in a structured format and can be retrieved for analysis. The system is designed to be efficient and secure, with events stored in the node's database.
+The Audit system records various events that occur during the operation of a
+Polykey node. These events are stored in a structured format and can be
+retrieved for analysis. The system is designed to be efficient and secure, with
+events stored in the node's database.
 
 ## Core Components
 
 ### Audit Class
 
-The `Audit` class is the main component of the audit system. It provides methods for:
+The `Audit` class is the main component of the audit system. It provides methods
+for:
 
 - Recording audit events
 - Retrieving audit events
@@ -22,13 +28,15 @@ Audit events have the following structure:
 
 - `id`: A unique identifier for the event (AuditEventId)
 - `path`: An array of strings representing the event category/path
-- `data`: The event data, which can contain any relevant information about the event
+- `data`: The event data, which can contain any relevant information about the
+  event
 
 ## Usage
 
 ### Retrieving Audit Events
 
-Audit events can be retrieved from a node using the `nodesAuditEventsGet` RPC method. This method supports:
+Audit events can be retrieved from a node using the `nodesAuditEventsGet` RPC
+method. This method supports:
 
 - Pagination through `seek` and `seekEnd` parameters
 - Limiting the number of results with the `limit` parameter
@@ -39,10 +47,10 @@ Example usage through the node connection:
 ```typescript
 // Retrieve audit events from a connected node
 const response = await nodeConnection.getClient().methods.nodesAuditEventsGet({
-  seek: 0,                // Start from the beginning or specific audit event ID
-  seekEnd: Date.now(),    // End at current time or specific audit event ID
-  limit: 100,             // Limit the number of results
-  order: 'asc'            // Order results (asc or desc)
+  seek: 0, // Start from the beginning or specific audit event ID
+  seekEnd: Date.now(), // End at current time or specific audit event ID
+  limit: 100, // Limit the number of results
+  order: 'asc', // Order results (asc or desc)
 });
 
 // Process the audit events
@@ -55,21 +63,28 @@ for await (const auditEvent of response) {
 
 ### Event Types
 
-The audit system can record various types of events, including but not limited to:
+The audit system can record various types of events, including but not limited
+to:
 
 - Node connection events (e.g., `['node', 'connection', 'forward']`)
 - Authentication events (e.g., `['auth', 'success']`, `['auth', 'failure']`)
 - Vault operations (e.g., `['vault', 'create']`, `['vault', 'delete']`)
 - Secret access events (e.g., `['secret', 'read']`, `['secret', 'write']`)
-- Permission changes (e.g., `['permission', 'grant']`, `['permission', 'revoke']`)
+- Permission changes (e.g., `['permission', 'grant']`,
+  `['permission', 'revoke']`)
 
-Each event type has a specific path structure and data format. The path is an array of strings that categorizes the event, while the data contains relevant information specific to that event type.
+Each event type has a specific path structure and data format. The path is an
+array of strings that categorizes the event, while the data contains relevant
+information specific to that event type.
 
 ## Security Considerations
 
-Audit events are stored locally on the node and are only accessible to authorized users with appropriate permissions. When retrieving audit events from another node, proper authentication and authorization are required.
+Audit events are stored locally on the node and are only accessible to
+authorized users with appropriate permissions. When retrieving audit events from
+another node, proper authentication and authorization are required.
 
-The audit system is designed to be secure and tamper-resistant, ensuring that audit events cannot be modified or deleted without proper authorization.
+The audit system is designed to be secure and tamper-resistant, ensuring that
+audit events cannot be modified or deleted without proper authorization.
 
 ## Integration with Other Components
 
@@ -99,8 +114,10 @@ The audit system is implemented using the following key files:
 - `src/audit/Audit.ts`: The main Audit class implementation
 - `src/audit/types.ts`: Type definitions for audit events
 - `src/audit/utils.ts`: Utility functions for audit operations
-- `src/nodes/agent/handlers/NodesAuditEventsGet.ts`: Handler for retrieving audit events
-- `src/nodes/agent/callers/nodesAuditEventsGet.ts`: Caller for the audit events RPC method
+- `src/nodes/agent/handlers/NodesAuditEventsGet.ts`: Handler for retrieving
+  audit events
+- `src/nodes/agent/callers/nodesAuditEventsGet.ts`: Caller for the audit events
+  RPC method
 
 ## Future Enhancements
 
@@ -110,4 +127,4 @@ Future versions of the audit system may include:
 - Enhanced filtering capabilities based on event paths and data
 - Export functionality for audit logs to common formats (CSV, JSON)
 - Integration with external logging systems (Syslog, ELK stack)
-- Real-time audit event notifications
+- Real-time audit event notifications

docs/theory/decentralized-trust-network.md

@@ -26,7 +26,7 @@ Slack).
 
 <p align="center">
   <figure>
-    <img src="/images/gestalts-and-DIs/di-ceos.png" width="60%" />
+    <img src={require('@site/images/gestalts-and-DIs/di-ceos.png').default} width="60%" />
     <br />
     <figcaption>From top left to bottom: Digital identities for the CEOs of Twitter, GitHub, LinkedIn, and FaceBook</figcaption>
   </figure>
@@ -141,7 +141,7 @@ a [X.509 certificate](https://en.wikipedia.org/wiki/X.509).
 
 <p align="center">
   <figure>
-    <img src="/images/divio_quadrant.png" width="100%" />
+    <img src={require('@site/images/divio_quadrant.png').default} width="100%" />
     <br />
     <figcaption>X.509 certificates act as the root of trust for Polykey Sigchains</figcaption>
   </figure>
@@ -175,7 +175,7 @@ Keynodes and digital identities as its vertices.
 
 <p align="center">
   <figure>
-    <img src="/images/gestalts-and-DIs/GestaltDiagram.png" width="70%" />
+    <img src={require('@site/images/gestalts-and-DIs/GestaltDiagram.png').default} width="70%" />
     <br />
     <figcaption>Visual depiction of a Polykey Gestalt</figcaption>
   </figure>
@@ -210,7 +210,7 @@ distributed clients.
 
 <p align="center">
   <figure>
-    <img src="/images/gestalts-and-DIs/keybase.png" width="70%" />
+    <img src={require('@site/images/gestalts-and-DIs/keybase.png').default} width="70%" />
     <br />
     <figcaption>Digital identity augmentation as implemented within Keybase</figcaption>
   </figure>
@@ -247,15 +247,15 @@ stages, however, only the final three belong to the augmentation itself:
 
 <p align="center">
   <figure>
-    <img src="/images/gestalts-and-DIs/augmentation.png" width="90%" />
+    <img src={require('@site/images/gestalts-and-DIs/augmentation.png').default} width="90%" />
     <br />
     <figcaption>Polykey's Digital Identity (DI) augmentation process</figcaption>
   </figure>
 </p>
 
 <p align="center">
   <figure>
-    <img src="/images/gestalts-and-DIs/augmentationv3.png" width="90%" />
+    <img src={require('@site/images/gestalts-and-DIs/augmentationv3.png').default} width="90%" />
     <br />
     <figcaption>Structure of a cryptolink generated via augmentation</figcaption>
   </figure>
@@ -342,7 +342,7 @@ communicate with.
 
 <p align="center">
   <figure>
-    <img src="/images/gestalts-and-DIs/gestalt-discovery.png" width="90%" />
+    <img src={require('@site/images/gestalts-and-DIs/gestalt-discovery.png').default} width="90%" />
     <br />
     <figcaption>The Gestalt Discovery process</figcaption>
   </figure>
@@ -355,7 +355,7 @@ functionality and application.
 
 <p align="center">
   <figure>
-    <img src="/images/gestalts-and-DIs/gestalt-trust-chain.png" width="90%" />
+    <img src={require('@site/images/gestalts-and-DIs/gestalt-trust-chain.png').default} width="90%" />
     <br />
     <figcaption>The beginnings of a trust network formed by Gestalts</figcaption>
   </figure>

docs/tutorials/polykey-cli/claiming-digital-identities.md

@@ -100,7 +100,7 @@ After successfully authenticating with GitHub, you can claim your identity. This
 involves posting a cryptographic link to a publicly verifiable location, such as
 a GitHub gist. This link serves as proof of ownership of the identity.
 
-<img src="/images/cryptolink.png" alt="Cryptolink"
+<img src={require('@site/images/cryptolink.png').default} alt="Cryptolink"
 style={{ width: '70%', height: 'auto' }} />
 
 ### Command Usage