feat: Draft resolution for multi-node funding

.gitignore

@@ -1,3 +1,3 @@
 site/
 .venv
-.~
+*~

docs/federation/resolutions/draft/043.md

@@ -0,0 +1,59 @@
+---
+title: "Resolution 043: Budget 018: Multi-Node Coop Cloud"
+---
+
+- Topic: Budget 018: Multi-Node Coop Cloud
+- Date: 2026-07-16
+- Deadline: 2026-07-30
+- Size: Large
+- Budget: 2000€, with possibility of extension in future resolutions
+- Who will implement this: @amras and other willing contributors
+- Duration: Until the budget is exhausted or all goals are met. Estimated end of October 2026.
+
+## Motivation
+Coop Cloud's recipes and tooling were developed to support vertical, single-VPS infrastructure. This was sufficient for a time, because the early member coops used single-VPS infrastructure. However, several newer members have a need for swarms distributed across multiple machines.
+
+In an ideal world we would like to see a plug-and-play model, where user-members of a Coop Cloud instance can contribute multiple (low-power, unreliable) devices to construct a robust network- without relying on a data center.
+
+## Goals
+
+### The Desired Configuration
+- Has one manager node, containing the load balancer
+- Has two worker nodes, which do not rely on local persistent storage
+- Has two data storage nodes
+- Runs abra and at least two recipes
+- Can survive the death of one or both worker nodes, and one data storage node - with only a momentary loss of data/access
+- Provides routing ingress from any node in the swarm
+
+### Example issues to be addressed
+- distributed storage, in particular:
+    * object storage
+    * databases
+    * filesystem/volumes
+ - abra limitations, e.g.:
+	* log retrieval
+	* fetching container status
+	* running commands on remote containers
+- conventions for `deployment:` tags
+
+### Limitations that won't be addressed
+- There are usecases where an operator would want to distinguish between sensitive data stored in one location, and open data accessible to all storage nodes. For this project, we should assume no data is sensitive.
+- While worker nodes and data storage nodes can be treated as unreliable, we will assume there will be only one manager node and a central load balancer. In practice, this would mean that a VPS is still required for a coop cloud deployment - though it could be arbitrarily small and store no user data.
+
+## Project structure and Accountability
+- The hub for this initiative is a toolshed Project
+	- Day-to-day discussions can be held within issue comments
+	- Hours are logged under specific issues
+- An open meeting would be held once a month at a set date, until the conclusion of this project. Any federation members are welcome to join and ask about the status of the project.
+- At the conclusion of the project, or after major milestones, a demo will be presented, e.g. during a Kite Flying hour.
+
+## Budget
+- 2000€, with the possibility to negotiate an extension in the future.
+- Standard rate of 20€/hour
+
+### Work consists of
+- Meetings and Demos
+- Investigating and integrating upstream tools (garage, docker volume plugins, rsync, etc.)
+- Writing documentation and guides for docs.coopcloud.tech
+- Modifying existing recipes
+- Creating and investigating test deployments

docs/federation/resolutions/in-progress/042.md

@@ -0,0 +1,22 @@
+---
+title: "Resolution 042: Bunk Computer Cooperative to join the federation as a member"
+---
+
+- Topic: Resolution 042: Bunk Computer Cooperative to join the federation as a member
+- Date: 2026-06-18
+- Deadline: 2026-07-03
+- Size: large
+
+## Summary
+
+Bunk Computer Cooperative uses abra and coop cloud to manage infrastructure for their clients. Bunk has also contributed to the Keycloak and Nextcloud recipes, and one Bunk member is doing financial administration for the federation.
+
+## Details
+
+In Maren's words:
+
+> Bunk has been using coop cloud since we started our co-op. Once we learned about co-op cloud, it was apparent to all three of our members that co-op cloud's structure was super smart. Tooling maintained by a federation of the co-ops that use it is set up for long term sustainability, and we want to contribute to that sustainability just as we benefit from it. We hope to upstream our work on co-op cloud whenever possible, and have already done some of that with Nextcloud and Keycloak.
+
+@ammaratef45:matrix.org from [RTM](https://resisttechmonopolies.online/) happy offered to vouch.
+
+Bunk's representative to the federation will be Maren. She can be reached at `@maren:matrix.bunk.computer` on Matrix or `maren@bunk.computer` on email.

mkdocs.yml

@@ -139,12 +139,14 @@ nav:
               - federation/resolutions/passed/037.md
               - federation/resolutions/passed/038.md
               - federation/resolutions/passed/039.md
+              - federation/resolutions/passed/041.md
           - "Stalled":
               - federation/resolutions/stalled/013.md
               - federation/resolutions/stalled/030.md
           - "In Progress":
               - federation/resolutions/index.md
               - federation/resolutions/in-progress/040.md
+              - federation/resolutions/in-progress/042.md
       - "Minutes":
           - federation/minutes/index.md
           - "Recently":