docs: update docusaurus with correct relative links [skip ci]

docs/docusaurus/connections/connection.md

@@ -2,15 +2,15 @@
 
 A connection is a stateful relationship between two parties that enables secure communication.
 
-The [Connection protocol](docs/concepts/glossary#connection-protocol) is required to establish secure connections between agents,
+The [Connection protocol](/docs/concepts/glossary#connection-protocol) is required to establish secure connections between agents,
 allowing them to exchange information and interact.
 
 ## Roles
 
 The connection protocol has two roles:
 
-1.  [Inviter](docs/concepts/glossary#inviter): A subject that initiates a connection request by sending a [connection invitation](docs/concepts/glossary#connection-invitation).
-2.  [Invitee](docs/concepts/glossary#invitee): A subject that receives a connection invitation and accepts it by sending a [connection request](docs/concepts/glossary#connection-request).
+1.  [Inviter](/docs/concepts/glossary#inviter): A subject that initiates a connection request by sending a [connection invitation](/docs/concepts/glossary#connection-invitation).
+2.  [Invitee](/docs/concepts/glossary#invitee): A subject that receives a connection invitation and accepts it by sending a [connection request](/docs/concepts/glossary#connection-request).
 
 ## Prerequisites
 
@@ -55,7 +55,7 @@ ConnectionResponseSent --> [*]
 
 1.  Receive the OOB invitation (`InvitationReceived` state)
 2.  Accept the invitation (connection is created in `ConnectionRequestPending` state)
-3.  Send the connection request via [DIDComm](docs/concepts/glossary#didcomm) (connection achieves `ConnectionRequestSent` state)
+3.  Send the connection request via [DIDComm](/docs/concepts/glossary#didcomm) (connection achieves `ConnectionRequestSent` state)
 4.  Receive the connection response (connection achieves `ConnectionResponseReceived` state)
 
 The following diagram represents the Invitee's Connection state transitions:

docs/docusaurus/credentials/issue.md

@@ -1,13 +1,13 @@
 # Issue Credentials
 
-In Atala PRISM, the [Issue Credentials Protocol](docs/concepts/glossary#issue-credentials-protocol) allows you to create, retrieve, and manage issued [verifiable credentials (VCs)](docs/concepts/glossary#verifiable-credentials) between a VC issuer and a VC holder.
+In Atala PRISM, the [Issue Credentials Protocol](/docs/concepts/glossary#issue-credentials-protocol) allows you to create, retrieve, and manage issued [verifiable credentials (VCs)](/docs/concepts/glossary#verifiable-credentials) between a VC issuer and a VC holder.
 
 ## Roles
 
 In the Issue Credentials Protocol, there are two roles:
 
-1. The [Issuer](docs/concepts/glossary#issuer) is responsible for creating a new credential offer, sending it to a Holder, and issuing the VC once the offer is accepted.
-2. The [Holder](docs/concepts/glossary#holder) is responsible for accepting a credential offer from an issuer and receiving the VC.
+1. The [Issuer](/docs/concepts/glossary#issuer) is responsible for creating a new credential offer, sending it to a Holder, and issuing the VC once the offer is accepted.
+2. The [Holder](/docs/concepts/glossary#holder) is responsible for accepting a credential offer from an issuer and receiving the VC.
 
 The Issuer and Holder interact with the PRISM Agent API to perform the operations defined in the protocol.
 
@@ -18,7 +18,7 @@ Before using the Issuing Credentials protocol, the following conditions must be
 
 1. Issuer and Holder PRISM Agents up and running
 2. A connection must be established between the Issuer and Holder PRISM Agents (see [Connections](../connections/connection.md))
-3. The Issuer must have a published PRISM DID, and the [DID document](docs/concepts/glossary#did-document) must have at least one `assertionMethod` key for issuing credentials (see [Create DID](../dids/create.md) and [Publish DID](../dids/publish.md))
+3. The Issuer must have a published PRISM DID, and the [DID document](/docs/concepts/glossary#did-document) must have at least one `assertionMethod` key for issuing credentials (see [Create DID](../dids/create.md) and [Publish DID](../dids/publish.md))
 4. The Holder must have a PRISM DID, and the DID document must have at least one `authentication` key for presenting the proof.
 
 ## Overview
@@ -29,7 +29,7 @@ The protocol consists of the following main parts:
 
 1. The Issuer creates a new credential offer using the [`/issue-credentials/credential-offers`](/agent-api/#tag/Issue-Credentials-Protocol/operation/createCredentialOffer) endpoint, which includes information such as the schema identifier and claims.
 2. The Holder can then retrieve the offer using the [`/issue-credentials/records`](/agent-api/#tag/Issue-Credentials-Protocol/operation/getCredentialRecords) endpoint and accept the offer using the [`/issue-credentials/records/{recordId}/accept-offer`](/agent-api/#tag/Issue-Credentials-Protocol/operation/acceptCredentialOffer) endpoint.
-3. The Issuer then uses the [`/issue-credentials/records/{recordId}/issue-credential`](/agent-api/#tag/Issue-Credentials-Protocol/operation/issueCredential) endpoint to issue the credential, which gets sent to the Holder via [DIDComm](docs/concepts/glossary#didcomm). The Holder receives the credential, and the protocol is complete.
+3. The Issuer then uses the [`/issue-credentials/records/{recordId}/issue-credential`](/agent-api/#tag/Issue-Credentials-Protocol/operation/issueCredential) endpoint to issue the credential, which gets sent to the Holder via [DIDComm](/docs/concepts/glossary#didcomm). The Holder receives the credential, and the protocol is complete.
 
 The schema identifier defines the structure and the credential type issued,
 while the claims provide specific information about the individual, such as their name or qualifications.
@@ -152,7 +152,7 @@ curl "http://localhost:8090/prism-agent/issue-credentials/records" \
 To accept the offer, the Holder can make a `POST` request to the [`/issue-credentials/records/{recordId}/accept-offer`](/agent-api/#tag/Issue-Credentials-Protocol/operation/acceptCredentialOffer) endpoint with a JSON payload that includes the following information:
 
 1. `holder_record_id`: The unique identifier of the issue credential record known by the holder PRISM Agent.
-2. `subjectId`: This field represents the unique identifier for the subject of the verifiable credential. It is a short-form PRISM [DID](docs/concepts/glossary#decentralized-identifier) string, such as `did:prism:subjectIdentifier`.
+2. `subjectId`: This field represents the unique identifier for the subject of the verifiable credential. It is a short-form PRISM [DID](/docs/concepts/glossary#decentralized-identifier) string, such as `did:prism:subjectIdentifier`.
 
 ```shell
 # Holder POST request to accept the credential offer

docs/docusaurus/credentials/present-proof.md

@@ -1,8 +1,8 @@
 # Present proof
 
-The [Present Proof Protocol](docs/concepts/glossary#present-proof-protocol) allows:
-- a [Verifier](docs/concepts/glossary#verifier) to request a verifiable credential presentation from a Holder/Prover
-- a [Holder/Prover](docs/concepts/glossary#holder) responds by presenting a cryptographic proof to the Verifier
+The [Present Proof Protocol](/docs/concepts/glossary#present-proof-protocol) allows:
+- a [Verifier](/docs/concepts/glossary#verifier) to request a verifiable credential presentation from a Holder/Prover
+- a [Holder/Prover](/docs/concepts/glossary#holder) responds by presenting a cryptographic proof to the Verifier
 
 The protocol provides endpoints for a Verifier to request new proof presentations from Holder/Provers and for a Holder/Prover to respond to the presentation request using a specific verifiable credential they own.
 
@@ -11,15 +11,15 @@ The protocol provides endpoints for a Verifier to request new proof presentation
 The present proof protocol has two roles:
 
 1.  Verifier: A subject requesting a proof presentation by sending a request presentation message, then verifying the presentation.
-2.  Holder/Prover: A [subject](docs/concepts/glossary#subject) that receives a [proof presentation](docs/concepts/glossary#proof-presentation) request, prepares a proof, and sends it to the verifier by sending a proof presentation message.
+2.  Holder/Prover: A [subject](/docs/concepts/glossary#subject) that receives a [proof presentation](/docs/concepts/glossary#proof-presentation) request, prepares a proof, and sends it to the verifier by sending a proof presentation message.
 
 ## Prerequisites
 
 Before using the Proof Presentation protocol, the following conditions must be present:
 
 1. Holder/Prover and Verifier PRISM Agents must be up and running
 2. A connection must be established between the Holder/Prover and Verifier PRISM Agents (see [Connections](../connections/connection.md))
-3. The Holder/Prover should hold a [verifiable credential (VC)](docs/concepts/glossary#verifiable-credential) received from an [Issuer](docs/concepts/glossary#issuer) see [Issue](./issue.md).
+3. The Holder/Prover should hold a [verifiable credential (VC)](/docs/concepts/glossary#verifiable-credential) received from an [Issuer](/docs/concepts/glossary#issuer) see [Issue](./issue.md).
 
 ## Overview
 

docs/docusaurus/dids/create.md

@@ -1,16 +1,16 @@
 # Create DID
 
-PRISM DIDs are a type of [decentralized identifier (DID)](docs/concepts/glossary#decentralized-identifier) used across the Atala PRISM product suite.
+PRISM DIDs are a type of [decentralized identifier (DID)](/docs/concepts/glossary#decentralized-identifier) used across the Atala PRISM product suite.
 
-It is a variation of a [sidetree protocol](https://identity.foundation/sidetree/spec/) and uses the Cardano blockchain as the underlying ledger for [DID resolution](docs/concepts/glossary#did-resolution) and operation publication.
+It is a variation of a [sidetree protocol](https://identity.foundation/sidetree/spec/) and uses the Cardano blockchain as the underlying ledger for [DID resolution](/docs/concepts/glossary#did-resolution) and operation publication.
 Please refer to the [PRISM method specification](https://github.com/input-output-hk/prism-did-method-spec/blob/main/w3c-spec/PRISM-method.md) for a more detailed explanation of how it works.
 
-PRISM DIDs can be created entirely offline without interacting with the blockchain by constructing a DID create-operation, a [protocol buffer (protobuf)](docs/concepts/glossary#protocol-buffer) message with a set of public keys and services.
+PRISM DIDs can be created entirely offline without interacting with the blockchain by constructing a DID create-operation, a [protocol buffer (protobuf)](/docs/concepts/glossary#protocol-buffer) message with a set of public keys and services.
 Once the create-operation gets constructed, deriving a DID from this operation is possible, which is well-defined by the [PRISM DID method](https://github.com/input-output-hk/prism-did-method-spec/blob/main/w3c-spec/PRISM-method.md).
 
 ## Roles
 
-1. [DID Controller](docs/concepts/glossary#did-controller) is the organization or individual who has control of the DID.
+1. [DID Controller](/docs/concepts/glossary#did-controller) is the organization or individual who has control of the DID.
 
 ## Prerequisites
 
@@ -53,7 +53,7 @@ The result should show an empty list, as no DIDs exist on this PRISM Agent insta
 
 ### 2. Create a PRISM Agent managed DID using DID registrar endpoint
 
-The DID controller can create a new DID by sending a [DID document](docs/concepts/glossary#did-document) template to the Agent.
+The DID controller can create a new DID by sending a [DID document](/docs/concepts/glossary#did-document) template to the Agent.
 Since key pairs are generated and managed by PRISM Agent, DID controller only has to specify the key `id` and its purpose (e.g., `authentication`, `assertionMethod`, etc.).
 The current PRISM DID method supports a key with a single purpose, but it is extendible to support a key with multiple purposes in the future.
 

docs/docusaurus/dids/deactivate.md

@@ -1,7 +1,7 @@
 # Deactivate DID
 
 DID deactivation is an important feature that provides greater control for managing digital identity.
-DID deactivation can be helpful if the [DID](docs/concepts/glossary#decentralized-identifier) is compromised or unused.
+DID deactivation can be helpful if the [DID](/docs/concepts/glossary#decentralized-identifier) is compromised or unused.
 This feature is crucial for the security and risk management of identity owners.
 
 Similar to [DID update](./update.md), deactivating a PRISM DID is a process of putting deactivate-operation on the blockchain so that other participants know that the DID is no longer active.
@@ -20,7 +20,7 @@ The PRISM DID method only allows published DID to be deactivated.
 ## Overview
 
 DID deactivation operates similarly to the DID update, where deactivate-operation publishes to the blockchain, and confirmation blocks must be created before participants consider it deactivated.
-Once the DID is deactivated, all content in the [DID document](docs/concepts/glossary#did-document) gets deleted, and no operation will affect the DID afterward.
+Once the DID is deactivated, all content in the [DID document](/docs/concepts/glossary#did-document) gets deleted, and no operation will affect the DID afterward.
 The same concept also holds for PRISM DID deactivation in that the fork can occur if any subsequent operation occurs before the operation is confirmed.
 Please refer to the `SECURE_DEPTH` parameter in [PRISM method - protocol parameters](https://github.com/input-output-hk/prism-did-method-spec/blob/main/w3c-spec/PRISM-method.md#versioning-and-protocol-parameters) for the number of confirmation blocks.
 At the time of writing, this number is 112 blocks.

docs/docusaurus/dids/publish.md

@@ -1,7 +1,7 @@
 # Publish DID
 
 PRISM DID creation involves generating key pairs and additional data (e.g., services) to construct a create-operation.
-The create-operation allows [DID Controller](docs/concepts/glossary#did-controller) to derive two types of [DIDs](docs/concepts/glossary#decentralized-identifiers):
+The create-operation allows [DID Controller](/docs/concepts/glossary#did-controller) to derive two types of [DIDs](/docs/concepts/glossary#decentralized-identifiers):
 
 1. [Long-form DID](https://github.com/input-output-hk/prism-did-method-spec/blob/main/w3c-spec/PRISM-method.md#long-form-dids-unpublished-dids). It has the following format `did:prism:<initial-hash>:<encoded-state>`
 2. Short-form DID. It has the following format `did:prism:<initial-hash>`
@@ -117,7 +117,7 @@ Example response with status `PUBLISHED`
 }
 ```
 
-> **Note:** The `status` here is the internal status of the DID on the PRISM Agent (`PUBLISHED`, `CREATED`, `PUBLICAION_PENDING`). It does not indicate the lifecycle of the DID observed on the blockchain (e.g., deactivated, etc.). The [DID resolution](docs/concepts/glossary#did-resolution) metadata is for that purpose.
+> **Note:** The `status` here is the internal status of the DID on the PRISM Agent (`PUBLISHED`, `CREATED`, `PUBLICAION_PENDING`). It does not indicate the lifecycle of the DID observed on the blockchain (e.g., deactivated, etc.). The [DID resolution](/docs/concepts/glossary#did-resolution) metadata is for that purpose.
 
 ### 4. Resolve a short-form DID
 

docs/docusaurus/dids/update.md

@@ -1,11 +1,11 @@
 # Update DID
 
-PRISM DID method allows [DID Controller](docs/concepts/glossary#did-controller) to update the content of the [DID document(docs/concepts/glossary#did-document) by constructing a DID update-operation.
+PRISM DID method allows [DID Controller](/docs/concepts/glossary#did-controller) to update the content of the [DID document(/docs/concepts/glossary#did-document) by constructing a DID update-operation.
 The update-operation describes the update action on the DID document.
 For example, DID Controller can add a new key to the DID document by constructing an update-operation containing the `AddKeyAction`.
 It is also possible for DID Controller to compose multiple actions in the same update-operation.
 The [PRISM DID method - Update DID section](https://github.com/input-output-hk/prism-did-method-spec/blob/main/w3c-spec/PRISM-method.md#update-did) includes a complete list of supported update actions.
-The PRISM DID method only allows published [DID](docs/concepts/glossary#decentralized-identifier) to be updated.
+The PRISM DID method only allows published [DID](/docs/concepts/glossary#decentralized-identifier) to be updated.
 
 Each DID update-operation is cryptographically linked, creating a lineage of DID operations.
 The lineage is not allowed to contain forks.

docs/docusaurus/index.md

@@ -3,9 +3,9 @@
 Welcome to the Atala PRISM Tutorials!
 
 These tutorials will help you get started with using Atala PRISM.
-The tutorials will guide you through setting up a connection, working with [Decentralized Identifiers (DIDs)](docs/concepts/glossary#decentralized-identifer), and using [verifiable credentials](docs/concepts/glossary#verifiable-credentials).
+The tutorials will guide you through setting up a connection, working with [Decentralized Identifiers (DIDs)](/docs/concepts/glossary#decentralized-identifer), and using [verifiable credentials](/docs/concepts/glossary#verifiable-credentials).
 
-Whether you are new to [self-sovereign identity (SSI)](docs/concepts/glossary#self-sovereign-identity) or have prior experience, these tutorials will provide the necessary information and skills to build and use SSI-based applications.
+Whether you are new to [self-sovereign identity (SSI)](/docs/concepts/glossary#self-sovereign-identity) or have prior experience, these tutorials will provide the necessary information and skills to build and use SSI-based applications.
 
 
 Throughout all code examples in tutorials, the following conventions are in use:

docs/docusaurus/schemas/create.md

@@ -1,6 +1,6 @@
 # Create the credential schema
 
-The PRISM platform v2.0 exposes REST API for creation, fetching, and searching the [credential schema](docs/concepts/glossary#credential-schema) records.
+The PRISM platform v2.0 exposes REST API for creation, fetching, and searching the [credential schema](/docs/concepts/glossary#credential-schema) records.
 
 The OpenAPI specification and ReDoc documentation describe the endpoint.
 
@@ -12,7 +12,7 @@ The following guide demonstrates how to create a driving license credential sche
 
 ### 1. Define the JSON Schema for the Verifiable Credential
 
-Assume that you need a credential schema for the driving license, and the [verifiable credential](docs/concepts/glossary#verifiable-credential) must have the following
+Assume that you need a credential schema for the driving license, and the [verifiable credential](/docs/concepts/glossary#verifiable-credential) must have the following
 fields:
 
 - emailAddress - the email address of the driver
@@ -340,7 +340,7 @@ The response should contain the JSON object representing the schema you just cre
 ```
 
 The PRISM Agent instance's triple `author`, `id`, and `version` are unique.
-So, having a single [DID](docs/concepts/glossary#decentralized-identifier) reference that the author uses, creating the credential schema with the same `id` and `version`
+So, having a single [DID](/docs/concepts/glossary#decentralized-identifier) reference that the author uses, creating the credential schema with the same `id` and `version`
 is impossible.
 
 ### 4. Update the credential schema