Merge branch 'main' into gheorghe-patch-1-updateD2_1

Having it in red means nothing was worked on for this deliverable, which is not the reality. This is why I updated the status of the D2.1 Software release test environment to 80% completed and the task in progress. I considered today's situation, the missing architecture document, the grant agreement specifications for this deliverable and work package, and the demo that has already been presented. We'll add the remaining 20% after the architecture document is finished.

architecture-docs/Fediversity-architecture-notes.md

@@ -1,9 +1,6 @@
 ```mermaid
 graph TB
 
-Core[<b>Core-services</b><br/><small>DNS<br/>Email<br/>identity_management<br/>secret_management<br/>authentication<br/>SASL</small>]
-
-
 subgraph Management
     A[Nix-panel] --> I
     Z[(central database<br/>Netbox)]--> B[Orchestrator<br/>NixOps] --> D[Proxmox]
@@ -11,9 +8,10 @@ subgraph Management
     B --> G[DNS]
     B --> F[Email]
     B --> J[Garage]
-    B --> H[IdentityManagement]
+    B --> H[<b>IdentityManagement</b><br/><small>Authentication<br/>Authorization<br/>Accounting</small>]
     I[Nix-Panel API] --> Z
     H --> I
+    Core[<b>Core-services</b><br/><small>DNS<br/>Email<br/>identity_management<br/>secret_management<br/>authentication<br/>SASL</small>]
 end
 
 
@@ -86,3 +84,16 @@ Attendees: Robert, Valentin, Koen, Kevin
         - But for the full integration to work one will have to understand the whole system anyway
           - At that point one may as well keep maintaining it or rewrite it
       - Koen: The existing thing needs work regardless, and would like to move away from PHP to Python anyway
+
+## Architecture meeting
+- Identitymanagement == AAA
+- Central database is two databases, one accounting and one state
+- Datamodel -> dns, aaa, ip, machines, etc.
+- Data complete first, model later
+- Data flows/processes
+- Describe casestories
+- Nixos -> VM
+- LinuxOS out of scope
+- Services and Fediservices one box
+- move secretsmanagement
+- move core-services to management

architecture-docs/architecture.puml

@@ -0,0 +1,80 @@
+@startuml
+
+package Management {
+    object "Nix-Panel" as A {
+    }
+    object "Nix-Panel API" as B {
+    }
+    object "**Central Database**" as CD {
+        Netbox
+        Accounting
+        State
+        Secrets
+    }
+    object "**Orchestrator**" as Orch {
+        NixOps
+    }
+    object "**Identity Management**" as AAA {
+        Authentication
+        Authorization
+        Accounting
+    }
+    object "**Central Services**" as CS {
+        DNS
+        Email
+    }
+}
+
+package Hardware {
+    object "**Systems**" as Sys {
+        Operating System
+        Network
+        Storage
+        Virtualisation
+    }
+    object "**Storage**" as Stor {
+        exclusive_filesystem
+    }
+    object "**S3 storage**" as S3 {
+        Garage
+    }
+}
+
+package Virtualization {
+    object "**Nixos VM A**" as NixA {
+        Application A
+        Application B
+    }
+    object "**Nixos VM B**" as NixB {
+        Application C
+    }
+    map "**Application options**" as App {
+        Edumeet => Matrix
+        NextCloud => Pixelfed
+        Webmail => Peertube
+        Hedgehoc => Mastodon
+        Project planning => Owncast
+        Office => Castopod
+    }
+}
+
+Sys --> Stor
+Sys::Virtualisation -l-> Virtualization
+NixA --> Stor
+NixB --r--> S3
+NixA --> App
+NixB --> App
+NixA --> AAA
+NixB --> AAA
+A -d-> B
+B -d-> CD
+CD <-d-> Orch
+Orch -r-> CS::DNS
+Orch -r-> CS::Email
+Orch -d-> Virtualization
+Orch --> NixA
+Orch --> NixB
+Orch --> S3
+Orch <-l-> AAA
+B -d-> AAA
+@enduml

meeting-notes/2024-11-15-standup notes.md

@@ -0,0 +1,26 @@
+Attendees: Valentin,  Ronny, Richard, Gheorghe, Nicolas,  Bjorn, Robert
+
+Nicolas: 
+	* proxmox provisioning shell cleanup & refinement
+	* added a removal script
+	* worked on CI in the repository
+		* there was some preliminary work that never got merged
+	* still waiting for an email account to test the various services with
+Valentin:
+	* website deployed, fixed a display issue
+	* reviewed Nicolas PR's
+	* will look into the state of CI today (WP2) 
+Richard: 
+	* Helped with the website
+	* Is currently not available for this project (will try to fix the email) 
+Robert: 
+	* working on making the deployment process concurrent         
+	* once that's done, will continue adding more resources (support stateful ones first)
+	* after standup chat tech with Bjorn
+Bjorn
+	* Waiting for Wiki setup
+		* Is there a backup?
+		* Does everyone have access?
+		* Needs to be made private
+	* Waiting on answers to questions asked in Element
+

meeting-notes/2024-11-18 standup notes.md

@@ -0,0 +1,11 @@
+2024-11-18 Present: Gheorghe, Kevin, Koen, Nicolas, Richard, Valentin
+
+* Gheorghe has trouble accessing the wiki
+* Richard sent e-mail details Nicolas
+* Nicolas connected the two actions runners in a NixOS deployment so we use our own tooling
+	* It works except vm02179 is excruciatingly small
+	* Kevin + Koen will look into it
+* Valentin with Nicolas looked into fully e2e testing the setup
+	* Robert also has some work in that direction in the NixOps4 repo, should be finish that up in a couple of hours
+* Koen and Richard will compile an overview of what to do this week
+	* Want to improve turnaround time on serving requests by the development team

meeting-notes/2024-11-19 standup notes.md

@@ -0,0 +1,20 @@
+Attendees: Gheorghe, Kevin, Richard, Valentin, Nicolas, Ronny, Eric
+
+* Valentin:
+	* Did some internal review and planning with Nicolas and Gheorghe
+	* Thought about UX and implementation for asset management in the static website setup
+		* Trying to minimize the amount of code, moving parts, and content author interactions required
+		* Will start writing a first prototype today
+* Nicolas:
+	* Continued unifying the infrastructure code
+	* CI is too slow though, and tests still fail because of that
+		* Will check in with Eric on what to do about it
+	* Can help with setting up email on the internal wiki
+		* Need access to the machine hosting it
+	* Can demo a script for spinning up Proxmox VMs (the Thursday demo started with existing VMs to deploy NixOS)
+* Robert (via Matrix):
+	* Made progress on a test-support framework
+		* This is Nicolas can write automated tests with NixOps4, reusing the NixOS VM test framework
+	* Planned after that are concurrency and then stateful resource support
+* Kevin: Worked on providing more resources to the CI runner. May have to rack a machine with a faster CPU
+* Richard: Will provide Nicolas with an email address for testing the Wiki, and investiate how to configure the Wiki

meeting-notes/2024-11-20 standup notes.md

@@ -0,0 +1,21 @@
+Attendees: Bjorn, Valentin, Gheorghe, Robert, Kevin, Richard, Nicolas
+
+	* Robert: Currently splitting out the NixOS integration into a separate repo
+	* Nicolas: Continued consolidation of configurations
+		* WIP PR https://git.fediversity.eu/Fediversity/Fediversity/pulls/11
+		* Discussed CI performance issues with Eric, he wanted to take a look at running QEMU more efficiently by leveraging the host more
+			* Proxmox may also be involved somehow, but currently I don't have access to the Proxmox configuration and how it sets up the details of virtualisation
+			* Overall not inconclusive yet
+		* Need access to the SSH jumphost to be able to deploy the website
+		* Got access to the wiki machine, will add email once done with the config
+			* Should be a one-liner and redeploy
+	* Valentin:
+		* Saving up hours for the workshop Sat & Sun (NixOS ZHF Hackathon)
+	* Richard: on standby
+	* Kevin:
+		* Gave Niols and Valentin access to the respective machines
+		* Will start moving all machines into the Fediversity VPN
+			* This should also speed up CI since that environment has faster CPUs
+	* Gheorghe:
+		* Prepared the archictecture review meeting today, compiled a glossary, noted where clarficiations are needed
+	* Bjorn: Will prepare the archtecture review today

meeting-notes/2024-11-20-architecture-meetup/2024-11-20-architecture-meetup.md

@@ -0,0 +1,79 @@
+​Architecture meetup 2024-11-20
+
+13:30 -  15:00
+
+Agenda Times are approx. Less is better ;) 
+13:30 - 13:35 Goals of the meeting (~5min)
+13:35 - 14:15 Diagram discussion (~40min)
+14:15 - 14:35 Status of the project (~20min)
+14:35 - 14:55 Roles & responsibilities (~25min) 
+14:55 - 15:00 FOSSDEM (~5min) 
+
+Attendees: Bjorn, Ronny, Richard, Kevin, Nicolas, Gheorghe, Valentin
+
+Goals:
+	*     Clarify uncertainties and "freeze" the architecture
+
+Notes:
+	* Robert and Koen are missing today, both are critical
+	* Management layer:
+		* IdentityManagement should be clarified as Authorization, Authentication, Accounting (AAA)
+		* The Nix-Panel to used by the operator (our "customer") with high-level parameters
+			* operator's email
+			* DNS zone
+			* booked storage and compute
+			* etc
+		* TBD in how much this will be greenfield, see architecture discussion from a few weeks ago
+		* About the central database (multiples)
+		* Q: what is the datamodel? TBD in more detail.  
+			* State of the system per operator
+			* AAA stuff 
+			* Operator bespoke info
+			* Provider bespoke info
+				* upstream DNS config
+				* Netbox: provider side (physical network layout & hardware) 
+		* Q: What's the role  of NixOps4 here?
+			* Valentin: NixOps4 merely provides a mechanism. The policy is implemented by "resource providers" which are domain-specific and plugged into NixOps4 to CRUD the various data sources
+		* TO DO: There are no "use cases" yet to describe how the services works; e.g setting up a service like Pixelfed etc. Basically a case to describe how the components work together. 
+			* (some discussion on the various representations of the system: component dependency graph, data flow graph for how deployments come together, user stories for the various actors)
+			* Valentin proposes to focus on the component dependencies for now, as the current diagram already mostly represents those 
+				* can sketch user stories on the side
+		* "Nix-configuration" and Proxmos are merely resource providers for NixOps4
+		* TODO: Glossary for definitions (make sure we all speak the same language).
+		* Gheorghe proposes to annotate each box with the component type (e.g. "virtualisation provider") and [at least one, if there are multiple planned] concrete implementation (e.g. "proxmox")
+		* Ronny: there may be services that happen not to run under NixOS but some other Linux distro
+			* We will need another configuration system for those, e.g. Ansible
+				* This would be another resource provider for NixOps4
+			* We shouldNix declare it out of scope, since NixOS is the more natural thing to do, or hack it together with shell scripts if absolutely required
+				* We currently don't have services that aren't - and defintely none that can't be - nixified
+				* Also, centrally managed systems, such as provider-side DNS management, can be handled by the provider classically, e.g. on Debian
+					* Our particular target deSEC would be expensive to package for NixOS, but we need it exactly once per provider and it won't be redeployed
+		* NixOS services:
+			* The only difference between "Services" and "FediServices" is that "FediServices" have federation
+				* More nuanced: Fediverse services are intended to be used by the general public, while the others are more interesting for academic institutions
+					* This is a distinction per work package
+			* Technically, all of them are NixOS modules with configurations that are somewhat specific to our architecture
+			* Unspecified requirement: Backups for all of these
+				* From previous discussions: storage is one of
+					* Service data: Block storage (ZFS), and snapshots are pulled on the provider side
+						* Essentially anything that can't be stored as blob storage
+					* User data: Blob storage (e.g. Garage), could optionally be replicated to compatible services
+						* Q: is this already available in Garage or would we need to build it, and is it relevant to our mission?
+				* Storage needs to be rewired for each service so the data actually lands where it should
+					* Need to decide whether it's worth the time investment on a case-by-case basis
+		* "Core services":
+			* secrets management is more of a concern for deployments (as a NixOps4 resource provider)
+				* Secrets are a resource & need a resource provider plugin.
+				* Which resourceproviders does NixOps need to talk & their context.
+			* The purpose of this block is to signify that some services are mandatory for an operator-side deployment, but they exist already and only need to be interfaced with via NixOps4
+				* For example, there is a DNS management system and an email server, and a deployment merely needs to register with them
+					* TODO: label this in the architecture diagram
+				* TODO: move it into the "Management" block, maybe rename this to "existing" or "pre-defined" services
+			* TODO: clarify mapping between archtectural components and use case actors, refine naming
+			* 
+
+Due to other meetings we had to stop here. We still have to discuss these topics from the agenda: 
+14:15 - 14:35 Status of the project (~20min)
+14:35 - 14:55 Roles & responsibilities (~25min) 
+14:55 - 15:00 FOSSDEM (~5min) 
+ 

meeting-notes/2024-11-20-architecture-meetup/2024-11-21-roberth-comments-post-meeting.md

@@ -0,0 +1,130 @@
+
+# Architecture diagram
+
+- Split out central database, netbox. They're separate databases
+  "Operator" accounts and high-level configuration => NixPanel database
+- Netbox will be accessed as a resource; perhaps move down
+  - Netbox IP resource (IP allocation resource)
+- Split up into nodes for each db so that it's clear which parts talk to which state.
+- Nix configurator: NixOS is just a resource to NixOps, as Valentin says
+- (PlantUML diagram) is this a package diagram? Package diagrams are meant to describe the application level structure (e.g. within NixPanel) rather than the system level structure (e.g. between NixPanel and NixOps)
+  The arrows are supposed to be code dependencies, but many aren't. They seem to be some sort of interactions.
+
+# Misc Notes
+
+Valentin is on point about the NixOps decoupling
+
+Ansible could be invoked by NixOps, over ssh remotely.
+Only if there's a need. 100% on restricting to NixOS for now.
+
+# Platform definitions
+
+Running some "fixed" infrastructure on non-NixOS, like Proxmox, Garage, etc is fine. We do have an ambition to deploy everything from hardware using NixOps and NixOS, but this is not a blocker.
+The way to think of this is what is the platform onto which a Fediversity is deployed:
+- current platform: Proxmox + Garage + deSEC + netbox
+- future alternative platform: bare metal
+    - see [NixOps4-based-installation process] for an impression; out of scope for now iiuc
+- other future alternative platform: Google Cloud, OVH, AWS, Scaleway, etc
+    - no ambition to do this as part of Fediversity, but someone else may want to develop this
+    - Nix language is capable of such abstractions
+
+<details><summary>Example: Object Storage</summary>
+
+Depending on the platform, the NixOps configuration will activate different resources. For example, object storage could be provided by
+1. A provided Garage instance. The Fediversity NixOps configuration will need admin credentials to be entered.
+   This is our first and for now only target.
+2. Bare metal, in which case the Fediversity NixOps configuration may allocate VMs that run Garage, and configures Garage to give NixOps admin credentials.
+3. A cloud native S3 compatible service
+
+</details>
+
+<details><summary>Abstractions in Nix</summary>
+
+In NixOps4 we use the module system to perform abstractions.
+Possible pattern:
+
+- Option `objectStorage.backend.s3`: submodule with options to access an S3 compatible service
+  - configured by hand when deploying onto an existing S3 service, such as Garage on Debian, or a cloud provider
+
+- Option `objectStorage.backend.garage.enable`: whether to deploy a Garage cluster
+
+- Option `objectStorage.buckets.<name>`: submodule with information about the bucket
+
+- Config `resources."bucket-${name}"`: the various bucket resources, derived from the `objectStorage.buckets` option set
+
+- Config `resources.garage.resources."${...}"`, conditional on `objectStorage.backend.garage.enable`: the resources to deploy Garage onto Proxmox or bare metal
+
+The infra layer might be best modeled as a separate NixOps deployment. It does not need to run as part of the NixPanel user interface, but run by those who run the service provider.
+
+</details>
+
+# Secrets
+
+- Sources
+  - NixOps user level (workstation, not copied anywhere)
+    - user ssh private key is reused by NixOS resource
+    - credentials to access the NixOps state (e.g. in bucket object or over ssh)
+    - (anything that bootstraps access to the NixOps state)
+  - Outputs of resources will contain credentials (stored in NixOps state)
+    - e.g. the admin password for anything created through NixOps resources
+  - Sensitive infrastructure parameters inserted into the NixOps state initially
+    - e.g. using a `pinentry` resource
+    - or dummy resource that fails, but whose output attributes can be overridden by the NixOps CLI
+- Destinations
+  - Files on NixOS machines
+    - copied to very private directory over ssh (`root`-only)
+    - copied to their final place by NixOS systemd units
+      <details>
+
+      - work with NixOS community to standardize this
+      - e.g. each service specifies with options where it expects its secrets, and waits for secret-specific systemd units using some convention
+      - `nixops4-nixos`, `agenix`, `sops-nix`, etc. can all implement this interface
+
+      </details>
+    - handled in such a way that they don't end up in the Nix store (use protective wrapper when passed around in the Nix language)
+  - NixOps resources
+    - Passing one resource's output to another resource's input: the purpose of NixOps
+    - NixOps state
+      - Encrypted at rest
+- Process
+  - Simplest is to pass credentials around through NixOps, but indirections are possible. Benefits:
+    - Implement key rotation without redeployment => vault-style secret management with short-lived secrets so that credential leaks are less damaging and less valuable
+    - Fewer places with secrets => brings more structure to the organization's credentials management
+      - Only if all secrets from the NixOps state can be moved over to the secret management system.
+      - This will require more complexity in NixOps; would not recommend for now
+      - Single point of failure, _or_ "use one hinge and oil it well" -- paraphrasing [age] authors or reference, out of context
+  - `vaultwarden` can be written to by NixOps as needed, so that it can grant access declaratively
+
+Security: compromise of a NixOps user compromises the whole deployment, and same for the NixOps state.
+This probably includes equivalents of aforementioned "NixOps user level" secrets
+  - State is likely compromised by compromising a NixOps user
+  - NixPanel credentials are probably in the state, and they will need to have similar capabilities to those of the NixOps user credentials
+Configuration management is expected to be able to do anything. (No need to freak out, but do use caution.)
+
+# Terminology
+
+- **operator**: I'm not super happy about "operator" instead of e.g. "customer". You're ignoring the Ops in NixOps. I can accept that, but it's not great communication.
+
+  For NixOps it makes sense to use "operator" and "author" roles to describe its users. I don't see a better alternative for NixOps.
+
+- **target platform**: Core services, infrastructure services, etc may be useful terms to distinguish the roles in terms of behavior and functionality.
+  I think the missing term is "target platform", which captures the boundary of the scope of the Fediversity project. As described, this scope can be variable.
+
+  For example, _infrastructure services_ like Garage or email can each individually be part of the _target platform_, as they are right now, or they can become part of Fediversity's infrastructure services.
+
+  Being managed by Fediversity code is a less intrinsic property than it being "infrastructure", although arguably that's still a bit fuzzy; S3 not so much, but email is.
+
+# Meta notes
+
+- My contract is to develop NixOps, not NixPanel. I give advice.
+- Usually "foo is done by NixOps" does not mean that it is implemented in the NixOps project, but rather that some action is initiated by calling a NixOps command, and the details of the operation are declared in a combination of
+  - NixPanel output of some sort
+  - A NixOps resource provider implementation
+  - A set of Nix expressions developed by the Fediversity project
+  - A Nix expression that's specific to a Fediversity deployment, which refers to the generic Fediversity expressions
+    (kept to a minimum, things like does Fediversity deploy a garage or is it provided by the underlying platform)
+
+
+[NixOps4-based-installation process]: https://git.fediversity.eu/Fediversity/meta/src/branch/main/architecture-docs/NixOps4-based-installation-process.md
+
+[age]: https://github.com/FiloSottile/age

meeting-notes/2024-11-21 standup notes.md

@@ -0,0 +1,13 @@
+Attendees: Eric, Kevin, Ncolas, Ronny, Richard, Valentin, Gheorghe, Robert
+
+* Ronny converted the Gantt chart and architecture diagram to UML, following the meeting from yesterday
+	* (some review comments on minor details)
+* Bjorn asked what the status of the old project board on Forgejo is
+	* The deliverables are formalized only for Tweag's responsibilities
+	* Issues are out of date, need to close as completed/irrelevant, and add recent issues based on action items from meeting notes
+	* Once done, everyone should be responsible to keep it in good shape at fine granularity
+* Valentin reviewed Nicolas' infra code refactorings
+* Nicolas needs reviews from ProcoliX with respect to bespoke server configuration, there are some open questions
+	* Kevin will take a look
+* Gheorghe prepared the next architecture meeting to present what's been done so far
+	* Will review spending next and start planning for the next phase

meeting-notes/2024-11-22 standup notes.md

@@ -0,0 +1,29 @@
+​Attendees: Bjorn, Eric, Gheorghe, Richard,  Kevin,  Ronny 
+
+Not attending (travel to Zurich): Valentin, Koen, Nicholas 
+
+* Kevin: 
+	- VM access wil be available monday (Fediversity website)
+	- Not available Monday due house renovations
+	- PR's from nicolas are in progress.
+
+* Richard (happy birthday!): 
+	- Wiki mail is fixed
+	- on stand-by 
+		
+* Ronny 
+	- nothing to discuss 
+	
+* Eric
+	- Nothing to discuss 
+	- Suggestion: start standup with: is anyone blocked?  
+	
+* Bjorn: 
+     	- Fossdem participation will sent out reminders
+     	- Continue with wiki & architecture doc
+	
+*  Gheorghe 
+	- Make clear that this is not a reporting meeting
+	- Suggestion: use a token to keep participants engaged.  
+	- Took a closer look at the numbers / hrs Tweag. Not finished yet. Need to be able to show this in audits 
+	- Will send an old UML training (see Matrix) to make sure everyone understands this	   

planning/gantt.md

@@ -6,13 +6,13 @@ title       Fediversity
 section WP1
 WP1 Project Management :w1, 2023-12-01, 2026-11-30
 M1 First ActivityPub presence :milestone, done, a1, 2023-12-29, 0d
-D1.1 Data Management Plan :crit, a2, 2023-12-01, 2024-02-29
+D1.1 Data Management Plan :done, active, a2, 2023-12-01, 2024-02-29
 M6 First Tech talk :milestone, done, a3, 2024-05-31, 0d
-M7 First Workshop :milestone, a4, 2024-07-31, 0d
+M7 First Workshop :milestone, done, a4, 2024-07-31, 0d
 
 section WP2
 WP2 Vertical Hosting :w2, 2023-12-01, 2026-11-30
-D2.5 Technical architecture document :crit, b1, 2024-01-01, 2024-03-29
+D2.5 Technical architecture document :active, b1, 2024-01-01, 2024-03-29
 D2.7 Analyze investment on fediverse :crit, b2, 2023-12-01, 2024-04-30
 D2.6 CI/CD setup :crit, b3, 2024-03-01, 2024-10-31
 D2.4 Nix Packages and NixOS Services :crit, b4, 2024-05-01, 2024-11-29
@@ -23,7 +23,7 @@ D2.3 Software release 1.0 :b7, 2025-12-01, 2026-11-30
 section WP3
 WP3 Vertical Public organizations :w3, 2023-12-01, 2026-11-30
 D3.1 Requirements document :crit, c1, 2023-12-01, 2024-07-31
-D3.2 Pilot program proposals :crit, c2, 2024-08-01, 2024-11-29
+D3.2 Pilot program proposals :crit, c2, after c1, 2024-11-29
 D3.3 Technical architecture document pilot programs :c3, 2024-12-02, 2025-05-30
 D3.4 Nix service flakes, packages and services for pilot programs :c4, 2024-12-02, 2025-05-30
 D3.5 CI/CD setup for pilot programs :c5, 2024-12-02, 2025-05-30
@@ -33,7 +33,7 @@ section WP4
 WP4 Open calls and grant management :w4, 2023-12-01, 2026-11-30
 M2 Announcement open call :milestone, done, d1, 2023-12-29, 0d
 M3 First open call opens :milestone, done, d2, 2024-02-01, 0d
-M4 First batch of grantees selected :milestone,  d3, 2024-03-29, 0d
+M4 First batch of grantees selected :milestone, active, d3, 2024-03-29, 0d
 D4.1 Overview of granted projects :d4, 2026-07-01, 2026-11-30
 
 section WP5

planning/gantt.puml

@@ -0,0 +1,59 @@
+@startgantt
+
+<style>
+ganttDiagram {
+  task {
+    BackGroundColor GreenYellow
+    LineColor Green 
+  }
+  undone {
+    BackGroundColor Yellow
+  }
+}
+</style>
+
+Project starts 2023-12-01
+projectscale monthly
+-- 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 80% 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
+
+-- 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 colored in Red
+[D2.1 Software Release test environment] starts 2024-06-28 and ends 2024-11-29  and is 80% 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
+
+-- WP3 Vertical Public organizations --
+[D3.1 Requirements document] as [c1] starts 2023-12-01 and ends 2024-07-31 and is colored in Red
+[D3.2 Pilot program proposals] starts at [c1]'s end and ends 2024-11-29 and is colored in Red
+[D3.3 Technical architecture document pilot programs] starts 2024-12-02 and ends 2025-05-30 and is 0% completed
+[D3.4 Nix service flakes, packages and services for pilot programs] starts 2024-12-02 and ends 2025-05-30 and is 0% completed
+[D3.5 CI/CD setup for pilot programs] starts 2024-12-02 and ends 2025-05-30 and is 0% completed
+[D3.6 Running Fediverse software for public organisations advisory] starts 2025-05-01 and ends 2026-10-30 and is 0% completed
+
+-- 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
+
+-- 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
+
+-- 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] starts 2024-05-01 and ends 2024-07-31 and is colored in Red
+[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
+@endgantt