diff --git a/architecture-docs/architecture.md b/architecture-docs/architecture.md index b9f541f..5df9854 100644 --- a/architecture-docs/architecture.md +++ b/architecture-docs/architecture.md @@ -130,7 +130,9 @@ The used legend is as follows: For further info on components see the [glossary](#glossary). -![](https://git.fediversity.eu/Fediversity/meta/raw/branch/main/architecture-docs/interactions-migration.svg) + +![](./interactions-migration.png) + ### Configuration data flow This data flow diagram refines how a deployment is obtained from an operator's application configuration and a hosting provider's runtime setup. @@ -141,7 +143,8 @@ For its runtime setup, a hosting provider has to supply a **resource mapping** t Applications and runtime environments thus interface through **resources**, the properties of which are curated by Fediversity maintainers. -![](https://git.fediversity.eu/Fediversity/meta/raw/branch/main/architecture-docs/interactions-fediversity.svg) + +![](./interactions-fediversity.png) ### Service portability @@ -159,7 +162,7 @@ The process of migrating one's applications to a different host encompasses: Whereas the bulk of our configuration logic is covered in the configuration schema, [implemented here](https://git.fediversity.eu/Fediversity/Fediversity/src/branch/main/deployment/data-model.nix) and [tested here](https://git.fediversity.eu/Fediversity/Fediversity/src/branch/main/deployment/data-model-test.nix), our reference front-end applications will store data. The data model design for the configuration front-end needed support the desired functionality is as follows, using the crow's foot notation to denote cardinality: - + ### Host architecture