Correct doc to docs for assets. Doh!

swcurran · swcurran · commit ce91d85d9bc4 · 2021-02-19T11:40:06.000-08:00
Signed-off-by: Stephen Curran &lt;swcurran@gmail.com&gt;
diff --git a/AdminAPI.md b/AdminAPI.md
@@ -6,7 +6,7 @@ ACA-Py provides an OpenAPI-documented REST interface for administering the agent
 
 To see the specifics of the supported endpoints as well as the expected request and response formats it is recommended to run the `aca-py` agent with the `--admin {HOST} {PORT}` and `--admin-insecure-mode` command line parameters, which exposes the OpenAPI UI on the provided port for interaction via a web browser. Production deployments should run the agent with `--admin-api-key {KEY}` and add the `X-API-Key: {KEY}` header to all requests instead of running the agent with the `--admin-insecure-mode` parameter.
 
-![Admin API Screenshot](/doc/assets/adminApi.png)
+![Admin API Screenshot](/docs/assets/adminApi.png)
 
 To invoke a specific method:
 
diff --git a/Mediation.md b/Mediation.md
@@ -67,7 +67,7 @@ See [Aries RFC 0211: Coordinate Mediation Protocol](https://github.com/hyperledg
 
 ## Mediator Message Flow Overview
 
-![Mediator Message Flow](/doc/assets/mediation-message-flow.png)
+![Mediator Message Flow](/docs/assets/mediation-message-flow.png)
 
 ## Using a Mediator
 
diff --git a/Multitenancy.md b/Multitenancy.md
@@ -37,7 +37,7 @@ The wallets used by the different tenants are called **sub wallets**. A sub wall
 
 The **base wallet** however, takes on a different role and has limited functionality. Its main function is to manage the sub wallets, which can be done using the [Multi-tenant Admin API](#multi-tenant-admin-api). It stores all settings and information about the different sub wallets and will route incoming messages to the corresponding sub wallets. See [Message Routing](#message-routing) for more details. All other features are disabled for the base wallet. This means it cannot issue credentials, present proof, or do any of the other actions sub wallets can do. This is to keep a clear hierarchical difference between base and sub wallets
 
-![Multi-tenancy Architecture](/doc/assets/multitenancyDiagram.png)
+![Multi-tenancy Architecture](/docs/assets/multitenancyDiagram.png)
 
 ### Usage
 
@@ -223,4 +223,4 @@ For deterministic JWT creation and verification between restarts and multiple in
 
 When using the SwaggerUI you can click the :lock: icon next to each of the endpoints or the `Authorize` button at the top to set the correct authentication headers. Make sure to also include the `Bearer ` part in the input field. This won't be automatically added.
 
-![](/assets/adminApiAuthentication.png)
+![](/docs/assets/adminApiAuthentication.png)
diff --git a/deploymentModel.md b/deploymentModel.md
@@ -7,7 +7,7 @@
 
 This document is a "concept of operations" for an instance of an Aries cloud agent deployed from the primary artifact (a PyPi package) produced by this repo. In such a deployment there are **always** two components - a configured agent itself, and a controller that injects into that agent the business rules for the particular agent instance (see diagram).
 
-![ACA-Py Deployment Overview](/doc/assets/deploymentModel-full.png "ACA-Py Deployment Overview")
+![ACA-Py Deployment Overview](/docs/assets/deploymentModel-full.png "ACA-Py Deployment Overview")
 
 The deployed agent messages with other agents via DIDComm protocols, and as events associated with those messages occur, sends webhook HTTP notifications to the controller. The agent also exposes for the controller's exclusive use an HTTP API covering all of the administrative handlers for those events. The controller receives the notifications from the agent, decides (with business rules - possible by asking a person using a UI) how to respond to the event and calls back to the agent via the HTTP API. Of course, the controller may also initiate events (e.g. messaging another agent) by calling that same API.
 
@@ -23,7 +23,7 @@ The sections below detail the internals of the ACA-Py and it's configurable elem
 
 **Aries cloud agent** implement services to manage the execution of DIDComm messaging protocols for interacting with other DIDComm agents, and exposes an administrative HTTP API that supports a controller to direct how the agent should respond to messaging events. The agent relies on the controller to provide the business rules for handling the messaging events, and to initiate the execution of new DIDComm protocol instances. The internals of an ACA-Py instance is diagramed below.
 
-![ACA-Py Agent Internals](/doc/assets/deploymentModel-agent.png "ACA-Py Agent Internals")
+![ACA-Py Agent Internals](/docs/assets/deploymentModel-agent.png "ACA-Py Agent Internals")
 
 Instances of the Aries cloud agents are configured with the following sub-components:
 
@@ -41,7 +41,7 @@ Instances of the Aries cloud agents are configured with the following sub-compon
 
 A controller provides the personality of Aries cloud agent instance - the business logic (human, machine or rules driven) that drive the behaviour of the agent. The controller’s “Business Logic” in a cloud agent could be built into the controller app, could be an integration back to an enterprise system, or even a user interface for an individual. In all cases, the business logic provide responses to agent events or initiates agent actions. A deployed controller talks to a single Aries cloud agent deployment and manages the configuration of that agent. Both can be configured and deployed to support horizontal scaling.
 
-![Controller Internals](/doc/assets/deploymentModel-controller.png "Controller Internals")
+![Controller Internals](/docs/assets/deploymentModel-controller.png "Controller Internals")
 
 Generically, a controller is a web app invoked by HTTP webhook calls from its corresponding Aries cloud agent and invoking the DIDComm administration capabilities of the Aries cloud agent by calling the REST API exposed by that cloud agent. As well as responding to Aries cloud agent events, the controller initiates DIDComm protocol instances using the same REST API.
 
diff --git a/docs/GettingStartedAriesDev/AriesAgentArchitecture.md b/docs/GettingStartedAriesDev/AriesAgentArchitecture.md
@@ -2,7 +2,7 @@
 
 This section talks in particular about the architecture of this Aries cloud agent implementation. An instance of an Aries agent is actually made up of to two parts - the agent itself and a controller. 
 
-![ACA-Py Deployment Overview](/doc/assets/deploymentModel-full.png "ACA-Py Deployment Overview")
+![ACA-Py Deployment Overview](/docs/assets/deploymentModel-full.png "ACA-Py Deployment Overview")
 
 The agent handles all of the core Aries functionality such as interacting with other agents, managing secure storage, sending event notifications to, and receiving directions from, the controller. The controller provides the business logic that defines how that particular agent instance behaves--how to respond to events in the agent, and when to trigger the agent to initiate events. The controller might be a web or native user interface for a person or it might be coded business rules driven by an enterprise system.
 
