Add Envoy support page and update theme

docs/.gitignore

@@ -1 +1,2 @@
 .hugo_build.lock
+.hvm

docs/content/envoy/api.en.md

@@ -7,7 +7,7 @@ weight: 90
 ---
 
 {{% notice style="tip" title="API Credentials" icon="rocket" %}}
-In order to use the API you will have to generate an API Key Client ID and Secret either from the user interface, or by using the command line tool as described in ["creating api keys"]({{< relref "deploy.md#creating-api-keys" >}}).
+In order to use the API you will have to generate an API Key Client ID and Secret either from the user interface, or by using the command line tool as described in ["creating api keys"]({{% relref "deploy.md#creating-api-keys" %}}).
 {{% /notice %}}
 
 ## Authentication and Authorization

docs/content/envoy/deploy.en.md

@@ -6,7 +6,7 @@ description: "A quick guide on deploying your Envoy node"
 weight: 10
 ---
 
-This guide assumes that you're ready to deploy your Envoy node and that you've already obtained either TRISA TestNet or MainNet certificates as described by [the Joining TRISA guide]({{< ref "joining-trisa" >}}). If you haven't already, please go to the [TRISA Global Directory Service (vaspdirectory.net)](https://vaspdirectory.net/) to register for your certificates!
+This guide assumes that you're ready to deploy your Envoy node and that you've already obtained either TRISA TestNet or MainNet certificates as described by [the Joining TRISA guide]({{% ref "joining-trisa" %}}). If you haven't already, please go to the [TRISA Global Directory Service (vaspdirectory.net)](https://vaspdirectory.net/) to register for your certificates!
 
 {{% notice style="note" title="Local Development" icon="code" %}}
 If you'd like information about how to run Envoy locally using [Docker Compose](https://docs.docker.com/compose/) and self-signed keys generated using `openssl` please go to the repository at [trisacrypto/envoy](https://github.com/trisacrypto/envoy) and follow the instructions in the `README.md`.
@@ -16,7 +16,7 @@ The general/top-level steps to deploy an Envoy node are as follows:
 
 1. Obtain and decrypt TRISA certificates
 2. Setup a deployment environment (e.g. a cloud instance or kubernetes cluster)
-3. [Configure]({{< relref "configuration.md" >}}) the Envoy node via the environment
+3. [Configure]({{% relref "configuration.md" %}}) the Envoy node via the environment
 4. Deploy your Envoy node using one of the instructions below
 5. Ensure that you can reach your node at port 443
 6. Configure DNS to point your TRISA endpoint at your node
