2024-01-mvp-demo-roadmap.md

@@ -1,54 +0,0 @@
-# Target: Demo at Fediforum online conference 2025-04-01 
-
-Goal: Demo Fediversity and make this demo available for download for others to use.
-Focus on 1 or 2 Fediverse applications that can be 'automagically' installed aka a minimal viable product.
-
-To determine:
-
-- What are the minimal requirements to make this happen?
-- What components are needed?
-- Which Fediverse services are we going to offer?
-- There are ~47 (~9weeks) workdays between 27-01-2025 and 01-04-2025. How will we divide the work among the team?
-
-# Roadmap
-
-* As a first measure, set up a new site with a simple email form: "set up your Fediverse services"
- * Initial form fields:
-  * text field: subdomain to use under e.g. <code>demo.fediversity.eu</code>
-  * multi-select: services to deploy (start with one or two)
-  * text fields: ssh public keys
-  * freeform: additional requests
- * Simply send an email to the project team for manual processing
- * Figure out the rest as we go, automate time-consuming repetitive tasks incrementally
-  * Systematically keep procedural notes from which we can later derive code
-* Split test environment into staging and production deployment
-* Start preparing a Django service ([as discussed 2024-11-06](../meeting-notes/2024-11-06%20standup%20notes.md#working-session-architecture-discussion)) that will eventually replace the manually processed form
- * It will take about a work week to make the development cycle smooth (maybe 2 weeks on the wall clock), enough to refine the initial data model
- * It could trigger NixOps4 asynchronously on form submission
-  * Requires figuring out the exact interaction model on the backend. Especially how deployment state gets stored, retrieved, and updated
-  * Requires a Passbolt provider for dynamic secrets ([as discussed regarding secrets handling 2024-12-10](meeting-notes/2024-12-10-decision-making-meeting-dealing-with-secrets.md))
-   * We probably don't want to mess with Git-backed storage there
-  * Requires a proper deployment provider
-   * Terraform is currently planned
-   * For single NixOS machines something more robust than a shellscript would already be nice, but that would require talking to Proxmox via API anyway
-* Rebrand MyProtagio to Fediversity
-  * It currently interfaces with an intermediate registrar, need to remove that
-  * Demo users could register an actual domain using a voucher token
-* Interfacing with MyProtagio for leveraging its DNS setup capabilities may need more time to study the code
-  * We’d ideally co-deploy an instance with the other front-end to enable smooth CI/CD; though that’s more up-front work
-  * MyProtagio doesn't have metering or billing yet
-    * If we hand out exactly one credit, it would include one domain name and some bulk service package for some period of time
-
-# TODO
-
-* Division of labor
-  * Tweag can do the domain-specific data types and transformations, as well as the the backend wiring
-    * Ronny asked to get involved in the domain modeling
-  * Waiting for Koen to contact their UI expert  
-  * Robert needed for NixOps4 providers
-* Selection of initial services
-  * Also have to resolve friction around versions being up to date in Nixpkgs
-
-# Next steps
-
-* Define detailed scope, integration points, schedule

meeting-notes/2025-01-24-mvp-demo-roadmap.md

@@ -0,0 +1,110 @@
+# Target: Demo at Fediforum online conference 2025-04-01
+
+This is a result of the [team discussion on 2025-01-23](https://git.fediversity.eu/Fediversity/intra/src/branch/main/2025-01-23-roadmap-discussion-fediforum.md).
+
+# Goal
+
+Demo the key aspects of Fediversity:
+1. One-click deployment of Fediverse services
+2. (stretch goal) One-click portability between hosting providers
+
+The point of the demo is to communicate:
+ - That the project extists, what it is about, how it's special, and that it's progressing towards its goals
+ - That this is the infrastructure you can use to provide a micro-cloud to end users
+ - The ultimate goal is infrastructure portability
+ - That we care about technological and economic sustainability
+ - For organisations that want to participate in the Fediverse, we may be a good partner
+
+Target audiences:
+- Peers, potential clients, policymakers
+- Hosting providers, organisations with sysadmins
+
+# Assumptions
+
+- There are ~47 (~9weeks) workdays between 27-01-2025 and 01-04-2025.
+
+- Demo users will use the Fediversity infrastructure.
+
+  There are a few things we have to hard-code for now, so the backend setup won't be easily adopted by others, and this isn't the goal for the demo.
+  Eventually we'll also need to describe the infrastructure one needs to run the whole thing.
+
+- At this point it's not clear if we'll manage to enable service portability.
+
+  Services ready to run on top of Garage: PeerTube, Mastodon, Pixelfed.
+  Making them portable is fairly involved though.
+
+  [Galene](https://github.com/jech/galene) doesn't have any state and only needs configuration files to be ported over.
+  But it doesn't have a NixOS service yet.
+  Likely we we'll only need the Nix expression once we have it.
+
+# User story 1: Deployment
+
+- Log in with NixPanel
+- Configure a DNS domain and select services to deploy
+- Observe a progress indicator
+- (optional) Get a notification when the process finishes
+- Check that the services are accessible under the configured domain
+
+# User story 2: Migration
+
+- Log in on a different instance of NixPanel
+- Create a migration token (e.g. callback URL)
+- Paste the token in the first instance and start migration
+- Observe a progress indicator
+- (optional) Get a notification when the process finishes
+- Check that the services run on the new instance
+
+# Roadmap
+
+* Set up a Django [CRM](https://en.wikipedia.org/wiki/Customer_relationship_management) service ([as discussed 2024-11-06](./2024-11-06%20standup%20notes.md#working-session-architecture-discussion))
+ * Trigger NixOps4 on form submission:
+  * Requires a provider for the NixPanel to store deployment state and send progress updates
+  * Requires a Passbolt provider for dynamic secrets ([as discussed regarding secrets handling 2024-12-10](meeting-notes/2024-12-10-decision-making-meeting-dealing-with-secrets.md))
+  * First step: assume a fixed provisioned setup
+  * For (optional) migratio: VM provisioning will be handled via Ansible for now:
+    * A NixOps4 Terraform provider is currently planned but will not be ready in time
+* Rebrand MyProtagio to Fediversity
+  * Remove the intermediate registrar and register DNS domains ourselves
+  * Demo users will register an actual domain (and a bulk service package) using a voucher token
+
+# Next steps
+
+* Define:
+  * Detailed scope
+
+    Which components need which capabilities to fulfill the user stories?
+
+    Example:
+    - We need a Passbolt provider for NixOps4
+    - We need a CRM to be set up and running, ready for triggering deployments
+
+  * Specific division of labor
+
+    Who exactly is responsible for which compononents?
+    Which time capcities are available for each contributor?
+    
+    Example:
+    - Tweag: Valentin will do the data modeling, Nicolas will wire up deployment-related Nix code
+    - Procolix: Hans will help integrate the existing Ansible script to spin up VMs on demand
+    - Robert will develop a provider for NixOps4 to interact with the CRM
+
+  * Milestones (scheduled delivery of capabilities)
+
+    What are the component capabilities we can test together?
+    When can we provide these aggregate capabilities?
+
+    Example:
+    - Week 1: Spin up the CRM and configure a rudimentary data model
+    - Week 2: Let a fixed CRM user trigger NixOps to deploy a fixed config to a fixed existing VM
+    - Week 3: Configure SSH keys in the CRM, deploy to a fixed VM a NixOS config accessible with these keys
+    - ...
+
+  * Issues (granular tasks)
+
+    What exactly needs to be done to reach the milestones?
+
+    Example:
+    - Deploy CRM
+    - Add UI for selecting a service
+    - ...
+