Upload files to "meeting-notes"

meeting-notes/Tech session 2024-07-02.md

@@ -0,0 +1,199 @@
+​[https://www.fediversity.eu/](https://www.fediversity.eu/)
+
+  
+
+Guest: [https://selfprivacy.org](https://selfprivacy.org/)
+
+[https://garagehq.deuxfleurs.fr/](https://garagehq.deuxfleurs.fr/)
+
+  
+
+First tech discussion
+
+  
+
+**Fediversity**
+
+collaboration between
+
+- open internet discussion
+
+- tweag / modus
+
+- nordinet
+
+- nlnet
+
+  
+
+**Goal**
+
+pilot program of "horizon projects". our aim is to support and make available software created under the "next generation internet" program. special focus goes to open source software that is about the fediverse.
+
+  
+
+we want to make sure there is as diverse as possible software to connect to the fediverse
+
+  
+
+**principles**
+
+- everything is open source
+
+- as transparent as possible
+
+- we use nix/nixos
+
+  
+
+**the project**
+
+an interface for small "micro"-cloud providers to enable administrators to easily set up some combination of fediverse applications (gotosocial, mastodon, pixelfed, peertube, etc)
+
+  
+
+start with hardware. physical machines.
+
+  
+
+aiming to get a working set by the end of this year / beginning of next year
+
+  
+
+**sub-components**
+
+- nixops4 for deployment
+
+- ground-up replacement for nixops2/3
+
+- garage for storage
+
+- NixPanel will be the administrative interface. 
+
+- Nothing built yet.
+
+- NixConfigs sits in between nix panel and nixops4
+
+- defines what the services look like
+
+  
+
+**Kubernetes discussion**
+
+Why are we developing something new on Nix that already exists?
+
+  
+
+Advantage: Don't reinvent the wheel
+
+Disadvantage: We are targeting public organizations, and a lot of them already have cloud accounts. If we support kubernetes, they will run it on whatever large cloud provider they are already using.
+
+  
+
+**SelfPrivacy**
+
+Goal to get everyone to deploy their own server with federated services
+
+  
+
+Difference: don't offer hosting, offer services that manage your hosting.
+
+  
+
+Like ansible/terraform for NixOS servers.
+
+Control your server with nice mobile app GUI
+
+  
+
+Deployment using nixos-infect fork called by cloud-init script generated by the mobile app.
+
+  
+
+Then, the services are added/removed and configured using Nix, which reads the JSON file manipulated by the SelfPrivacy API. No changes of the Nix files are needed on the end machines despite all the differences between them. 
+
+  
+
+Things that cannot be done using Nix modules and NixOS rebuilds are done by our API (like, complex migrations, systemd unit restarts, backups, etc)
+
+  
+
+Nix definitions: [https://git.selfprivacy.org/SelfPrivacy/selfprivacy-nixos-config](https://git.selfprivacy.org/SelfPrivacy/selfprivacy-nixos-config)
+
+nixos-infect fork: [https://git.selfprivacy.org/SelfPrivacy/selfprivacy-nixos-infect/src/branch/master/nixos-infect](https://git.selfprivacy.org/SelfPrivacy/selfprivacy-nixos-infect/src/branch/master/nixos-infect)
+
+  
+
+Similarity: simple interface for administrators
+
+Differences: Fediversity is for large numbers of end-users (10k, 100k, more)
+
+  
+
+**Question:** Can we join forces / use parts of what SelfPrviacy is doing for Fediversity?
+
+  
+
+**Kubernetes**
+
+  
+
+- Koen/Robert/Taeer are all not very experienced with kubernetes.
+
+- It adds a lot of complexity, and is built around state management, which we don't need to do very much of.
+
+- Maybe Kubernetes can also replace NixGuard, watching the system and fixing things that go wrong
+
+- We chose Nix to avoid complexity. Reproducible, declarative systems are designed to be simple.
+
+- But kubernetes will also manage services on the servers. 
+
+- Restart services that go down
+
+- Scale up by adding more instances
+
+- "etc"
+
+- How does SelfPrivacy deal with this?
+
+- Not much.
+
+- Notify if a service goes down
+
+- User can try to restart it
+
+- Manual support
+
+- Systemd can manage it in some cases
+
+- SelfPrivacy does not have access to the server. That's a difference from Fediversity.
+
+- There may just be a lot of inherent complexity in the problem of coordinating multiple machines and ensuring availability
+
+- How does nixops4 fit into this?
+
+- nixops4 does not deal with runtime information like load
+
+- you could pass off most of the work to something like kubernetes
+
+- you could try to build something that runs nixops4 periodically
+
+  
+
+TODO:
+
+- What features we want for NixGuard does kubernetes already provide? What does it not provide?
+
+- load balancing
+
+- ...
+
+- Is there something else that already exists and does those functions?
+
+- Pacemaker
+
+- Corosync
+
+- Nomad
+
+- Find someone who has more experience with kubernetes