diff --git a/README.md b/README.md
index 0d95f9df000052a8120ae23345a5d473076c47e3..cdd0bb694ebf13666e4f6ff1ade7031e699fd868 100644
--- a/README.md
+++ b/README.md
@@ -19,9 +19,11 @@ among sections and is self-explanatory (compare with the sidebar appearing [here
(that is, tagged with `##`) will appear at the right part of the page
(see for example [here](https://essif-lab.pages.grnet.gr/essif-lab/docs/infrastructure)).
-Images must be put inside `static` and referred to with their _absolute_ urls.
-Example: 
-(note that the `static` directory is missing, as this links to the DEPLOYED environment.)
+Images must be put inside the directory `static/images` and developers must refer to them using _relative_ urls.
+Example: 
+Docusaurus knows that the `../images` directory is inside the `static` directory, and thus process correctly.
+The deployment pipe will convert `../images/` in such links to their _*absolute*_ urls.
+Of course, if you want to link to images on the web, you can still use absolute urls.
### Installation
diff --git a/docs/essif-lab-functional-architecture.md b/docs/essif-lab-functional-architecture.md
index 27cc47183a7978e3eed149f823f6de21162aea46..91e9be2d2d9ed27b65cc5cbd961f04cb164271b2 100644
--- a/docs/essif-lab-functional-architecture.md
+++ b/docs/essif-lab-functional-architecture.md
@@ -30,7 +30,7 @@ However, the participants of a business transaction are different parties, which
Every agent that communicates with another actor for the purpose of progressing a transaction, will need to be sufficiently sure (to the extent necessary for the value of the transaction) that the actor that it is communicating with, is in fact an agent of the peer party of its owner. We will use the term ‘**peer agent (of a specific agent, in the context of a single transaction)**’ to refer to an actor with which the specific agent has a communications session, and for which it has obtained sufficient assurance that it is an agent of the peer party of its owner. Note that establishing whether or not an actor is a peer agent does not necessarily require knowing who the peer party actually is.
-
+
*Figure 1. eSSIF-Lab Single Party Functional Architecture Overview.*
@@ -102,7 +102,7 @@ The **SSI Tech APIs** interface layer is the union of the interfaces that the co
This section details the functional specifications of the components that are in scope of the eSSIF-Lab infrastructure, i.e. in the green (rounded) rectangle as shown in the figure below:
-
+
*Figure 2: eSSIF-Lab infrastructural (functional) components.*
@@ -304,7 +304,7 @@ This chapter explains at a high level how electronic business transactions are b
### 5.1. Overview
-
The adjacent figure shows how a transaction is conducted at the highest abstraction level. One party, called the ‘Requester’, sends a request for a product or service to another party (that we will call the ‘Provider’). Then, they start to negotiate a ‘transaction agreement’, which means that they exchange data through various channels for the purpose of establishing the details of the product/service to be provided and the compensation, data needed to mitigate transaction risks, etc., all of which is necessary for the parties to (individually/subjectively) decide whether or not to commit to the transaction. Section 3.2 provides more detail about this phase.
+
The adjacent figure shows how a transaction is conducted at the highest abstraction level. One party, called the ‘Requester’, sends a request for a product or service to another party (that we will call the ‘Provider’). Then, they start to negotiate a ‘transaction agreement’, which means that they exchange data through various channels for the purpose of establishing the details of the product/service to be provided and the compensation, data needed to mitigate transaction risks, etc., all of which is necessary for the parties to (individually/subjectively) decide whether or not to commit to the transaction. Section 3.2 provides more detail about this phase.
After commitment, the producer works to provide the product or service, and the requester arranges the compensation. This phase is entirely up to the business, and hence out of scope of this document.
@@ -318,7 +318,7 @@ Please note that while transactions are symmetrical in nature (i.e. both request
This phase starts by the requester sending a transaction request to the provider, and ends whenever either one of the parties quits, or both parties commit.
-
The adjacent figure shows the high-level interactions during this phase. It starts by the requester sending a request for a product or service to the provider. Typically, this would lead to the provider presenting a (web) form the requester must fill in. In the eSSIF-Lab context, the form will also provide a means for setting up a SSI communications channel, i.e. a secure communications channel through which provider and requester can both request and obtain (presentations of) credentials, the contents of which they can use to fill in the form. Then, after the form is ‘clean’, i.e. contains sufficient information for deciding whether or not to commit to the transaction, this phase ends.
+
The adjacent figure shows the high-level interactions during this phase. It starts by the requester sending a request for a product or service to the provider. Typically, this would lead to the provider presenting a (web) form the requester must fill in. In the eSSIF-Lab context, the form will also provide a means for setting up a SSI communications channel, i.e. a secure communications channel through which provider and requester can both request and obtain (presentations of) credentials, the contents of which they can use to fill in the form. Then, after the form is ‘clean’, i.e. contains sufficient information for deciding whether or not to commit to the transaction, this phase ends.
Note that forms may contain fields that are required only in specific circumstances. It may only be possible to assess whether or not such circumstances apply after some (other) fields have been filled in. This means that the phase for requesting credential presentations and responding to such requests may very well consist of multiple requests and associated responses.
@@ -365,7 +365,7 @@ It is a task of the TVE to orchestrate the inputs: different parts of the form m
Because of this orchestration, the interface to the verifier component can be quite simple; it is shown in the image below:
-
+
The request identifier is included in messages between the TVE and verifier so as to allow them to handle different transactions at the same time.
@@ -375,5 +375,5 @@ We assume that the provider has specified the form and the associated validation
[text still needs to be written\]
-
+
diff --git a/docs/essif-lab-vision-and-purpose.md b/docs/essif-lab-vision-and-purpose.md
index 7a56890a9a9caad151022f441e1582fa495cdc18..566d61f90cdc00eada1c233abafeeddfde52a94f 100644
--- a/docs/essif-lab-vision-and-purpose.md
+++ b/docs/essif-lab-vision-and-purpose.md
@@ -27,11 +27,11 @@ In order for this to work, the provider must design the form such that when a re
Perhaps the most important contribution that the eSSIF-Lab project aims to make, is to create a ubiquitously used infrastructure for designing, filling in, and validating forms (not just web-forms, but also for ‘forms’ - e.g. JSON objects - in API requests). The benefits this will bring are enormous, but outside the scope of this document to list.
-
+
The figure below is a high-level visualization of the filling in and validation parts:
-
+
*Figure 1. High-level visualization of the filling in and validation of a form.*