filip(fix): add config for trailing slashes (#1764)

<!-- Describe your change here -->
add config for trailing slashes on docs site
---

<!-- Consider each and tick it off one way or the other -->
* [ ] CHANGELOG updated or not needed
* [X] Documentation updated
* [ ] Haddocks updated or not needed
* [ ] No new TODOs introduced or explained herafter

docs/docs/dev/architecture/index.md

@@ -23,7 +23,7 @@ $ plantuml -Tsvg architecture-c4.puml
 
 ### Network
 
-The _network_ component is responsible for communication between Hydra nodes related to the off-chain part of the Hydra protocol. See [Networking](./networking) for details.
+The _network_ component is responsible for communication between Hydra nodes related to the off-chain part of the Hydra protocol. See [Networking](./architecture/networking) for details.
 
 ### Chain interaction
 

docs/docs/dev/index.md

@@ -4,4 +4,4 @@ If you've read the [user manual](../index.md) and want to learn more about the H
 
 The developer documentation provides detailed materials that move beyond just _using_ Hydra to _understanding_ it. This section is for anyone looking to gain a comprehensive understanding of the Hydra protocol, including protocol architects interested in developing their own variants and developers contributing to the [reference implementation](https://github.com/input-output-hk/hydra) of Hydra.
 
-The following sections are more technical and may be less cohesive than the user manual. However, the [architecture](./architecture) and the [specification](./specification) sections are good starting points.
+The following sections are more technical and may be less cohesive than the user manual. However, the [architecture](./dev/architecture) and the [specification](./dev/specification) sections are good starting points.

docs/docs/index.md

@@ -4,7 +4,7 @@ This section is a manual for users interested in running a Hydra node.
 
 Hydra node is an implementation of the Hydra Head protocol, designed to enable fast and low-cost transactions by operating off-chain while leveraging the security of the main Cardano blockchain.
 
-Decentralized applications (DApps), exchanges, and enterprise-level services can choose to run a Hydra node to participate in forming Hydra heads – mini-ledgers that process transactions independently and in parallel, significantly enhancing throughput and reducing latency. 
+Decentralized applications (DApps), exchanges, and enterprise-level services can choose to run a Hydra node to participate in forming Hydra heads – mini-ledgers that process transactions independently and in parallel, significantly enhancing throughput and reducing latency.
 
 The `hydra-node` interfaces with the Cardano blockchain, connects to other `hydra-nodes` on a dedicated overlay network, runs a simplified (coordinated) Hydra Head protocol, and provides an API for clients.
 
@@ -32,7 +32,7 @@ implied terms are excluded to the fullest extent permitted by law. For details,
 see also sections 7, 8 and 9 of the [Apache 2.0 License][license].
 :::
 
-Now, without further ado, you can learn more about the protocol by visiting the [protocol overview page](./protocol-overview) or directly dive into [getting started using a local devnet](./getting-started).
+Now, without further ado, you can learn more about the protocol by visiting the [protocol overview page](./docs/protocol-overview) or directly dive into [getting started using a local devnet](./docs/getting-started).
 
 [known-issues]: ./known-issues.md
 [license]: https://github.com/cardano-scaling/hydra/blob/master/LICENSE

docs/docs/tutorial/index.md

@@ -386,7 +386,7 @@ In summary, the Hydra head participants exchanged and agreed on:
 ## Step 3. Start the Hydra node
 
 
-Scripts are pre-published for all [released](https://github.com/cardano-scaling/hydra/releases) HYDRA_VERSIONs of the `hydra-node` and common Cardano networks. Consult the [user manual](../configuration#reference-scripts) for guidance on publishing your own scripts.
+Scripts are pre-published for all [released](https://github.com/cardano-scaling/hydra/releases) HYDRA_VERSIONs of the `hydra-node` and common Cardano networks. Consult the [user manual](../docs/configuration#reference-scripts) for guidance on publishing your own scripts.
 
 
 Start the `hydra-node` using these parameters:

docs/docusaurus.config.js

@@ -24,6 +24,7 @@ const config = {
   projectName: "Hydra",
   staticDirectories: ["static", customFields.apiSpecDir],
   customFields,
+  trailingSlash: false,
 
   scripts: [
     {

docs/topologies/managed/index.mdx

@@ -21,7 +21,7 @@ This document outlines the _managed Hydra head_ topology, which could also be de
   />
 </p>
 
-The [basic Hydra head setup](../basic) requires each participant to host an instance of a `hydra-node`, similar to how `cardano-node`s operate on the Cardano network. In contrast, 'light node' setups allow users to access the blockchain through a hosted API, with light wallets being a common example.
+The [basic Hydra head setup](./basic) requires each participant to host an instance of a `hydra-node`, similar to how `cardano-node`s operate on the Cardano network. In contrast, 'light node' setups allow users to access the blockchain through a hosted API, with light wallets being a common example.
 
 In this topology, clients do not need to run their own `hydra-node`s but instead access a `hydra-node` provided by a _service provider_. Client applications, such as light wallets, do not need to be aware of individual `hydra-node` instances. Instead, logical _Hydra heads_ are accessible via an API.
 
@@ -30,6 +30,6 @@ For this setup to be feasible, it is crucial that the _Hydra keys_ remain on the
 
 As a result, the client must be online for any progress to occur within a Hydra head. This requirement can be cumbersome in multi-party Hydra heads, as they may stall if a lightweight mobile client is offline for a period. However, this setup aligns well with _two-party Hydra heads_, where a transaction is only completed if both parties are online to send, receive, and acknowledge it.
 
-An example use case for two-party Hydra heads includes payment channels between two [machines](../../use-cases/payments/pay-per-use-api) or [individuals](../../use-cases/payments/inter-wallet-payments), especially if such multiple channels are logically interconnected, similar to the Lightning Network.
+An example use case for two-party Hydra heads includes payment channels between two [machines](./../use-cases/payments/pay-per-use-api) or [individuals](./../use-cases/payments/inter-wallet-payments), especially if such multiple channels are logically interconnected, similar to the Lightning Network.
 
 Although access to Hydra heads is facilitated by the service provider, this does not centralize the system. A client can always close a head and recover funds with an alternative provider or even use a transaction created out-of-band (eg, by the client application using another service to submit the transaction).