Delete Fediverse-investments-an-estimation.md

remove old version, new ones exist in https://git.fediversity.eu/Fediversity/meta/src/branch/main/investment_analysis

Fediverse-investments-an-estimation.md

@@ -1,88 +0,0 @@
-Outline 
-> Release a report on the estimated collective current investment on fediverse technology: 
->
-> Look at qualifiers like:
->- Used system resources (CPU, storage, networking)
->- Amount of software developers actively working on Fediverse software >products
->- Amount of system administration engineers actively working on Fediverse software products
->- Amount of moderation and governance people
-
-* * *
-
-# An estimate of investments in the Fediverse 
-
-## Introduction
-To provide an estimate of the investments made into the Fediverse, is a very daunting task due to decentralised nature of the Fediverse, the amount of volunteers contributing freely and - in our experience - a lack of research on this topic thus far. Nonetheless, we have taken upon ourselves the task to provide a first glimpse on this subject. 
-
-[TODO: describe 'the why' better] 
-
-We hope our work will contribute and ignite more serious research into this topic.  
-
-In this document we describe our assessment of the investments made in the Fediverse. We start with how we define the Fediverse, describe our methodology for gathering data on the defined Fediverse and share information on the services, platforms and software applications we have deemed relevant to include. 
-
-[TODO: need to add more info here ]
-   
-
-* * * 
-
-
-
-
-
-
-
-## Define the Fediverse
-We need to define what the Fediverse is. 
-
-Wikipedia defines Fediverse as "a collection of social networking services that can communicate with each other (formally known as federation) using a common protocol. Users of different websites can send and receive status updates, multimedia files and other data across the network. The term Fediverse is a portmanteau of "federation" and "universe". (Wikipedia contributors, 2024)[^1]". 
-
-Erin Kissane & Darius Kazemi in 'Findings Report: Governance on Fediverse Microblogging Servers' define the Fediverse as "a decentralized interoperable network of social media sites, apps, and services built on the ActivityPub protocol.[^2]". 
-
-[ TODO: add the other definitions ]
-
-
-It seems there has not yet formed consensus on what exactly are the attributes which could define a platform, service or software application part of the Fediverse.
-
-  
-
-## Methodology
-* Numbers used & why these numbers and not other numbers
-* Services / platforms investigated
-* Why these services & platforms? 
-* Software applications  
-* Topic opened: https://socialhub.activitypub.rocks/t/any-info-on-the-estimated-collective-investments-time-money-on-fediverse-tech/4844?u=bjornw  
-
-## A closer look at the Fediverse platforms  
-* Name of service/platform 
-* Description of service/platform 
-* estimated nr of installations 
-* estimated nr of users (Monthly Active Users)
-* estimated nr of developers working on the service 
-* estimated nr of moderators
-* estimated costs for the service 
-
-## Estimating investments in the Fediverse 
-* Conclusion  
-
-
-## Notes
-[^1]: Wikipedia contributors. (2024, December 29). Fediverse. Wikipedia. https://en.wikipedia.org/wiki/Fediverse
-[^2]: Kissane, E., & Kazemi, D. (2024, September 4). Findings Report: Governance on Fediverse Microblogging Servers. https://fediverse-governance.github.io/#brief-glossary
- 
- 
-## References 
-* https://en.wikipedia.org/wiki/Fediverse
-* https://fedidb.org/
-* https://mastodon-analytics.com/ 
-* https://www.thinkimpact.com/mastodon-statistics/
-* https://fediverse.observer/
-* https://the-federation.info/
-* https://fediverse.party
-* https://socialhub.activitypub.rocks/t/fep-f1d5-nodeinfo-in-fediverse-software/1190 
-* https://codeberg.org/fediverse
-
-https://hachyderm.io/@esk/113793277371908181
-
-	 		
-
- 

architecture-docs/.gitignore

@@ -0,0 +1,3 @@
+*.err
+*.odt
+.~lock*

architecture-docs/2025-05-architecture-replaced-by-mermaid.dot

