Compare commits

...

55 commits

Author SHA1 Message Date
Valentin Gagarin 8f4cac8d0a merged meeting note uploads (and made a clarification) 2024-11-26 11:01:56 +01:00
Valentin Gagarin d5ab99de0c 2024-11-26 standup notes 2024-11-26 11:01:56 +01:00
BjornW e688b1304e add standup notes 2024-11-25 2024-11-26 11:01:56 +01:00
Valentin Gagarin 34f60b7b30 add Björn to attendees 2024-11-26 11:01:56 +01:00
Valentin Gagarin ecff049928 2024-11-25 standup notes 2024-11-26 11:01:56 +01:00
Ronny Lam 6738ce3988 merged failed MR 2024-11-26 11:01:56 +01:00
BjornW 59fc1bb80e add standup notes 2024-11-26 11:01:56 +01:00
Ronny Lam a63050bf0c added UML training doc 2024-11-26 11:01:56 +01:00
Robert Hensing 8d823f69d6 Add 2024-11-21-roberth-comments-post-meeting.md 2024-11-26 11:01:56 +01:00
Ronny Lam a0839682a7 renamed .uml to .puml 2024-11-26 11:01:56 +01:00
Valentin Gagarin d5bc38165e 2024-11-21 standup notes 2024-11-26 11:01:56 +01:00
BjornW 6147e33178 Notes from the architecture meetup 2024-11-20 2024-11-26 11:01:52 +01:00
Ronny Lam feda821b85 converted to uml and changes after meeting 2024-11-26 11:01:43 +01:00
Ronny Lam 5ff10fafd8 created arch svg 2024-11-26 11:01:43 +01:00
BjornW 006b3e27ae standup notes 2024-11-26 11:01:43 +01:00
BjornW b675aa61ee standup notes 2024-11-26 11:01:43 +01:00
Valentin Gagarin ffddea97a7 2024-11-19 standup notes 2024-11-26 11:01:43 +01:00
Valentin Gagarin 1c0c3db96b 2024-11-18 standup notes 2024-11-26 11:01:43 +01:00
BjornW 49ed946413 standup notes 2024-11-26 11:01:43 +01:00
Ronny Lam aa530dac87 changed some states in gantt 2024-11-26 11:01:43 +01:00
BjornW ed2592d841 standup notes 2024-11-14 2024-11-14 14:14:04 +01:00
BjornW 1d79ae9705 standup notes 2024-11-13 2024-11-13 17:02:01 +01:00
Ronny Lam 702ef53959 add gantt image 2024-11-13 16:33:09 +01:00
Ronny Lam c1afdc9f9f moved gantt chart 2024-11-13 16:29:38 +01:00
Ronny Lam b7381efdf5 added gantt chart 2024-11-13 16:27:00 +01:00
Laurens Hof 2ce96d12c7 Upload files to "/"
korte notes van ideeen koen op 2024-02-26
2024-11-13 16:16:12 +01:00
Valentin Gagarin f87dadf3ea move bootstrapping instructions to code repo 2024-11-13 16:13:39 +01:00
Valentin Gagarin 0257cf3fb2 move to meeting notes 2024-11-13 14:50:49 +01:00
ronny 9ffddad2da Update architecture-docs/Fediversity-architecture-notes.md 2024-11-12 11:20:16 +01:00
ronny 7ea407ad38 Update architecture-docs/Fediversity-architecture-notes.md 2024-11-12 11:19:45 +01:00
Valentin Gagarin 84df6c01a9 2024-11-12 standup notes 2024-11-12 10:03:41 +01:00
Ronny Lam 9c425217f4 Merge branch 'main' of git.fediversity.eu:Fediversity/meta
merge files
2024-11-11 15:58:15 +01:00
Ronny Lam f67d01b21d added services 2024-11-11 15:57:59 +01:00
Valentin Gagarin b74fa304e9 2024-11-11 standup notes 2024-11-11 10:00:15 +01:00
Ronny Lam c44bab99ce updated after session with Koen 2024-11-10 21:40:58 +01:00
Valentin Gagarin 73f011cdee clarify the DNS requirement 2024-11-08 11:48:00 +01:00
Valentin Gagarin baedb4693c 2024-11-08 standup notes 2024-11-08 09:58:26 +01:00
Valentin Gagarin 2e07baf6ac 2024-11-07 standup notes 2024-11-07 10:09:22 +01:00
Valentin Gagarin 690f3e5669 add notes on user-facing architecture 2024-11-06 10:58:50 +01:00
Valentin Gagarin 52dd28f2b8 normalise file name 2024-11-06 10:23:03 +01:00
Valentin Gagarin edede4a051 2024-11-06 standup notes 2024-11-06 10:08:09 +01:00
Valentin Gagarin 9cfe72f1f2 add updates from work meeting 2024-11-05 10:34:48 +01:00
Valentin Gagarin 9c6cd28eb9 2024-11-05 standup notes 2024-11-05 10:25:04 +01:00
Nicolas Jeannerod fb4f82113c Few improvements based on Valentin's experience 2024-11-04 14:26:07 +01:00
ronny 1cdd0524eb Add meeting-notes/20241104 Meeting notes.md 2024-11-04 10:02:16 +01:00
Valentin Gagarin bae765b340 2024-11-01 standup notes 2024-11-01 10:01:46 +01:00
Ronny Lam 5ddbf6060f yet another box, maybe too much 2024-10-31 14:21:52 +01:00
Ronny Lam c97a4423f0 add connection to storage and mgmt block 2024-10-31 14:03:25 +01:00
Ronny Lam ed60f4fdce make the br xhtml-complient 2024-10-31 13:46:18 +01:00
Ronny Lam ac8c82b2d6 changed mermaid to graph 2024-10-31 13:39:53 +01:00
Ronny Lam eaec2e3890 Merge branch 'main' of git.fediversity.eu:Fediversity/meta
merged
2024-10-28 09:53:06 +01:00
Nicolas Jeannerod cae541d159 Improve upon the notes 2024-10-25 22:42:05 +02:00
Hans van Zijst 2025d4aa5d Few small additions. (#20)
Not a lot, but probably useful.

Co-authored-by: Hans van Zijst <hans@woefdram.nl>
Reviewed-on: #20
Co-authored-by: Hans van Zijst <hans@procolix.com>
Co-committed-by: Hans van Zijst <hans@procolix.com>
2024-10-25 15:52:14 +02:00
Nicolas Jeannerod 3950c6359e Very raw notes on provisioning VMs 2024-10-25 12:04:28 +02:00
Nicolas Jeannerod 23e8450bf4 Move Proxmox doc to subdirectory 2024-10-25 11:47:20 +02:00
36 changed files with 892 additions and 80 deletions

9
.gitignore vendored Normal file
View file

@ -0,0 +1,9 @@
# ---> Vim
# Swap
[._]*.s[a-v][a-z]
!*.svg # comment out if you don't need vector files
[._]*.sw[a-p]
[._]s[a-rt-v][a-z]
[._]ss[a-gi-z]
[._]sw[a-p]

View file

@ -0,0 +1,21 @@
Overview van ideeen van Koen met mogelijkheden voor outreach van fediversity project:
# fediverse projecten hosten op subdomein
NLnet heeft een hele lijst van fediverse projecten die zij hebben ondersteund de afgelopen jaren.
https://mastodon.social/@fediversereport/110543307314408377 voor een lijst
fediversity kan deze projecten gaan hosten op een subdomein:
pixelfed.fediversity.eu
gotosocial.fediversity.eu
etc
En hierbij accounts aanbieden voor developers en andere geinteresseerden die met de software willen spelen om te kijken hoe het allemaal werkt.
# Developers uitdagen om NixOS packages up to date te houden
Een van de issues is dat de NixOS packages voor fediverse software niet altijd up to date is. Dit is zeker van belang als er security updates zijn uitgekomen. Onlangs heeft Mastodon in kortere tijd meerdere security updates uitgebracht, en het is daarmee van belang dat de NixOS packages in ritme blijven lopen.
Hoe krijg je developers met schaarse resources hiertoe prioriteit aan te geven, of de ruimte te geven voor andere contributors om hier aan mee te werken. Eerste mogelijkheid is om devs te stimuleren met goodies zoals tshirts ed.

Binary file not shown.

Binary file not shown.

After

Width:  |  Height:  |  Size: 59 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 31 KiB

View file

@ -1,91 +1,51 @@
<!-- Note: we're "abusing" the classDiagram for the moment as we sketch this out -->
```mermaid
graph TB
``` mermaid
classDiagram
subgraph Management
A[Nix-panel] --> I
Z[(central database<br/>Netbox)]--> B[Orchestrator<br/>NixOps] --> D[Proxmox]
B --> E[Nix-configuration]
B --> G[DNS]
B --> F[Email]
B --> J[Garage]
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
%% TODO: replace classDiagram
Hardware --|> Storage
Hardware --|> Virtualization
Virtualization --|> Nixos
Virtualization --|> LinuxOS
Core_Services <|-- Services
Core_Services <|-- FediServices
Storage <|-- Services
Storage <|-- FediServices
Nixos --|> Services
Nixos --|> FediServices
Management_UI --|> NixOps
Management_UI --|> Administration
subgraph Hardware
Systems[<b>Systems</b><br/><small>Storage<br/>Networking<br/>Operating-system<br/>Virtualization</small>]
Storage[<b>Storage</b><br/><small>exclusive_filesystem<br/>shared_blob Garage<br/>zfs</small>]
end
class Core_Services{
DNS
EMail
identity_management
secret_management
authentication()
SASL()
}
subgraph Virtualization
Nixos[<b>Nixos</b><br/><small>Application</small>]
LinuxOS[<b>LinuxOS</b><br/><small>Application</small>]
class Services {
NextCloud
secure_document_collaboration
Forgejo
webmail
HedgeDoc
project_planning
}
Services[<b>Services</b><br/><small>Edumeet<br/>NextCloud<br/>secure_document_collaboration<br/>Forgejo<br/>webmail<br/>HedgeDoc<br/>project_planning</small>]
FediServices[<b>FediServices</b><br/><small>Matrix<br/>Pixelfed<br/>Peertube<br/>Mastadon<br/>Owncast<br/>Castopod<br/>activityPub</small>]
end
class FediServices {
Matrix
Pixelfed
Peertube
Mastadon %%GotoSocial
activityPub()
}
class Administration {
monitoring
alerting
graphing
restore_backups
}
class Management_UI {
human-oriented administration
replication()
migration()
}
class Storage {
exclusive_filesystem
shared_blob
zfs()
}
class Hardware {
Storage
Networking
Operating-system
Virtualization
}
class Virtualization {
Proxmox
}
class Nixos {
Application
}
class LinuxOS {
Application
}
class NixOps {
orchestration
}
Systems --> Storage
Hardware --> Virtualization
Virtualization --> Hardware
Services --> Core
FediServices --> Core
Core --> Hardware
Nixos --> Services
Nixos --> FediServices
F --> Core
G --> Core
J --> Storage
D --> Virtualization
E --> Nixos
H --> Core
```
* human-centric
* easy, automated, replication and migration to different datacenter provider
* blob storage replicated generically
@ -100,3 +60,40 @@ orchestration
* Dovcot
* Zimbra
* LXC containers (not Docker-style)
* zfs-snapshots + replicatie (send/receive)
* s3 replicatie naar 3rd party
* locatie-mirorring? (buiten scope?)
* (maar dan Linstore op zfs)
### Working session: Architecture discussion
Attendees: Robert, Valentin, Koen, Kevin
- Robert: NixOps should handle backup creation and restore, since it knows all the details for that
- There will be an interface to plug Nix expressions with scripts that can access all the resources
- Once should be able to build domain-specific applications around that
- Valentin: Backups seem to be morally equivalent to deployments "to a file"
- Koen walked us through myprotagio.nl
- Kevin will share source code with Valentin
- It's a role-based-permission and billing UI wrapping PowerDNS, Postfix Admin, and InvoiceNinja
- Written in Laravel and Tailwind
- To build a UI for deployment we'd primarily need a REST API to a database
- Primary work would be to do the architecture and design
- Valentin: Maybe we could add just the APIs for the deployment workflows from a completely new service, and connect the front-end to that
- Won't have to touch the PHP then
- 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

Binary file not shown.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 463 KiB

After

Width:  |  Height:  |  Size: 74 KiB

View file

@ -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

View file

@ -0,0 +1,18 @@
Attendees: Nicolas, Ronny, Valentin
- Nicolas:
- Taeer left (waves to the internet)
- Handed off Mastodon and Peertube
- Fixed the remaining issue with Mastodon
- It was kind of accidental because in the meantime we had started letting Garage serve TLS on port 443
- The problem was that Mastodon has very strict content restrictions, and the port matters
- The instance works, but not the tests yet, because they don't use the new ports yet
- Tried spinning up a Mastodon machine with the automatic installer
- Needed to fix some networking issues
- Problem: We don't have our own domain yet
- Next steps: quick access to *some* domain, eventually access to the PowerDNS instance
- Ronny:
- Ported the [architecture diagram](https://git.fediversity.eu/Fediversity/meta/src/branch/main/architecture-docs/Fediversity-architecture-notes.md) to mermaid
- Will sort through the old issues and milestones to get an overview of the overall state of affairs
- Will get everyone in a room to answer questions and get everyone on the same page, once there's some order

View file

@ -0,0 +1,22 @@
- attending: Niols, Valentin (flaky connection), Ronny
- Niols has a working install for Mastodon and Peertube
- The installs are working, but you just get one go, this is related to networking
- Ronny will share the design with Koen.
- Valentin implemented a slice of the DOM specification in Nix module system options
- It goes slower than imagined because the standard is quite messy
- Many rules are specified verbally and have nothing to do with the syntactic representation
- But the module system has dependent type capabilities, so the PoC works as intended:
- Everything snaps together nicely
- It makes for an interface that allows creating correct-by-construction documents with very little visual noise
- Need to clean up history before pushing latest commits
- Will continue filling the missing elements needed for the page as is, and then go on to skinning
- Should be operational by Friday, as planned
We have to discuss the following with Robert:
```mermaid
graph LR
A[Fediversity-UI] --> Z((central database??))--> B[NixOps] --> C[something] --> D[Proxmox]
B --> E[Nix-machineconfig]
B --> F[IP-config] --> G[DNS]
```
We have to discuss interfaces and datamodel. Ronny will ping Robert.

View file

@ -0,0 +1,17 @@
Attendees: Nicoals, Valentin, Robert
* Valentin and Nicolas failed to run through the complete provisioning instructions because there were some inscrutable problems with proxmox
* Contacted Kevin for resolution
* Niols:
* Not many more news than above.
* Did some Mastodon-on-metal debugging.
* Would like to meet with Robert for a multi-machine configuration.
* Robert:
* Next steps for NixOps is to move NixOS-specific code to a separate repo and write documentation
* Will work with Niols today to use the prototype code first
Notes from work meeting:
- Applied Robert's example to the config we worked on yesterday
- Now need to connect to an actual machine, need to provision one first
- Eventually we don't want to have to know any details about the machine
- NixOps4 will keep a mapping between the attribute in the expression and the actual resource

View file

@ -0,0 +1,36 @@
Attendees: Kevin, Koen, Valentin, Robert, Ronny
* Koen:
* Björn is getting on board this week to help with communications until at least March 2025
* Robert:
* Completed the planned improvements to logging
* Managed to deploy a service via Proxmox from scatch yesterday
* (rehashing progress of the past week)
Availability in the next weeks:
* Nicolas: about 4.5 days/ week
* Valentin: 5x .5 day/week
* Robert: 3x .5 day/week
* Koen: 4x .8 day/week + 1x .5 day/week
* Ronny: 4x .2 day/week
* Kevin: 5x .5day/week
# Working session: Architecture discussion
Attendees: Robert, Valentin, Koen, Kevin
- Robert: NixOps should handle backup creation and restore, since it knows all the details for that
- There will be an interface to plug Nix expressions with scripts that can access all the resources
- Once should be able to build domain-specific applications around that
- Valentin: Backups seem to be morally equivalent to deployments "to a file"
- Koen walked us through myprotagio.nl
- Kevin will share source code with Valentin
- It's a role-based-permission and billing UI wrapping PowerDNS, Postfix Admin, and InvoiceNinja
- Written in Laravel and Tailwind
- To build a UI for deployment we'd primarily need a REST API to a database
- Primary work would be to do the architecture and design
- Valentin: Maybe we could add just the APIs for the deployment workflows from a completely new service, and connect the front-end to that
- Won't have to touch the PHP then
- 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

View file

@ -0,0 +1,18 @@
Attendees: Koen, Ronny, Robert, Eric, Valentin
* small discussion on mastodon/gotosocial database use
* Koen:
* Progress on project manager role (more public updates planned next week)
* Booked tickets for Zurich Nix hackathon and NGI meetup
* Regarding DNS: Need a separate DNS server setup
* Could do it to day, will try
* Asked Hans if he can fix the Procolix Matrix server, he said he'll spend time on it tomorrow
* Valentin
* HTML framework works (estimated finished by Friday, as planned)
- Can do cool things now such as element-level template overriding
- Working title: HTNL -- Hypertext Nix language, a DOM-specific language ;)
* Needs a bit of CSS to show it off
* Koen: Will show this to Kevin, it's wonderful
* Ronny will show it to Jos
* Kevin, please share the code that currently hosts the website so we can switch over once it's 50-80% of the way in terms of styling
* Everyone can add feature requests now

View file

@ -0,0 +1,11 @@
Attendees: Kevin, Ronny, Robert, Gheorghe, Valentin, Nicolas
* Gheorghe is a project manager from Tweag to listen in and assist the engineers with administrative tasks in the background
* Kevin will be on vacation the entire next week
* Ronny:
* Will sync with Koen today regarding the current state of the system architecture
* Planning to "drink our own champaign" with the applications we want to deploy
* Need to run and use them to be sure we have a working set of software for Fediversity
* Will set up a project board on Forgejo to track status of applications
* Nicolas: Still need write access to a DNS zone to do a full deployment
* Exchanged times of absence until end of the year

View file

@ -0,0 +1,13 @@
Attendees: Björn, Gheorghe, Ronnz, Richard, Robert, Valentin
* Introducing Björn
* Original qualification as interaction designer, later become programmer, sysadmin, project manager
* Worked on WordPress for 18 years as a self-employed developer.
* Valentin showed us a demo of the website overhaul.
* Hugo was rebuilt in pure Nix using the module system.
* Why? Because it now fits the method of working we want.
* Most importantly, it makes a completely self-contained static website where anything can be pre-processed transparently in the Nix langauge
* Will continue styling it, adding image processing
* Ronny showed the updated architecture diagram, done after catching up with Koen
* https://git.fediversity.eu/Fediversity/meta/src/branch/main/architecture-docs/Fediversity-architecture-notes.md
* Robert is currently dealing with a bug, probably not related to the project but still something that needs attention.

View file

@ -0,0 +1,30 @@
Attendees: Gheorghe, Koen, Ronny, Valentin, Richard
* Richard is Kevin's vacation replacement
* Will provide Nicolas with DNS access
* Bjoern will join some of the standups, will determine the concrete schedule this week
* Ronny brought him up to speed yesterday
* Will get to know everyone separately
* Koen:
* Arranged the travel to the Zurich meetup
* Will have an exploratory talk with a potential hire this week
* Plan engage with NORDUNET this week, so they start looking into Fediverse applications
* Nicolas has made a small setup with four services last week
* Now decoupling the Garage configuration and testing the deployment roundtrips
* Should finish today or tomorrow to have Garage on a fully independent machine
* Have some design questions on the way
* Will put them in the code, open an issue, and ping the Matrix channel
* Koen will be available this week
* Ronny asks for a presentation on NixOps4, since it's such a crucial component
* Valentin offers Robert to help preparing one
* Scheduled as a lightning talk for the ZHF Hackathon
* Plans for FOSDEM 2025:
* There will be a Nix devroom, which we could join
* There could also be a Fediverse devroom (not sure yet)
* We could also have a Fediversity BoF session
* Sign-ups open soon
* Koen and Bjoern will take care of that
* Will also ask some Fediverse people
* OFFDEM happens in the vicinity, may also be an option
* Valentin investigated accessible and mobile-friendly semantic designs for the website
* Will make it "look good" tomorrow

View file

@ -0,0 +1,23 @@
Attendees: Gheorghe, Koen, Ronny, Valentin, Robert, Eric, Richard, Nicolas, Bjorn
- Valentin demoed the website:
Dark mode, smaller screens accessible.
Slightly changed menu interaction.
Needs access to host, preferably today, can publish then.
Koen will help out today.
Next step is processing and displaying images
The framework should transaprently allow serving multiple sizes and resolutions depending on media query
Ronny: how many hrs spent on website?
Valentin: ~25-30hrs on the website. It's an investment for future work as well, since it will allow integrating anything from the source code, such as tested examples.
- Ronny had an update meeting with Eric. Updated the architecture based on this chat.
- Robert rehearsed his NixOps4 presentation with Valentin and incorporated feedback
- Eric won't be able to join tomorrow, Robert will give him an exclusive preview
- Bjorn will open a private repo for contact details and other sensitive information
- Robert will present nixops4 tomorrow (2024-11-14) after standup.

View file

@ -0,0 +1,17 @@
Attendees: Gheorghe, Ronny, Valentin, Robert,  Richard,  Bjorn, Nicolas, Koen (joined a bit later due to traffic) 
• Valentin: worked on deploying the website, got stuck on permissions
◦ Needs help from Richard with enabling passwordless sudo to keep going
◦ Moved all code into a single repo, preserving history; archived everything else
▪ Locked main branch to prevent messy history
▪ Need to figure out responsibilities for reviewing PRs
• Nicolas: worked on decoupling Garage in deployment
◦ Dealing with issues that keep poping up
◦ Needs an email address,  Richard will take this up with Koen
• Robert prepared the NixOps4 presentation for after the standup
• Gheorghe: works on the report for the software testing environment deliverable (due end of November). Needs attention due to obligations we have with EU
• Ronny worked on updating the Gantt chart for the deliverables
◦ Will meet with Bjoern, Koen, and Gheorghe after the presentation to sync
• Bjorn started playing with an internal repo and establishing more structures in the project
◦ Would like to use the mediawiki, which was set up recently, for internal purposes, since we're not using it for public documentation
▪ Asking Koen to provide credentials

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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)

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -0,0 +1,30 @@
Attendees: Gheorghe, Richard, Valentin, Ronny, Nicolas, Björn
Not attending: Koen & Robert (travelling), Kevin (day off)
* Bjorn set up some data structures in the internal Wiki
* Valentin:
* Met Eli from Thymis & Johannes from Clan. Discussed the three system architectures with them.
* NixOps took some time for them to make it click. Now I know a bit better what we can learn from them, and if and on what we can collaborate.
* Overlap with those projects is smaller than expected, but it was undoubtedly an extraordinarily fruitful exchange
* We need to think about how to convey the power of NixOps in such a way that people understand it properly
* It's at a very high level of abstraction (essentially an IO monad for the Nix language), while people typically think in terms of their concrete use cases.
* That gap requires some storytelling and didactic techniques to bridge.
* Will work on a report & publish it on the website to communicate
* Valentin & Bjorn will have a chat tomorrow after standup
* Gheorghe:
* Shared the UML info last Friday
* Will work on the financials & get the numbers
* Diagram code wants to add a PR
* Update the numbers
* Nicolas:
* Wiki e-mail: we need to have a secrets management solution.
* No test for PeerTube yet. So I started working on it. Probably finished today
* Ronny:
* Will have a look at Gheorghe's PR.
* Richard:
* Will ask Kevin about his work & check if I can help out
* Looking for stuff to work on
* Nicholas opened up the wiki registration so each team member can create their own account today.
* Nicholas: Make Forgejo send out notifications (Nicholas will do this).

View file

@ -0,0 +1,24 @@
Attendees: Eric, Gheorghe, Valentin, Kevin, Ronny, Koen, Nicolas
Not present: Bjorn (conflicting commitments)
* Gheorghe:
* Completed all internal information for the wiki
* Started review of spending this year, will continue today
* Valentin:
* Reviewed workshop notes and started writing something for pusblishing, will continue and finish today
* Asking for confirmation to continue working on website infrastructure, since that will be important next year
* Ronny: Started thinking about data models for the overall system
* Nicolas:
* Collected some issues that may block future work
* Large tests still don't run on the CI machines
* Ran into a Mastodon bug already that broke tests in the past
* Turned out that due to refactoring we merged the sources to all use Nixpkgs 24.05 (stable)
* This may question a decision made in the past to base our deployment on stable Nixpkgs releases, as we may end up missing out on relevant updates
* Koen:
* Tried to update peertube in Nixpkgs but the tests failed
* Summer of Nix requested an upstream change that may unblock this, which was not addressed yet
* Have a backlog from what Bjorn requested
* Robert:
* Discussed application architectures with Thymis and Clan at the hackathon
* Found some overlap and potential for collaboration

BIN
planning/gantt-1.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 110 KiB

57
planning/gantt.md Normal file
View file

@ -0,0 +1,57 @@
```mermaid
gantt
dateFormat YYYY-MM-DD
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 :done, active, a2, 2023-12-01, 2024-02-29
M6 First Tech talk :milestone, done, a3, 2024-05-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 :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
D2.1 Software Release test environment :crit, b5, 2024-06-28, 2024-11-29
D2.2 Software Release beta environment :b6, 2025-01-01, 2025-12-31
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, 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
D3.6 Running Fediverse software for public organisations advisory :c6, 2025-05-01, 2026-10-30
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, active, d3, 2024-03-29, 0d
D4.1 Overview of granted projects :d4, 2026-07-01, 2026-11-30
section WP5
WP5 Enhancement and Usability :w5, 2023-12-01, 2026-11-30
D5.6 Setup UX design testlab :crit, e1, 2023-12-01, 2024-07-31
D5.1 User requirement document :crit, e2, 2024-05-01, 2024-08-30
D5.2 UX design :crit, e3, 2024-09-02, 2025-11-28
D5.3 UX design implementation :e4, 2025-12-01, 2026-05-29
D5.4 UX design user studies :e5, 2026-05-01, 2026-09-30
D5.5 Design iteration and final release :e6, 2026-10-01, 2026-12-31
section WP6
WP6 Outreach and Dissemination :w6, 2023-12-01, 2026-11-30
D6.1 Communication strategy :crit, f1, 2023-12-01, 2024-01-31
D6.2 Media package :crit, f2, 2024-05-01, 2024-07-31
D6.3 Communication report first period :f3, 2025-03-03, 2025-04-30
D6.4 Communication report second period :f4, 2026-09-01, 2026-10-30
```

BIN
planning/gantt.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 79 KiB

59
planning/gantt.puml Normal file
View file

@ -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