shorter folder name, hex/nlnet add

fix main links
refactor: fedi passthrough
2026-10-29 15:44:53 +01:00 · 2026-10-29 15:28:35 +01:00 · 2026-10-29 15:22:56 +01:00 · 2026-10-23 11:40:31 +02:00 · 2026-10-23 11:30:26 +02:00 · 2026-10-23 11:24:18 +02:00
44 changed files with 4332 additions and 1749 deletions
@@ -1,2 +1,3 @@
 site/
-.venv
+.venv
+*~
@@ -26,6 +26,32 @@ wget -q -O - https://install.abra.coopcloud.tech | bash
 curl https://install.abra.coopcloud.tech | bash
 ```

+### NixOS
+
+The install example is based on the [using nix flakes wiki page](https://nixos.wiki/wiki/flakes#Using_nix_flakes_with_NixOS).
+
+1. Add the flake to your inputs
+```nix
+inputs = {
+  abra = {
+    url = "git+https://git.coopcloud.tech/toolshed/abra.git";
+  };
+};
+```
+2. Add abra package to system packages, replace _x86_64-linux_ with the value according to your system 
+```nix
+{
+  pkgs,
+  abra,
+  ...
+}:
+{
+  environment.systemPackages = with pkgs; [
+    abra.packages.x86_64-linux.default
+  ];
+}
+```
+
 ## Release candidate

 ### Wget
@@ -7,27 +7,24 @@ title: Finance

 ## Agreeing to spend money (Budgets)

+The Federation agrees on Budget items as large decisions that must pass a resolution [reference](https://docs.coopcloud.tech/federation/resolutions/passed/004/). All paid work must be within a Budget. Each budget has an associated "Project" on OpenCollective. Current approved budgets are:

+* [Abra Critical Fixes](https://opencollective.com/coop-cloud/projects/4-abra-critical-fixes) - see also [critical fixes budget resolution](https://docs.coopcloud.tech/federation/resolutions/passed/010/)
+* [Kite Flying](https://opencollective.com/coop-cloud/projects/13-kite-flying) - see also [kite flying budget resolution](https://docs.coopcloud.tech/federation/resolutions/passed/024/)
+* [Federation Radmin](https://opencollective.com/coop-cloud/projects/014-federation-radmin) - see also [radmin budget resolution](https://docs.coopcloud.tech/federation/resolutions/passed/029/)
+* [Website Development](https://opencollective.com/coop-cloud/projects/041-website-development) - see also [website development budget resolution](https://docs.coopcloud.tech/federation/resolutions/passed/041/)

 ## Sending and receiving money

-It's slightly complicated, because money is complicated, but here's how it works. There are two moving parts:
+Money is managed through The Co-op Cloud Open Collective account. Platform 6 is [the fiscal host](https://docs.opencollective.com/help/fiscal-hosts/fiscal-hosts) for the Co-op Cloud Open Collective account.

-* The Co-op Cloud Open Collective
-* The Autonomic Wise account
-
-Autonomic is [the fiscal host](https://docs.opencollective.com/help/fiscal-hosts/fiscal-hosts) for the Co-op Cloud Open Collective (OC).
-
-OC helps us make all expenses and transfers transparent to the Federation. No actual money is handled via the OC interface. All payments are done via the Autonomic [Wise](https://wise.com) account. The total sum of the available funds shows on the OC page is the actual amount that is held in the Autonomic Wise account.
-
-Autonomic Co-op members commit to support the federation by doing the financial adminstration work for the time being. Autonomic is publicy registered, has a bank account, files taxes etc. All financial comings/goings are kept on the books internally at Autonomic. This could be further mutualised or another collective could pick this up in the future.
-
-Autonomic does not eat the transfer costs from the Wise account when paying out expense for members. That is charged to the Federation common fund.
+Transactions are submitted through Open Collective, approved by the Federation and paid out by our fiscal host.

 ### How to get paid via Open Collective

 * [Create an account on Open Collective](https://opencollective.com/create-account)
-* Go to the [Co-op Cloud Open Collective](https://opencollective.com/coop-cloud)
+* Go to the [Co-op Cloud Open Collective](https://opencollective.com/coop-cloud/projects)
+* Find the appropriate Project
 * Click [SUBMIT EXPENSE](https://opencollective.com/coop-cloud/expenses/new)

 **Important** Please include bank details in your expense so that we can make a bank transfer. We do not currently support payments via Paypal and other platforms.
@@ -36,36 +33,22 @@ If you urgently need the money, please let us know on the Co-op Cloud Finance ch

 Finally, please let us know what your username/email is for your Open Collective account so we can add you to the team. This helps us build up the view of our community from the perspective of our Open Collective page.

-### How to pay someone via Wise
+#### Invoice Requirements

-> **Note**: only Autonomic Co-op members can do this
+Invoices are required to be submitted with your expense. Open Collective can generate an invoice for you if you select this option. Please include the hours worked and any work tickets if applicable in the line items of your invoice.

-* First off, be wary of two things: 1) the currency conversion 2) the transaction fees of Wise. For 1) we have the complicating factor that the OC represents the common fund in GBP but our internal Wise jar is EUR. Then you're getting deeper into trouble if someone wants to get paid in e.g. USD.
+#### What transfer type do we use for payments?

-* In order to cover the transaction fee, you need to fake do the transfer to see what you'll be charged and then add that to what you withdraw from the jar. This is because Autonomic does not eat the cost of the transfer from Wise, that is charged to the Federation.
+Platform 6 dispenses other payments as bank transfers via [Wise](https://wise.com), please allow up to a week for pay out.

-* First step is to withdraw cash from the Co-op Cloud jar. It will automatically be transferred to the general EUR jar because the Co-op Cloud jar is also in EUR.
+### Contributing to Co-op Cloud

-* To transfer to USD, you don't have to use USD, you can use GBP/EUR directly. It's easier to make the direct payment from the jar you transferred it to. This is purely because it is easier to follow it in the accounting bookkeeping later on.
-
-* When making the payment, do the following:
-    * Select international transfer, choose your requird `$currency`
-    * Put correct amount in "recipient gets exactly" to get Wise to figure out the correct amount
-    * Open the invoice in Open Collective and look for the expense number, e.g. "Expense #132373" and put this in the reference number of the payment
-    * Note how long the transfer will take (Wise should tell you)
-
-* Mark the expense as paid in Open Collective. Use the "manual" method.
-
-* Let the member know the payment is on the way and how long it will take (if you have time).
-
-#### FAQ
-
-##### What transfer type do we use for USD?
-
-`ACH`. If you see `Abartn`, that is the `ACH routing number`.
-
-### Tiers on Open Collective
+[Contribute to Co-op Cloud](https://opencollective.com/coop-cloud#category-CONTRIBUTE)

 * Infrastructure Sustainability: Folks who are making use of Co-op Cloud digital infrastructure (e.g. [git.coopcloud.tech](https://git.coopcloud.tech)) and want to help out with maintenance costs. All recurring donations are spent directly on running costs and system adminstration labour. Thanks for considering!
+* Federation Membership: Dues paid by members of the Co-op Cloud Federation. Please see [Resolution 002: Membership/Dues 2023-03-22](https://docs.coopcloud.tech/federation/resolutions/passed/002/) for more information. There may be further decisions made around dues, please refer to the Federation documentation on [docs.coopcloud.tech/federation](https://docs.coopcloud.tech/federation).
+* One-time Contribution: Just stopping in and want to support? Thanks! [Come say hi!](https://docs.coopcloud.tech/intro/contact/)

-* Federation Membership: Dues paid by members of the Co-op Cloud Federation. Please see "Resolution 002: Membership/Dues 2023-03-22" for more information. There may be further decisions made around dues, please refer to the Federation documentation on [docs.coopcloud.tech/federation](https://docs.coopcloud.tech/federation).
+When scheduling membership dues, please make them from the OpenCollective account associated with your co-op/collective/project. If you do not have an account for your project and are paying with a personal account, please let us know in the Co-op Cloud Finance channel.
+
+*Please note that Open Collective charges recurring contributions on the 1st of the month*
@@ -4,7 +4,7 @@ title: Ford foundation

 # Ford foundation

-> Status: **pending**
+> Status: **rejected**

 * [Previous material](https://notes.bonfire.cafe/nlnet-bonfire-coopcloud-hosting)
 * [Application](https://fordfoundation.forms.fm/2023-digital-infrastructure-insights-fund-rfp/forms/9724)
@@ -0,0 +1,567 @@
+---
+title: NLNet CodeSupply
+---
+
+# NLNet CodeSupply
+
+> Status: **pending** ([Link to open call](https://nlnet.nl/propose/))
+
+## System3: High Performance Scanner
+
+## Reference
+
+- [`0x29a/hestia`](https://codeberg.org/0x29a/hestia)
+
+## Project Summary
+
+System3 is a generalization of a docker SBOM generation and security scanning
+tool called Hestia. It is intended to create a higher performance and more
+extensible alternative to ScanCode.io.
+
+Hestia is a proof of concept high speed, stand alone scanner for large numbers
+of docker images currently built to scan for vulnerabilities in the Co-op Cloud
+recipe catalog. This project will merge functionality from AboutCode to provide
+a more scalable alternative architecture to ScanCode.io and the scancode cli.
+
+The results of this project will be a Software Composition Analysis (SCA) tool
+that analyzes docker containers, produce SBOMs, and use those to identify
+vulnerable software. This vulnerability information will be enriched using open
+sources (such as EPSS). This proof of concept will be pluggable, making it easy
+to port scancode.io pipelines over to it.
+
+System3 is a reference to part of the cyberneticist Stafford Beer's Viable
+System Model.
+
+## Proposed effort
+
+- Total cost: €30030.00
+
+## Explanation
+
+### Which tasks will you undertake, and (roughly) how much time/effort will each take?
+
+1.5 engineer weeks: Currently Hestia uses Syft and Trivy to build SBOMs and
+scan them for vulnerabilities. Over the course of this project, Syft will be
+replaced by AboutCode's container-inspector. Custom code fetching will be
+replaced with skopeo (what AboutCode's fetchcode-container plugin uses under
+the hood) to help identify missing or incorrectly specified docker images.
+AboutCode's packageurl-python will be used to generate PURLs for vulnerability
+identification. Where useful, AboutCode's commoncode will replace existing
+utilities. 
+
+(SPDX generation will use spdx-tools, rather than adopting ScanCode's custom
+implementation.)
+
+1.5 engineer weeks: PURLdb and Vulernable code databases will be used, if
+possible, to find vulnerabilities. If this works, they will replace Trivy as
+the scanner (though other tools may also be used to identify vulnerabilities).
+This accounts for both the exploration time and implementation (given
+feasibility). If this is not feasible, this time will also include a problem
+analysis.
+
+6 engineer weeks: Turning Hestia into System3 will also mean changing the
+underlying architecture. Currently a pipeline architecture passes messages
+between workers (analogous to ScanCode.io's pipes). This will be abstracted
+with a framework where worker functions advertise their capabilities using
+decorators, and interfaces and pipelines are specified using YAML. The actual
+queue management functionality will be abstracted so that worker developers
+simply need to understand the data model of their worker's domain and can
+ignore all other details of the system.
+
+This time accounts for framework design, implementation, usability experiments,
+and improvements based on feedback. 
+
+Additional work: Interspersed through the development process, I will be adding
+unit testing, property testing, and integration testing. This will all be run
+through continuous integration to detect breaking changes in upstream
+dependencies and bugs induced by code changes.
+
+### What hourly/daily/monthly rate did you use?
+
+€65/hr x 40 hour/week x 11 weeks = 28600 + 5% margin of error = 30030.00.
+
+### Will there be any expenses?
+
+There are no additional expenses.
+
+### Next Steps and Strech Goals:
+
+If I'm able to complete other tasks, I will add additional workers such as:
+
+- A worker that connects to matrix and reports vulnerabilities to a chat
+- A worker that files security issues based on SCA results against Gitea, Forjeo, or GitHub repositories
+
+As a fast follow, I also plan to build a tool that turns pipeline definitions
+into cloud pipelines using n8n and Terraform.
+
+### Comparison
+
+System3 will be most similar to ScanCode.io and the ScanCode toolkit CLI
+application.
+
+The ScanCode toolkit schedules jobs against the ScanCode.io server. The System3
+cli will simply be a scaled and stripped down version of the architecture,
+allowing it to run independently from the representation layer.
+
+ScanCode.io is a django web service that exposes a REST API and a web UI. The
+underlying pipeline data model tightly couples multiple unrelated concepts
+(such as django presentation). Failure to separate concerns degrades
+performance by increasing the context needed to execute operations, increasing
+the minimum lines of code involved in any pipeline, and by preventing efficient
+horizontal scaling (that is, scaling by component not scaling the entire
+platform). 
+
+Hestia already presents more clean separation of concerns that allows it to
+scale any individual component simply by increasing the number of worker
+threads. A queuing oriented design makes it possible to transition from threads
+in a single application, as it currently is, to a server-less architecture with
+minimal changes. With appropriate abstraction, workers can run locally as
+threads within a single application, or can be deployed to Scaleway Serverless
+Functions, OVHcloud managed Knative, AWS Lambda, Google Cloud Functions,
+Beam.cloud, Kubernetes with Knative/OpenFaaS/Fission, or other frameworks,
+without being completely rearchitected. When deployed to serverless platforms,
+horizontal scaling can be handled by the platform. Serverless bound to queues
+(such as RabbitMQ or SQS) is already a common architecture for systems that
+must support horizontal scaling.
+
+The failure to separate concerns also forces pipeline developers to understand
+the concept of a project and a pipeline, in order to implement a pipe. Hestia
+separates these concerns so that a worker simply needs to take input from a
+queue and write to another queue. 
+
+System3 will further abstract this so that pipelines can be written using a
+configuration language, like yaml or json, while workers are simply functions
+and classes that focus on input and output. Presentation is completely
+separated, reducing developer context and enabling more complexity in the way
+that views can be managed. The System3 proof of concept will implement the
+vulnerable code pipeline for docker containers.
+
+An enterprise, especially one focused on technology such as Microsoft, Amazon,
+or Google, may have thousands or millions of repositories, container images,
+and servers to assess. Downloading each container is simply infeasible, even
+for a project as small as Co-op Cloud with 2k docker images to scan. Hestia
+automates the work of downloading, caching SBOM artifacts, and cleaning up so
+that it doesn't run out of disk space. As I understand it, this requires
+additional external scripts to emulate in ScanCode.
+
+The failure to separate representation from the rest of the platform means that
+data processing workloads can impact the performance of the web interface.
+
+But the monolithic nature of ScanCode.io represents a larger missed opportunity
+at generalization. Scanning for vulnerabilities in repositories or containers
+can provide important security signals. These signals may be more appropriately
+processed within an open source SIEM/XDM such as Wazuh or an existing internal
+stack. Security signals don't need to be handled as a single atomic pipeline,
+but can be processed as a stream. Streaming events can allow continuous
+autonomous data enrichment, such as a vulnerability detected in a repository
+triggering a search against a data lake to identify potential deployed
+endpoints, then triggering dynamic vulnerability scanning against those
+endpoints.
+
+Why should a "project" be limited to things that can be represented as files?
+Why not a list of IP addresses used by workers running NMAP with NSE
+vulnerability detection scripts, producing vulnerability identification
+results, which could be enriched using the very same enrichment as SCA? Why
+should it not be possible to correlate vulnerabilities identified in SCA, SAST,
+build time DAST, or IAST reports, with each other to find gaps in the security
+process?
+
+With the right architecture, these problems are solved by implementing workers
+and wiring them into pipelines or writing new visualizations over data produced
+by these workers. That is the vision of System3. 
+
+### Technical (and other) Challenges
+
+There are three patterns my system needs to support:
+
+- Queue with a single action. A worker consumes an item from the queue, processes the item, in serial.
+- Pub/Sub. Work items are broadcast in parallel with no built-in mechanism for deduplication, allowing different types of work items to execute in parallel.
+- Aggregation/Correlation. A work item may have several subtasks. Results of subtasks need to be collected up and correlated back to original projects. For example, a "recipe" (or application) has multiple versions, each version has multiple images, each image has multiple pieces of software, each piece of software may have multiple vulnerabilities. A worker needs to correlate vulnerabilities back to "recipes" at specific versions.
+
+There are two modes:
+
+- Serial
+- Batch
+
+There are two data source/sinks:
+
+- Messages
+- Data Lake
+  
+There are two target platforms:
+
+- Local
+- (host your own) Cloud
+
+Each of these, and the interaction between them, creates multiple opportunities
+for failure. The experience of the developer will be determined by how I
+balance exposing vs hiding detail. The more I obscure, the easier the system
+will be to use but the more limited it will be. This is often the key
+difference between enterprise tooling (where everything must be adapted to a
+wide range of scenarios) and small business tooling (where everything must be
+as simple as possible). 
+
+Due to character limitations, I've enumerated these challenges in more detail
+in the attached doc titled "Technical Challenges" (see below).
+
+### Ecosystem (max. 2000 characters)
+
+The tool will immediately be used by the Co-op Cloud project. Long term
+operational funding and management will be handled by the federation.
+Federation decisions are made democratically, via a resolution process. I'm
+actively coordinating with Co-op Cloud stakeholders and have attached a draft
+of the resolution 0XX (see below for draft) that describes the larger ecosystem
+within which this fits.
+
+One missing element is the security advisory announcement element (Co-op Cloud
+Security Advisory, or CCSA). Security advisory management is also a gap within
+the [AboutCode
+ecosystem](https://aboutcode.org/docs/getting_started/software-security/#manage-risk-with-aggregated-vulnerability-data).
+I will be writing a proposal for this as well, as I also have a proof of
+concept for it.
+
+Since I'm primarily using stable AboutCode libraries, coordination with
+AboutCode should not be necessary. If it is, I can use GitHub issues and the
+gliter channel (#aboutcode-org_discuss:gitter.im). During development I will
+probably join the VulnerableCode meeting to make sure I'm tracking the
+development of that project.
+
+However, the main users will likely be the Co-op Cloud project at the
+beginning. Once I can demonstrate that the system is stable and maintainable,
+it will make sense to expand to influencing AboutCode to consider integration
+opportunities. 
+
+## Background
+
+### Personal
+
+I have been a security engineer at Amazon (both the store and AWS) for almost
+10 years, and was a consultant to companies including Amazon and Microsoft for
+several years before that. During my time in AWS, I designed, built,
+operationalized, and drove adoption for a security testing framework now used
+by every AWS service and dozens of adjacent security teams. I designed a single
+framework that was easy for security engineers to develop, developers to
+onboard to and extend, and operators to maintain. The project was able to gain
+so much momentum, because I started by pulling in multiple stakeholders to
+understand the scope of the problem. 
+
+I have extensive experience with systems that must be highly performant. The
+tool I replaced was a DAST scanner. The scanner my tooling replace scanned a
+few dozen endpoints with 7 tests. My scanner ran dozens (and later hundreds) of
+tests against 16k endpoints, and did so in hours instead of days. I have
+implemented multiple orders of magnitude performance improvements to tooling
+more than once.
+
+I have developed other tooling as well, always bridging the gap between
+developers and security, always focused on making using the same toolkit for
+endpoint testing as build/integration testing. I have lead multiple consecutive
+successful programs to drive security improvement at scale at AWS. AWS is a
+highly technologically diverse environment. The combination of operating at
+scale against heterogeneous systems and previous work as a consultant has given
+me the diverse background I need to address similar problems globally. 
+
+## Other Funding (max. 1000 characters)
+
+There is currently no other funding for this project.
+
+## Attachments
+
+* [`technical_challenges.pdf`](./technical_challenges.pdf)
+* [`security_bus_design.pdf`](./security_bus_design.pdf)
+
+## Resolution 0XX Draft
+
+### Resolution 0XX: Security Event Management
+
+- Deadline: Date
+- Size: Medium
+
+#### Summary
+
+Create a federation wide Security Event Management process to address the
+following concerns:
+
+- End users and security researchers need a mechanism to report security
+  vulnerabilities in Co-op Cloud maintained recipes
+- Operators need to know if the version they are deploying or have deployed is
+  vulnerable, or if there are security related actions they need to take
+- Maintainers needed to know if a recipe they maintain needs a(n emergency)
+  security update
+
+#### Details
+
+##### Background
+
+We have created a Co-op Cloud Security room on Matrix to coordinate on security
+improvements, and have discussed security concerns during kite flying on
+[2026-08-27](https://docs.coopcloud.tech/federation/kite-flying-pad-archive/#2026-08-27-12-utc),
+[2026-08-06-19](https://docs.coopcloud.tech/federation/kite-flying-pad-archive/#2026-08-06-19-utc),
+and
+[2026-07-30](https://docs.coopcloud.tech/federation/kite-flying-pad-archive/#2026-07-30-12-utc)
+(the later related to maturity models). We have also worked on at least one
+[document](https://cloud.klasse-methode.it/s/aNitMQjeo5QpHs4?dir=/&editing=false&openfile=true)
+outlining the security domains we are working within and to help focus on the
+most critical areas.
+
+Over the course of the past month, we have identified the most critical gaps as
+described by the following user stories.
+
+##### User Stories
+
+- US1: As a Security Researcher, I have found a vulnerability in a Co-op Cloud
+  recipe. I would like to responsibly disclose this vulnerability to a Co-op
+  Cloud Security Contact so that users can be protected.
+- US2: As an operator, I would like to be actively informed as soon as possible
+  when an exploitable vulnerability is detected in a recipe I am using so that
+  I can keep my end users safe.
+- US3: As an operator, I would like to be able to find out if any recipes I'm
+  currently using have known vulnerabilities so that I can upgrade them in
+  order to keep my customers safe.
+- US4: As a maintainer, I would like to be informed of vulnerabilities in
+  recipes I maintain so that I can update recipe definitions and tell consumers
+  to upgrade.
+- US5: As an operator or maintainer, I would like to be able to run my own
+  vulnerability scans to identify new vulnerabilities so that I can keep ahead
+  of security team latency. Vulnerability scanners tend to produce a lot of
+  noise, so I'd like to be able to leverage security team pre-filtering for all
+  *known* issues so that I can focus on only *net new* issues.
+
+##### Co-op Cloud Security Advisories (CCSA) feed
+
+Security advisories are the foundation of any project's security program. They
+allow a project to announce security events, including, but not limited to,
+vulnerabilities that require upgrades, security incidents such as compromised
+hosts, and security program changes.
+
+The primary function of an advisory is to fulfill US2 by announcing
+vulnerabilities as soon as there are actions that an end user can take to
+mitigate the issue.
+
+Feeds generally come in the form of an email list. Often the email list is
+replicated to an RSS for easier tracking.
+
+Within the Co-op Cloud recipe set, there are currently known issues with
+recipes. Unfortunately the current way to alert users is to post in the general
+channel. This is easy to miss and is not easily searchable.
+
+The creation of a CCSA email list and RSS feed allows operators to quickly
+learn about issues, as information becomes available, without needing to filter
+through other chatter. With an RSS feed, additional automation (such as a
+Matrix bot) becomes significantly easier.
+
+##### Co-op Cloud Security Advisories (CCSA) catalog and Abra Integration
+
+While email/RSS can fulfill US2, a catalog can help fulfill UC3. CCSA can be
+written using a simple format such as yaml, toml, or json (so they can be
+searched based on recipe, CVE, or other metadata), and output to email, RSS,
+and a json vulnerability catalog. Such a catalog can be easily searched using
+automated tooling, can be rendered into a searchable page, or can be integrated
+into the abra deployment tool.
+
+One specific request that multiple operators have repeated is for some kind of
+"abra vulnerability check." This is a sequence diagram for populating feeds and
+catalogs:
+
+```
+,--.                  ,---------.                                 ,-----. ,-------. ,----.
+|SE|                  |CCSA tool|                                 |email| |catalog| |feed|
+`-+'                  `----+----'                                 `--+--' `---+---' `--+-'
+  | security advisory tml  |                                         |        |        |
+  |- - - - - - - - - - - ->|                                         |        |        |
+  |                        |                                         |        |        |
+  |                        | send from ccsa@security.coopcloud.tech  |        |        |
+  |                        |---------------------------------------->|        |        |
+  |                        |                                         |        |        |
+  |                        |     build security.coopcloud.tech/ccsa.json      |        |
+  |                        |------------------------------------------------->|        |
+  |                        |                                         |        |        |
+  |                        |        publish to security.coopcloud.tech/rss.xml|        |
+  |                        |---------------------------------------------------------->|
+  |                        |                                         |        |        |
+,-+.                  ,----+----.                                 ,--+--. ,---+---. ,--+-.
+|SE|                  |CCSA tool|                                 |email| |catalog| |feed|
+`--'                  `---------'                                 `-----' `-------' `----'
+```
+
+Once in a catalog, a user could run abra to test their own servers:
+
+```
+,----.                     ,----.                     ,----------. ,---------.
+|user|                     |abra|                     |swarm host| |ccsa.json|
+`--+-'                     `--+-'                     `-----+----' `----+----'
+   |     abra sec_check       |                             |           |
+   |- - - - - - - - - - - - ->|                             |           |
+   |                          |                             |           |
+   |                          |         get recipes         |           |
+   |                          |- - - - - - - - - - - - - - >|           |
+   |                          |                             |           |
+   |                          | deployed recipe/image list  |           |
+   |                          |< - - - - - - - - - - - - - -|           |
+   |                          |                             |           |
+   |                          |         download if not cached          |
+   |                          |- - - - - - - - - - - - - - -|- - - - - >|
+   |                          |                             |           |
+   |                          |          check against recipes          |
+   |                          |- - - - - - - - - - - - - - -|- - - - - >|
+   |                          |                             |           |
+   |                          |           vulnerable matches|           |
+   |                          |< - - - - - - - - - - - - - -|- - - - - -|
+   |                          |                             |           |
+   | list of vulnerable apps  |                             |           |
+   |< - - - - - - - - - - - - |                             |           |
+   |                          |                             |           |
+,--+-.                     ,--+-.                     ,-----+----. ,----+----.
+|user|                     |abra|                     |swarm host| |ccsa.json|
+`----'                     `----'                     `----------' `---------'
+```
+
+Here are command line mockups to help communicate the UX..
+
+Check one host, find vulnerabilities:
+
+```
+$ abra ccsa_check example.coopcloud.tech 
+Downloading latest Co-op Cloud Security Advisories
+|================================================| 100%
+Checking........ complete!
+[thisapp.example.coopcloud.tech]
+CRITICAL: RCE in ThisApp 1.2.3+3.4.5 -> ThisApp 1.2.4+3.4.6
+        CVE-4321-12345, CVE-2033-12346, CVE-2033-12347
+        https://security.coopcloud.tech/CCSA-20260914-2.html
+[thatapp.example.coopcloud.tech]
+WARNING: Denial of Service ThatApp 3.2+2.2.3
+        CVE-4321-12111
+        https://security.coopcloud.tech/CCSA-20260914-6.html
+```
+
+Check for vulnerabilities across all managed hosts:
+
+```
+$ abra server ls -m
+[{"host":"foo.coopcloud.tech","name":"foo"},
+{"host":"bar.coopcloud.tech","name":"bar"}]
+
+$ abra ccsa_check example.coopcloud.tech --all
+Using cached Co-op Cloud Security Advisories 
+Checking...
+foo
+bar
+...complete!
+
+[thisapp.foo.coopcloud.tech]
+CRITICAL: RCE in ThisApp 1.2.3+3.4.5 -> ThisApp 1.2.4+3.4.6
+        CVE-4321-12345, CVE-2033-12346, CVE-2033-12347
+        https://security.coopcloud.tech/CCSA-20260914-2.html
+[thatapp.foo.coopcloud.tech]
+WARNING: Dangerous configuration in OtherApp 332.1+1.2.3
+	    Read advisory to make sure this deployment isn't vulnerable
+        https://security.coopcloud.tech/CCSA-20260914-6.html
+[bar.coopcloud.tech]
+No vulnerabilities detected!
+```
+
+CCSA can provide a mechanism to alert users about issues outside of just CVEs.
+Supply chain attacks could poison docker images, requiring upgrades or
+downgrades for images downloaded during certain times. Compromise of member
+accounts could result in malicious code in abra or other tools. A CCSA can
+provide a key outlet for incident response actions that require public
+reporting.
+
+##### Maintainer
+
+In order to be able to provide updates to fulfill UC2 and UC3, we first need to
+have actionable information. It isn't enough to tell an operator that an
+application has a vulnerability if they can't do anything about it.
+Unactionable information manifests apathy. We must have a clear path from
+vulnerable to (more) secure.In most cases, this will require working with a
+recipe maintainer to upgrade a recipe to a version that isn't vulnerable.
+
+Unfortunately, there is no automated mechanism to identify a recipe maintainer
+point of contact. There are few acceptable options for this:
+
+1. Include a maintainer contact (email or matrix id) in the recipe.
+2. Include a link to a maintainer support matrix channel.
+3. Create a matrix channel in the coop cloud space for maintainers.
+4. create a mailing list for maintainers.
+
+Option 1 is optimal since it provides the highest level of ownership and
+accountability. Option 2 makes a support rotation easier and more accessible,
+but has no clear and specific point of contact. Option 3 is not optimal since
+it would be a bit noisy. Option 4 would also make a support rotation easier (as
+option 2) but would make it harder to find a specific person during a security
+event.
+
+##### Reporting Contact
+
+Today we are able to identify new security issues. Once a new vulnerability is
+identified within a recipe, someone needs to triage the vulnerability. This
+includes reading the description, understanding how it does or does not impact
+the specific image and associated network as deployed via the recipe, and
+determining the level of additional actions.
+
+For important vulnerabilities, maintainers need to be alerted. Someone needs to
+coordinate with those maintainers to make sure there's a safe upgrade path.
+Someone needs to write up a security advisory
+([demo](https://0x29a.codeberg.page/CCSA-DEMO/), publish that advisory, and,
+optimally, answer questions related to the advisory.
+
+This is part of the work of a Security Analyst in the field of Vulnerability
+Management. This needs to be staffed in accordance with our event response
+time. This doesn't need to be a task that takes up all someone's time, but
+there do need to be contacts in various time zones to be able to respond in
+case something comes up.
+
+##### VEX
+
+Triage work can be recorded using the Vulnerability Exploitability eXchange
+format (VEX). By also publishing this information as we review findings, we can
+coordinate with operators who may wish to run their own scans, or who are doing
+internal security work. We may also want to consume VEX from operators or other
+analysis teams. Hestia does not currently support VEX ingestion, but Trivy
+does. Code and infrastructure adjustments to hestia could allow authorized
+users to coordinate on vulnerability management.
+
+##### Recommendations
+
+1. Create a "Security@" email mailing list to which coop members and authorized
+   security engineers can subscribe.
+2. Repurpose the existing "Security" room for public (operator, maintainer, and
+   external) facing security support.
+3. Create a "Security Team" room in the "Co-op Cloud" matrix space specifically
+   for people working on security problems (triaging, security engineering,
+   etc).
+4. Allocate infrastructure (two swarm hosts, one subdomain) for security team
+   related work and testing.
+5. Create a "scanner" bot ([PoC here](https://codeberg.org/0x29a/hestia)) to
+   find new vulnerabilities for triage. Run this daily, increase to hourly if
+   needed.
+6. Create a matrix bot for the "Security Team" room to alert on new
+   vulnerabilities.
+7. Create a "Recipe Maintainer" room specifically for identifying maintainers
+   to coordinate with.
+8. Create a "support" object for each recipe entry in "recipes.json" a. Add a
+   (mandatory) "maintainer" field to this support object to identify a
+   maintainer contact (could be a mailing list maintainers are on). b. Add an
+   (optional) SLA field to the "support" field that lists the maintainer
+   response time. c. Decrease the "status" to "basic" for all recipes that lack
+   the support object. d. Decrease the "status" to "ok" for all recipes that
+   lack an SLA or for which the SLA has been missed in the last month.
+9. Create a security.coopcloud.tech subdomain for security related information
+   b. link from docs.coopcloud.tech to security.coopcloud.tech a. list security
+   contact information here
+
+##### Follow up
+
+1. Consider compensating maintainers of recipes with low SLAs and high scores
+2. Determine how to staff Triage team
+3. Apply for funding from nlnet to staff the security team for the first year.
+4. Create generic incident response plans for different incident types
+5. Identify an appropriate security contact method
+
+```
+// Security contact - email, matrix chat, list on website
+// Security feed - Co-op Cloud Security Advisory
+// -- mailing list, RSS feed
+//
+// Security management team
+```
@@ -44,7 +44,7 @@ Beyond our grant funding, and support in terms of time and technical resources f

 ### 4. Compare your own project with existing or historical efforts. (eg what is new, more thorough, or otherwise different)

-We maintain an ongoing analysis of Co-op Cloud compared to other options in the [Co-op Cloud documentation](https://docs.coopcloud.tech/faq/#what-about-alternative).
+We maintain an ongoing analysis of Co-op Cloud compared to other options in the [Co-op Cloud documentation](https://docs.coopcloud.tech/intro/faq/#what-about-alternative).

 Overall, Co-op Cloud has architectural and organisational advantages over existing libre options like Yunohost and [Caprover](https://caprover.com), and our open governance and libre licencing make Co-op Cloud a better long-term, pro-social choice than proprietary platforms like [Cloudron](https://cloudron.io). Versus options like [Ansible](https://ansible.com) or [Kubernetes](https://kubernetes.io), Co-op Cloud aims to be usable by less-technical users, to reduce their reliance on third parties to manage their data and tools.

@@ -1,39 +0,0 @@
---
-title: Organising handbook
---
-
-## Where do I find "the community"?
-
-The main place is the [Matrix community chat channels](/intro/contact/#matrix). You'll find a number of folks who are actively interested in the project and/or using `abra` and some of our recipes. Furthermore, Matrix has an excellent network of Cool People :tm: and in practice we've e-met a lot of groups who are interested in Co-op Cloud.
-
-## Onboarding new project members
-
-We still haven't worked this out. We're working on it.
-
-## Gathering new case studies
-
-We try to gather as many "case studies" as possible, stories & concrete examples of Co-op Cloud being used For Good :tm: See [coopcloud.tech](https://coopcloud.tech) for our existing examples. These studies help people identify what the purpose of the project is.
-
-## Monthly updates
-
-We have decided we'll try to do monthly progress updates. These will be published on the Co-op Cloud blog. It's a pretty loose format and we're basically just copy/pasta'ing things to a public pad during the month: ["This month in Co-op Cloud"](https://pad.autonomic.zone/YHKn4vHORmS6wjN1t2zi5A?both). Feel free to add your items to the monthly agenda and they will be included! All the previous posts can be seen [here](https://coopcloud.tech/blog/).
-
-## Kite Flying Hours
-
-The "Kite Flying Hour" is a weekly public moment where anyone can "drop by" into a Jitsi call and ask/do/propose whatever and meet some people who are currently working on the project. We haven't worked it all out but our process for now is the following.
-
-Someone from Autonomic will volunteer to be present and talk about the project for an hour weekly from 15:00 CEST - 16:00 CEST. We announce the hour via our socials: A [pinned toot](https://social.coop/web/statuses/106528094828958420) on [`@coopcloud@social.coop`](https://social.coop/@coopcloud) and a post to the `#coopcloud:autonomic.zone` room.
-
-Here is some invitation boilerplate which you can use:
-
-> Hey folks, you're all warmly invited to the Co-op Cloud Kite Flying Hour at `$X_TIME` `$Y_TZ` `$Z_DATE` over in [meet.jit.si/CoopCloudKiteFlyingHour](https://meet.jit.si/CoopCloudKiteFlyingHour)!
->
-> Inspired by exquisite childhood memories of [flying kites, eating popsicles and looking at clouds](https://norwichhistory.org/norwich-a-z-j-is-for-jigsaw/), it's an open hour to come hang out online and discuss/co-work/lurk/etc. around the [Co-op Cloud](https://coopcloud.tech/) project.
->
-> There are no "stupid questions"! It's a space to inquire, be curious and have a good time and get to know each other.
->
-> We take notes and doodle on [this collaboratively editable pad](https://pad.autonomic.zone/VtyrLUl9RWaJGgEDrncQUw?view). If you don't have time to attend, feel free to drop your questions and some contact details also, so we can get in touch. This is only the first Kite Flying Hour in a recurring series of Kite Flying Hours.
->
-> Hope to see you there! ☁️ 🌞 🖥️
-
-To work around Hedgedoc length limits, [we keep past content from the kite-flying pad here](./kite-flying-pad-archive).
@@ -1,5 +1,5 @@
 ---
-title: Joining the Co-op Cloud Federation (CCF)
+title: Join the CCF
 ---

 Organisations that are aligned with our values (e.g. [vision](/federation/proposals/federation/#vision), [strategy](/intro/strategy/), [code of co-operation](/federation/code-of-coop/) and [bylaws](/federation/bylaws/)) can apply to join CCF.
@@ -4,21 +4,27 @@ title: Membership

 > Are you also interested in joining the federation? Please check [our process](/federation/join/) on how to join. If you have any questions, [drop us a line](/intro/contact/) or come for a chat.

-| Name      | Dues Paid | Notes    | Contact |
-| --------- | --------- | -------- |-------- |
-| Agaric    | - | - | `@wolcen:matrix.org` |
-| [Autonomic](https://autonomic.zone) | - | - | `@3wc`, `@cas`, `@knoflook`, `@travvy`, `@aadil` |
-| [Bonfire](https://bonfirenetworks.org) | - | - | `@mayel:matrix.org` + Ivan (`@cambriale:matrix.org`) |
-| [Doop.coop](https://doop.coop) | - | - | `@yusf:gottsnack.net` |
-| [EOTL](https://eotl.supply) | - | - | `@basebuilder:pub.solar` |
-| [Karrot](https://karrot.world) | - | - | `@nicksellen:matrix.org` |
-| [Klasse & Methode](https://klasse-methode.it) | - | - | `@p4u1_f4u1:matrix.org` |
-| [Local IT](https://local-it.org/)  | - | - | `@moritz:matrix.local-it.org` + `@simon_sth:matrix.org`|
-| Mirsal ™  | - | - | `@mirsal:1312.media` |
-| [UTAW](https://utaw.tech) | -  | - | `@javielico:matrix.org` |
-| `@decentral1se` | Waiver | - | `@decentral1se` |
-| [ruangrupa](https://ruangrupa.id) | - | - | Henry `@babystepper:matrix.org` |
-| [RTM](https://resisttechmonopolies.online) | ✅ | - | `@ammaratef45:matrix.org` + `@linnealovespie:matrix.org`|
-| [MIR](https://mirnet.org/) | ✅ | - | `@sixsmith:matrix.org` |
-| [Red Abya Yala](https://abyayala.sutty.nl/) | - | - | `@fauno:sutty.nl` |
-| [Merri-bek tech](https://www.merri-bek.tech/) | - | - | `coop-cloud-delegate@merri-bek.tech`|
+| Name      | Dues Paid | Notes    | Contact | Status   |
+| --------- | --------- | -------- |-------- | -------- |
+| [Agaric](https://agaric.coop/) | ⭕ | - | `@wolcen:matrix.org` | Paused  |
+| [Autonomic](https://autonomic.zone) | ⭕ | - | `@kawaiipunk:autonomic.zone` | Active  |
+| [Bonfire](https://bonfirenetworks.org) | ✅ | - | `@mayel:matrix.org`) | Active  |
+| [Bunk Computer Cooperative](https://bunk.computer) | ✅ | - | `@maren@bunk.computer` | Active  |
+| [CoQuest - IT Coop Stuttgart](https://coquest.coop/en) | ✅ | voting rights waived | `hallo@coquest.coop` | Active  |
+| [Democratic Tech Fund](https://democratictech.fund/) | ✅ | - | `@mike_hales:matrix.org` | Active  |
+| [Doop.coop](https://doop.coop) | ⭕ | - | `@yusf:gottsnack.net` | Active  |
+| [eCommons](https://ecommons.nl) | ✅ | - | `@dannygroenewegen:matrix.org` | Active  |
+| [EOTL](https://eotl.supply) | ✅ | - | `@basebuilder:pub.solar` | Paused  |
+| [Karrot](https://karrot.world) | ⭕ | - | `@nicksellen:matrix.org` | Active  |
+| [Klasse & Methode](https://klasse-methode.it) | Waiver | - | `@p4u1_f4u1:matrix.org` | Active  |
+| [Kolektivo Sennacieca Cifereca](https://www.sekuro.nl) | ✅ | - | `@hex_m_hell:matrix.org` | Active |
+| [Local IT](https://local-it.org/)  | ✅ | - | `@simon_sth:matrix.org`| Active  |
+| [Merri-bek tech](https://www.merri-bek.tech/) | ✅ | - | `@sarah@merri-bek.tech`| Active  |
+| [MIR](https://mirnet.org/) | ✅ | - | `@sixsmith:matrix.org` | Active  |
+| [Red Abya Yala](https://abyayala.sutty.nl/) | ⭕ | - | `@fauno:sutty.nl` | Active  |
+| [RTM](https://resisttechmonopolies.online) | ✅ | - | `@ammaratef45:matrix.org`| Active  |
+| [ruangrupa](https://ruangrupa.id) | ⭕ | - | `@babystepper:matrix.org` | Paused  |
+| [UTAW](https://utaw.tech) | ⭕  | - | `@javielico:matrix.org` | Paused  |
+| Amras | Waiver | - | `coop-cloud@joinmeonmy.quest` | Active  |
+| Mirsal ™  | ✅ | - | `@mirsal:1312.media` | Active  |
+
@@ -0,0 +1,131 @@
+# Community Call "Cooperative Clouds with Kollicloud"
+
+## Date: 2026-05-21 12:00 UTC
+
+## Attendance
+Hosting: Simon, Wouter Tebbens (Free Knowledge Institute)
+
+Minutes: amras
+
+Present: Carla, d1 (coop cloud), Danny (eCommons), Graham (innovation.coop), Jeff, iexos, KawaiiPunk (Autonomic, Co-op Cloud, Tech Care Co-op), mikemh, Moritz, Simon, steven
+
+## Resources
+- [Video recording, and a report by Wouter Tebbens](https://freeknowledge.eu/cooperative-clouds-in-practice-kollicloud-shows-how-affordable-sovereign-infra-is-already-here)
+- [Announcement fediverse toot](https://social.coop/@fkinstitute/116566545446152790)
+- [Post-show fediverse toot](https://social.coop/@fkinstitute/116618445246768053)
+
+## Minutes
+
+### Admin
+Only the presentation will be recorded. Recording switched off for Q&A and conversation.
+
+### Democratic Tech Fund
+[Website](https://democratictech.fund/)
+- w: Democratic Tech means: the community impacted by tech takes responsibility for its own tech. Beyond OSS, OSS+governance+economics.
+- Tech monopolies take political power over a lot of people in our society; impacted+dependant. This is why we work on digital autonomy. Not just technical, but social capacity, appropriate technologies + economics & governance models. This can't be done alone, need to do in a network fashion.
+- 3 domains: collaborative workspaces, decentralized social media, tools for cooperative organizing. We're collectively studying what exists, what works, what people need and how we respond to those needs.
+- Democratic Tech Fund works on discovery of the tech and collective fund raising, vouch funding, public+private match funding. Early stage, building one step at a time. Tough to get started, but in good company.
+- Thanks to ecommons we have a doc server on outline, thank you to d1 for help with running that on a coop cloud recipe.
+- We're asking for donations for DTF.
+
+### Kollicloud
+[Website](https://kollicloud.de/)
+
+Introducing: Simon, Carla, Moritz from [Local-IT](https://local-it.org)
+
+- Q(w): what is the relationship of Kollicloud to the coop cloud federation
+
+> Simon presenting & talking
+
+- Local-IT is a small non-profit.(35 members, 6 part time). Focused on education and networking events to move orgs away from big tech. Digital Sovereingty and free software for society.
+- Building on Co-Op cloud's amazing infrastructure:
+    - configuration commons + abra tool
+    - not going into details, want to focus on demo w/ alakazam
+    - The deployment process with abra is fairly manual, not a lot is preconfigured.
+    - When I discovered this, focus was less on the federation aspect but the tech aspect. After talks at CCC etc, focused more on how we want to govern/collaborate at Local-IT and DTF. This makes Co-op Cloud distinct form similar projects.
+- KolliCloud is a ready-to-use integrated hosting toolkit for clubs, NGOs and collectives in Germany (no international right now). Bundle of 15 apps + SSO, backups, monitoring so it can be deployed quickly.
+
+#### 3 hosting flavors
+- self-hosting with alakazam. We have guides in german on the kollicloud website. Hope to translate to English soon.
+- Managed hosting: we offer support.
+- Collective hosting approach, intermediate between self and managed hosting. Share not only the integrated config but also the infra. Multiple admins on the same infra, cogoverning multiple instances. More on this later.
+
+#### alakazam
+- core of kollicloud; meta-config layer.
+- Managing 230 apps by hand is not an option (if we wanted to do everything with abra)
+- alakazam's commands help us orchestrate instances on multiple VMs, multiple docker swarm instances per VM.
+- hierarchical yaml configs -> generate env files, with different override for testing/production stages.
+- one secret can be shared between multiple instances
+- batch updates, each coop cloud recipe is checked for upgrades, verify nothing broke in testing, and if nothing breaks push to prod. A month ago we did this with our 230 apps.
+
+#### Configuration hierarchy:
+- defaults set, with default app settings grouped by domain.
+- We have defaults for subdomains of our apps
+- ovverrides as you move deeper into the hierarchy; the closer the config is to the instance, the higher prio.
+- a lot of configs depend on app combinations, e.g. authentik (SSO+ident) with nextcloud - alakzam knows what to enable in the authentik and nextcloud env files to make them work together.
+- We want to move these combinations out of global, to per-recipe.
+
+#### Demo, deploying an instance:
+- File structure: 
+    - usually we have one file that specifies backup+monitoring+traffic, named after the vm.
+    - we then have 1 file per instance on that vm, which specifies apps to deploy. Usually, it's enough to name the app, don't need to specify custom configs. Ongoing work: feature packs.
+- alakazam command, layered:
+`alakazam group_dir/server_dir/instance.yml <command>`
+> running config command
+> running secret command
+
+- I commented out the part of the secrets code which prints secrets, for privacy
+- w: time for murphy's law
+- after waiting a minute, error printed in `alakazam.py` (known issue), just rerun secrets.
+> running deploy command
+- deploy dumps all the abra commands in stdout
+- w: a lot of magic happening :)
+> S continues talking while we wait for deployment
+- half a year ago, had a discussion in the coop cloud channel: "the future is not self-hosted". For most people, sh is too difficult, it's only an option for a tech niche. We need a way for everyone to use the tech, not just those who can provide their own software for themselves. Co-op cloud solves a lot of this, because shared recipes are convenient. One of the first things I do when I want to try out new software is I search for a coop cloud recipe; makes it very easy. The next step at KolliCloud is to integrate it with backups, monitoring, defaults.
+
+- When I was using abra, I procrastinated on SSO, and every time I tried it was problematic. KolliCloud is a lot more convenient, because you don't have to think where what secret goes etc.
+- w: demo deployment is up, just opened it https://login.dtf.dev.kolli.cloud/
+> returning to demo
+- s: alakazam deploy won't try to deploy what's already deployed.
+- w: not working on my side
+    - s: right, we need to run a few more commands
+    - w: we're actually short on time, maybe we can move to questions?
+
+### Questions
+- Q(w): what orgs are using kolli cloud?
+    - [Lambda Bundesverband](https://lambda-online.de/) - germany's largest queer youth org. We host their IT tools, next cloud and stuff. We also host a queer support tool, which allows queer people to get in contact with them. This is integrated in the backend with Zammad via Matrix/Element and Signal-Bridge. So people who respond to questions are replying in matrix chat.
+        - Valentin provides them with computers+preinstalled software, tightly integrated with kollicloud, we're providing hosting.
+- Q(w): how large are these groups?
+    - s: 100+ users, not sure how many active at once. But this is more than we aim for. We usually aim for up to 100.
+    - Moritz: we also have a voluteer fire brigade.
+- Q(w): why only associations and clubs? This tooling could be useful in other types of orgs.
+    - M: Local-IT is an association; easier to provide tools for usecases similar to our own. We also have funding that supports associations in Germany, that's why our main focus is on associations.
+    - M: for commercial orgs, we have to check/vet if we can stand behind it. So we're open to providing for commercial orgs, but only aligned with our values. There are a lot of associations in Germany.
+- w: Thank you Simon for your presentation! Switching off recording now.
+- Q(d1): Love the "where actual work sits" slide - progression from coop cloud to kollicloud. I want to hear about the economic side. We know the economics of hosting are shit; we're approaching the most underfunded parts of society and asking them to pay us for something they get 'for free'. How can we make this sustainable in the long term? Interested in the mutualization of labor, shared admin layer. Does that come in to the economics of this?
+    - S: Mostly funding from various sources; calculated we need like 500 instances to pay 2-3 part-time jobs.
+    - S: on shared admin, we need to work on this more. The idea is set - a couple people have admin rights+ssh keys on a server with e.g. 7 VMs. Admins can then assist each other, like "I'm going on holiday; please help if my community's infra breaks". A lot of people are engaged in communities; if each has a cloud like ours then a federated cloud might not be so far away.
+    - d1: seems that our ideas are leading to this point on the horizon.
+- Q(Graham): Interested in that economics question, but also interested in how robust the stack is. It's not a mainstream tech stack, for all of it. How might this apply to small businesses, small cooperatives? It needs to be rock solid if someone runs a business on this.
+    - S: Main reasons we're not targetting small businesses is our own availability. If something goes down, we can't address it in minutes/hours. This expectation is less for associations.
+    - S: I think this stack is quite stable. Most problems arise when the FOSS we use becomes unavailable because of premiumizing. E.g. software makes SSO premium and we have to ask if we have backup options or if we need to spend money on licenses.
+    - M: the stack is quite stable; biggest problems arise from software. Some of what we deploy is maintained a single person in their spare time, so there are bugs/instabilities in the software itself.
+    - M: updates can break a lot of stuff, which is why we test for two weeks on our own servers first before we deploy for production for all the associations. Testing updates is the biggest factor in stability. But there are still bugs we can do nothing about. When we have important security patches, we need to deploy updates even with bugs. You probably know these problems if you self-host open source software.
+- w: Proposal: could you keep this demo deployed so everyone can have a look?
+- Q(mikemh): across all the accounts you operate; are there patterns emerging with the apps or configs people are using? Can you have an expectation of what people will need?
+    - S, M: that's what we're doing with the default configs. We expect most users want to deploy with these configs. We learn from our users and put that into our defaults.
+- Q(w): what if we want to add a new app, that's not in kollicloud? Is that a lot of work? How do you go about that in contact with the co-cop cloud federation?
+    - S: I have a slide for this!
+    - S: Not a lot of work. But you need a well-maintained CC recipe (needs to run).
+    - S: If we need it to integrate we add it to combine.yml.
+    - S: If we want to specify defaults we put them in the kolli-config repo, based on the diff of the config compared to CC's default.
+
+> Demo finishes deploying, it works!
+
+- w: beautiful dashboard with powerdul applications. You're offering a powerful methodology for collaboration. Really promising.
+    -S: thank you! Wanted to show more, but ran out of time.
+- Q(w): how long will you keep this demo site open?
+    - M: for the next few hours.
+    - M: we have other demo instances; you can ask us for credentials :)
+    - w: please post those in the matrix channels!
+- w: another world is possible; you are doing it!
@@ -1,39 +0,0 @@
---
-title: Organisers
---
-
-Welcome to the organisers guide! Organisers are folks who focus on the social work in the project. Speaking for the project at talks, helping new tech co-ops & collectives join, keeping an eye out for funding opportunities, seeing what things come up in the community chats, etc. It's important work.
-
-<div class="grid cards" markdown>
-
- __Organisers Handbook__
-
-    One-stop shop for all you need to know to organise in the community :sparkles:
-
-    [Read Handbook](/federation/handbook){ .md-button .md-button--primary }
-
- __Say Hello First__
-
-    If you like what you see, but are not sure how to best contribute :speech_left:
-
-    [Get In Touch](/get-involved/){ .md-button .md-button--primary }
-
-</div>
-
-We're still working out what it looks like to do this kind of work in the project. If you like the idea of this kinda of work and/or are already doing it, please send patches to improve this documentation :rocket:
-
-## Kite Flying Hours
-
-The "Kite Flying Hour" is a weekly public moment where anyone can "drop by" into a Jitsi call and ask/do/propose whatever and meet some people who are currently working on the project. We haven't worked it all out but our process for now is the following.
-
-Someone from Autonomic will volunteer to be present and talk about the project for an hour weekly, alternating between 12 and 19 UTC each week. We announce the hour via our socials: A [pinned toot](https://social.coop/@coopcloud/113555815289767778) on [`@coopcloud@social.coop`](https://social.coop/@coopcloud) and a post to the `#coopcloud:autonomic.zone` room.
-
-Here is some invitation boilerplate which you can use:
-
-> Hey folks, you're all warmly invited to the Co-op Cloud Kite Flying Hour at `$X_TIME` `$Y_TZ` `$Z_DATE` over in [vs.autistici.org/CoopCloudKiteFlyingHour](https://vs.autistici.org/CoopCloudKiteFlyingHour)!
->
-> Inspired by exquisite childhood memories of [flying kites, eating popsicles and looking at clouds](https://norwichhistory.org/norwich-a-z-j-is-for-jigsaw/), it's an open hour to come hang out online and discuss/co-work/lurk/etc. around the [Co-op Cloud](https://coopcloud.tech/) project.
->
-> There are no "stupid questions"! It's a space to inquire, be curious and have a good time and get to know each other.
->
-> We take notes and doodle on [this collaboratively editable pad](https://pad.autonomic.zone/VtyrLUl9RWaJGgEDrncQUw). If you don't have time to attend, feel free to drop your questions and some contact details also, so we can get in touch. This is only the first Kite Flying Hour in a recurring series of Kite Flying Hours.
@@ -1,5 +1,5 @@
 ---
-title: The Co-op Cloud Federation Proposal
+title: CCF
 ---

 # The Co-op Cloud Federation Proposal
@@ -0,0 +1,16 @@
+# resolution 045: automatic membership pause
+
+topic: automatic membership pause
+date: 2026-09-03
+deadline: 2026-09-17
+size: large
+
+## Problem
+
+According to [Resolution 001](https://docs.coopcloud.tech/federation/resolutions/passed/001/) a Large decision requires "more than 50% of total number of federation members 👍 votes". This works well as long as enough members are active. But as with every organisation it is normal that that some members become inactive at some point.
+
+## Resolution
+
+If a member does not give a vote for the last 3 resolutions its membership will be paused automatically. Paused memberships are not counted in the total 👍 votes required for a large resolution. The membership gets active again once they give their next vote. If a member sees that another member is inactive they can update their status on the website. If a member status was inactive for one year its membership is automatically canceled.
+
+Members that have their voting rights waived are excluded from the automatic membership pause.
@@ -0,0 +1,18 @@
+---
+title: "Resolution 046: 3wc to join the federation as an individual member"
+---
+
+- Topic: Resolution 046: 3wc to join the federation as an individual member
+- Date: 2026-09-30
+- Deadline: 2026-10-15
+- Size: large
+
+## Summary
+
+3wc to join the federation as an individual member
+
+## Details
+
+@3wc:autonomic.zone is an active member of our community and supports with some of the ongoing work. they were a member of one of our cooperative members (autonomic) but they are no longer part of the cooperative but would like to stay in the cooperative as an individual member.
+
+@ammaratef45:matrix.org from [RTM](https://resisttechmonopolies.online/) is happy to vouch.
@@ -0,0 +1,33 @@
+---
+title: "Resolution 046: Restore servers.coop as a Coop Cloud project"
+---
+
+- Topic: Restore servers.coop as a Coop Cloud project
+- Date: 2026-10-13
+- Deadline: 2026-10-27
+- Size: medium
+
+### History
+
+[servers.coop](https://servers.coop) was launched as a project of Coop Cloud, intended to cooperatise lower down the stack than the abra toolshed. Similarly to how abra gives small cooperatives the tools to easily and collaboratively deploy services on a cloud, servers.coop is meant to support small cooperatives in deploying VPSs on hardware owned or managed by them.
+
+The project was left on the backburner for some years. Recently, we were motivated by rising data center costs and concerns about digital sovereignty to start working on the project again. A working group of four-ish people from the Coop Cloud community is currently working on defining and deploying an MVP.
+
+Servers.coop goals are closely aligned with those of Coop Cloud as a whole, but its usecases and userbase may end up diverging from those of abra. In the long term, servers.coop ought to become an independent collective, with its own governance, membership, budget, and infrastructure - similarly to how Coop Cloud grew from an Autonomic project into a distinct federation. In the short term, servers.coop needs the support of the Coop Cloud federation.
+
+### Proposal
+
+Formally, we treat servers.coop as a project of the Coop cloud federation.
+
+This grants the servers.coop project access to Coop Cloud's resources. For instance:
+
+- Coop Cloud server infrastructure can be used to organize and manage the project, including:
+   - conferencing or notetaking services provided by members for Coop Cloud use
+   - git.coopcloud.tech
+   - build.coopcloud.tech
+   - the servers.coop domain and subdomains
+- Grants written on behalf of Coop Cloud can include servers.coop in their goals and budget.
+- Coop Cloud federation members can propose and vote on resolutions regarding servers.coop governance, infrastructure, and budget.
+- Coop Cloud budget can be allocated to servers.coop goals, through resolutions.
+
+This support is intended to be temporary. Over the course of several years, the group working on/with servers.coop ought to move its resources onto dedicated instances and establish its own structure of governance and financing. When this happens, a new resolution should be passed to formally establish the new collective and change how Coop Cloud participates in the project.
@@ -0,0 +1,35 @@
+---
+title: "Resolution 039: Amras Ciaszczyk to join the federation as a member"
+---
+
+- Topic: Resolution 039: Amras Ciaszczyk to join the federation as a member
+- Date: 12-05-2026
+- Deadline: 26-05-2026
+- Size: large
+
+## Summary
+
+Amras maintains one of our recipes and facilitates half of kite-flying sessions, their membership will allow participation in the decision making and mutual accountability.
+
+## Details
+
+In Amras' own words:
+
+
+> I started using abra a few years ago, when I needed a stack to
+host services for my polycule. Last year, I talked with d1 at CCC and
+became more involved in the community. Since then, I've taken on
+facilitating the 12 UTC Kite Flying sessions and assigned myself as the
+mumble recipe's maintainer.
+
+> I'm also in the process of starting a small hosting, advice, and
+services provider under community-first and sustainability principles.
+
+> I'm already active in the Co-op Cloud community and on the periphery of
+a few organizing discussions. I'd like to formalize my role and become a
+bona fide member. My main motivation is to submit and vote on proposals
+related to the tasks I'm performing.
+
+@ammaratef45:matrix.org from [RTM](https://resisttechmonopolies.online/) is happy to vouch!
+
+To talk to Amras they are @amras0000:matrix.org and can be emailed at r039@joinmeonmy.quest
@@ -0,0 +1,20 @@
+# resolution 040: a collective member provides loomio instead of dues
+
+topic: a collective member provides loomio instead of dues
+date: 2026-05-28
+deadline: 2026-06-04
+size: large
+
+## problem
+using matrix emojis for voting has several issues:
+- it's hard to retain records of voting
+- easy double counting since collectives can have multiple delegates
+- matrix clients vary in how bad they are with seeing reactions
+
+## resolution
+[loomio](https://www.loomio.com/) has been suggested and regarded as a good alternative for voting. We have a [recipe](https://git.coopcloud.tech/coop-cloud/loomio/) for it and it's maintained by members of [rtm](https://resisttechmonopolies.online/).
+
+
+I propose a) we migrate to using loomio for voting without a change to voting rules.
+
+in the spirit of mutual aid, self-reliance, and cooperativism, I also propose b) we hire a federation member to self-host and manage the loomio instance for us with the option to waive their dues in exchange.
@@ -0,0 +1,38 @@
+---
+title: "Resolution 041: Budget 017: Website development"
+---
+
+- Topic: Budget 017: Website development
+- Date: 2026-06-02
+- Deadline: 2026-06-15
+- Size: Large
+
+## Description
+
+Budget 017 proposes to compensate [Sutty](https://sutty.coop.ar/en/) for
+the new Co-op Cloud website development, according to the user
+experience research process from [Resolution
+035](/federation/resolutions/passed/035/) for the total amount of 3500
+EUR, paid in 3 installments.
+
+The budget will cover the website development of the [prototype that was
+the result of the UX
+research](https://nube.yanapak.abyaya.la/s/eM8AMbACNbEm3qY).
+
+Please see [the full proposal
+text](https://vvvvvvaria.org/~decentral1se/cc/CoopCloud-2025WebsiteProposal-Sutty.pdf)
+for all details.
+
+As per previous communications, there is around 4000 to 5000 EUR
+destined to website development, out of which we're budgeting 3500 EUR
+for website development.  The reminder of the budget is reserved for new
+features or maintenance (ie. recipes, SSO, etc.)
+
+## Budget
+
+The budget total is:
+
+* 1250 EUR at start.
+* 1250 EUR after the first month.
+* 1000 EUR at final delivery.
+* **3500 EUR total.**
@@ -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.
@@ -0,0 +1,23 @@
+---
+title: "Resolution 043: eCommons to join the federation as a member"
+---
+
+- Topic: Resolution 043: eCommons to join the federation as a member
+- Date: 2026-08-04
+- Deadline: 2026-08-18
+- Size: large
+
+## Summary
+
+[eCommons](https://ecommons.space/en) runs multiple Co-op Cloud recipes for several commons-based organisations in the Netherlands, uses Alakazam to manage their instances, and has contributed to various recipes.
+
+## Details
+
+At eCommons we build and operate shared digital infrastructure for our commons-based member organisations in the Netherlands: cooperative housing groups, food co-ops, and similar communities that want to keep their data, collaboration, and tools in their own hands. We use Co-op Cloud to run and manage these instances across our members, and use Alakazam to operate our growing set of apps.
+
+Along the way we've contributed to several recipes we depend on. Co-op Cloud's federated model, tooling maintained collectively by the co-ops that use it, matches how we think infrastructure should be built and sustained. And we'd like to formalize our participation in the federation.
+
+@fauno:sutty.nl from Red Abya Yala is happy to vouch for us.
+
+eCommons' representative to the federation will be Danny. He can be reached at
+`@dannygroenewegen:matrix.org` on Matrix or `danny@ecommons.nl` by email.
@@ -0,0 +1,26 @@
+---
+title: "Resolution 044: CoQuest to join the federation as a member"
+---
+
+- Topic: Resolution 044: CoQuest to join the federation as a member
+- Date: 2026-08-19
+- Deadline: 2026-09-02
+- Size: large
+
+## Summary
+
+*CoQuest - IT Coop Stuttgart* offers hosting with co-op cloud for paid customers from the non-profit and coop sector. It acts as co-maintainer for several recipes and does abra development.
+
+## Details
+
+CoQuest already hosts services for several customers and plans to extend their hosting services in the future:
+
+> We welcome clients and partners who share our values and work with us towards a more just, solidary, and sustainable world. We are especially keen to cooperate with worker-owned enterprises, cooperatives, non-profit associations, and initiatives of the community supported economy, as well as works councils and trade unions. Together we want to realize projects in culture, education, social welfare, and ecology.
+
+More information at [coquest.coop](https://coquest.coop)
+
+Some of CoQuest's members are also active at Klasse & Methode and therefore Klasse & Methode vouches for CoQuest.
+CoQuest will waive it's voting rights in the federation.
+
+CoQuest's representative to the federation will be p4u1. He can be reached at
+`@p4u1_f4u1:matrix.org` on Matrix or `member@coquest.coop` by email.
@@ -0,0 +1,28 @@
+---
+title: "Resolution 047: Kolektivo Sennacieca Cifereca to join the federation as a member"
+---
+
+- Topic: Resolution 047: Kolektivo Sennacieca Cifereca to join the federation as a member
+- Date: 2026-10-06
+- Deadline: 2026-10-20
+- Size: large
+
+## Summary
+
+[Kolektivo Sennacieca Cifereca](https://www.sekuro.nl) is a security and organizational consultancy responsible for the proof of concept  [Hestia](https://git.coopcloud.tech/hex/hestia) build quality and security analyzer and [CCSATool](https://git.coopcloud.tech/hex/CCSATool) security advisory tool. KSC is focused on the improving the security of the platform. 
+
+## Details
+
+At Kolektivo Sennacieca Cifereca we provide security consulting, security reviews, security program guidance, and penetration testing services. We would like to use and recommend services provided by Co-op Cloud member organizations, and thus have a vested interest in driving security improvements within the federation.
+
+We have worked closely with eCommons, providing security guidance and identifying opportunities for improvement at the federation level (recipe scanning via Hestia, and security advisory announcement via CCSATool).
+
+We agree with eCommon's assessment:
+
+> Co-op Cloud's federated model, tooling maintained collectively by the co-ops that use it, matches how we think infrastructure should be built and sustained. 
+
+Further, we believe that distributed systems may present additional challenges related to pushing forward security initiatives, but they provide increased resilience against state-level threat actors with the goal of shutting down infrastructure by geographical region or ideological alignment. 
+
+@dannygroenewegen:matrix.org from eCommons has agreed to vouch for this organization. 
+
+Kolektivo Sennacieca Cifereca's representative to the federation will be hex. He can be reached at `@hex:matrix.org` on Matrix or `biz@sekuro.nl` by email.
@@ -0,0 +1,3 @@
+---
+title: Surveys
+---
@@ -0,0 +1,12 @@
+---
+title: Usage Survey (2026)
+---
+
+Federation member `@hex` conducted our first community usage survey in October 2026.
+
+> [...] In the end we had 62% coming from Europe, 31% from North America, 1 from Austrailia, and 1 from South America. 
+85% responded that they maintain recipes, 77% manage services for customers. Almost half added more information on their use cases. 
+The majority of respondents were "small" organizations. 69% were managing services for themselves or for less than 10 customers, while about 1/3 were what might be described as "medium to large" organizations (with 101-1000 customer organizations). I think this presents a really interesting picture of the Federation, with a diverse ecosystems from tiny to large organizations all interacting and cooperating.
+
+Here is a link to all the results: [`results.csv`](/results.csv). Please note,
+all identifying information has been stripped out.
@@ -1,12 +0,0 @@
---
-title: Digital tools
---
-
- [Public documentation](https://docs.coopcloud.tech/federation)
- [Git hosting](https://git.coopcloud.tech/)
- [Matrix Space](https://matrix.to/#/#coop-cloud-space:autonomic.zone)
- [Website](https://coopcloud.tech/)
- [Single Sign On](https://translate.coopcloud.tech/)
- [Translation](https://translate.coopcloud.tech/)
- [Sheets and time tracking](https://sheets.coopcloud.tech/)
- [Drone CI/CD](https://build.coopcloud.tech)
@@ -0,0 +1,3 @@
+---
+title: Digital Tools
+---
@@ -1,7 +1,16 @@
 ---
-title: Shared Infrastructure Inventory
+title: Inventory
 ---

+- [Public documentation](https://docs.coopcloud.tech/federation)
+- [Git hosting](https://git.coopcloud.tech/)
+- [Matrix Space](https://matrix.to/#/#coop-cloud-space:autonomic.zone)
+- [Website](https://coopcloud.tech/)
+- [Single Sign On](https://translate.coopcloud.tech/)
+- [Translation](https://translate.coopcloud.tech/)
+- [Sheets and time tracking](https://sheets.coopcloud.tech/)
+- [Drone CI/CD](https://build.coopcloud.tech)
+
 ## Shared repository for fedi maintainers

 > [coop-cloud-apps](https://git.coopcloud.tech/toolshed/coop-cloud-apps)
@@ -31,4 +31,10 @@ Pick the right medium for your interests.

    [Email Us](mailto:helo@coopcloud.tech){ .md-button .md-button--primary }

+- __Online call__
+
+    Join our weekly(ish) low-pressure drop-in call, "Kite flying"
+
+    [Fly a kite](/intro/kite-flying){ .md-button .md-button--primary }
+
 </div>
@@ -12,7 +12,7 @@ We are happy to have designers, critical thinkers, artists, hackers, documenters

 There are a number of "roles" such as "operator", "maintainer", "organiser" which we've tried to come up with to make it more clear how you can relate to the project and how you can find ways to be involved which suit your interests. If you don't fit one of these roles, that is fine.

-We have [an irregular online check-in](/federation/organisers/#kite-flying-hours) for contributors of this project to let each other know what we're working on, how much time we've spent on it and how to coordinate further work.
+We have [an irregular online check-in](/intro/kite-flying) for contributors of this project to let each other know what we're working on, how much time we've spent on it and how to coordinate further work.

 We have a [status page](/intro/bikemap) showing what we are aiming to achieve in the near future. That gives a good overview of where we're going together.

@@ -0,0 +1,11 @@
+# Kite-flying
+
+The "Kite Flying Hour" is a weekly public moment where anyone can "drop by" into a Jitsi call and ask/do/propose whatever and meet some people who are currently working on the project. 
+
+We meet on Thursdays, alternating between 12 and 19 UTC each week. You can find out when the next call is by adding [our shared calendar](https://coopcloud.tech/ics/kite-flying.ics) to your calendar application, or look out for an announcement via [`@coopcloud@social.coop`](https://social.coop/@coopcloud) and a post to the `#coopcloud:autonomic.zone` room.
+
+Participation in kite-flying can be compensated at €20/hour; see Co-op Cloud Federation [Resolution 024](/federation/resolutions/passed/024) for details.
+
+We take notes and doodle on [this collaboratively editable pad](https://pad.autonomic.zone/VtyrLUl9RWaJGgEDrncQUw?view). If you don't have time to attend, feel free to drop your questions and some contact details also, so we can get in touch. 
+
+To work around Hedgedoc length limits, [we keep past content from the kite-flying pad here](/federation/kite-flying-pad-archive).
@@ -13,5 +13,7 @@ title: Managed hosting
 *Co-op Cloud* is still [beta quality software](https://en.wikipedia.org/wiki/Software_release_life_cycle#Beta) :bomb: but you can still work with a tech co-op or collective to host some part or all of your online digital services with it. Organisations who want to support the project can get in touch with *Co-op Cloud* service providers via the following list for a quote on what they're looking for and how much it will cost. Service providers can then factor in some percentage of the cost to co-fund the development of this project.

 - [Autonomic Co-op](https://autonomic.zone) (contact: [`helo@autonomic.zone`](mailto:boop@autonomic.zone))
- [makeITsocial](https://makeitsocial.net) (managed hosting, see [price calculator](https://makeitsocial.net/kolli-cloud/))
+- [soulhub-IT](https://soulhub-it.de) (managed hosting, see [price calculator](https://soulhub-it.de/produkte/))
 - [Local-IT](https://local-it.org/) ([selfhosting](https://wiki.local-it.org/s/kollicloud-wiki/doc/selfhosting-guide-1xZJt8UIha) & cooperative hosting, contact: [`info@local-it.org`](mailto:info@local-it.org))
+- [eCommons](https://ecommons.nl) (contact: [`info@ecommons.nl`](mailto:info@ecommons.nl))
+- [CoQuest - IT Coop Stuttgart](https://coquest.coop) (managed hosting, contact: [`hello@coquest.coop`](mailto:hello@coquest.coop))
@@ -32,7 +32,16 @@ You can start by reading The Maintainers Proposal: [`R025`](https://docs.coopclo

 It is important that only recipe maintainers have write permissions to the repository. As it currently stands, every member of the [Co-operators Team](https://git.coopcloud.tech/org/coop-cloud/teams/co-operators) has write permissions to all recipe repositories for convenience while we are missing enough maintainers.

-To change this, create a new team on [`git.coopcloud.tech/coop-cloud/teams`](https://git.coopcloud.tech/org/coop-cloud/teams) for your specific recipe, e.g. `mycoolrecipe-maintainers`. Add yourself and any other maintainers and don't forget to add the recipe repository itself on the repositories tab. Remove your recipe repository from the [list of repositories for the Co-operators Team](https://git.coopcloud.tech/org/coop-cloud/teams/co-operators/repositories) so that write permissions are removed.
+To change this:
+
+1. Log into git.coopcloud.tech as an administrator account (e.g. `coopcloud`)
+2. Create a new team on [`git.coopcloud.tech/coop-cloud/teams`](https://git.coopcloud.tech/org/coop-cloud/teams) with the following settings:
+
+    - Name: e.g. `mycoolrecipe-maintainers`
+    - Repository access: Specific repositories
+    - Permission: Administrator access 
+3. Add maintainers as "Team Members" on the "members" tab, and add the recipe repository on the "repositories" tab 
+3. Remove your recipe repository from the [list of repositories for the Co-operators Team](https://git.coopcloud.tech/org/coop-cloud/teams/co-operators/repositories) so that write permissions are removed.

 ### Repository Permissions

@@ -56,7 +56,7 @@ Abra can't deploy any applications in future steps unless it can run `docker` co
 groups | grep docker

 # if the docker group doesn't already exist, add it manually
-groupadd docker
+sudo groupadd docker

 # add user to docker group
 sudo usermod -aG docker $USER
@@ -1,3 +1,8 @@
 ---
 title: Specifications
 ---
+
+We gather all community written specifications here. Specifications are useful
+for coordinating implementation across moving parts and different tools which
+everyone needs to understand. One clear example is how `backup-bot-two` and
+`abra` interact.
@@ -9,7 +9,6 @@ theme:
  features:
      navigation.instant.progress
    - content.action.edit
-    - navigation.expand
    - navigation.indexes
    - navigation.instant
    - navigation.path
@@ -66,6 +65,7 @@ nav:
      - "Inspirations": intro/inspirations.md
      - "Project Status": intro/bikemap.md
      - "Managed Hosting": intro/managed.md
+      - "Kite flying hour": intro/kite-flying.md
      - "Get In Touch": intro/contact.md
      - "Credits": intro/credits.md
      - intro/get-involved.md
@@ -79,25 +79,18 @@ nav:
      - "Packaging Handbook": maintainers/handbook.md
      - maintainers/catalogue.md
  - "Operators":
-      - operators/index.md
      - "New operators Tutorial": operators/tutorial.md
      - "Operators Handbook": operators/handbook.md      
  - "Federation":
      - federation/index.md
-      - federation/handbook.md
-      - federation/organisers.md
-      - federation/kite-flying-pad-archive.md
      - "Bylaws": federation/bylaws.md
      - "Finance": federation/finance.md
      - "Membership": federation/membership.md
-      - "Joining the Co-op Cloud Federation": federation/join.md
+      - "Join the CCF": federation/join.md
      - "Code of Co-operation": federation/code-of-coop.md
-      - "Shared Infrastructure Inventory": federation/infra.md
      - "Proposals":
-        - federation/proposals/index.md
        - federation/proposals/federation.md
      - "Resolutions":
-          - federation/resolutions/index.md
          - "Draft":
              - federation/resolutions/index.md
          - "Passed":
@@ -133,19 +126,28 @@ nav:
              - federation/resolutions/passed/031.md
              - federation/resolutions/passed/033.md
              - federation/resolutions/passed/034.md
+              - federation/resolutions/passed/035.md
              - federation/resolutions/passed/036.md
+              - federation/resolutions/passed/037.md
              - federation/resolutions/passed/038.md
+              - federation/resolutions/passed/039.md
+              - federation/resolutions/passed/041.md
+              - federation/resolutions/passed/040.md
+              - federation/resolutions/passed/042.md
+              - federation/resolutions/passed/043.md
+              - federation/resolutions/passed/044.md
+              - federation/resolutions/passed/047.md
          - "Stalled":
              - federation/resolutions/stalled/013.md
              - federation/resolutions/stalled/030.md
          - "In Progress":
+              - federation/resolutions/in-progress/045.md
+              - federation/resolutions/in-progress/046.md
              - federation/resolutions/index.md
-              - federation/resolutions/in-progress/035.md
-              - federation/resolutions/in-progress/037.md
      - "Minutes":
-          - federation/minutes/index.md
          - "Recently":
              - federation/minutes/2025-12-28.md
+              - federation/minutes/kf-archive.md
          - "Archive":
              - federation/minutes/2024-08-15.md
              - federation/minutes/2024-04-17.md
@@ -153,14 +155,18 @@ nav:
              - federation/minutes/2024-02-01.md
              - federation/minutes/2022-03-03.md
              - federation/minutes/2023-05-03.md
-      - "Digital Tools": federation/tools.md
+      - "Digital Tools":
+          - federation/tools/infra.md
+      - "Surveys":
+          - federation/surveys/usage-2026.md
      - "Funding applications":
-          - federation/funding-applications/index.md
-          - federation/funding-applications/culture-of-solidarity.md
-          - federation/funding-applications/ford-foundation.md
-          - federation/funding-applications/private-funder.md
-          - federation/funding-applications/sovereign-tech-fund.md
-          - federation/funding-applications/user-operated-internet.md
+          - federation/funding/culture-of-solidarity.md
+          - federation/funding/ford-foundation.md
+          - federation/funding/private-funder.md
+          - federation/funding/sovereign-tech-fund.md
+          - federation/funding/user-operated-internet.md
+          - federation/funding/sovereign-tech-fund.md
+          - federation/funding/nlnet-codesupply.md
  - "Abra":
      - abra/index.md
      - "Install": abra/install.md
@@ -175,7 +181,6 @@ nav:
  - "Specifications":
      - specs/index.md
      - "Backups":
-          - specs/backup/index.md
          - specs/backup/maintain.md
          - specs/backup/spec.md

@@ -185,6 +190,7 @@ plugins:
  - redirects:
      redirect_maps:
        "get-involved/support/index.md": intro/support.md
+        "faq.md": intro/faq.md

 repo_name: toolshed/docs.coopcloud.tech
 repo_url: https://git.coopcloud.tech/toolshed/docs.coopcloud.tech/
Author	SHA1	Message	Date
decentral1se	058dfe75de	shorter folder name, hex/nlnet add continuous-integration/drone/push Build is passing Details	2026-10-29 15:44:53 +01:00
decentral1se	37064cf4d2	fix main links continuous-integration/drone/push Build is passing Details	2026-10-29 15:28:35 +01:00
decentral1se	7b0684a7a1	refactor: fedi passthrough continuous-integration/drone/push Build is passing Details	2026-10-29 15:22:56 +01:00
hex	65de9e5656	Adding hex (sekuro.nl/Kolektivo Sennacieca Cifereca) continuous-integration/drone/push Build is passing Details	2026-10-23 11:40:31 +02:00
hex	72f2a7e86d	changed sekuro.nl -> www.sekuro.nl to fix wirdness with my dns provider	2026-10-23 11:30:26 +02:00
hex	7ec47a55c3	fixed missing index	2026-10-23 11:24:18 +02:00
hex	9347c5fd83	Update docs/federation/membership.md	2026-10-23 08:58:34 +00:00
hex	4e5f051eae	added hex and moved the resolution to passed	2026-10-23 10:55:48 +02:00
Amras	7d6e347fad	proposal: formally support servers.coop continuous-integration/drone Build is passing Details With servers.coop building steam, there's a need to secure some resources and organizational support for the project. Proposal has been discussed among the servers.coop working group.	2026-10-13 17:01:18 +02:00
dannygroenewegen	dedbc99d12	Update the date for 047 and move to in-progress continuous-integration/drone/push Build is passing Details	2026-10-07 15:54:30 +02:00
hex	0bf4c61066	fixed typo continuous-integration/drone/push Build is passing Details	2026-10-07 13:06:32 +00:00
hex	e386bc27fa	fixed bad copy pasta	2026-10-07 13:06:32 +00:00
hex	9429ac74b8	added resolution to be added to the coop	2026-10-07 13:06:32 +00:00
maren	cf7bf24b31	Update membership list (#332 ) continuous-integration/drone/push Build is passing Details Reviewed-on: #332 Reviewed-by: p4u1 <133+p4u1@noreply.git.coopcloud.tech> Co-authored-by: maren <maren@bunk.computer>	2026-10-05 19:32:30 +00:00
ammaratef45	755536aaef	res 46 continuous-integration/drone/push Build is passing Details	2026-09-30 11:24:56 -07:00
Amras	4886512e16	[fix] markdown on draft resolution 046 continuous-integration/drone/push Build is passing Details Fixed slight formatting issues, which caused the resolution to render incorrectly.	2026-09-29 12:31:07 +02:00
Amras	5bc037aa84	draft proposal: formally support servers.coop continuous-integration/drone/push Build is passing Details With servers.coop building steam, there's a need to secure some resources and organizational support for the project. This proposal is listed as a draft, so that both federation members and the working group around servers.coop can provide comments before it's brought to a vote.	2026-09-29 12:14:44 +02:00
stevensting	bbb7c6347b	added dues information continuous-integration/drone/push Build is passing Details	2026-09-15 12:17:34 +02:00
stevensting	2399092150	Add CoQuest to managed hosting section continuous-integration/drone/push Build is passing Details	2026-09-15 12:03:05 +02:00
oxaliq	468188c088	fix broken link on intro/kite-flying continuous-integration/drone/push Build is passing Details	2026-09-14 10:29:16 -04:00
oxaliq	27d1941e44	clarify membership dues payment instructions continuous-integration/drone/push Build is passing Details	2026-09-10 16:35:15 +00:00
oxaliq	c61f8ac550	remove outdated wise instructions	2026-09-10 16:35:15 +00:00
oxaliq	8a7f0f08ca	simplify description of fiscal host	2026-09-10 16:35:15 +00:00
oxaliq	b81069a85e	edit budget section to include current budgets	2026-09-10 16:35:15 +00:00
devydave	47ff902c8a	fix: formatting continuous-integration/drone/push Build is passing Details	2026-09-10 16:34:15 +00:00
devydave	49b13faade	docs: nixos install example	2026-09-10 16:34:15 +00:00
dannygroenewegen	ca01c39132	Add eCommons to memberlist continuous-integration/drone/push Build is failing Details	2026-09-09 20:23:44 +02:00
maren	e8d36bcca5	Update docs/federation/membership.md continuous-integration/drone/push Build is passing Details	2026-09-08 19:05:01 +00:00
maren	5774f73689	Add Bunk Computer Cooperative and alphabetize the list	2026-09-08 18:15:30 +00:00
3wordchant	b5f27f82e1	Redirect /faq → /intro/faq, and fix link in UOI fund application continuous-integration/drone/push Build is passing Details	2026-09-05 13:35:54 -04:00
3wordchant	42bc380c8c	Slurp up the latest pad content for archival continuous-integration/drone/push Build is passing Details	2026-09-03 15:15:09 -04:00
p4u1	63b66ad469	resolution 045: add exception continuous-integration/drone/push Build is passing Details	2026-09-03 20:12:06 +02:00
p4u1	bc8885372f	add resolution 045 continuous-integration/drone/push Build is passing Details	2026-09-03 19:28:12 +02:00
p4u1	279b69da7f	resolution 044 has passed continuous-integration/drone/push Build is passing Details	2026-09-03 19:07:01 +02:00
fauno	c8c4cdd9b5	fix: 043 has passed continuous-integration/drone/push Build is passing Details	2026-08-19 10:17:01 -03:00
fauno	b50ea43924	Merge branch 'main' of https://git.coopcloud.tech/coop-cloud/docs.coopcloud.tech	2026-08-19 10:16:08 -03:00
stevensting	bc239a2867	fix dates of resolution continuous-integration/drone/push Build is passing Details	2026-08-19 13:51:43 +02:00
stevensting	2b3e1a9376	add resolution to menu continuous-integration/drone/push Build is passing Details	2026-08-19 13:01:41 +02:00
stevensting	9d18d3c2a1	add resolution for CoQuest as federation member continuous-integration/drone/push Build is passing Details	2026-08-19 12:15:50 +02:00
simon	1e812ce6a7	replace mITs hosting with soulhub-IT (#325 ) continuous-integration/drone/push Build is passing Details As we switched offering the managed hosting of KolliCloud from makeITsocial to soulhub, I propose updating the docs accordingly. :) Reviewed-on: #325 Co-authored-by: simon <135+simon@noreply.git.coopcloud.tech>	2026-08-18 14:26:17 +00:00
ammaratef45	bf36054516	res 40 and 42 passed continuous-integration/drone/push Build is passing Details	2026-08-10 11:06:54 -07:00
fauno	95c254b02b	fix: added link to website	2026-08-04 12:00:34 -03:00
fauno	d26bcb5129	fix: move to today continuous-integration/drone/push Build is passing Details	2026-08-04 09:13:53 -03:00
dannygroenewegen	beaab9b7b9	Add resolution 043: eCommons to join the federation as a member continuous-integration/drone/push Build is passing Details	2026-08-04 10:14:11 +02:00
ammaratef45	88e1cde12c	add proposal 42 continuous-integration/drone/push Build is passing Details	2026-06-18 13:49:12 -07:00
fauno	de5d1ee7d2	Merge branch 'main' of https://git.coopcloud.tech/coop-cloud/docs.coopcloud.tech continuous-integration/drone/push Build is passing Details	2026-06-16 11:38:10 -03:00
fauno	74dece6876	fix: resolution 041 passed with 9 out of 16 votes	2026-06-16 11:37:33 -03:00
3wordchant	b514dd5071	Show the money continuous-integration/drone/push Build is passing Details	2026-06-12 07:44:44 +00:00
3wordchant	940dc50599	Cross-link new KF page from get-involved	2026-06-12 07:44:44 +00:00
3wordchant	db93530f5c	Combine, trim, and update kite-flying content	2026-06-12 07:44:44 +00:00
maren	87b84dd891	Introduce resolution for Bunk to join the federation continuous-integration/drone/push Build is passing Details	2026-06-12 04:54:12 +00:00
Amras	b5e05001aa	[minutes] Kollicloud Demo continuous-integration/drone/push Build is passing Details	2026-06-10 09:47:32 +00:00
Amras	17d37eefac	Adding Amras to the list of members continuous-integration/drone/push Build is passing Details Including email as the most reliable way to reach me; I'll add a website when that's running again.	2026-06-10 09:47:11 +00:00
vagnretur	e1c9501778	Fix link to Get In Touch page from Organisers continuous-integration/drone/push Build is passing Details	2026-06-10 09:46:40 +00:00
fauno	7d14f1e059	fix: resolution dates continuous-integration/drone/push Build is passing Details	2026-06-02 17:19:28 -03:00
fauno	377110fb43	fix: link to prototype continuous-integration/drone/push Build is passing Details	2026-06-02 17:13:12 -03:00
fauno	90bd074ded	fix: context and payments	2026-06-02 16:49:10 -03:00
fauno	a8002265d9	feat: budget 017	2026-06-01 14:06:36 -03:00
ammaratef45	e2aae57336	mark res39 complete, introduce res40 continuous-integration/drone/push Build is passing Details	2026-05-29 04:48:04 +00:00
3wordchant	9b7b3a260d	docs: More kiteflying archive continuous-integration/drone/push Build is passing Details	2026-05-28 15:48:02 -04:00
amras	a7a0fa25f9	Merge pull request 'resolution 039: Amras joins the federation' (#314 ) from amras-proposal into main continuous-integration/drone/push Build is passing Details	2026-05-17 05:03:46 +00:00
ammaratef45	c639c20d73	Merge branch 'main' into amras-proposal	2026-05-16 19:06:18 -07:00
ammaratef45	668b254808	resolution 039: Amras joins the federation	2026-05-16 19:02:36 -07:00
decentral1se	1f0fb6d68a	docs: status continuous-integration/drone/push Build is passing Details	2026-05-15 08:51:59 +00:00
mayel	72b1c34b5a	Merge pull request 'Update docs/federation/membership.md' (#2 ) from mayel-patch-2 into main continuous-integration/drone/push Build is passing Details Reviewed-on: mayel/docs.coopcloud.tech#2	2026-05-06 12:04:50 +00:00
mayel	eec8fa65ee	Merge pull request 'Update docs/federation/kite-flying-pad-archive.md' (#3 ) from mayel-patch-3 into main Reviewed-on: mayel/docs.coopcloud.tech#3	2026-05-06 12:04:37 +00:00
mayel	48f5f81466	Merge pull request 'Update docs/federation/organisers.md' (#4 ) from mayel-patch-4 into main Reviewed-on: mayel/docs.coopcloud.tech#4	2026-05-06 12:04:32 +00:00
mayel	e54ec4b121	Merge branch 'main' into mayel-patch-4	2026-05-06 12:04:23 +00:00
mayel	ab65f6bed7	Merge pull request 'add sudo in front of `group add`' (#1 ) from mayel-patch-1 into main Reviewed-on: mayel/docs.coopcloud.tech#1	2026-05-06 10:18:15 +00:00
mayel	51e9145b96	Update docs/federation/organisers.md	2026-05-06 10:15:53 +00:00
mayel	adc7a33151	Update docs/federation/kite-flying-pad-archive.md	2026-05-06 10:13:44 +00:00
mayel	aa553414d7	Update docs/federation/membership.md	2026-05-06 10:07:57 +00:00
decentral1se	b6014385fe	fix: mv 35/37 also continuous-integration/drone/push Build is passing Details	2026-04-27 21:54:44 +02:00
fauno	3522296492	fix: resolution 035 has passed continuous-integration/drone/push Build is failing Details	2026-04-27 19:54:07 +00:00
fauno	b3e954c695	fix: resolution 037 has passed continuous-integration/drone/push Build is passing Details	2026-04-27 19:54:00 +00:00
3wordchant	40a8d25257	Add more detail to gitea team setup continuous-integration/drone/push Build is passing Details	2026-04-27 18:12:07 +00:00
mayel	807370bdd7	add sudo in front of `group add` otherwise fails in some scenarios	2025-10-01 15:33:34 +00:00