@@ -1,4 +1,4 @@
-// usage: nix-shell -p graphviz --command dot -T png -o architecture.png architecture.dot
+// usage: nix-shell -p graphviz --command 'dot -T png -o architecture.png architecture.dot'
 
 digraph FediversityArchitecture {
   graph[fontname="Liberation Sans"];
@@ -7,11 +7,13 @@ digraph FediversityArchitecture {
   subgraph cluster_frontends {
     label="front-ends";
 
+    nix[label="NixOS module"];
     tofu[label="OpenTofu CLI"];
     panel[label="FediPanel"];
     protagio[label="NixPanel"];
   }
 
+  nix -> core;
   tofu -> core;
   panel -> core;
   protagio -> core;

architecture-docs/architecture.md

@@ -0,0 +1,176 @@
+# Fediversity Implementation and planning
+
+## Actors
+
+- Maintainers
+
+  The group developing and maintaining this project.
+  We are creating the deployment workflows and service configurations, and curate changes proposed by contributors.
+
+- Developers
+
+  People with the technical background to engage with our work, and may contribute back, build on top of, remix, or feel inspired by our work to create something better.
+
+- Hosting provider
+
+  They provide and maintain the physical infrastructure, and run the software in this repository, through which operators interact with their deployments.
+  Hosting providers are technical administrators for these deployments, ensuring availability and appropriate performance.
+
+  We target small- to medium-scale hosting providers with 20+ physical machines.
+
+- Operator
+
+  They select the applications they want to run.
+  They don't need to own hardware or deal with operations.
+  Operators administer their applications in a non-technical fashion, e.g. as moderators.
+  They pay the hosting provider for registering a domain name, maintaining physical resources, and monitoring deployments.
+
+- User
+
+  They are individuals using applications run by the operators, and e.g. post content.
+
+## Glossary
+
+- [Fediverse](https://en.wikipedia.org/wiki/Fediverse)
+
+  A collection of social networking applications that can communicate with each other using a common protocol.
+
+- Application
+
+  User-facing software (e.g. from Fediverse) configured by operators and used by users.
+
+- Configuration
+
+  A collection of settings for a piece of software.
+
+  > Example: Configurations are deployed to VMs.
+
+- Provision
+
+  Make a resource, such as a virtual machine, available for use.
+
+- Deploy
+
+  Put software onto computers.
+  The software includes technical configuration that links software components.
+
+- Migrate
+
+  Move service configurations and deployments (including user data) from one hosting provider to another.
+
+- Run-time backend
+
+  A type of digital environment one can run operating systems such as NixOS on, e.g. bare-metal, a hypervisor, or a container run-time.
+
+- Provider
+
+  An interface against which we deploy to a run-time backend.
+
+- Provider configuration
+
+  A configuration that specifies resources made available to deploy to and how to access these.
+
+- Resource
+
+  A resource is any external entity that we need for our set-up
+  This may include e.g. hypervisors, file systems, DNS entries, VMs or object storage instances.
+
+## Technologies used
+
+This is an incomplete and evolving list of core components planned to be used in this project.
+It will grow to support more advanced use cases as the framework matures.
+
+### Nix and [NixOS](https://nixos.org/)
+
+NixOS is a Linux distribution with a [vibrant](https://repology.org/repositories/graphs), [reproducible](https://reproducible.nixos.org/) and [security-conscious](https://tracker.security.nixos.org/) ecosystem.
+As such, we see NixOS as the only viable way to reliably create a reproducible outcome for all the work we create.
+
+Considered alternatives include:
+
+- containers: do not by themselves offer the needed reproducibility
+
+### [Proxmox](https://proxmox.com/)
+
+Proxmox is a hypervisor, allowing us to create VMs for our applications while adhering to our goal of preventing lock-in.
+In addition, it has been [packaged for Nix](https://github.com/SaumonNet/proxmox-nixos) as well, simplifying our requirements to users setting up our software.
+
+Considered alternatives include:
+
+- OpenNebula: seemed less mature
+
+### [Garage](https://garagehq.deuxfleurs.fr/)
+
+Garage is a distributed object storage service.
+For compatibility with existing clients, it reuses the protocol of Amazon S3.
+
+Considered alternatives include:
+
+- file storage: less centralized for backups
+
+## Architecture
+
+At the core of Fediversity lies a NixOS configuration module for a set of selected applications.
+
+- We will enable using it with **different run-time environments**, such as a single NixOS machine or a ProxmoX hypervisor.
+- Depending on the targeted run-time environment, deployment may involve [NixOps4](https://nixops.dev) or [OpenTofu](https://opentofu.org/) as an **orchestrator**.
+- We further provide demo front-end for **configuring applications** and configuring **run-time backends**.
+
+To ensure reproducibility, all software will be packaged with Nix.
+
+To reach our goals, we aim to implement the following interactions.
+
+The used legend is as follows:
+
+- Circle: [actor](#actors)
+- Angled box: type
+- Rectangle: value
+- Rounded box: function
+- Diamond: state
+- Arrow: points towards dependant
+
+For further info on components see the [glossary](#glossary).
+
+<!-- ![](./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.
+
+An **application module** specifies operator-facing **application options**, and a **configuration mapping** which determines the application's underlying implementation. Application modules can be supplied by external developers, which would curate application modules against that interface.
+
+For its runtime setup, a hosting provider has to supply a **resource mapping** that would take their self-declared **provider configuration** (which determines the *available* resources) and the output of an application's resource mapping (which determine resource *requirements*) and produce a **configuration**. This configuration ships with a mechanism to be *deployed* to the infrastructure (which is described by the environment, and features the required resources), where it will accumulate **application state**.
+
+Applications and runtime environments thus interface through **resources**, the properties of which are curated by Fediversity maintainers.
+
+<!-- ![](./interactions-fediversity.svg) -->
+![](./interactions-fediversity.png)
+
+
+### Service portability
+
+The process of migrating one's applications to a different host encompasses:
+
+1. Domain registration: involves a (manual) update of DNS records at the registrar
+1. Deploy applications: using the reproducible configuration module
+1. Copy application data:
+    - Run back-up/restore scripts
+    - Run application-specific migration scripts, to e.g. reconfigure connections/URLs
+
+### Data model
+
+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="./panel-data-model.svg" alt="" style="max-width:600px;"/>
+
+### Host architecture
+
+Whereas the core abstraction in Fediversity is a NixOS configuration module, a more full-fledged example architecture of the web host use-case we aim to support as part of our exploitation would be as follows, where virtual machines in question run Fediversity to offer our selected applications:
+
+![](https://git.fediversity.eu/Fediversity/meta/raw/branch/main/architecture-docs/host-architecture.png)
+
+### CI / CD
+
+In our simplest set-up, continuous integration and continuous deployment pipelines are handled using Forgejo's [built-in runner](https://code.forgejo.org/forgejo/runner), with relevant secrets handled using [Forgejo secrets](https://forgejo.org/docs/latest/developer/secrets/). Jobs we handle using CI include linting, formatting, testing, and a periodic life-cycle management job to keep our dependencies up-to-date.
+In a future iteration, we may make use of [Gerrit](https://gerrit.googlesource.com/) to better manage our review process for incoming merge requests.

architecture-docs/configuration-to-deployment-dataflow.md

@@ -0,0 +1,74 @@
+# 2025-06-24 Fediversity configuration data flow
+
+This data flow diagram refines the [global architecture diagram](./interactions-migration.mmd) with respect to how a deployment is obtained from an operator's application configuration and a hosting provider's runtime setup.
+
+## Legend
+
+- Circle: actor
+- Angled box: type
+- Rectangle: value
+- Rounded box: function
+- Diamond: state
+- Arrow: points towards dependant
+
+## Description
+
+An **application module** specifies operator-facing **application options**, and a **resource mapping** which determines the application's underlying implementation in terms of which resources it requires to be deployed. Application modules can be supplied by external **contributors**, which would package applications against that interface.
+
+For its **runtime environment**, a **hosting provider** has to supply a **policy mapping** that would take their self-declared **resource configuration** (which determines *available* resources, i.e. a description of the infrastructure on which to run the applications) and the output of an application's resource mapping (which determines resource *requirements*) and produce the description of a **deployment**.
+
+An **operator** can supply an **application configuration** and request the hosting provider to let the resulting deployment take effect, such that it will accumulate **application state**, which can later be migrated to other hosting providers.
+
+Applications and runtime environments thus interface through **resources**, the properties of which are curated by Fediversity **maintainers**.
+
+
+```mermaid
+flowchart
+
+subgraph configuration
+  application-config
+end
+subgraph resource[resource module]
+  resource-options
+  provider-options
+end
+subgraph application[application module]
+  application-options{{application-options}} --> application-config
+  application-config --> config-mapping
+  resource-options{{consumer-options}} --> config-mapping
+  config-mapping(resource-mapping)
+end
+subgraph fediversity[runtime-environment]
+  config-mapping -->|required resources| resource-mapping(policy-mapping)
+
+  provider-options{{resource-options}} --> resource-config --> |available resources| resource-mapping -->|configured resources| deployment[deployment]
+  deployment --> |deploy| state{application state}
+
+end
+
+maintainer((maintainer)) -->|curates| resource
+
+
+contributor((contributor)) -->|packages| application
+operator((operator)) -->|enters| configuration
+
+
+hosting-provider((hosting provider)) -->|maintains| fediversity
+
+```
+
+## Discussion
+
+Decoupling of operator-facing application configuration and resource use allows for portability at the infrastructure level: hosting providers determine how applications are deployed to available resources through policies which are agnostic to applications. Additionally it allows hosting providers to isolate applications from each other depending on their deployment model, leveraging the entire toolkit provided by the Nix ecosystem. This puts single-machine and cluster deployments on equal footing, since policies are simply Nix language functions.
+
+At first glance this is an increase in complexity as opposed to configuring NixOS directly, since it adds a layer of indirection. It also requries Fediversity maintainers to declare resource types for use by application packagers and hosting providers. But the layering drastically simplifies application composition over what NixOS can currently offer, frees the hosting provider to choose how to implement required services, and enables security-conscious deployments at very fine granularity.
+
+## Next steps
+
+- Versioning: Each of the components can change; model all supported interactions such that deployments will always be correct.
+
+  Primarily, both applications and runtime environments depend on the resource API, and need to be versioned against it. Application packages can be updated on top of that, and will need to provide facilities to migrate between both application versions and resource API versions, both in terms of configurations and application state.
+  
+- Provider migrations: Prototype an application-agnostic migration workflow.
+
+  Since state migration is application-specific, application packages will need to ship with instructions for how to move their data between hosting providers, also taking version migrations into account. This will likely require extending the resource API with ways to express where state is located, and give hosting providers the tools to expose interfaces though which migrations will take place.

architecture-docs/data-model-requirements.md

@@ -1,126 +1,26 @@
 # migration data model requirements
 
-To transfer between two providers, the target provider must be able to import the sending provider's versions. (e.g.: a deployment may have latest fediversity, latest pixelfed, but previous mastadon) Thus, for each "realease" of the data model, it needs to be versioned, and applications/APIs also are versioned.
- * (May need a way to show on the front-end which versions are in place, and which migrations are supported. However, for application versions which are completely controlled by the installation and setup, this is "solved".)
+Given:
 
-for release version 0, focus on known current needs
- * to be expanded later as each new application is added and can be transferred between providers
- * review migration guides for the known apps with an eye to odd/unusual details that influence design choices (task for Niols? others?)
+- no change in control of domains;
+- two Fediversity set-ups (to be provided by ProcoliX) with a run-time environment such as ProxmoX, for an initial test using the same version;
+- a Fediversity configuration of at least a single application (to start)
 
-Specifically, this suggests scoping to migrating:
+Our data model must describe a migration:
 
-- managed infrastructure (rather than managed applications)
-- between servers owned by procolix
-- same proxmox version
-- NixOS VMs set up by us so we can guarantee identical application versions
-- hosting limited to a single application (to start)
+- specifying [entity relations](https://mermaid.js.org/syntax/entityRelationshipDiagram.html#relationship-syntax) e.g. many-to-many;
+- migrating both deployed and staged configurations;
+- deploying of applications using the same versions;
+- retaining relevant application state;
+- handling of application-specific migration logic, such as to rewrite URLs as needed;
 
-First, a bit of an inventory (list without much structure now, later will create structured form/schema with e.g. many-to-many links, useful for the migration code):
- * clearly mark items that will not be in the first migration as eventually or speculative
- * or reamove them if they would be too far in the future
- * later we understand what is useful for migration code, we can extract and transform in to a format suitable as data model documentation
+Tests:
 
-Hosting Provider provides:
-* proxmox, git
-* hardware
-* filesystem storage
-* DNS automation hooks?
-* central/shared garage storage or only hardware+diskspace for the garage VMs to create storage?
-  * with central: more efficient but less isolated
-
-FooUniversity (Operator)
-* invoice info
-  * is all info expected to be transferred from provider A to provider B?
-    * May not want to transfer e.g. bank details, because they are already set up at B
-    * May also depend on regulation (which information are you allowed to hand out?)
-* Admins:
-  * credentials
-* persistent identifiers
-  * mappings between them (also need to travel across providers)
-    * e.g. if we can't change content URLs, we may need to create (and from then on carry around) a redirects mapping
-    * those mappings are likely application-specific, but they all belong to the same type class
-* domain(s)
-    * what is needed for DNS management?
-    * users
-      * display name
-      * email(s)
-      * login id
-        * oauth2 (eventually)
-        * 2fa
-        * password
-        * passkeys (eventually)
-        * LDAP? (eventually?)
-    * all applications
-      * sub domain ( social.example.org vs example.org/social )
-      * info for proxmox setup such as to provision VMs (to reproduce proxmox )
-        * mem
-        * cpus
-        * storage mounts
-        * IPs likely not the same in the target network
-      * storage
-        * filesystem
-           * very well specified per application
-        * blob storage config (garage, s3-like)
-           * index
-           * Can we make it a requirement that Garage is behind a predictable URL, eg. `<application>.garage.<customer domain>`? As opposed to something vendor-specific, eg. `pixelfed-university.garage.procolix.com/<customer domain>/<application>`
-           * may need to rewrite URLs to blobs automatically, depending on the underlying URL scheme, which may be per setup or application
-        * limits? per application? per user? where are these used/set/enforced?
-        * TODO: what does e.g. borgmatic need to back up storage?
-        * out of scope?: focus on actual state, disregarding reconstructable stuff
-      * SQL database
-        * dump/snapshot
-        * TODO: what does e.g. borgmatic need to back up databases?
-* application specifics
-  * postfix? (is email in version 0?)
-  * pixelfed
-    * where is blob storage
-      * in the specific case of Pixelfed, if blob storage changed URL, we might need to rewrite the pictures URLs in the database (try to avoid this)
-    * redis (in the case of pixelfed, it is not just a cache)
-      * misc config: theme, name of instance, email of sysadmin
-    * database
-    * on-disk files
-      * Daniel Supernault is currently making it so evertying can be stored remotely in a garage or sql database
-    * users (login id) (in database? in redis?)
-      * user preferences/settings
-  * peertube
-  * mastodon
-  * matrix? (is it in version 0?)
-* logos
-
-Other considerations:
-
-- Put a boundary for what is
-  - operator-configurable
-  - needs to get fixed, but at the implementation level
-  - what can be configured dynamically per environment
-- Most importantly we need to preserve persistent identifiers
-
-- When transforming the data-model code to a deliverable version of the data model as part of the technical architecture document, documenting user-data storage and with respects fot security and GDPR
-
-See also:
-
-- possible overlap/inspiration: Stalw.art [configuration docs](https://stalw.art/docs/server/general)
-
-## MVP scoping ideas
-
-User story 1: New customer
-When a new customer goes to the Fediversity website we want to show that user what Fediversity is all about and what it can give to the customer. This points the customer to a signup form where they can enter all the details that are needed to get it working. Here they can also decide what applications to use (at first no more than three). Details can be, the user/admin login, name, address, bank details, domain, other users, and applications. Than when the customer hits the install/provision/go button everything starts to install automagically. After which the customer is presented with (some) url's to login to.
-
-User story 2: Take out / move to other instance
-At any time a customer may wish to change service providers. They can easily go to an admin screen where they can get their configuration and data packaged for transfer. This packaged data can be provided to a new service provider where they will be up-and-running again easily, with minimal downtime.
-
-proposed MVP scope:
-- block storage
-- blob storage (garage)
-- physical servers
-- proxmox vm management
-- nixops service
-- nixops scripts
-- 1 to 3 applications packaged in Nix (Mastodon, Peertube, Pixelfed)
-- frontend / website
-- working dns, can be external, but automated
-- takeout area
-- import area
-- 2 Fediversity environments to transfer between
-- demonstration of User story 1
-- demonstration of User story 2
+1.
+    A Fediversity user may wish to migrate their Fediversity set-up between monolithic and distributed configurations.
+    In an admin screen they can get their configuration and data for transfer.
+    Using this they may migrate to the desired configuration.
+1.
+    At any time a Fediversity user may wish to migrate their Fediversity set-up.
+    They can go to an admin screen where they can get their configuration and data for transfer.
+    This data can be provided to a new service provider where they will be up-and-running again, with minimal downtime.

architecture-docs/entity-relations.mmd

@@ -0,0 +1,25 @@
+---
+title: Fediversity migration entity relations
+---
+erDiagram
+    setup["Fediversity setup"]
+    env["run-time environment"]
+    deployed["deployed configuration"]
+    staged["staged configuration"]
+    token["deployment token"]
+    script["migration script"]
+
+    setup }o--o{ env : offers
+    setup ||--o{ operator : serves
+    operator ||--o{ domain : owns
+    deployment }|--|| domain : uses
+    operator ||--o{ deployment : has
+    deployment ||--|{ token : generates
+    deployment ||--o| deployed : has
+    deployment ||--|| staged : has
+    deployed |o--|| staged : compares
+    deployed ||--|{ application : describes
+    application ||--o{ version : follows
+    application ||--o{ script : runs
+    deployed }|--o{ version : follows
+    script }o--|| token : uses

architecture-docs/host-architecture.puml

@@ -1,4 +1,5 @@
 @startuml
+skinparam backgroundcolor transparent
 
 package Management {
     object "Nix-Panel" as A {
@@ -12,7 +13,7 @@ package Management {
         Secrets
     }
     object "**Orchestrator**" as Orch {
-        NixOps
+        Terraform
     }
     object "**Identity Management**" as AAA {
         Authentication
@@ -49,12 +50,10 @@ package Virtualization {
         Application C
     }
     map "**Application options**" as App {
-        Edumeet => Matrix
+        Vaultwarden => Matrix
         NextCloud => Pixelfed
         Webmail => Peertube
-        Hedgehoc => Mastodon
-        Project planning => Owncast
-        Office => Castopod
+        Forgejo => Mastodon
     }
 }
 

architecture-docs/interactions-fediversity.mmd

@@ -0,0 +1,30 @@
+flowchart
+
+subgraph configuration
+  application-config
+end
+subgraph resource[resource module]
+  resource-options
+  provider-options
+end
+subgraph application[application module]
+  application-options{{application-options}} --> application-config
+  application-config --> config-mapping
+  resource-options{{resource-options}} --> config-mapping
+  config-mapping(config-mapping)
+end
+subgraph fediversity[fediversity setup]
+  config-mapping -->|required resources| resource-mapping(resource-mapping)
+
+  provider-options{{provider-options}} -->  provider-config --> |available resources| resource-mapping -->|configuration| deployment{deployment}
+
+end
+
+maintainer((maintainer)) -->|curates| resource
+
+
+contributor((developer)) -->|curates| application
+operator((operator)) -->|enters| configuration
+
+
+hosting-provider((hosting provider)) -->|maintains| fediversity

architecture-docs/interactions-migration.mmd

@@ -0,0 +1,47 @@
+flowchart
+
+  user((user)) --> |use| deployment
+
+  configuration1 -->|deploy| deployed1
+  maintainers --> |maintain| fediversity
+
+  fediversity --> |update| provider1
+  subgraph provider1["fediversity setup A"]
+    subgraph configurations1[configurations]
+      configuration1[staged configuration]
+      configuration1 --> |update| configuration1
+      deployed1[deployed configuration]
+    end
+    deployed1 --> |describe| deployment
+    provider-config[runtime config] --> |describe| host
+    provider-config --> |implement runtime interfaces| configurations1
+    subgraph host[runtime environment]
+      deployment[applications]
+      state{state}
+    end
+  end
+
+  deployment --> |store| state
+
+  operator((operator)) --> |change| configuration1
+
+  subgraph provider2["fediversity setup B"]
+     subgraph configurations2[configurations]
+      configuration2[staged configuration]
+      deployed2[deployed configuration]
+    end
+    subgraph host2[runtime environment]
+      deployment2[applications]
+      state2{state}
+    end
+  end
+
+  operator --> |trigger| migration(migration)
+  configurations1 & state --> migration
+  migration --> configurations2 & state2
+  provider((hosting provider)) --> |maintain| provider1
+  subgraph fediversity[fediversity source code]
+    applications[application modules]
+    backends[runtime backends]
+    config{{runtime options}}
+  end

architecture-docs/panel-data-model.mmd

@@ -0,0 +1,24 @@
+---
+title: Data model of sample web application
+---
+erDiagram
+    operator {
+        string username
+        string password_hash
+    }
+    deployment {
+        json deployed_configuration
+        option[string] staged_configuration
+        option[string] version
+    }
+    backup["back-up"] {
+        string bucket
+        string endpoint
+    }
+    keypair {
+        string access_key
+        string secret_key
+    }
+    operator ||--o{ deployment : has
+    deployment ||--o{ backup : has
+    backup ||--|{ keypair : authorises

default.nix

@@ -0,0 +1,14 @@
+{
+  pkgs ? import <nixpkgs> { },
+}:
+{
+  shell = pkgs.mkShellNoCC {
+    packages = with pkgs; [
+      pandoc
+      texliveMedium
+      librsvg
+      mermaid-cli
+      plantuml
+    ];
+  };
+}

investment_analysis/README.md

@@ -0,0 +1,160 @@
+<!--
+> Get insight in the total global investments of the Fediverse (OID)
+> To get an overview of the total investment of capital, human resources and other valuables, we will research the usage of these in the (visible) Fediverse globally. A report of this will be released.
+
+> Release a report on the estimated collective current investment on fediverse technology: 
+> Look at qualifiers like:
+>- Used system resources (CPU, storage, networking)
+>- Amount of software developers actively working on Fediverse software products
+>- Amount of system administration engineers actively working on Fediverse software products
+>- Amount of moderation and governance people
+-->
+
+# An estimate of investments in the Fediverse
+
+## Introduction
+
+To provide an estimate of the investments made into the Fediverse, defined[^1] as a decentralized interoperable network of social media sites, apps, and services built on the ActivityPub protocol, is a daunting task, owing due to:
+
+1. a lack of research (in our experience) on this topic thus far;
+1. the vast number of services part of the Fediverse[^2];
+1. the Fediverse's decentralised nature;
+1. involvement of voluntary contributions;
+1. the third-party nature of some of the integrations.
+
+Nonetheless, we have taken upon ourselves the task to provide a first glimpse on this subject. Given the Fediverse's interoperability empowers users, a better overview on the resources in this technology helps clarify its momentum for key decision-makers interested in adopting, investing in and interfacing with this technology. We further hope our work will contribute and ignite more serious research into this topic.
+
+In this document we describe our assessment of the investments made in the Fediverse. We start with describing our methodology for gathering data on the Fediverse and share information on the services, platforms and software applications we have deemed relevant to include.
+
+## Methodology
+
+In order to better scope our research, we will address the mentioned challenges by:
+
+1. given the lack of research on this topic so far, gathering missing data by contacting representatives of the respective projects;
+1. to account for the vast number of services part of the Fediverse, focusing on the major services[^3] part of the Fediverse, in this case the software with at least 10,000 active monthly users as per Fediverse Observer[^2], in total accounting for over 95% of the active users across Fediverse services, i.e.:
+    * Threads
+    * Mastodon
+    * Pixelfed
+    * NodeBB
+    * Lemmy
+    * Peertube
+    * Loops
+    * Wordpress
+    * WriteFreely
+1. to account for the Fediverse's decentralised nature, extrapolating for each service to their overall number of (visible[^4]) instances from their flagship instances;
+1. to account for the involvement of voluntary contributions, separately citing internal versus overall contributors active on the projects, and extrapolating from the former to estimate the latter;
+1. to account for the third-party nature of some of the integrations, explicitly distinguishing these in our overview.
+
+### NodeInfo
+
+Fediversity instances tend to expose data using the NodeInfo protocol (<https://nodeinfo.diaspora.software/>). Data exposed this way is gathered in <https://fediverse.observer/>, which we use as our source for metrics:
+
+* estimated number of installations
+* estimated number of users
+* estimated number of monthly active users
+
+### Human resources
+
+#### Moderators
+
+<!-- #### Amount of moderation and governance people -->
+On users with moderation privileges ActivityPub unfortunately exposes no structured data yet, although this is an outstanding feature request[^5].
+
+In addition, for some single-tenant platforms such as WriteFreely, moderation does not apply. Platforms that support user sign-ups, such as Mastodon, may similarly disable user sign-up, in which case moderation similarly is not relevant.
+
+<!-- TODO: distinguish active user data by whether instances enable user sign-up -->
+
+#### Developers
+
+<!-- #### Amount of software developers actively working on Fediverse software products -->
+The amount of active developers we estimate as users:
+
+* as identified by unique emails
+* who are not bots, as measured by whether their name contains 'bot',
+* who contributed at least **5** commits to the default Git branch at the main forge/fork
+* over the past year.
+
+We obtain this metric by running a Nushell query[^6] on the project's respective Git repositories.
+
+Based on project estimations on internal engineers involved measured in FTE, we further estimate the total amount of development involved by extrapolating from these FTE figures to include external contributors based on their relative number of commits --- thereby for the purpose of this estimate presuming similar time and effort required for external versus internal commits.
+
+#### System administrators
+
+<!-- #### Amount of system administration engineers actively working on Fediverse software products -->
+
+### Used system resources
+<!-- >- Used system resources (CPU, storage, networking) -->
+#### CPU
+* minimum/average/peak percentage of (number of) CPU cores used?
+<!-- (presumes similar performance across CPU models) -->
+* CPU model used
+#### storage
+in e.g. GB currently used by the instance
+#### networking
+in e.g. min/max/average MiB/s in/out of the instance, along with physical caps potentially limiting these
+<!-- #### RAM -->
+### Capital
+<!-- * income -->
+<!-- note that while most of the Fediverse projects have had grants from NLNet, NLNet does not publish structured information on financial resources committed or reimbursed. -->
+<!-- * estimated costs for the service -->
+
+## A closer look at the Fediverse platforms
+<!-- 
+* Name of service/platform
+* Description of service/platform
+* capital
+  * income
+  * estimated costs for the service
+* NodeInfo
+  * estimated number of installations
+  * estimated number of users (Monthly Active Users)
+* human resources
+  * [ ] Amount of software developers actively working on Fediverse software products
+    * estimated number of developers working on the service
+  * [ ] Amount of system administration engineers actively working on Fediverse software products
+  * [ ] Amount of moderation and governance people
+    * estimated number of moderators
+* Used system resources
+  * [ ] CPU
+  * [ ] storage
+  * [ ] networking
+ -->
+
+| Project | Installations | monthly active users |
+|-|-|-|
+| mastodon | 8033 | 736878 |
+| pixelfed | 501 | 126065 |
+| nodebb | 43 | 52399 |
+| lemmy | 407 | 41341 |
+| peertube | 962 | 25804 |
+| loops | 1 | 26548 |
+| wordpress | 2863 | 11510 |
+| writefreely | 492 | 11188 |
+
+## Estimating investments in the Fediverse
+
+<!-- * Conclusion -->
+
+## Notes
+[^1]: Kissane, E., & Kazemi, D. (2024, September 4). Findings Report: Governance on Fediverse Microblogging Servers. https://fediverse-governance.github.io/#brief-glossary
+[^2]: https://fediverse.observer/allsoftwares
+[^3]: Note that this focus would exclude work on protocols such as W3C's work on the ActivityPub protocol, as well as on non-core repositories, and ancilliary software whose development is run by others than by the lead developers of the mentioned services, such as bridges, cross-posters, third-party clients, browser extensions, instance indices, etc.
+[^4]: Visibility, for our purposes meaning exposing metadata using the NodeInfo protocol, for Mastodon, the Fediverse service with the highest amount of active users, notably excludes an instance with more active users than its biggest visible instance <https://mastodon.social/>, namely Donald Trump's Truth Social.
+[^5]: This feature requested may be tracked at: https://github.com/swicg/activitypub-trust-and-safety/issues/25
+[^6]: The used query here is: `git log --pretty=%h»¦«%s»¦«%aN»¦«%aE»¦«%aD | lines | split column "»¦«" commit subject name email date | upsert date {|d| $d.date | into datetime} | where ($it.date > ((date now) - 365day)) | where not ($it.name has 'bot') | group-by name | transpose | upsert column1 {|c| $c.column1 | length} | sort-by column1 | rename name commits | where ($it.commits >= 5) | reverse | length`
+
+## References
+
+* https://en.wikipedia.org/wiki/Fediverse
+* https://fedidb.org/
+* https://mastodon-analytics.com/
+* https://www.thinkimpact.com/mastodon-statistics/
+* https://fediverse.observer/
+* https://the-federation.info/
+* https://fediverse.party
+* https://socialhub.activitypub.rocks/t/fep-f1d5-nodeinfo-in-fediverse-software/1190
+* https://codeberg.org/fediverse
+* https://hachyderm.io/@esk/113793277371908181
+
+## Changes 
+Older versions of this directory lived here: https://git.fediversity.eu/Fediversity/meta/src/commit/0006758ab7d12c2914f915813815bea89208fc6d/Fediverse-investments-an-estimation.md

meeting-notes/2025-06-12-developer-sync.md

@@ -0,0 +1,35 @@
+# 2025-06-11 Fediversity developer sync
+
+- @kiara has been updating the project proposal to reflect current ideas
+    - https://git.fediversity.eu/kiara/fedi-goals/src/branch/rewrite/
+    - need to make sure all stakeholders are on board with the updated vision
+    - new slated project manager would need to know what they're signing up for
+    - we reviewed and discussed the draft
+
+- @niols got the full integration test for deploying via the panel to pass
+    - https://git.fediversity.eu/Fediversity/Fediversity/pulls/361
+    - we tinkered on reducing the number of hacks involved
+    - @fricklerhandwerk had some ideas for that, but the sketches need cleanup
+        - https://git.fediversity.eu/Fediversity/Fediversity/pulls/364
+- @kiara and @fricklerhanderk continued editing the adjustments to the project proposal
+    - @kiara: whether/how to concentrate on external contributors (and if so, how to sensibly reflect that in a key result)
+    - @kiara: whether keeping the fediverse in even helps communicate our mission, considering fediversity could not fix the fediverse if we wanted to (given speed of adoption imo def isn't about self-hosting)
+- @fricklerhandwerk incorporated discussion results into the writeup
+    - https://git.fediversity.eu/kiara/fedi-goals/pulls/2
+    - https://git.fediversity.eu/kiara/fedi-goals/pulls/3
+
+## Draft success metrics for the adjusted objectives
+
+- Implement a way to run online services emphasizing user autonomy and data portability
+    - Integration tests pass for
+        - Setting up a fediversity hosting environment from a declarative configuration
+        - Configuring, deploying, and migrating a set of dummy applications
+    - Code passes data protection audit
+- Disseminate our results by engaging the open-source community to further expand on work in this direction
+    - Present results on at least 3 conferences
+    - At least 5 applications compatible with Fediversity thanks to external contributions by 2027-03
+- Exploit our work by enabling reproducible deployments of an initial set of portable applications
+    - There are 3 fediverse applications available out of the box:
+        - Mastodon
+        - PeerTube
+        - Pixelfed

meeting-notes/2025-07-01 developer sync.md

@@ -0,0 +1,12 @@
+Attendees: @niols @kiara @fricklerhandwerk
+
+- updated the project board
+- made some clarifications around splitting https://git.fediversity.eu/Fediversity/Fediversity/pulls/389 into manageable chunks
+- agreed on a general strategy to get a grip on the project layout:
+  - migrate everything to modules
+  - keep using flake-parts but don't use the flake parts except for CI checks
+    - we may simply swap it out with our custom modules eventually, since most of them will be custom anyway
+    - eventually we will be able to render most of contributor documentation via a Git hook
+  - a few small steps already pushed as PRs
+- @niols and @kiara will focus on speeding up CI and making the runner reproducible
+- @fricklerhandwerk will keep developing the data model with @kiara

meeting-notes/2025-07-03 data model review.md

@@ -0,0 +1,16 @@
+Attendees: @kiara @fricklerhandwerk
+
+- Discussed @fricklerhandwerk's WIP branch for implementing https://git.fediversity.eu/Fediversity/Fediversity/issues/103
+- The resource policy idea seems sound
+- The test sample doesn't look minimal at first glance, but in fact is
+  - An entire NixOS configuration is only minimal in terms of resource policy -- just put it in a VM
+  - An application that configures a whole NixOS needs to set many more things to make it run
+  - The login-shell sample also allows us to explicitly enumerate resource-specific configuration options to demonstrate how they're declared and used
+- We re-iterated on the stance not to touch actual applications before we have the whole workflow tested with samples
+  - Our packaged applications are already tested and in a state where we could translate them to the proper data model mechanically once it's in place and well-understood, so this will be a well-scoped problem for next year
+- It emerged again that we need to figure out a notion of compatibility (and therefore versioning) before being able to model migrations
+  - Once the data model draft type-checks and the tests pass, this will be the next research question
+  - We need to check if we want or have to make simplifying assumptions, such as not allowing version rollbacks
+  - Chances are, once we have compatibility clarified, migrations will be trivial
+- @kiara will spend some time today debugging the draft
+- Likely we'll need the next week to finish that part and play with it a bit, such as by adding a few more test cases.

meeting-notes/2025-07-08 weekly planning

@@ -0,0 +1,28 @@
+Attendees: @fricklerhandwerk @niols @kiara
+
+- @fricklerhandwerk
+    - almost completed the data model up to deployment, including a test
+        - @kiara fixed up some typos and evaluation errors
+        - remaining is to mold `nixops4Deployment` into a type that is accepted
+    - started compiling the mid-term technical report
+    - will pause work on the data model until that's done (next week)
+- @niols worked on extracting a minimal flake for the test
+    - (discussed how to handle lazy/strict source closures)
+- @kiara
+    - tried containerizing the CI but it didn't work out yet
+        - setting up a cache may improve turnaround time by a lot
+        - will pair with @niols the week after next
+    - tried patching the workflow to enable automatic dependency updates, made small progress
+        - we can do dependency bumps manually for now
+    - will pause work on CI until the technical report is done
+- todo for end-to-end beta: (REST) API for interacting with a runtime environment (general idea already settled in earlier discussions)
+    - GET json schema for configuring applications
+    - GET configuration
+    - POST configuration
+    - POST deploy
+    - GET deployment (version, config, status, ...)
+    - GET (stream) deployment progress
+    - Webhook: deployment state updates, e.g. completed, failed, ...
+    - TODO: workflow for migration
+        - ...
+        - 

meeting-notes/2025-07-22 developer sync.md

@@ -0,0 +1,20 @@
+Attendees: @kiara @fricklerhandwerk @niols
+
+- CI still bad: checkout action flaky, secrets exposed to all contributors
+  - We discussed switching to Gerrit (for review suggestions) and buildbot-nix (for CI)
+  - It will be a lot of effort, but it's already a lot of effort and we better spend it now than when more people join the project
+  - Chances are this will solve the secrets issue automatically
+- Regressions in Proxmox provisioning
+  - needs tests and docs, `proxmox-provision.sh` was written ad hoc beginning of the year
+  - we haven't been exercising our knowledge of provisioning since
+  - would be nice to rewrite in Python, also as a way to turn it into a NixOps4 resource provider
+- NixOps4 future:
+  - @roberth signaled the path to nested deployments may not be all that long
+  - @fricklerhandwerk: currently our use case is perfectly suited by the state of affairs (especially having everything one language), but eventually we'll need something more powerful
+  - @niols: dry run threatens to be a can of worms with nested deployments
+    - @fricklerhandwerk: we'd need to mock away everything, we don't have a programming pattern for that yet (sigh)
+    - @niols: for now we expose only the NixOS configurations to get evaluated separately
+- @kiara kept dabbling at the data model, fixing small issues
+  - @fricklerhandwerk will go through the WIP branch and cherry-pick what works
+- @niols will add tests to provisioning code to fix regressions from recent refactorings
+  - will start refactoring `infra/flake-parts.nix` to remove the wild function passing

planning/gantt.puml

@@ -1,4 +1,5 @@
 @startgantt
+skinparam backgroundcolor transparent
 
 <style>
 ganttDiagram {
@@ -12,7 +13,7 @@ ganttDiagram {
 }
 </style>
 
-2024-12-20 to  2025-01-5 is closed
+2024-12-20 to 2025-01-05 is closed
 2025-07-01 to 2025-08-31 is closed
 Project starts 2023-12-01
 projectscale monthly
@@ -20,47 +21,52 @@ projectscale monthly
 [Reporting period 1] happens at 2025-05-31
 Separator just at [Reporting period 1]'s end
 -- WP1 Project Management --
-[M1 First ActivityPub presence] starts 2023-12-29 and requires 7 days and is 100% completed
-[D1.1 Data Management Plan] starts 2023-12-01 and ends 2024-02-29 and is 100% completed
-[M6 First Tech talk] starts 2024-05-31 and requires 7 days and is 100% completed
-[M7 First Workshop] starts 2024-07-31 and requires 7 days and is 100% completed
+[M1 First ActivityPub presence] as [a1] starts 2023-12-29 and requires 7 days and is 100% completed
+[D1.1 Data Management Plan] as [a11] starts 2023-12-01 and ends 2024-02-29 and is 100% completed
+[M6 First Tech talk] as [a6] starts 2024-05-31 and requires 7 days and is 100% completed
+[M7 First Workshop] as [a7] starts 2024-07-31 and requires 7 days and is 100% completed
 
 -- WP2 Vertical Hosting --
-[D2.5 Technical architecture document] starts 2024-01-01 and ends 2024-03-29 and is 60% completed
-[D2.7 Analyze investment on fediverse] starts 2023-12-01 and ends 2024-04-30 and is colored in Red
-[D2.6 CI/CD setup] starts 2024-03-01 and ends 2024-10-31 and is colored in Red
-[D2.4 Nix Packages and NixOS Services] starts 2024-05-01 and ends 2024-11-29 and is 67% completed
-[D2.1 Software Release test environment] starts 2024-06-28 and ends 2024-11-29 and is 67% completed
-[D2.2 Software Release beta environment] starts 2025-01-01 and ends 2025-12-31 and is 0% completed
-[D2.3 Software release 1.0] starts 2025-12-01 and ends 2026-11-30 and is 0% completed
+[D2.5 Technical architecture document] as [b5] starts 2024-01-01 and ends 2025-06-15 and is 90% completed
+' [b5] is colored in Red
+[D2.1 Implementation] as [b1] starts 2024-03-01 and ends 2026-11-30 and is 50% completed
+[D2.2 Produce sample applications] as [b2] starts 2024-05-01 and ends 2026-11-30 and is 50% completed
 
 -- WP3 Vertical Public organizations --
-[D3.1 Requirements document] as [c1] starts 2025-01-01 and ends 2025-03-31 and is 0% completed
-[D3.2 Pilot program proposals] as [c2] starts at [c1]'s end and ends 2025-05-31 and is 0% completed
-[D3.3 Technical architecture document pilot programs] as [c3] starts at [c2]'s end and ends 2025-12-31 and is 0% completed
-[D3.4 Nix service flakes, packages and services for pilot programs] as [c4] starts at [c2]'s end and ends 2025-12-31 and is 0% completed
-[D3.5 CI/CD setup for pilot programs] as [c5] starts at [c2]'s end and ends 2025-12-31 and is 0% completed
-[D3.6 Running Fediverse software for public organisations advisory] starts at [c3]'s end and ends 2026-10-30 and is 0% completed
-[D3.6 Running Fediverse software for public organisations advisory] starts at [c4]'s end and ends 2026-10-30 and is 0% completed
-[D3.6 Running Fediverse software for public organisations advisory] starts at [c5]'s end and ends 2026-10-30 and is 0% completed
+[D3.1 Requirements document] as [c1] starts 2025-01-01 and ends 2025-03-31 and is 100% completed
+[c1] is colored in Grey
+[D3.2 Pilot program proposals] as [c2] starts at [c1]'s end and ends 2025-05-31 and is 100% completed
+[c2] is colored in Grey
+[D3.3 Technical architecture document pilot programs] as [c3] starts at [c2]'s end and ends 2025-12-31 and is 100% completed
+[c3] is colored in Grey
+[D3.4 Nix service flakes, packages and services for pilot programs] as [c4] starts at [c2]'s end and ends 2025-12-31 and is 100% completed
+[c4] is colored in Grey
+[D3.5 CI/CD setup for pilot programs] as [c5] starts at [c2]'s end and ends 2025-12-31 and is 100% completed
+[c5] is colored in Grey
+[D3.6 Running Fediverse software for public organisations advisory] as [c6] starts at [c3]'s end and ends 2025-06-15 and is 100% completed
+[c6] is colored in Grey
 
 -- WP4 Open calls and grant management --
-[M2 Announcement open call] starts 2023-12-29 and requires 7 days and is 100% completed
-[M3 First open call opens] starts 2024-02-01 and requires 7 days and is 100% completed
-[M4 First batch of grantees selected] starts 2024-03-29 and requires 7 days and is 0% completed
-[D4.1 Overview of granted projects] starts 2026-07-01 and ends 2026-11-30 and is 0% completed
+[M2 Announcement open call] as [d2] starts 2023-12-29 and requires 7 days and is 100% completed
+[M3 First open call opens] as [d3] starts 2024-02-01 and requires 7 days and is 100% completed
+[M4 First batch of grantees selected] as [d4] starts 2024-03-29 and requires 7 days and is 100% completed
+[D4.1 Overview of granted projects] as [d41] starts 2026-07-01 and ends 2026-11-30 and is 0% completed
 
 -- WP5 Enhancement and Usability --
-[D5.6 Setup UX design testlab] starts 2023-12-01 and ends 2024-07-31 and is colored in Red
-[D5.1 User requirement document] starts 2024-05-01 and ends 2024-08-30 and is colored in Red
-[D5.2 UX design] starts 2024-09-02 and ends 2025-11-28 and is 0% completed
-[D5.3 UX design implementation] starts 2025-12-01 and ends 2026-05-29 and is 0% completed
-[D5.4 UX design user studies] starts 2026-05-01 and ends 2026-09-30 and is 0% completed
-[D5.5 Design iteration and final release] starts 2026-10-01 and ends 2026-11-30 and is 0% completed
+[D5.6 Setup UX design testlab] as [e6] starts 2023-12-01 and ends 2024-07-31 and is 100% completed
+[D5.1 User requirement document] as [e1] starts 2024-05-01 and ends 2024-08-30 and is 100% completed
+[D5.2 UX design] as [e2] starts 2024-09-02 and ends 2025-11-28 and is 100% completed
+[D5.3 UX design implementation] as [e3] starts 2025-12-01 and ends 2026-05-29 and is 100% completed
+[e3] is colored in Grey
+[D5.4 UX design user studies] as [e4] starts 2026-05-01 and ends 2026-09-30 and is 100% completed
+[e4] is colored in Grey
+[D5.5 Design iteration and final release] as [e5] starts 2026-05-01 and ends 2026-11-30 and is 100% completed
+[e5] is colored in Grey
 
 -- WP6 Outreach and Dissemination --
-[D6.1 Communication strategy] starts 2023-12-01 and ends 2024-01-31 and is colored in Red
-[D6.2 Media package] as [f2] starts 2024-12-01 and ends at [c1]'s start and is 0% completed
-[D6.3 Communication report first period] starts 2025-03-03 and ends 2025-04-30 and is 0% completed
-[D6.4 Communication report second period] starts 2026-09-01 and ends 2026-10-30 and is 0% completed
+[D6.1 Communication strategy] as [f1] starts 2023-12-01 and ends 2024-01-31 and is 100% completed
+[D6.2 Media package] as [f2] starts 2024-12-01 and ends at [c1]'s start and is 100% completed
+[D6.3 Communication report first period] as [f3] starts 2025-03-03 and ends 2025-04-30 and is 100% completed
+[D6.4 Communication report second period] as [f4] starts 2026-09-01 and ends 2026-10-30 and is 0% completed
+[D6.5 Developer outreach] as [f5] starts 2025-01-01 and ends 2026-11-30 and is 10% completed
 @endgantt

planning/work-packages.mmd

@@ -0,0 +1,13 @@
+---
+title: Fediversity work package interdependencies
+---
+flowchart
+    management["WP1: Project Management"]
+    vertical["WP2: Vertical Hosting"]
+    grants["WP4: Open calls and grant management"]
+    ux["WP5: Enhancement & Usability"]
+    dissemination["WP6: Outreach & Dissemination"]
+
+    management --> vertical & ux & dissemination & grants
+    vertical --> ux
+    vertical & ux & dissemination --> grants

shell.nix

@@ -0,0 +1 @@
+(import ./. { }).shell