@@ -135,5 +135,5 @@ Alternative, you can specify which permissions you want the API key to have by l
 $ envoy createapikey users:manage users:view
 ```
 
-The list of the permissions you can add to an API key can be found in the [API guide permissions table]({{< relref "api.en.md#permissions" >}}).
+The list of the permissions you can add to an API key can be found in the [API guide permissions table]({{% relref "api.en.md#permissions" %}}).
 

docs/content/envoy/support.end.md

@@ -0,0 +1,22 @@
+---
+title: "Envoy Support"
+date: 2024-12-10T13:53:33-05:00
+lastmod: 2024-12-10T13:53:33-05:00
+description: "Envoy Support"
+weight: 100
+---
+
+## How can we help?
+
+
+|                        | Open Source            | One-Time Setup         | Managed Service |
+| ------------------------------- | :----------------------: | :----------------------: | :----------------------: |
+| [Envoy Documentation](https://trisa.dev/envoy/index.html)                                            | 	✓                                    | 	✓                                    | 	✓                                    |
+| Access to [TRISA Slack Community](https://trisa-workspace.slack.com/)                                | 	✓                                    | 	✓                                    | 	✓                                    |
+| Training from Envoy Team                                       |                                              | 	✓                                    | 	✓                                    |
+| Dedicated Support                                              |                                              |                                              | 	✓                                    |
+| Response Time*                                                 | Within 5 business days                       | Within 5 business days                       | Within 3 business days                       |
+
+
+
+***The Envoy team's business hours are 9AM - 6PM Eastern.**

docs/content/envoy/webhook.en.md

@@ -7,7 +7,7 @@ weight: 95
 ---
 
 {{% notice style="tip" title="Enabling the Webhook" icon="anchor" %}}
-To enable the Envoy webhook, you must first specify a webhook endpoint using the `$TRISA_WEBHOOK_URL` as specified in the ["configuration values"]({{< relref "configuration.md#configuration-values" >}}). This URL should be available for HTTP POST requests from the Envoy node. If this value is not specified, Envoy will not make any webhook callbacks.
+To enable the Envoy webhook, you must first specify a webhook endpoint using the `$TRISA_WEBHOOK_URL` as specified in the ["configuration values"]({{% relref "envoy/configuration.md#configuration-values" %}}). This URL should be available for HTTP POST requests from the Envoy node. If this value is not specified, Envoy will not make any webhook callbacks.
 {{% /notice %}}
 
 When Envoy receives an incoming travel rule message from a remote counterparty it must return a response to that request (for both TRP and TRISA requests). Envoy may handle the request automatically using accept/reject policies or it may simply send a pending message back as the default response. Envoy also supports handling incoming messages by using a webhook callback for another compliance system to determine handling.
@@ -82,7 +82,7 @@ The reply to the POST request must have a 200 status code and the following data
 
 If the `transaction_id` does not match the ID of the request, then Envoy will fail and return an error to the counterparty.
 
-The `transfer_action` can be one of "PENDING", "REVIEW", "REPAIR", "ACCEPTED", "REJECTED", or "COMPLETED". See [TRISA workflows]({{< relref "../api/workflows.md" >}}) for more about how these states determine responses to incoming messages. A basic summary is as follows:
+The `transfer_action` can be one of "PENDING", "REVIEW", "REPAIR", "ACCEPTED", "REJECTED", or "COMPLETED". See [TRISA workflows]({{% relref "../api/workflows.md" %}}) for more about how these states determine responses to incoming messages. A basic summary is as follows:
 
 Use `"PENDING"` if a compliance officer on your team needs to review the travel rule request, make sure you include a `pending` and `identity` in your reply.
 
@@ -122,7 +122,7 @@ The fields for the error are as follows:
 | message | string | a detailed message about why the request is being rejected or what needs to be repaired |
 | retry | bool | should be false if this is a rejection, true if a repair is being requested |
 
-View the available [error codes in the TRISA API docs]({{< relref "../api/errors.md" >}}).
+View the available [error codes in the TRISA API docs]({{% relref "../api/errors.md" %}}).
 
 ### Payload
 
@@ -150,9 +150,9 @@ The payload fields are as follows:
 | sent_at | string | the RFC3339 encoded timestamp of when the compliance exchange was initiated |
 | received_at | string | the RFC3339 encoded timestamp of when the compliance exchange was approved by the counterparty |
 
-For more information about IVMS101, please see: [Working with IVMS101]({{< relref "../data/ivms.md" >}}).
+For more information about IVMS101, please see: [Working with IVMS101]({{% relref "../data/ivms.md" %}}).
 
-For more information about the pending and transaction generic payloads, please see: [TRISA Data Payloads]({{< relref "../data/payloads.md" >}}).
+For more information about the pending and transaction generic payloads, please see: [TRISA Data Payloads]({{% relref "../data/payloads.md" %}}).
 
 ### Counterparty
 

docs/content/joining-trisa/verification.en.md

@@ -6,7 +6,7 @@ description: "Domain Verification"
 weight: 70
 ---
 
-The [TRISA Certificate Authority]({{% relref "/ca" %}}) issues [x509 certificates](https://sectigo.com/resource-library/what-is-x509-certificate) for mTLS authentication in its peer-to-peer network. These certificates are dependent on the verified ownership of a domain name that is used both in the _common name_ of the certificate (CN) as well as the _subject alternative name_ (SAN) extension of the certificate. Your TRISA node must be hosted at a domain name that is in the SAN field of the certificate otherwise mTLS connections will fail.
+The [TRISA Certificate Authority]({{% relref "joining-trisa/ca" %}}) issues [x509 certificates](https://sectigo.com/resource-library/what-is-x509-certificate) for mTLS authentication in its peer-to-peer network. These certificates are dependent on the verified ownership of a domain name that is used both in the _common name_ of the certificate (CN) as well as the _subject alternative name_ (SAN) extension of the certificate. Your TRISA node must be hosted at a domain name that is in the SAN field of the certificate otherwise mTLS connections will fail.
 
 {{% notice note %}}
 The domain that you host your TRISA node, e.g. `trisa.example.com` must be the common name of your TRISA Identity Certificates and _must_ match the endpoint of your TRISA directory record, e.g. `trisa.example.com:443`. If not, TRISA peers will be unable to connect to your TRISA node using mTLS. If you are using multiple domain names, please contact TRISA support for assistance.

docs/hugo.toml

@@ -14,7 +14,6 @@ enableMissingTranslationPlaceholders = false
 [params]
 
     # Source Code repository section
-    description = "TRISA Documentation"
     github_repository = "https://github.com/trisacrypto/trisa"
     version = "v1beta1"