in-source architecture images

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.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.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:
 
-<img src="https://git.fediversity.eu/Fediversity/meta/raw/branch/main/architecture-docs/panel-data-model.svg" alt="" style="max-width:600px;"/>
+<img src="./panel-data-model.svg" alt="" style="max-width:600px;"/>
 
 ### Host architecture