From https://pad.autonomic.zone/VtyrLUl9RWaJGgEDrncQUw?edit#

Next kite flying (open community meeting)

Schedule (ICS link) (subscribe in your calendar app)

2026-08-27, 12 UTC

Attending: Jade (they/he), hex (he/him), Sarma (they/them), muris, papiris

Intros: - J: portugal at team retreat, but have a cold - h: - p: norway had the sun for the third day this summer. Spent the night in a common house (which used to be a lord's house) where the doors are never locked and anyone can use it. Fed up with k8s. Gonna migrate to abra. - S: low energy, but that should improve during the meeitng - m: listening in - I'm Murilo, I'm from the land of Tupi-Guaranis people (also known as South East Brazil) and I currently live in Stockholm! I'm here because I'm a full stack developer/creative technologist, I do a lot of sysadmin and would like to get closer to tech cooperatives as it seems aligned with what I want to do with my life 😃

Topics: - security related stuff - high availability distributed clusters - K8s/abra - US anarchist blogging platform designated as terrorist orgs, people looking for alt hosting.

Minutes: - h: short intro to noblogs - noblogs is a host based in italy - people with riseup accounts can use them - treasury is trying to freeze financial transfers, imprison people who give donations - connection with KKK - some anarchist groups trying to move to wordpress. Smaller hosts, distributed. - h: if you're looking for clients, advertising on mastodon might be a good idea. - Q(S): do we have US-based members? - h: it'd be nice to have a tool to find coopcloud hosting based on location. - J: noblogs is running by the Autistici Inventati collective. If we step up to provide servers, this might help get around blocking - but will that cut income streams to the collective? Anything we should do in solidarity with them? US sanctions tend to affect global payment (Visa, Mastercard, etc) so they might be affected. - J: can we do mirroring, to prevent noblogs from being blocked? - h: the service is free, so moving people off the sites won't harm them. Giving them money might be good. - h: If other collectives pick up this work - there's a risk the US govt could target a different provider.

• S: maybe we could suggest the location-based member search to the new website?
  • h: https://docs.coopcloud.tech/intro/managed/ and https://docs.coopcloud.tech/federation/membership/ have information, so at minimum we could link to these.

• h: The anarchist book fare shared A list of hosts.

  • h: These people generally aren't paying for hosting, but they might be willing to pay.
  • p: Patio is another federation of tech co-ops, would be good to contact them: https://patio.coop/

• Q(S): how much time/resources do you have, hex? Can you coordinate this?

  • h: I have a bit of time. Getting radical collectives to use coop cloud might be a good strategy, but it would increase the security profile - gaps we'd need to close.
  • S: cool, sounds like you're the perfect person for the job <3

• p: I'm in a group that hosts on noblogs, but not in the US. I'm not sure if this affects us, but we'll be making sure we have backups.

• h: not sure how the US decision will impact AI's finances, getting people outside the US to donate money would be good.

---

• p: frustrated about k8s. Moving off of it would be a case of deploying some apps and restoring databases into the new deployments. Might take time to replicate the infra I have. I'd like to give it a go and discuss in future.
• S: when I tried migrating an existing system onto coop cloud, Only spent half an hour, but didn't want to move nginx into traefik. Would be worth asking if you have other apps that you'd need to switch out.

---

• h: wrote some scripts to go through each recipe, read each image mentioned, and running a vuln analyzer - to produce an SBOM. Some recipes should probably be delisted because of vulns. In total, found ~30 000 CVEs, of those 3000 critical. Because a lot of these require you to have local access, the real vulnerability count is probably pretty low - 10 or so.
• h: softsonic(?) has been running LLMs to do a similar kind of check. Given the scope of our problem and amount of data, we may want to use an LLM to flag high level patterns.
• h: additional layers of problems.
• h: Let's say we flag all vulns, upgrade recipes - there's no communication channel to tell everyone to upgrade their services. Matrix's General chat is not sufficient. Operators not reading matrix won't find out about them.

• h: supply chain attacks which can't be fixed by upgrades - need a way to tell people about those.

• h: we should have an automated scanner, a manual process to filter CVEs, a way to tell people about CVEs, and a way to get people to quickly upgrade: we need the upgrade process to be easy and not break everything.

• h: I know there are vulns that are not listed, and many won't be scannable. Not sure how to address those yet, open question.

• J: I feel nerd sniped. Want to dive in and fix them all, but already have priorities.

• J: So, we have difficulties getting information to maintainers and to operators; different problems. As a maintainer, I'd enjoy if I could be easily informed about that. Maybe a dashboard. We don't want to announce our vulns publically, ideally an internal vulnerability dashboard.
• Q(J): Could merribek pay a collective each month to provide tooling around specifically our recipes? Don't know if we can pay enough to be useful, but could pool resources.
  • J: alternately, we have a security expert who could join a working group.
• J: in lores, we're not a tech cooperative; we're a tech commons. Our server operators are beginners. Each local server has ~2 stewards whom we've taught linux. So we want big flashing alerts for these people. We're thinking of doing this on the lores node app; but it'd be better to have it on a separate/dedicated monitoring app.
  • J: monitoring apps should probably install something not in docker, to have OS access.
  • J: eventually, I'd like the stewards to also be informed about OS security upgrades etc.
• h: We need an easy way to contact maintainers directly. We don't want vulns to be out there. If we don't have a fix, we need a backchannel way to communicate that. Pipeline: vuln data collection->identification->vuln management. We need a point of contact which isn't broadcast, a closed/security communication path.
  • h: some stuff is going to be public anyway; everyone knows wordpress is vulnerable. I'd lean more to moving fast than to restricting access to information.
• h: getting every operator to update - should be public. Suggest an RSS feed, other announcement systems exist. Each vendor (redhat etc) has a feed like this, with clear security announcements and instructions. We should have that channel, too.

• h: endpoint monitoring is another issue, but low on time

• Q(S): Would it be enough to DM maintainers based on README contacts?

  • h: this information should be accessible by automated tools, like in the recipe json.

• Q(S): do we want abra to print warnings? Like, any time you call an abra command it prints existing vulns?

  • h: yes!
  • Q(S): is this a 'critical fix'?
    • h: no, we need detection first before this makes sense.

• h: for financing - it'd be good to have a security federation within the coop cloud federation, so some members can work on

---

Checkouts: - S: thanks hex for sharing your expertise! It's fascinating to listen to. For future KFs, I know calix is planning some beginner courses and comparing coop cloud to other similar projects. - h: thanks for letting me dump a bunch of stuff. Want to follow up on these security topics. - J: feeling buoyed. These talks always feel awkward/slow at the start, but really good at the end. These topics will be very distrcting for me, lots to think about. Busy with lores. Might find some people to nerdsnipe. In a 2 week work retreat for an offline-first messenger. Will be doing bug fixing in a nice locaiton in Portugal. - p: thanks for facilitating & notes <3 Always impressed with how Sarma manages to write while holding a conversation. Topics really interesting. I like finding out what's happening outside coop cloud, stuff that matters to us. Good security deep dive. Things went a bit too quickly for me, not sure if we decided on points of action: what do we do in the coming time? Once I get more experience with abra, it'd be nice to have a topic: Experience with k8s vs abra. Next, gonna play with the animals and sleep before night shift. - m: I feel good, first time! I like the range of topics and looking forward to contribute and join next meeting. I am going to continue monitoring a freaking database migration until it's time to run outside.

2026-08-20, 19 UTC

Attending: calix (they/them), hex, Chasqui (he/him), Sarma (they/them)

Intros: - C: Mexico, worried about droughts. - S: back in Kraków, drained from tax/invoice learning

Topics: - distributed data storage for volumes

Resources: - https://articles.usulnet.com/articles/swarm-storage-solutions - https://rclone.org/sftp/ - https://www.haproxy.org - https://github.com/gluster/glusterfs

Minutes: - distributed data storage for volumes - S: different layers. Docker volumes etc. Fun things you can do with rclone. abstractions over data storage protocols. SFTP, googl drive. Same API, just different URI. Poking at it with SFTP. Idea: different laptops with different storage locations, each with different storage capacity. Rclone to sync to single source of truth. Use rclone as a proxy to attach to single source of truth. - S: Benefit: volumes created on central machine, but in case of outage, can rotate load. - H: Heartbeat, HA configuration - pinging primary, rotate to secondary. Writes go to one system, reads distributed? - S: Currently, writes and reads go to the same system. Protecting against unreliability of machines, frequent downtime. - Q(ca): is there a system in place already for failover? - S: No system, still in planning phase. Considerations: timeouts in rclone, SSH. Because we're in VPN, we could rely on the security of that layer. Nothing satisfactory so far. - Q(ca): does rclone have automatic sync, or is there a scheduled job? - S: Not AFAIK. Just thinking of doing a cronjob, sync every 5-15 minutes or something. - Q(ca): about to try out garage, which does distribute storage and makes it available through s3. Did you try it out and it didn't work, or using apps that don't support s3? - A lot of apps still need non-S3 storage. When you have containers on different machines, need to communicate, garage not sufficient. Lack of file locking. Locks and sync of reads/writes does happen somehow in rclone, not sure how. Garage / S3 dangerous to rely on for that. - Q(h): what is the goal? - S: Reliability. Solving the question of how you get reliable systems out of unreliable machines. A bunch of co-op cloud members have attacked that from different angles. e.g. for Merri-Bek, important not to drop connections during power / internet outages. And: use case of building cloud of random laptops in people's apartments. - h: are we talking about availability, or data backups? Disaster recovery vs HA. - S: Both important. Can't have availability if the data is gone. "Back up to a stable system as quickly as possible in an automated way" - Ch: we're working with low-cost computers, good usecase for us. We're trying to do something similar: distributed storage. I don't know if they use S3 or not. Could share the work. - ca: wrt mounting S3 as disk storage, I saw all the same warnings: anything that expects file locking will break because it's not a real POSIX file system. - Q(ca): say we have nextcloud, with a constellation of laptops. If I upload a file, this gets stored on a regular disk, which gets synced. What happens when rclone syncs while I'm still uploading? - S: If we're talking about storage large files, then this is probably not a good solution because of (missed it?). Apps that need to store large files, e.g. fediverse instance or nextcloud have good S3, would definitely suggest using S3. Garage or dozen corpo object storage providers. System I'm describing is not efficient for large amounts of data. But what it can do is be fairly robust for small amounts of data. Target: files max few kB each. If sync happens while files are being modified then I think you'd have partial files — need to look more into how locking happens, how that interacts with sync. Regardless, you might get incomplete versions. Not sure how to protect against that, other than through more rigorous layers of backups. - Q(ca): how easy would it be to manually start an instance on a different node? - S: In principle, assuming you have config files, only thing you'd need to change is the config file of where you have the data. All the backup nodes are equivalent. - h: have done this in the past with drbd - where youre seeking the block device at the kernel level. GFS, clusterFS which might do this. - S: First time hearing about these. Biggest thing for me is finding something that has a ready-to-go docker volume plugin. Blunt instrument idea would be just mounting whole docker volumes directory, but then each node needs a full copy. - h: DRBD running @ kernel level, probably can't just plug in. First thought: separating things out. Configuration in LDAP, application layer. Data store makes more sense to have at a lower level, more efficient storage for that. - ca: vaguely remember docker volume storage options. Reasonale to avoid NFS ime. GlusterFS and CEPH both have docker volume plugins. - Q(ca): Any thoughts on rubric for deciding which nodes get which pieces of data? - S: Assumption is: very little data cached. Play around with cache once we have basic MVP set-up. In that scenario: worker nodes with almost no data stored locally, pinging single source of truth. Other option: some kind of local copies of vols. Not storing data that isn't used by that node. 2 ways of looking at it: #1 when a docker volume is requested / mounted, that's when data is requests. Or #2, whenever node performs read/write operation, only that particular file is touched. Like #2 for prototyping, #1 for efficiency. Biggest difficulty: 2 services which need same volume mounted, option #2 would be great for that. - Q(ca): Example of 2 services using same volume? - S: Hometown, mastodon fork. Has "app" volume storing some stuff, but because there's a lot of situations where individual posts on mastodon need to be handed off to different services to be sync'd with other servers or stored appropriately -- certain data stored in common volume which other services in Hometown stack (e.g. sidekiq) rely on. - h: FYI, this also sounds related https://www.haproxy.org/ - Q(ca): Is every place that rclone copies data to a docker swarm worker node? Or not necessarily? Say I connect my laptop to your system - would it still be useful without connecting to the swarm - S: Formal distinction between worker nodes and storage nodes. (Also category of manager nodes). Thought is: manager nodes prioritise reliability but can be very tiny, small VPSs which don't know much about data. Or small cheap-ish machine that happens to be located in a place we know won't go down. Worker nodes, usually require fair amount of 🐏. Data storage nodes, usually require a fair amount of HD space. Each requirement is independent, so given machine can do 1, 2 or 3 of those, doesn't have to do all of them. - h: wrt mastodon - there's a postgres backend, and traffic on the load balancer. For high-availability configs, having a postgres cluster is the best approach for pg. These kinds of edge cases are baked in. If you had two mastodon clusters with traffic between them, and pg over multiple machines, you could use HAProxy to switch automatically between them at the application layer. - S: Only really considered 3 categories of data: databases (handled independently, handle their own decentralisation), S3 (handles own decentralisation), then $all_of_the_rest, data which needs to be handled in a generic way. Because I want to find a solution that assumes low amounts of data, low traffic, any time that an application requires a heavy load then it would be a better idea to find an app layer solution.

• S: h mentioned HAProxy as a solution for detecting dead servers and doing failover properly. Kind of assumed that failover would be a fairly common thing in various load-balancers but haven't really done a comparison. Can I get a quick haproxy infomercial?
  • h: 10-15 years ago I built a hi-avail system, two servers in different buildings so we'd have 100% uptime. I don't remember the details of it. At one point someone drove a forklift into the fiber connection between the two buildings and no one noticed until people were working on different LDAP systems. We were running docker at the time, DRDB, a heartbeat between the machines which would switch heads if one of the systems went down.
  • h: the split brain failure scenario is something to be aware of.
• h: interest in talking about this further
• ca: wonder how much is possible to do in traefik
• Ch: Propose to make a post in the channel, so I can show to my people - it seems similar to what we're doing.

Check-outs: - h: going to bed. Would like to talk about the security situation in terms of CVEs, how to report them, how to fix them - S: also head to bed, listen to the rain. Like distribution is a growing topic, appreciate so much interest. We had a dedicated kiteflying on it recently, could do another one. Maybe also a dedicated work group? Central knowledge store? - C: Jealous about Sarma's brain <3. Travelling to Mexico City to gather posters. I like the KF format of "put something in the oven and let things happen". - 3: Filled with inspiration. Love the idea of working group on distributed stuff, hearing more and more people interested in it. Future KFs: "what is coop cloud" - introductory talk. Going to fix an eink screen for friend.

2026-08-13, 12 UTC

Attending: may (they/them), Sarma (they/them), Chasqui (LPML)

• Sarma: recently installed a coopcloud server + apps for a client, estimates about 8h labour total, incl meetings and admin
• Chasqui (LPML):
  • working more on translations, improving command docs
  • talked about global gathering in september, seems a good event to attend: https://www.globalgathering.community/
  • gallinero project: a network, using coopcloud and backupbot2 (and maybe restic and garage?) for storing (3 copies) each others' backups, fauno from sutty and others working on it, first iteration already in place with 10+ TB and working
• may:
  • talked about managed hosting network inspired by Community Supported Agriculture (CSA) https://bonfirenetworks.org/hosting/
• we talked about the importance for people learn low level tech (eg command line, config files) but in a calm slow way, with entrypoints to first be empowered and then dig deeper

2026-08-06, 19 UTC

Attending: Sarma (they/them), hex (he/him), Danny (he/him), stevensting (he/him)

Topics: - CVE: how we can share info about security patches

Intros: - Sarma: got a client! Art collective. - hex: turning a shed into an office, after a year - Danny: starting a court case against a construction company - stevensting: crowdfunding campaign went well; 2600€ after two weeks, more than expected! Crowdfunding is for hard drives for a new server. Will be hosting coop cloud federation services.

Minutes: - Q(st): where are hex and Danny using coop cloud? - h: volunteering with ecommons, working with a lawyer to exit current employer. Will have to volunteer for the next month, won't work until september. Then, will finish starting a BV, start a company, and do pen testing + blue team security engineering. Helping orgs, collectives with threat modeling and security program. - D: work with cc for a half year; sevring apps for a few housing cooperatives in amsterdam.

• st: proposal: let's go through the document we have and talk about it.
• h: three things: lack of funding (maybe talk later). QA/security stuff. As we read through document, we could discuss usecases - make sure we're trying to solve the right problems.

• st: high level. Without having a lot of security knowledge, I can sketch what we have. Then your expertise can put that in the right frame. See if this is an achievable first goal.

• st: what I imagine is not related to QA. Rather, as a group of maintainers in coop cloud, we'd get notified about security issues which might get exploited soon. Highly critical CVEs like we had with wordpress. The top 1% or 5% CVEs that pose a likely exploitation risk, that we get notified about those right away. I've seen lots of databases about CVEs. I'd lke that when these get put into these databases we get a notification in matrix chat and we coordinate, who can put in a workaround or fix and we all upgrade right away. Everything else is nice to have afterwards.

• Q(st) Is this feasible? Are these also your conclusions from our chat?
  • D: sounds like a solid plan. Is it possible to get a short list of CVEs we need to address?
  • h: sounds reasonable and achievable. I wrote a step-by-step plan at the end of that doc: suggested longer term strategy. Each of these items could be a phase, a step forward.

    1. Create OpenCVE recipe (I can take this action, because it would be useful for me to know the tooling)
    2. Add SBOM functionality to abra using syft as a library to get SBOM by server deployment
    3. Set up a central OpenCVE instance for Coop Cloud
    4. Write a tool that runs grype (or similar) on SBOM to get issues, checks against a central for accepted risk, and reports any unaccpeted CVEs by recipe. 
    5. Write tool to sync SBOM from abra to OpenCVE (using abra). Add config to OpenCVE recipe to sync against another repo. 
    

• h: (3) would enable the matrix notifications.
• h: (4) with a centralized openCVE instance, we'd have a team looking over it, more people looking at what we can accept. Individual maintainers can run a tool that can check if their recipes have vulnerabilities.
• h: (5) allows individual collectives to have different objectives than coop cloud as a whole.
• h: I think this gets us close to what you were talking about. One thing that's easy to miss is the top CVEs, what is going to be exploited. CVEs have a CVSS rating: a number.
  • st: CVSS: the higher = more critical
• h: a high CVSS means it's bad, it will be exploited. CVSS accounts for ease, where the attacker is located, etc. E.g. "a network accessible thing that's easy to exploit." Usually, if you don't have a good threat ingelligence system, you go by "what's high or critical". When you talk about "what's most likely to be exploited" you're talking abotu a threat intelligence system: honeypots, monitoring, looking for attack patterns. Large companies have a dept for that, which is supposed to tell you if there's a CVE actively being exploited.
• h: I was working at amazon when log4j came out. Internally, we found out because there's an agreement between google and amazon and other companies, to get early intelligence on this stuff. One thing they share are Indicators of Compromise (IOC). When there's an incident they'll share with the other orgs in the agreeement.
• h: on our scale, we could also share IoC with eac other. So we want to see information when something affects a given collective. That's the goal.

• h: For now, we'd rely on CVSS - but we'd get a lot of noise from that. Something flagged as CVSS 9 might be e.g. "an auth exploit in saml". If you have saml disabled, it doesn't affect you. It's gonna be hard to filter down the high CVSSes. But we can do better than nothing.

• st: wrt IoC, this might be nice in the future/long-term, maybe.

• Q(st): what is the real advantage of using openCVE? It looks like a collaborative approach, shared UI for a database?
  • h: there are other tools, doesn't need to be opencve. This appears to be one of hte easiest ones. Minimalist. In the long term I'd like to migrate to something that's SIEM. Though that's a different department than I usually work in, there'd usually be a group dedicated to this: endpoint monitoring, sharing information back and forth. E.g. all your customers would be reporting their endpoint monitoring back to your central thing, which reports back to some cloud coop one. And you're looking for indicators of something being compromised. In addition to CVEs you also want to check config issues, you want to run vulnerability scans. Then there's cloud security on top of that.
  • h: this is all stuff that doesn't need to be built right this second. Instead, let's look at 'how do we get value at each step' so we start taking steps forward. OpenCVE is the lowest bar that gets something going.
• Q(st): why is it abra that should create SBOM? I imagined our CI could run syft. Is abra the right place?
  • st: abra can already parse information from the compose files, is that it?
  • h: yes, CI should be doing this. And also, prod and testing might differ. I understand abra as the last step - which knows exactly what's being deployed. I want to work backwards from deployment; start at the last point - so it gets caught at the very end - and only then push left to catch it earlier. We should have something that scans the recipe as it gets added, something to tag it as tainted, warnings during deployment ("this has an open CVE; are you sure you want to deploy"). (secretary's note: connection issues here; I missed a question and answer)
• st: how deep do we want to go? I made a supply chain levels table. With SBOM we're digging quite deep; we're checkig every lib/package used in a container. I don't want to do that in the beginning. We should start focusing only on the app run by the docker container. E.g. we're running wordpress, so we want to know the wordpress CVEs but (in th ebeginnning) not about a package/php library used by the container.
  • h: agreed. However, did not see an easy way to automatically figure that out for every application version.
  • st: Static angle where we look only at coop cloud's git, and do the process for the most recent versions there (what autonomic is doing) - then look at older versions. This does not tell us if anyone is using it in prod, but we can tag this information and inform people.
  • st: Other angle where each collective running deployments can get custom information about their own deployments based on what versions they have live.
  • h: similar to NVD (national vulnerability database, US so questionable trust) - the big thing that feeds openCVE. These are reports by a vendor of a specific software. Coop cloud could do the same thing, go thorugh the same mechanism: CC security figuring out which recipes are vulnerable and put out a report when one is vulnerable. (could be in chat, wherever)
  • st: I thought that we could run both angles. But, when we create an openCVE database, every coop could just pass their own server folders (maybe with abra) - then use openCVE to make a personalized vulnerability databse.
  • h: openCVE has a good APi and hooks. Point is that wyou can get an alert about a CVE and fling that where you need it, then come back - own, track it in the application. This approach is more similar to the distributed teams model in a large organization; you have central tracking and then someone comes to a team and yells at them to fix it. You might have a ticket that gets kicked up and 300 teams get thrown onto it, anyone affected, to go fast. I'd like a less tough approach which empowers the end groups: let collectives have information - it should be simple 'just upgrade' but sometimes they can't upgrade so we should give them all the information so they can work through it. I do want just a little bit of centralization.
• Q(st): what's the difference between step 4 and step 5? Is step 4 optional?
  • h: we should be able to say 'we don't have a functional system yet but here's a tool you can use now'. Maybe I'm deploying a custom recipe. I get the app, get the SBOM, see some vulns I don't know about - this checks against a central repo and says "these are the ones we haven't accepted".
  • h: We could simplify this. A tool where collectives can track vulns. So you can manually tack this thig.
• Q(Sa): Given that coop cloud deployments look very different from corporate clouds, should we look at
  • h: the NVD is the root for tools like openCVE, there's a mailing list/RSS for the newest CVEs. Tools like openCVE let you filter that down (e.g. only care about wordpress, nextcloud, etc). Then, there will be issues not tracked there - interactions between specific components (Secretary's note: connection issues again)
• st: unsure if each collective has its own openCVE instance
  • h: optimally you'd want to offload that to a specialist.
  • st: unfortunately we don't have that
• Sa: It would actually be nice to have a specialist in the federation: someone to hire to review clients' configurations.
  • h: I'd like to build a business around this and make it feasible. Ideally, there should be a security federation within the feeration - a few providers who can share information back an forth. So a collective can choose a vendor to work with.
• st: we're working on a proposal to come up with a process to finance these sorts of tasks. It's complex because members have different amounts of turnover/money.
  • h: potential govt funding, nlnet, etc.

Checkouts: - st: good stuff, need some more conversations - D: interesting stuff. The minimal solution seems feasible - Sa: got lost in all the acronyms, but want to hear more about this. - h: apologies for letter salad, not as scary, well only half as scary as it sounds.

2026-07-30, 12 UTC

Attending: papiris (he/they), Sarah, Sarma (they/them), stevensting

Topics: - FOSS Maturity - CVE - how can we share info about security patches quickly inside Coop cloud

Intros: - Sm: bracing for the upcoming heat wave, looking forward to hearing Sarah - p: hopeful, not a lot of sun in norway. Fields are too wet for the tractor. - Sh: LoRes is trying to transition from a one-person team (Jade) to additional coders. Hope to find a good basis for our next steps. - st: 38 degrees outside, but ok inside for now. Loooking forward to discussing organization growth. Sounds like a broad topic, but useful to Klasse Metode/coquest.

Minutes: - Sh: Reading lots of documents, lots of ground to cover. Want to know: what would be useful to your orgs and for coop cloud - to narrow the scope. Shared Document - Goals: allow an org to assess maturity day/to/day, how to handle things when they go wrong. Also improve operations, maintainability, resiliance in a way appropriate to an org's maturity. - Maturity models are good for step-by-step improvements to an org. Rather than assuming all orgs must be level 5, we can set goals appropriate to your level. Jumping straight from 1 to 5 is not sustainable, - Q: where should this documentation live - Q: what format should this documentation have - There's a convention to use tables, but it can be messy. We also have a pdf document that's more linear. - I haven't included: how big is the team, who are the copyright owners, how big is the roadmap, etc.

• st: where is the table from?
  • Sh: I synthesized this from maturity models listed later in the document, to make them more usable
• st: in the automotive industry as a product manager, the maturity models were important to software development. Assessments could run for days to establish the maturity of a project. How feasible is maturity assessment for underfinanced open source projects? Even in a mature project, it all stands on the availability of the maintainers .
• st: Lauti community calendar, I'm there as a voluntary basis. If no one on the core team could work on it, the project would collapse even if ok processes were in place.
  • Sh: I'd like this paired back to the essentials, for whatever coop cloud wants to get out of it. Not a checklist of what you have to do, but things to look out for when you have time for improvements.
  • Also, I've deliberately kept some things here as ideas to discuss; we should delete things rather than add things.
• Q(Sm): since we have different orgs, some maintaining foss products, some doing hosting, and coop cloud as a supportive federation.
  • Sh: if people can choose the categories they find relevant from one document it might make sense to have everything in one, or we might break it up.
  • Q(Sm): which type of org did you have in mind when writing this table?
  • Sh: focused on development.
• st: our org does all three. But financing is crucial. We need clients for funding, and we need to make sure our work is all being paid for. As we move away from a focus on development to a more mature org, the focus on organization should be larger: data protection, passwords, customer interaction. And that's the focus for hosting/services. For the federation, money is also important; the better funding we have the more possibility there is to establish proper processes and be reliable as an org.
• p: Regarding format and hosting of the doc, when we in datakollektivet were starting to organize ourselves, we found the format of this helpful: https://demo.common.guide/
• Sh: priorities will change depending on orgs depending on stakeholders etc. So hosting and development might need separate models.
• Sh: not sure what that looks like from the federation point of view.
  • Sm: since the federation wants to make a certain org type viable, and
  • Sh: sounds more like a horizon roadmap than a maturity model; taking stock of where members are now and where want to be in 5 years time. What we want to achieve, but also what we expect from ourselves.
  • Q(Sm): what's the difference between roadmaps and maturity models? Both point us from "further from o goals" to "closer to our goals"
  • Sh: my table is a checklist style maturity model. For a roadmap, we'd show horizons for now, 2028, 2032. And we can see what we can expect of the org. It provides a benchmark/baseline of what the org can be expected to deliver at different phases, and helps us not to jump ahead to 2032 levels of delivery in 2026
• st: We could say "in 2028 we want maturity level X in our org"; it can be one element alongside others. The maturity model comes out of various existing orgs, and can be used to judge an org. But horizon looks at possibilities, and looks at the future.
• Sm: Circling back to funding: coop cloud talks about money differently than a corporate environment does. Since a lot of open source environments have VC - and our orgs need to focus on securing funding early on - do we need to account for that?
  • st: evaluating where we spend money is a no-brainer for a cooperative. A corporate environment has a profit motive and we have an environmental motive. It still makes sense to examine where we spend money, but we need to apply our own goals/values to our spending decisions.
  • Sh: we might have differences for non-profit or volunteer work. Comparing to existing FOSS work is a good starting point, but we should modify these models to our orgs.
• Sh: working for an org with one coder, there's a passionate core group behind these projects which can put up barriers to risk management. So in organizing I focus on what passionate developers can overlook, and what users might need as we move from a small group of users to more widely used.
• Q(Sm): since a lot of projects have infinite growth models, and coop cloud members generally want to reach a set size.
  • Sh: we'd have to look more carefully, but there aren't many criteria in these models that assume growth of any sort. There are a few, and we can easily look at those

2026-07-23, 19 UTC

Attending: calix (they/them), Sarma (they/them), Sixsmith (he/him), j2

Topics: - Wordpress: how does updating work? - Web UI that Sixsmith's collective has been working on - Workshops, ideas and resources

Intros: - c: travelling - Sa: a little crunchy audio. Gonna commit to multinode when spoons allow. Also planning to do talks/workshops to teach people about what can be done with the internet. - Si: Atlanta. Using Co-op cloud with some folks, and evangelizing coop cloud to other collectives who need data security and data autonomy. Bursty activity, but inside of a burst now!

Minutes: - Si: working on frontend for managing apps, servers. Split into components, Want to publish this as a container, then as a recipe. Looking for thoughts to figure out next steps. - Si: demo currently not cooperating - Q(j): are we still trying to get a tagged release? - Si: we have a tagged build, builds succesfully. - Si: here's a link - Si: We use an automated builder, but it's not drone. At the moment builder lives independently, but ideally we want a CI w/ drone. - Q(Si): do we want the web ui as a recipe, so people can deploy it on the internet? Or do we want the container as a local application, which uses the user's configuration? - c: very excited, amazing stuff - c: lot to be said for encouraging people to run it as it has been. Main question is about git handling; how does this interact with git? That might affect where to run it. Also: what is your intended public? People come to coop cloud with different levels of sysadmin experience; different populations might want different options. - Q(Sa): haven't seen this before, curious about parity with abra/docker commands, how safe is this to give to an operator, how limiting? Would it be difficult to make local+deployed both options? I assume most of these questions would be answered by the demo or video. - Q©: clarifying git question - how are env variables handled? - Si: no handling of environment, secrets, server configuration, or sharing. Everything is consumed from the user's abra directory. So this would be on top of whatever existing sharing solution you have. - Si: we're seeing this as interchangeable with the abra CLI. Feature parity and used the same way by a single operator - but without requiring comfort with the terminal. - j: screensharing - c: agree, there's no support in the CLI for version control/sharing, so it makes sense not to have it in the web ui - Q(Sa): flexibility - do you imagine someone in an org has - j: the inflexibility can be a good thing. There are clear bounds on what you can/cannot do with the tool. So it's not a drop-in replacement for the CLI. - Q(Sa): how difficult would it be to make "local vs online" a configurable option? - j: sounds reasonable!

Wordpress! - Si: how does the upgrade process work, across recipes, across container images? - Si: way I sketched it out is: recipes use latest+greatest version of an upstream image that they have tested. There's been discussion in wordpress, if there is an RCE in an image should people find out about it? - Si: some recipes use non-standard versions of wordpress and they're nontrivial to upgrade. There's various levels of out-of-date packages. - Si: how do we consider there might be a different upgrade path, since operators are on different versions. - Sa: for different versions, I've seen recipes use "checkpoints" - like asking operators to upgrade to 4.0.0 and make sure verything works before they move on to 4.1.0 - Sa: for security updates, I've never seen conversations internal to coop cloud about them. I tend to follow upstream maintainers on fedi or RSS, to find out about security updates. - Si: renovate is a good tool. I've been playing with the digest ping feature. With pinning my label you don't know the image you're getting because labels are immutable. - Si: afaik no recipes use digests, only labels. I don't think abra has support for them. Ideally, maintainers should see a label but have it be a digest behind the scees. - Q(Sa): not familiar with what a digest is - [https://docs.docker.com/dhi/explore/security-concepts/digests/] - Si: there was an issue recently where someone took over the github account, and published a compromised image to an existing label. So pulling from the same label you got different images depending on time. - https://socket.dev/blog/checkmarx-supply-chain-compromise - Si: in renovate, you can just set "pin-digests=true". I would like to see if that works with our recipes. Check if this works with PRs in our recipes, and whether upgrading uses the digest sensibly. - Q(Sa): how big a concern is this for us? Should we prioritize this? Maybe a critical fix in abra, to use digests? - Si: on docker hub, I assume there;s some verification to protect against that. There's a setting in docker hub with an existing tag. But, the API does not tell you whether a given image has that setting. So this is an unknown, and yes, a vulnerability. - Si: only a fraction of recipes use renovate. I'm envisioning that renovate would be best practice, and recipes that don't use it's next action should be to use renovate. But the next step would be to have renovate use this digests-true setting. IIncremental deployment, since recipes are at various stages of readiness. - Q(Sa): I wonder how you'd communicate this to all maintainers. Maybe modify MAINTAINERS.md templates? - Si: I'd like to bring this up on matrix. Could also modify MAINTAINERS. Maybe there's a renovate default config we can modify?

BigBlueButton recipe development: - p: as part of Near (spelling?) I've been working on the BigBlueButton recipe for most of this year. We made a breakthrough last month. But we can't get video calling working. We seem to be running into issues with interactions between WebRTC/coop cloud/docker swarm. If anyone has experience with webRTC, please open an issue on the bigbluebutton recipe. - Q(Sa): do you have a budget for this, or asking for voluneer work? - p: asking for volunteer work

WebUI demo link (hopefully it stays up): https://vid.curls.soy/w/3K58ACBGSi9L9pwiR9uega

Outros: - j: looking forward to covering more topics/questions next meeting - Si: glad to interact with other humans working on coop cloud, want to come back! - p: should start coming to these more regularly, and use matrix more regularly

2026-07-16, 12 UTC

Attending: Jade, Sarma, Tom Idar, Papiris

Topics: - M-m-m-multinode

Intros: - Tom: new, doing something similar and wondering if I should join you - Jade: keen to jump into multinode

Minutes:

• Sarma: Vision
  • Deam of having a cheap VPS that acts as a proxy and gives access
  • A network of various machines, laptops etc that sit behind NAT and do the processing and storage
  • This is partly to keep costs down and give us control on our infrastructure
  • Much of the equipment is unreliable and cheap
• Q Tom: Why would a cluster of machines be good?
  • Co-op cloud initially established by co-ops doing web hosting for clients. For these co-ops, it was efficient and effective to have a cnetral VPS that would post everything.
  • Tom: We have next cloud servers, centralised login would enable the use of seperate servers that aren't connected.
  • Nextcloud servers can connect to each other and share between them
• Sarma:
  • The above describes federation between servers, supported by Nextcloud, Matrix, etc. Doesn't require servers to be in the same cluster
  • Having services on the same cluster (or swarm) allows for:
    • single load balancer, provides control of traffic
    • shared resources, eg (redis, storage)
• Tom: If you have services in a cluster, you need to be in the cluster to access. And you need to collaborate in a highly trusted way, not a federated way. Big clusters are often used by big tech.

• Sarma: Let's dive into how clusters work with Docker Swarm

  • Some magical things happen in docker swarm. Services start and stop automatically, but:
  • Each server/node has it's own data storage, its own copy of a volume.
  • One way to solve this is with custom rules in the compose file. The deploy section
    • Docker swarm can restrict particular services to particular nodes. Nodes can be tagged as having data storage, good compute, etc, and certain services can require those tags.
    • The solution we currently have is to have a single node that is both the manager and the data storage node. Any service that will break if it loses access to its data storage runs on the manager.
  • Many apps have a container that is resource intensive but doesn't care about persistance, and another that has the opposite needs. In those cases, our solution works well. The difficulty is in apps where a container requires both persistence and resources.
  • If we can get a container to use (something that looks like) S3, then we can run a distributed object storage service (Garage)
    • S3 usually requires us to work upstream. If a container relies on volume storage (rather than object storage) we did consider s3fs, but the folks working on Garage have told us that's a bad idea - S3 is missing many fs features like file locking.
    • Other solutions I've glanced at are: nfs (network filesystems), docker volume plugins, and manually syncing.

• Q(S): I'm curious to hear about your usecases

  • J: only a subset of people will want distirbuted. But here's Merribek's usecase:
  • We're running separate servers at separate community facilities, and reling on federation between them. So there's no docker swarm extending between locations. We wish to connect between locations with low-bandwidth and often unidirectional technologies (e.g. lora).
  • We picked raspberry pis, because they're easy for beginners to get running with $200 of technology. Each raspberry pi is also a unit of storage that everyone can understand.
  • But pis don't scale vertically. As a given location expands, we could move up from pis to a bigger computer. Or, we could cluster our pis. Some of our members are excitedd about shoebox racks or 3d printed cases.
  • Downside of clustering: marries us to buying new tech, rather than permacomputing.
  • If we use multiple pis in a single location, we'd probably centralize storage. The SD cards would not hold volumes, only OS.
  • We aspire to running our servers entirely off renewables and batteries. Having lots of small computers allows us to prioritize them and power them down. E.g. we might power down the minecraft server when batteries are low. So we might want to tag services and power them down at low battey levels.
• S: really interesting question of prioritizing services for shutdown; I'll definitely look into this.
• Sarma usecase:
  • 200 AUD for a Pi server is actually quite a lot. In some communities, a laptop with a broken screen is actually more achievable.
  • You can often find these fairly cheap at various local marketplaces.
  • I have some concern that this might not scale well in terms of energy usage, but the upfront cost is more achievable.

• Q(J): Would a non-docker-swarm solution fit this usecase better? e.g. k3s?

• p: Have asked garage people how garage handles nodes falling offline/coming back online. It does not handle that very gracefully with redistribution of blocks. In an unstable network or unreliable nodes, to guarantee availability would require that each node holds all data.

• Q(S): papiris has more experience with k3s
  • p: K3S is... ok ... . If you're a k8s engineer and work with it daily an keep up to date with it... If you use it anyway and are compensated, I recommend it. But if your time spent to keep your knowledge up to date is not being compensated, it's a very expensive tool to learn. I've used it for thousands of hours and am still faced with walls I struggle to overcome.
  • k3s handles nodes falling off and coming back on, but it can be sketchy.

• S: based on this, I feel intimidated to try k3s. I'm actually considering splitting the problem: have docker swarm handle container disribution, and do data replication with a different system entirely (not sure which). Then the single reliable node that's handling load balancing can also function as the data proxy: from the perspective of docker swarm, data is centralized in that node, but in reality data is stored elsewhere.

• S: my concern with garage is that it's not a universal solution: if a service doesn't support S3, then garage won't cover file locking. E.g. in mailu, I think emails are transferred between services by saving a file to a docker volume;

• J: good to consider what level of the network stack we do our distribution. If we want to install not just swarms but also databases and other things, we want something that acts like a single distirbuted computer/operating system. On the application level, we also have a lot of services that have opinions about replication and their own implementations. Servers like stalwart have their own replicaiton. Identity/management system (authentik etc) have their own replication strategies. It's frustrating. I don't know if there's any way to build systems where we use a general system to network our machines, which provides enough networking/routing information that we can hand off to application-level synchronization.
• Things get weird when we do distribution, and we want users to understand that. Application-layer solutions have ways to communicate to users. But if we want a lower-layer solution, users might get frustrated because they either expect clear error messages, or they're used to the reliable pipes of big tech.
  • S: I've seen users get frustrated when a container goes down somewhere; their confirmation emails don't get sent and they don't know why.
• J: Many downsides to application-layer sync, I'm not promoting it and it's not winning the battle in comercial software. Cloud as absraction is the model we use globally for everything comercially. There are open source cloud options that move beyond just block storage. But they tend to be complicated because they're targetted at orgs much bigger than us.
• At LoresTech we are doing application-aware networking. And this means we're going so slowly we're delivering nothing.
• We need both strategies.

Checkouts: - Jade: always glad to have these meetings, appreciate that people find the time out of their day. Next, working on p2panda - Tom: starting a new company with 4 people. Found coop cloud through a collective in norway. Still gathering information, will definitely follow this group. - Papiris: inspired & enlightened about the various challenges and limitations, realizing that to know my usecase I need to get further in the organizing, to understand what people's needs, capabilities, and wishes are. Meeting was nice! Informative. Too bad about bad connections but such is life. For future KF, no new suggestions, review my previous KFs. Doing next - paying a benchful of unpaid bills, as well as paying the horses, sheep, and chickens. And setting up a bonfire instance . Already have a test instance, this will be prod! - Sarma: might want to introduce a 5-10 minute segment at the end of KFs to touch on topics we didn't get to, especially from people new to the community.

2026-07-09, 19 UTC

Attending: Steve, Calix, Papiris, Ben, Sarma

Topics: - what is the support intention for coop cloud across multiple machines - report back from Rojava - LLM use

Intros: - Steve: I've been doing self-hosting, coop cloud has been interesting in that space - Ben: member of a tech coop that does consulting, interested in decentralization and etc, just checking this out. - Sarma: glad to see more people! Setting up hosting business. Slow & difficult.

Minutes: - St: muliple machine question is connected to the docker swarm topic. Especially wondering if coop cloud is intended to be run on a single VPS - c: Sarma and Merri-bek are probably our experts on multiple nodes - Sa: Short answer to "does co-op cloud support having multiple worker nodes" is "no". But: co-op cloud very adaptable, gotten it to work fairly fine. A few considerations. Biggest difficulty is data storage: wherever you need to hold your volumes and databases, creates restrictions how many machines you can run a particular container on. For example: Mailu has database container; if you try to move that container to a different device, docker swarm won't move that data for you, it will spin up new (empty) database. In most cloud set-ups, you want special handling for databases generally. At the other end of the spectrum: webmail container, just presents frontend by connecting to other containers. Can run anywhere! From the perspective of docker swarm, you want to have constraints on containers which need to be bound to separate machines. Separate compose file, attach to recipe. At some point I would like to standardise, normalise, make it part of regular recipes. Still WIP. - St: Generally abra, recipes, whole stack assumes single-node docker swarm. Talking about putting a database on separate machines. More traditional configuration, docker compose? - Sa: All the configurations are stored in one place, running abra only on manager node. Where can I find information about that? - c: You're correct that the answer you'd get in the matrix and documentation is "abra will probably not work for multiple node docker swarm configurations". There's nothing in abra or the recipes that tries to prevent that. If you run the abra quickstart and attach worker nodes, you'll run into issues because the recipes have no defaults on where to deploy specific containers. - St: So, the design standard of recipes is to assume a single node? What I want from a pay-to-play tech coop is resiliance. If I'm running my storage from a small local machine, then when that machine goes down I lose access. What people say on self hosting is, if you want resiliant servers just rent a VPS. Problem with privacy is that the hardware owner can see the data. The solution to this would need to be on the recipe level of coop cloud. Some software has application-layer data replication, e.g. Sirus IMAP. And the deployment would need to be aware of that, of a swarm of Sirus IMAP nodes. I want to guarantee something durable, and not use a VPS. Hardware can take weeks to replace if something breaks. - Q(St): is multinode a direction that coop cloud is trying to go? - Q(St): how does this connect to the docker swarm question? - Sa: Definitely want to explore this. Active concern I'm currently looking into. Merri-Bek. Don't know about if "whole of co-op cloud" wants to do multinode, but at least two members are exploring it so there's space for conversation/work - b: S3 as a backup, peer to peer backup storage - c: Sutty is trying to build a coop based around garage - p: also interested personally in multinode coop cloud. Trying to do something similar to lores in Norway and Rojava. Acces to high-spec machines is difficult and having stuff in single locations is vulnerable. K8s is too complicated and unreliable in emergency situations, e.g. in areas with unreliable internet connections. - c: coop cloud's founding coop was focused on vertical scaling, and that led to the single node preference. The first few member orgs were all hosting on VPSes, likely because their threat model was different. But that's changing. Merribek Tech's Lores project seems to have a similar usecase to yours. - c: for the specific example of a mail server: if you want reliable failover need to consider what's handling network ingress. Coop cloud recommends traefik (most recipes have support for it). And since v2 you can't do network ingress for free, need to pay for premium. No one's looked extensively into whether caddy can handle this for us. If docker is trying to figure out which instance to send mail to, then if your reverse proxy is down it's like the whole server is down. - St: email is one of the protocols that doesn't need a reverse proxy; can do failover in DNS -- MX records are progenitors of SRV records. Jabber can also do this. For this type of software you don't need a big vertical stack. - St: for anyone interested in self-hosting, getting away from big tech at a bare metal level, 15h is developing coreboot open source firmware that can push the bare metal level towards independent and self-owned setups. - p: tried a cloud with multiple traefik installs. In the current k3s I'm using there's a tiny load balancer that shims traffic back to the main traefik container. So multiple ingress nodes only need one traefik container. Maybe we can explore that?

• c: there's a lot more to say on multinode and we could be nerdsniped into exploring that now, but we could move to other topics.
  • S: would be good to have a structured conversation on multinode. I can bring that up on matrix.
  • c: agreed, could do a merribek demo and different visions

Rojava

• p: spent 10 days with a European delegation in Rojava. tech was not main focus, so these are Observations and questions I've asked. My experience with the people of Rojava is that they mostly use big tech. They use WhatsApp for messaging. They use proprietary video editors for most of their content. I only saw Windows installs. Only in particular locations was it Linux. A lot of the Windows installs might have been pirated.
• p: secure communications and secure digital services, anything digitally secure, was practiced only by the most sensitive aspects of society. People working in technical stuff are interested in, willing, working to implement better security. They'd appreciate contributions of time or advice.

• p: cellphone towers are existant but vulnerable. Anything except talking to your family is not advised. The backbone network is very slow and unstable. Only 7-8 hours per day of electricity, inconsistent across the network.

• p: there are no hackerspaces, digital independence days, linux parties. There is some interest. Especially alternative social media days/seminars for the youth. A lot of youth use instagram, tik tok, youtube - exposed to the same right-wing/sexualized/capitalist/misogynistic content and propaganda that we are in europe. There's a lot of willingness to change that, but not a lot of knowledge.

• Q(St): What are people trying to do with local LLMs in the middle of all that's going on?

• p: various parts of society want to use it. Media studios want to create low-budget video works. Education is limited. Since 2021 there's more places (Peymangeha Bilind a Hunerê ya Rojavayê Kurdistane) that teach painting, dance, theater, music, film, but not animation. Currently there is no animation education.

• Q(Sa): Drawing a parallel with talking about how the youth approach social networks - feels so familiar. Same things happening in Europe. "I would like to be using something else", with little knowledge. Is there space to coordinate on that, collect teaching materials?

  • p: that rings true. The focus has been, until now, a lot about communication - how we enable resiliant, secure, distributed communications. But that's only one aspect, one area where people can contribute (e.g. mesh networking). Youth networks in the kurdistan freedom movement and rest of europe are definitely facing that problem so there's room to collaborate.

Checkouts: - c: lovely to meet new people. Always appreciate tales from papiris's travels spreading democratic tech. Saw coolify in matrix and again want to do kite flying session where we try alternatives to coop cloud. - b: interesting to hear different perspectives. Gonna work on OAUTH2 and some Rust. Then playing a Colorado Springs gig; 2 hours away through denver traffic. - St: Gonna work on my 15h board, get it booted. Going to read more on Rojava, too. - p: feeling fulfilled in having brought the messages from Rojava to you. Glad to be part of this bigger struggle of democratizing all the things. Will be hopping on a night train, because the train network ran out of power during my previous train attempt. Silver lining: I had stable connection during Kite Flying. For Future Kite Flying, would be interesting to discuss/learn organizing events around moving off big tech. - Sa: Cool topics as always, especially happy that there are still unanswered questions! Dug into a lot of things, opened up even more. Event idea seems interesting, not sure how to facilitate it, who should be invited. Multi-node seems like interesting topic for kiteflying. Will bring it up in matrix.

2026-07-02, 12 UTC

Present: Sarma

No meeting held, due to lack of attendance

2026-06-25, 19 UTC

Attending: Sarma, calix, Dieu (pronunciation "like you and me")

• LLM discussion seems to be needed, to generate a policy
• requires: knowing what the points already mentioned are
  • S: I think d1 mentioned they're making a list?
  • c: He seemingly explicitly didn't volunteer for facilitation or to share that?
  • S: there was a lot of crosstalk, so not-volunteering doesn't mean not-willing to share https://git.coopcloud.tech/toolshed/organising/issues/678
  • c: not too much here, because most of the conversation has been in Federation chat
  • c: one other thing to do is map out what the options are, unclear if d1 has done that.
• Q(S): have we had any LLM contributions?
  • c: sort of. 3 total. 2 linked from thread. Plus one nextcloud maintenance.md draft (same author as one of the PRs)
  • c: Autonomic has been using LLMs for recipe maintenance tooling; unclear if recipe changes are LLM generated.
  • S: Nextcloud maintenance doc is Claude.
  • c: depends what we mean by "LLM contributions". since there's no policy that you have to declare, we don't know if other contributors use LLMs.

Dieu joins - D: first time here; heard about you from the What We Will org - Q©: haven't head of WWW, talk about them/how you're involved? - D: https://wwwrise.org/ - associated with Tech Worker Coalition. I'm actively involved. - D: The What We Will coop is recently incorporated! - Q(D): So what are you up to? - everyone: being a mess - c: used to be part of the founding coop. Now independent trying to start a new thing. - S: hi, independentish Polish-based person, facilitating on other weeks - c: recap. 9-month-long conversation about what our LLM policy should be. One member of the coop is already using LLMs and brought the topic forward. Conversation has been federation-internal. Current goal is to map the current views. - D: currently working on a dev environment; want to be a fly on the wall and meet people, get touchpoints in orgs like this. - D: I'm interested in the high level concept of coop cloud. I have a few years experience front-end/react/web. Left tech and movement tech has been in the back of my mind. Not enough people know anything about this, even though it's not rocket science. - S: Curious what D's perspective is. "Even though not rocket science". Comparing apples to oranges. Problems that tech work prepares you for - problems fairly divorced from human stuff. "Software exists in a vacuum". Co-op Cloud is a group of people who are trying to make sense of those social problems. Finance, outreach, organising chats etc. Building software tools that make that more possible. - D: "not rocket science" is more something I tell myself - tech can be framed as reserved for an elite group to gatekeep. I get anxious, and telling myself this reassures me that it's not so bad/learnable. Might not be easy to figure out a solution, e.g. a non-hierarchal approach. What I meant to say is that given a better understanding of profit, surveillance driven architecture - reasons/tradeoffs, data sovereignty, privacy - why should an individual person or org care. There's a fear on the left that all tech is bad, because of exposure to corporate tech. - S: All valid! - c: two brief thoughts. coop cloud is three things: - 1. community of 300-ish people (figuring out solidarity, economy, liberatory tech) governed by intl democratic federation. - 2. configuration commons: collection of our recommended deployments of open source apps. We're synthesizing the wisdom from across the community how to run wordpress, jitsi, nextcloud, etc. A lot of people use this, but deployment is difficult because while each software publishes guides, you need to learn a lot about each to do security, sso, backups, etc. Recipes represent quite useful shared learning. In some cases, people have made contributions/recommendations despite not using Coop Cloud tooling. Configs touch on devops concepts: infra as code, etc. Goal: less duplication of work between orgs. - 3. Tools: built around docker swarm (an unloved mode of docker). The docker CLI is bad, swarm CLI is worse, so we have abra - which keeps app configuration separate from recipe configuration. This solves the problem that if you have 10 nextcloud deployments you need 10 repos. We also made (?), reluctantly. - Calling all this coop cloud brings some misconceptions. People imagine Coop cloud either provides hosting, or software to enable paid hosting - we do neither. - D: Maybe there is a barrier of entry, "technical knowhow". Appreciate the context. - Q(D): How long has Coop Cloud been around? - c: project started 2020, federation started 2021/2022 - Q(D): do people come in with these expectations often? Does it reflect a need of what people are looking for? - c: yes to both. Speaks to two unmet needs: - 1. not enough cooperative hosting providers for standard VPSs - 2. not enough IaaS/SaaS providers. There are people who will host Nextcloud for you, and some of them are cooperatives. And there are paid services (picapods, cloudron?). But orgs that want to use open software probably want a values-aligned org, not silicon valley. And because cooperatives usually do things manually they can be more costly. - S: don't personally run into that confusion. Personal set-up: all "cloud" software eventually hosted on people's laptops under their beds. But yes there is a need for this for others probably. Might not be enough of a need for this particular use-case to make it economically viable. But a lot of people who want it to happen. Seems like a difficult problem to solve compared to what we're trying to do. I do want to see a future where more organisations that are values-aligned with us would prefer to have some amount of geographically-local, spatially-local infrastructure. Ideologically "infra as a service" clashes with software autonomy. - Q(D): If I want to learn more about the problems you're aware of, are there groups having these conversations, articles, books, thought leaders? Does existing content inherently support capitalism? - S: Absolutely do not need to know devops or any particular tech to participate in conversation. Big need for people knowledgeable in other human aspects. Sutty has a good blog about the issues. - C: hour video discussing community tech - as opposed to corporate hosting and tech hosting - Q(D): so, pooling resources? - C: Not just resources. In self-hosting, each collective needs their own sysadmin. So if a collective doesn't contain a god-tier tech nerd... And we end up with the most radical groups using objectionable software - D: Grassroots group - "how do we use different tech", inconvenient, beyond capacity. Those who most want to use it have least resources, know-how. - Q(D): how do I stay in touch? - c: matrix or signal

Checkouts: - c: feeling better than at the start. Really nice meeting D, thanks for joining. Still feeling stressed about the LLM conversation; worried it will spiral out so that participation becomes impossible for people without infinite free time. One of these days, I'll propose a theme. E.g. "trying out alternatives to the tech side of coop cloud", or a hackathon - D: thanks for everything. I think there's too much of a gap between activists and technology. wrt LLMs, gotta think about the impact of the decision. Open source contributions exploded, but burnt out a lot of people. Questions around sustainability and inclusivity of newcomers. No need for FLOSS to churn out features that then break. - S: Hackathon was indeed great, fun to repeat that. Also constantly promise myself that I will come up with a theme then forget. Hoping that I will find a theme in the Matrix chat. I can try to help moderate the matrix. Cozy games.

Mapping out the options?

Hosted vs open source Hosted: US vs EU vs other - S: there's a legal argument for EU LLMs because of GDPR -

2026-06-17, 12 UTC

Attending: Sarma(they/them), steven (he/him), Jade(they/he), papiris (any), c (they/he/any)

Recent events (backup topics) - Wouter's LGBTQ+ outreach - Lores's shiny new app: https://lores.tech/blog/example-chat-app/ - Discussions around database/redis containers shared between recipes

Topics: - mesh networking / reticulum - local-first, p2panda - digital autonomy for Rojava - decentralized comms

Check-ins: - J: lores chat example!! Solarpunk meetup with people trying it out. 15 volunteers focused on getting through the instructions, but it's slow - people struggling to get through. Excitement around mesh networking. - common problem: offline installation - s: in the last stage of starting a big bonfire instance. Postgres troubles, long request timeouts. Interested in the AI discussion - we should have that in lauti and . A few PRs came in with AI contribution. - p: Headed to Rojava this weekend. Excited about what is to be and has come about, intl collaboration. Anxious due to unknowns, mostly in local (Norway) activities. - c: NZ, investigating how to get a longer life out of old hardware - refurbishing, rehashing, reworking, debloat. Resiliance: big storm that knocked out power. Mobile + fiber ran out of batteries/generators. - sa: Staying at a friends. I have a website now, which is great.

Minutes: - J: reticulum/Lora - seems like mesh networking has one main usecase: messaging. And that's a killer usecase, necessary. Everything else is mesh-native apps. What I'm pitching is an unholy marriage of web servers and mesh networking. Serving up sass, especially in domains other than messaging. We started with a messaging app as a demo ,though. - J: What would be the most interesting non-messaging app? Though about this a lot. Some of it is geographical in nature: library of things, etc, if the objects come from the same place the server is. Want to avoid trap where we build th software from scratch. So, what existing software could use messaging for sync? - J: kanidm - already have p2p message based sync. What else? - p: new to the mesh networking biosphere and p2p stuff. If the peering is on the backend, how do we make this transparent for people using and administrating the services/servers? So it doesn't require patience, grit, technical knowhow? - p: I put a surprising amount of hours into getting reticulum working. It's mostly there now, but wouldn't expect others to put in the same effort. - J: reticulum is the wilder west option of the mesh nets. there are non-technical people using [missed] . It's on us as technologists to hide that transparency from users. There's something to be said for eventual consistency. Users are used to low-latency high-bandwidth web apps that ship huge amounts of js and provide their own experience. Changing that might be necessary. Trying to solve the problem: how do you make a good user experience, e.g. "your message has left your phone, but hasn't necessarily arrived at the others". Users have to get used to very different experience. If we build custom mesh-native (event-sourced + eventually consistent) apps, they can provide good feedback to users. We mostly see those developed in the local-first space, not the server space. Interesting question if we can create this unholy blend. A sweetspot might be email - people already expect event sourcing & eventual consistency. I use emails as an example when describing lores. We could even use existing email servers as underlying infra. - J: the groups that are using mesh apps are largely rugged individualists and libertarians, not a lot of conversations about commons.

• Sa: comparing to an old system of SMS messaging, evey member of a decentralized group

  • J: don't think it's a requirement that things are event-sourced, but there are examples that aren't, e.g. Willow. Some protocols p2p sync large data structures rather than messaging. Most of the local-first space is using event sourced
  • st: how would bittorrent fit into this, as a decentralized version of file storage?
  • J: bittorrent is another example of a non-event sourced eventually consistent tech. docuwiki is based on a file system structure, not a relational database. So it could work for that.
  • J: bittorrent is a p2p network across existing inernet infra, there are other examples (Iroh). Meshcore/meshtastic ignore the eixsting strucutre of the internet. They make a new data link layer on existing network intefaces.

• J: wrt email, there was a geographical parallel: each domain would correspond to a building. As the internet was more interconnected - there are still controlling nodes - but we've moved away from geography. Wondering what it'd look like to have something based on local geography.

  • J: contrast with fediverse - your local organizers manage tech themselves. Your server can have its own policies and be isolated from the big bad world. But if it's in a specific place, you need to be able to connect to that place. How does that work in a mesh world? If each neighborhood has its own server and each runs its own mastodon - in a Mad Max "no internet" future it's cool that you can go to your local library and check your feed. But in a world with Internet, it's awkward - "why do I have to lose access when my library's server goes down?"
  • p: Same thoughts, geography is a natural organizing structure. For organizing/social aspects of building tech autonomy. Our local area loses electricity often - it'd be good to maintain a connection w/ outside world. We often have cell reception but no home electricity. Maybe a k8s cluster in the region, plus duplicate workload in another region would let you keep access. But doing k8s is hard. Pitfalls wrt running servers + databases geographically distributed. It might not be the best avenue to approach it. Haven't used docker swarm; is that viable?

• S: usecases, where either a malicious actor or natural disasters are attacking internet infra. Are those good examples of non-messaging usecases for mesh nets?

  • J: in these cases, local-first software might be better. E.g. sneakernets. Scuttlebut had its problems but did really well. A different thread: as people who run centralized infra, we can support the rolout of local-first apps by providing syncing servers (not necessary but useful)
  • J: local-first, some talks
  • J: local-first usually want something to start the handshake between peers, and cloud backups of your data. Sometimes that's the business model. But what if that was a general protocol: a standard syncing/backup server that you can use with any range of local-first apps. I don't think local-first apps are there yet, but we can keep abreast of that.
  • J: do we build SaaS, local-first, or neighborhood-first tools?

• S: let's talk about digital autonomy for Rojava

• p: requests no notes

Check-outs: - st: I'm interested in meshnets, may want to pursue in future. Want to hear more updates. - S: love the chat, Jade you're a fountain of knowledge, thank you for sharing. Papiris, all the support. - J: a bit guilty that we focused on my special interest - p: thought-provoking talk, fog is lifting on what avenues are interesting to pursue.

2026-06-11, 19 UTC

Sarma, calix

Q: Why are these slots drying up so much? - FOMO around 12 UTC ones - Seasonal stuff

Topics: - PR review - docs, some old/wrong kite flying info

Minutes: - code looks good - Q(S): where do I see the build process? - c: in the README there's a link - build failing, due to authentication - c: would be good to move off of my credentials, and use the abra bot token - switching to the abrabot auth fixed things

Discussing https://docs.coopcloud.tech/federation/organisers/#kite-flying-hours and https://docs.coopcloud.tech/federation/handbook/#kite-flying-hours

• Proposal (S): let's have just two toots, one for 19 UTC one for 12 UTC kite flying, and boost them at set times before each meeting
  • c: let's start next week
• Q(S): taking a step back, why does KF need to be mentioned in these docs?
  • c: could see an argument for "how to attend kite flying" and "how to organize kite flying" for facilitators: posting on mastodon, facilitation structures, etc.
  • c: neither of these two places do this. Organizers' intro is slightly more focused towards facilitators
  • S: nothing on Federation landing page about organisers / organisers handbook. Have to find the menu, hidden by default on narrower screens. Who needs to know about kiteflying, that it's paid, how to run it? Could sometimes be someone's first way of learning about CC. Or for really gnarly questions.
  • S: Also envisaging how this will show up post-new-website.
  • S: Nothing on homepage about kiteflying. Need to scroll down to https://docs.coopcloud.tech/intro/get-involved/
    • c: could be bigger
• c: what you noticed about organizers, it used to be a top-level section but got moved to federation. Agreed that it's missing from the federation landing page. Good to think about the intended public, and agree that people new to coop cloud are an intended public. Agree that it should be bigger on the get involved page, and we should add it to the contact page. New website should make it more obvious in general; in the short term... worried about the scope of moving the organizing pages.
  • c: at least, we could remove the duplication between the two pages

Pause in conversation, time for the build to finish. It succeeded!

• c: it only published one image?

  • nevermind, they images are listed under different versions in https://git.coopcloud.tech/coop-cloud-chaos-patchs/-/packages/container/hometown/v4.5.6-hometown-1.2.0-streaming

• S: should be quick to add a new chaos patch version. Abra recipe will have its own tag-based versioning referring to these 2 images.

back to kiteflying docs:

• S: Not sure docs belong in either of these places.
• S: Not sure about formalising kite-flying, currently personal. Don't want to put pressure on facilitators.
• S: Seen reminders as part of individual responsibilities of facilitating. Goal is to get people in the room and get them talking. Complete holistic strategy of where, how to announce. Make it flow with your own style. Of we want to make a "how to do facilitation" doc, keep it light, focus on goals. If we want to make "how to find us and how to join" then we definitely need an uptodate link (calendar?). Big Shiny Button, as close to homepage as possible. Under BSB = link to calendar ICS, basic boilerplate and call to action. Remove both of the things we have now. Mention compensation.
  • c: support that idea. what about "Get involved"? and https://docs.coopcloud.tech/intro/contact/?
  • S: can't find contact from the homepage... need to click docs first, then "get in touch".
  • C: "Contact" should be one of the big links at the top of website homepage. 2× BSB
• Q(C): is any of this controversial?
  • S: Shouldn't be, but we should give the PR a few days if we're changing the main page, out of protocol if not necesity

spending a few minutes working on: - https://git.coopcloud.tech/toolshed/docs.coopcloud.tech/pulls/322 - https://git.coopcloud.tech/toolshed/coopcloud.tech/pulls/60

Check-outs c: good to do something during KF, hackathon style S: was concerned, hoping people would be on, finishing off with getting a thing done felt good! hometown++.

2026-06-04, 12 UTC

Sarma, d1, kawaiipunk, jacob

Intros: - some connection issues - bird noises on Sarma's call - d1 in barcelona heading to hacker village thing, well rested, no notifications in 8 days, Local-IT talk was inspiring, made me want to talk about - k: jitsi unreliable from one instance to another. - j: any pronouns, overwhelmed/low energy, dissapointed with many of the left politics workers orgs I'm organizing with

Topics: - Local-IT/DTF talk - how to keep motivation up, not burn out - Economics

Minutes: - starting with motivation - d: jacob, you called in with sheep and cows sometime, right? - j: we have two horses born two days ago! - d: my standard is "go touch grass", but you seem to be touching a lot of grass. Where is the motivation running dry? - j: so much work at the farm, little time towards what I want to do. Farm work is unpaid (family farm), financial situation is dire; no economic capacity to do the opportunities I have. Orgs that I'm part of are doing digital stuff top-down; not consulting IT members. Invited to a youth delegation to Rojava, but the orgs (radical left, workers) require a formal application a long time in advance, which I can't do. Not enough support to help me achieve their level of bureaucrac. So why bother? Wrt digital sovereignty collective, lacking space to follow up, lost potential. Not doing, thinking about it fills with guilt, saps energy. - S: figure out which orgs make you happy and can support you, focus your prio on them - d: prio of people's happiness and community care, not sure what to add, but v. important and relatable - j: appreciate the advice. I'll take it up with my orgs, especially asking for something the person is bad at doing. Thanks! Animals need tending, doing farmwork so the animals don't starve <3 - d1: farm work sounds super citical important, life giving sustaining - S: was having a chat with mikemh about organizing a meeting of experts to discuss how infra can be financed. They wanted to get people in who have experience financing (non-digital-infra) community orgs, as well as people with experience running global federations/syndicates where local orgs can benefit from the global. (I'm concerned that with the groups proposed the topic would be too vague, and if we focus on specific questions we'd end up with very different participants). Someone in matrix said we're asking people to pay for something they get for free. And we're offering a necessary and brighter future. - d1 coops usually put a "coop veneer" on it but this is just like bio veg, kinda better, more expensive. this is social change and not social transformation. thr basic strucure of domination is maitained. so i think we also need to "fight" a conflict with the users lol. they are not our enemies but they somehow stand in our way because they need to do real mutual aid and pay us more. - S: would love to see a career path that's just getting people into collectives that can act as clients - so that service providers don't have to also provide the service of community building. - j: Users' union? - d1: we always imagined this, though it doesn't exist; multi stakeholder coop is the more liberal form - S: Reason I want this as a career path and not an organizational form, is that there are lots of ways to connect people - along region, ritual, etc. - d1: what are our interests ultimately, and why are they so divergent now? users and hosters - S: two visions of money, one being a marker of "here's how much I've contributed/benefitted", one being something contorlled by capital, where the bulk of money earned/spent is with capital. Hard to ask someone underprivileged, who spends most of their income to capital, to go to their farmer's market instead. We'd need a kickstart, money which can be spent into the community. - j: skipping the money question, could we focus on what people need? find providers for these needs (housing, food, transportation) so even without money we can ensure people have necessities. - S: are you proposing a barter system, or am I oversimplifying? - j: more like mutual aid. People provide what they can, and get what they cannot provide met themselves. - d: this reminds of that point that you cant make succesful economic interventions without considerin the cultural and political dimensions. interdependent fields. we should be careful not to mix what should be with what is. When speakin of money, we need money now. - S: Thinking of myself as a contractor, along the lines of a plumber, electrician, bike repair. The closest thing in IT is computer repair work; the smallest "leap" towards community infra. Gonna talk with a small local marketing firm to figure out how to communicate to people that I'm making this leap - that I can provide services for their friend group, or get them off instragram. Because if I can get an individual to buy a server for their friend group, I can start charging projects to the group as a whole. - d: these problems exist for our neighbourhood, city, region etc. i struggle to believe that this work can be made sustainable with solutions for individuals. e.g. "getting on fedi" looked like https://prikbord.page/ for rotterdam. a mass mobilisation in effect. this experiment is not finished but i am looking at it closely. i think the conversations are a really good idea - j: are you part of any community associations? The associations near me haven't taken me up on offers to run their infra (podcasts etc). But local associations are aware that digital infra is infra, and are open to paying me for running that for them. Might be the case for you as well. - S: I've tried to be, but a lot of the orgs respond with "we don't have enough to pay ourselves, so certainly can't pay a contractor" and only accept volunteer work. - d: that is the thing to fight in that sense - the relationship of volunteer with associations - S: I do want to work with associations, long term. But the work of convincing them that hiring me will be beneficial (over volunteer work) can take months, years. I need a financial base first, and starting with individual clients and working outwards feels faster than starting with associations. Once I have a base, I'd like to actually do volunteer work - not to write infra, but to do workshops and get people talking about infra. - d: nubo.coop got up to 100k in city funding (public). It's super inaccessible; we need a way to start that doesn't take years.

Closing: (what will stick with you, feedback on KF, what are you doing next) - j: Thanks for reading the chat out loud (accomodating I'm outside). Big topic, touched on interesting points. Want to do more stuff, but know I should do less. I'll start by making the orgs I'm part of aware I can't keep doing stuff the way I'm doing them. I'll have to get back into thinking about more stuff after. - j: enjoyed the format today. Might feel lonely with one person on voice and the rest in chat. But hearing a voice feels more human than reading text. - d: enjoyed it! Need to keep thinking about the economic question; it needs focus. - S: feeling heavy after the economic question. I want it to reach the ears of people who have success stories; will give more thought to supporting mike's proposal. Feeling a bit more confident in what I'm doing, trying to place my work in the context of an individualist culture without becoming part of it. But, it's still scary. Next: server work, mentoring someone on how to make oss contributions.

2026-05-28, 19 UTC

3wc, Sarma

Sarma: chilling and grilling (vegetables) 3wc: catching up on 100 gitea notifs

Sarma is a member! 👏

Conversation about commons.hour / economic sustainability.

"How do we take a product that a lot of people don't pay for and convince them it's a good idea to pay for it" a.k.a. how do we use bottom-up, collective funding strategies, and apply them to any of our groups / coöps / members. Currently brain-wrapping, what is the question?

https://docs.democratictech.fund/s/7c2a75d9-fb21-4bd3-a8a9-145b13225b3b/doc/economy-of-infrastructure-commonshour-LG80tBJyvi

Unknown status on whether FKI/DTF is hosting these commons.hour S: might want to touch on these topics in future KFs, if the commons.hour doesn't pick up.

c: will read this. If you can think of any ways that CC can help push this forward, it'd be cool if these happened. A lot of people in the CC community would be interested in these topics. It'd be cool to have collaboration.

Q©: how was last week's session?

S: Last-minute change of format! Different venue, recording. Brief panic. Kollicloud is a cool thing! Tech: alakazam, refined into ready product. c: really interesting they're targetting associations rather than cooperatives.

S: Better word? "Collective"? "Community"? Solving process problems of an Association, easier than companies (or other non-association).

S: Social/economic aspect: 3 options, self-hosting, community hosting (hybrid approach, federating with Local-IT), managed hosting. Community / hybrid has been floating around in Co-op Cloud community, Kollicloud is the first write-up I've seen.

c: wondering about it in combination with what we discussed 2w ago, of contributing your compute to a group you're joining. Different ways of collectivizing - sysadmin and the service provision

S: Agree it feels connected, hard to define.

Permissions

S: Chat with d1, explaining "optimistic merge" approach of encouraging new contributors, let them break things -- rather than making people go through a long process. Did similar with own infra recently: radicale crashing every few days, gave a friend root on server, "try and fix it".

3wc: Anything outstanding?

S: Fedi

3wc: Uhh I lost the password. Let's ask the federation.

S: "Radical trust" compared to usual IT interactions.

3wc: in opposite situation in some groups. Improving opsec, partition access. So not everyone in the org has easy access to the full contact list. Haven't heard any good answers. Permissions for everyone else + permissions for tech admins. Admins don't operationally need contact access, but since the - centralization of access/security assets based on tech skills. Maybe we can expect tech people to be more careful, but it feels weird from a decentralization/democratic perspective. 3: a lot of the systems we work on tend to inherintly centralize to who has admin access. With CC, we operate in the open and (almost) everything we do has a version history. In our threat model, it's not a bad thing if random people get info from our servers. So radical trust makes sense. 3: The usual IT interactions don't solve this either. Even if you have 10k layers of access cntrol, sysadmins can still do anything; tey're exempted.

S: Definitely something I've felt. Weird disconnect. Historical anarchist perspective, organising during the development of tech. Pre-encryption comms: sending message to 2 people (redundancy). No-one in the org has a full list. 2 copies of every message. A lot of systems make the assumption that centralised power is a good thing (corporate context). Wonder if decentralisation of power/access requires the lowest layers of communications to change… or can it be done with the way things are working now? Merri-bek, Lores — for a different purpose, but also a lot of small machines. Maybe a central system currently, but aiming at fully-distributed? Sysadmin can push software changes, push those through the network. But what if they only have knowledge of the 2 nearest nodes? Make a fix on my laptop: instead of deploying in once place, send out across other places, propagated to other servers?S:

3: curious what the capabilities of p2panda are. Agree there's something in human-powered redundancy/partitioning practices that could be useful for inspiration. Don't know if feasible to apply these practices to client/server model. In our labor union, we wanted to split a key to open a door between multiple people - to enforce a rule of doing something on the server with someone else. To prevent me from downloading the entire member db, I can only access the server when someone else is there. But we couldn't figure this out - wherever the key is entered is the weak point where one of us could grab the other part of the key. Analogy: box with multiple locks, that will only open when everyone with a key shows up.

S: Still looking at a system where a minority can access - ⅔ people who need to bring their keys. Parsing threat model: union = membership status dangerous to leak. But still need to verify membership status for login etc.

3: another layer: part of the union incoporates a lot of incarcerated members. Threat model, beyond the normal threats of union membership status being revealed, these groups end up categorized as prison gangs or other bs. So only people in the incarcerated members group should know who is in that group. But everyone's membership is in an CiviCRM instance - in an SQL database. Architectural problem: admin access to the system means you have ac

3: in a kollicloud style federated hosting, how can I help administer your server without being able to download your users' data?

S: Laptop-sharing situation: we are storing data that's not meant to be shared. But e.g. someone's roommate could come in and grab the data. Our solution: encrypted VM, which cannot be started unless someone who knows a password accesses from outside and starts up the machine. If you had that sort of solution on a database somewhere: separate, airgapped machine which has specific members of incarcerated group, could you make it so that when someone accesses server and does any work on it, that connection gets broken, cannot access that particular DB? Impossible to do work on server while connected to that DB.

3wc: So some kind of maintenance mode?

S: Similar to our case: protected from accessing inside of VM without password. Difficulty there: if someone restarts machine / takes out HD, could open it. Hence encryption, but where to store key?

Closing: 3: a lot of enthusiasm about doing a multinode demo on a KF sometime S: really busy, but eventually will do.

2026-05-21, 12 UTC

attendance:

:::info This week's KF has been isekaied. Instead of flying kites, we'll be learning about Kollicloud. :::

:::info Meeting and minutes here :::

:::warning a portion of this meeting is recorded :::

2026-05-14, 19 UTC

Sarma, calix

• Sad I missed sheep, but it's a very coop cloud thing to be tending to large mammals while talking about decentralized tech
• Summaries: spoosn and time intensive. Maybe we can get volunteers, maybe draft it in the pad itself.
  • +1 to drafts in pad
• proposal: checking in on wednesdays to confirm KF and collaborate on reminder text

Introductions: - wedge he/him from DC. Fixing issues. Want to see how I can contribute. Want to learn go. Mainly work in Java, Python, Ruby - sarma they/them from Poland. Tired, lot of work in starting a new business. First client! 🎉 - calix they/them, from (spelling) aka NYC. Gave security workshop this morning!

agenda: - how to contribute (w) - upgrades - some recipes got a push to become more stable, lot of issues with migrations, things breaking - possible solutions for that?

Minutes: - Q©: what are you interested in? How could it be more obvious on the wbesite or the community how people can contribute? - w: want repos to have "good first issue" tags. I look for low hanging fruit I can knock out to get used to your development flow. Otherwise, I start by updating README - s: can dig out URL for searching by tag, don't know if we have a standardised tag for that. I was looking for "critical fixes" i.e. ones we have a budget for. https://git.coopcloud.tech/api/v1/repos/issues/search?state=open&labels=critical+fix - action 3wc: post in new website chat about "good first issue" link - s: differentiate between abra issues and package issues. Maintenance things: searching by "status: 0" in the recipe catalogue. Usually a service that someone has put some effort into getting to work, but hasn't finished. Good maintenance challenges for training. - w: appeal of abra was working in go, can do things as needed - w: never used gitea outside of my own. Do I need to make an account, or can I use mine in a federated way? - c: not sure, but believe gitea can be a Single Sign On Provider. So in principle you could use your gitea as the provider for the coop cloud gitea. But surely there's a better way. Miss Oauth1. - w: know a fair bit about SSO, unclear what happens when you add a federated user. Could probably figure something out. - c: forgejo (fork of gitea, nearly compatible with gitea). Someone's working on a grant funded ActivityPub integration. This could eventually get ported to gitea. - w: wrt maintaining recipes. Is it a matter of spinning it up on your own, see what's going on? Do you need to run deployments? I want to use a miniPC to spin up docker swarm and start some deployments. - c: if you've deployed an app before and you can see that an existing recipe, based on your experience, should be done differently - then you wouldn't need your own deployment. - w: might need a test deploy system. Each recipe has its own repo, a matter of cloning that repo, replicating on my own deployment, and fixing that repo. [wedge leaves]

M-M-M-M-M-M-M-M-MULTI-NOOODE - s: initial goal: running on a potato. small upgrade, storage bucket. mastodon server, imageboard, git, email, etc. for 10 users all from lil VPS. eventually ran into server crash - mumble + photo browser. Attached extra offsite hardware to server. Layer of VPN + docker swarm TLS. Additional measures on hardware. COMPOSE_FILE to add custom properties to e.g. force an app onto manager node. Whac-a-mole moving services onto manager, then it works. Biggest issue: data storage. For now just moving anything that cares a lot about volumes or databases onto manager. Ideally: several nodes just for data storage. Might be tiny jails in someone else's VPS, or more well-connected & secure off-site hardware. For now, challenge is "which services need to run on the same machine" vs "which can run anywhere". Dream: someone joins community, has hardware = follows a guide, contributing to computing pool. - 3wc: WOW. which recipes in which category? where is traefik? - s: traefik on manager. maybe it supports some multinode? in general recipes you can move db service to point to a consistent node. hedgedoc, many others

# .abra/compose-files/compose.db-on-manager.yml
version: "3.8"
services:
  db:
    deploy:
      placement:
          constraints:
            - "node.role==manager"

# in an app's config
COMPOSE_FILE=$COMPOSE_FILE:../../compose-files/compose.db-on-manager.yml

• s: as it becomes clear which apps have preferences, move selectively. manager needs to run anyway, might as well put data there
• 3wc: does Jade know about this???
• action 3wc ask jade
• 3wc: ever done multiple services using scaling?
• s: not yet
• 3wc: any distributed storage yet? or "if it needs storage it goes on manager"
• s: "if it needs storage it goes on manager". garage people said "pls don't do that lol", buckets accessible by any node. file locks. better to have dedicated server. becomes less of an issue if app itself can connect to S3 directly, or DB directly (then you can use weird postgres solutions presumably)
• 3wc: any thoughts on how this could be included in co-op cloud?
• s: current solution, in theory you don't want a lot of things running on the manager. think it would be good to have project conventions for specific node tags, e.g. "database", "s3", "good gpu". then (always optional) compose files, e.g. compose.multinode..., push to every recipe. For multinode, can use those tags. Optional because otherwise operator, even single node operator, would need to put tags on everything they run. Depends on requirements. Difference between database = probably safe to put on any node / storage = might need to manually sync
• 3wc: built into docker swarm?

• s: yes: https://docs.docker.com/engine/swarm/manage-nodes/#add-or-remove-label-metadata

• 3wc: amazing social intervention with the "bring your spare compute"

• 3wc: how can maintainers / abra devs / community help?
• s: documented somewhere in the maintainers' guide "something to watch out for" might help detect issues earlier, get people more experienced with. today: gitea: no reason AFAICT that the app would need to run on same node as database… for some reason it's been necessary, don't know how to start debugging that.

• action 3wc draft docs paragraph, s to review

• s: bounties for getting a recipe up to stability. upgrading (especially through a few versions), often causes breakage. how to make upgrade testing part of the process. might be good to find a way to look back at the history.

• s: add to "state" tag, 5+ for testing historical upgrades

Checkout: - c: cool to have a freewheeling discussion. Need to process the implications for multinode. Future KFs: agree it'd be good to have a process around announcements. In the next month would like a themed KF around trying similar things to Coop Cloud. -

2026-05-07, 12 UTC

Sarma, sorrel, jacob

Introductions - sorrel: one meeting with d1, laying out the todo. Still need access to some systems. Intro process just starting this week. - Q (Sa) - do you have experience with CC before the call? - s: yeah, our coop is looking into using abra for our work. Have contributed to some recipes, but not using for deployments yet. Been engaging with CC for a short period before the call. - Q (so): how long have you been around - started poking at abra 3-4 years ago, for hosting a couple services for a friend group. Last year during CCC, I chatted with d1 about some paid abra work. Since then have been doing more work around maintenance and kite flying. Facilitating since Feb - Sa: want to get paid for maintaining recipes so I can spend more time on them, not sure if we have the budget for it.

Agenda - so: no topics, but want to connect with folks. - Sa: could talk about maintainers / getting people involved.

• so: haven't heard from d1 about maintenance issues, but observed them in some recipes. Our coop wants to deploy nextcloud, but the nextcloud recipe lacks a set of maintainers. Took a bit to figure out who to talk to.
  • Sa: convention to talk in the Tech chat or drop an issue;
• Sa: someone said recently that about 10% of the recipes have maintainers. Which is fine, many of them aren;t used by anyone. But hosting orgs need stable recipes, otherwise de facto they do maintenance.
  • so: alternative for orgs is to run recipes in chaos mode forever
    • Sa: I have done that for 1-2 recipes, for years.
    • so: it's a strategy to avoid the maintenance burden.
• Sa: abra issues can have a budget if they're high prio; maintenance work doesn't even for high prio recipes.
• Sa: different opinions about how much administrative overhead. Appreciate the freedom given to maintainers.
  • so: maintenance instructions in the docs, don't line up with the recipes I've looked at.
    • Sa: if a recipe hasn't been updated in a while, the docs are newer so the recipe is missing stuff. But also, sometimes the instructions don't line up with the needs of a recipe.

[jacob joins, surrounded by sheep and lambs] - ja: read about the radmin. How are you? - so: not surrounded by sheep, but doing well

• sa: looking forward to finding out what's realistic for funding
  • so: I want to start with where people are experiencing pain points with the process.
  • Sa: thinking more about pain points in the adminsitrative process? Or in the budget? Or both?
  • so: yeah, like you mentioned, "how do I know if there's a budget to invoice my work?". So, kinda admin - how to make it possible to renumerate your work.

• Sa: I should probably get involved in writing proposals - that's restricted to members, but I'm already in a lot of conversations about it.

• Sa: interesting to see a coop here that's still trying to figure out if CC is right for them.

  • so: main reason we haven't shown up to KF is scheduling concerns. We were using a big ansible deployment, and we won't ever completely get away from that because some of our services aren't containerized. I've been having a great time with abra. Biggest problem is we'd love to see recipes that don't exist yet, or use recipes that haven't been maintained in a long time. We want to simplify the number of tools.
  • so: the bigger question is not "do we use abra" but "do we have the bandwidth to maintain recipes?"
  • so: experience of using abra has been great; occasionally need to dig into the server
    • Sa: yeah, often need to use docker commands directly
• Sa: what recipes/services are missing?
  • so: zulip - someone set it up a year ago but no one else hsa touched it
  • so: we're trying to solve moving ldap server to a containerized deployment. Because RedHat makes 389DS(spelling?) more available to RHEL, we'll have to build our own containers. Technically free, but in practice costs a licencse.
  • so: nice to have : nextcloud integration with one of its SSO apps, so it's accessible from abra rather than the contianer's cli.
  • Sa: a lot of people have discussed nextcloud as a high prio app. We haven't discussed Zulip but we do have mattermost relatively stable.
• Sa: it's a pain point for migrating servers to coop cloud, that a happy path exists using traefik and authentik; if you use nginx or different LDAP providers it can be a pain to migrate. It's temtping to just move the configurations to traefik+authentik, but that's not always realistic.
• Sa: there has been talk a while back of formalizing happy tests, where combinations of recipes would be tested by maintainers.
• Sa: I'm surprised there's no formal maintainers on nextcloud, with how many CC members use it.
  • so: there's an issue with discussion, and there are de facto maintainers, but no one's closed the issue yet. Actively being discussed.

• Sa: trying to understand the LDAP situation better

  • so: wrt 389DS, no up-to-date tags on docker image repositories (quay, dockerhub). RH only pushes to the fedora ecosystem
  • Sa: standard approach in CC is to always prefer the official image, even at the cost of slower updates.
    • so: might be othe rCC members won't have a use for this, but for us a consistent deployment is more important.
  • Sa: trying to think how to share the work here. Might be that the 389DS recipe needs a chaos-patch image and an official image, as two release branches.
  • Sa: need to look into whether other recipes would care if youre using authentik or 390ds (or other ldap).

• Sa: a lot of orgs say SSO is the best way to convince a client.

  • so: yeah, we consider it required.

• Sa: jacob - any questions/comments?

  • ja: never used abra, and I'm not a member of the CC federation, so not much input. Seems interesting.
  • ja: in datakollektivet, we might start using coop cloud and hopefully become members. Having difficulties getting people to engage/become active in social/organizational/software aspects of datakollektivet. Do you have any tips? We've tried to do open nights, KF thing, but few people show up. We have 70 people in our matrix room, but a lot of work falls to very few people.
    • so: it's really tough. My coop is 3 people, grew out of a computer club. When some of us were interested in formalizing our work outside the club, it self-organized into a smaller group.
    • Sa: don't make 70 people your goal. Keep your meetings spoons-positive so that people who do participate stick around. And let others join when the agenda encourages them to.
    • ja: we try to be mindful, do checkins/checkouts, make sure people feel seen, and even if we discuss serious topics we end on a debrief. We're trying but it's not easy.

• Sa: dissapointed we only had a short time to discuss that. Maybe you'd like to join next week or the week after

Checkouts: - ja: a lot of the topics went over my head. Multiple connection issues with Sarma and myself. For future KF, maybe discuss how to organize better. CC are mostly organizations I gather, so maybe we can do something for members outside of coop cloud. Feeling good, will do hacking and take care of the sheep. - so: my first KF, exciting. We talked quite a bit despite not having topics! Thanks Sarma for faciliating. Future KFs: have a specific thing prepared, in case people don't have burning questions. Discussions about organizing is a topic that's always timely. Next up: breakfast, hacking on coop work - Sa: hope I could help with some of your specific recipe quesitons. Don't think people have suggested evergreen topics before; I'd like to discuss with 3wc to see if we can agree on a few. Next up: meeting with friend to either do ZNC recipe hacking or OSM contributions.

2026-04-23, 12 UTC

Sarma, sef

Introductions - Sarma/Amras - - sef: with doop coop did design work for coop cloud way back, just the other week started deploying things. Got traefik, rauthy, tuwunel and want to connect them. Avoiding synapse. - Amras: why choose rauthy over authentik? - sef: authentik is very resource intensive, built for corporate/large loads. Rauthy is capable, lean, and ugly. - Amras: there was talk some months ago about happy paths, where we would focus our maintenance on specific sets of recipes. So we could - sef: seems easy to set this up; I've done it for other applications. the difficulty is networking between containers. - Sa: generally the only thing that needs access to the outside world is traefik's socket proxy - sef: minutes/payment - sef: wht business are you doing? - Sa: broad outlines known, focus customers who need independent tech stack (maybe govts, maybe privacy-conscious folks, maybe leftist orgs). Might also poke at people who have heard about self hosting and want to try. - sef: it's a tough problem to find clients; if you exclude people with privacy concerns, it's hard to argue for self-hosting. SSO and a single identity base are a good argument, since the alternative is enterprise cloud level. But hard to sell that to individuals. - Sa: where are you located? - sef: Sweden - Sa: interviewing people with various perspectives. MS's offer is cheaper and covers a lot of people who would care about SSO/identity/own domain - sef: in europe there's a sovereignty discourse wrt american software, but people don't really care but it's building - Sa: tried joining a collective that tried to build non-american solutions. Their argument was usuaally about customer service. But then you have to convince your customer the company they're doing business with is lying to them. - sef: with a major product there's usually a solution to be found somewhere; obscure software requires giving support yourself - sef: are you maintaining anything? - Sa: not formally; I work on packages but I never get around to cleaning them up to push. - sef: would like to help maintain tuwenel if I can get it working. - sef: if you're gonna fix it you might as well fix it for others. More boring to maintain stuf you don't use; needs to be your own headache. - Sa: working on a solution for multi-worker-node setups. It's working but it's opinionated so need to figure out a general solution. - Sa: when we talk about being service providers or hosting services, the focus is on the business proposition and the tech stack. But there are specific social issues that we can address, like friends who never meet or a city that gets no feedback from its citizens - which won't be solved by an enterprise salesperson; but these groups won't know to ask a service hosting provider. - sef: in an SSO nirvana, you can combine dedicated apps; the combination becomes powerful. It's harder to keep a library in your head of commercial web apps/products. And products sometimes pivot to become something different. OSS usually stays in their lane. Aetherpad isn't pivoting to AI block chain, so it's more reliable. - Sa: permacomputing perspective is you don't need to update self-hosted stuff, so you get stability. Though that's not entirely true. - sef: you need to maintain it (maybe unless it's on your LAN) for security and interfacing with the open web. - sef: we're hosting apps for orgs, where a commercial counterpart becomes enshittified over 8 years, so their work goes down the train with the product. The permanence is desirable. It's a hard sell, because you won't notice the difference until years down the line. - Sa: maybe that's part of the cost proposition: sell the self-hosted stack as a pair of good shoes. One thing I feel is central is emigration, painlessly leaving the ecosystem and keeping your services running and work alive. - sef: (great skill to have, minutes) - sef: we have an org migrating off facebook. Wonder if they're expecting a new facebook. It's a costly emigration, need to set up new userbases etc. SSO is very helpful, because people don't want to set up 7 new accounts. - Sa: SSO has come up a lot during kite flying; I've been cautious if it's oversold; can you really sell a tech stack on SSO? But maybe it is such a big deal, a lot of people mention it here. - sef: seamlessly being signed in when you enter a new application feels right, though you might not think about it. - sef: interesting to see how we can integrate more SSO configs into coop cloud. Cloudrun(?) maintains downstream forks with OIDC plugins. - Sa: I should play around with that more. My infra needs SSO but I've been procrastinating on it. - sef: anything on the new website? I ran the survey and workshops around that material. I want to see if there's something to look at. - Sa: best check on Matrix; everyone wants to see a prototype but nothing's available yet.

Check-outs: - sef: good meeting you; idea for kf: more live work - someone tending to a website or working on a recipe. Will be poking at services. - Sa: we've had demos, on the website and monitor-ng - there it was someone showing a running service. - sa: will be in touch with 3wc to get better access to the mastodon account to get kite flyings advertised there.

2026-04-16, 19 UTC

calix (3wc) - facilitatin, diatom, Sarma - notes, jacob (papiris)

Checkins: - Sa: a little throat-ill so won't speak much; taking Jade's advice to heart on income sharing pods - d: meeting with (?) - c: at Take Back Tech in Atlanta, met people from Movement Infrastructure Research. Excited Guardian article mentioned coop cloud; spoke to the journalist a month and a half ago. - j: (any pronouns, any pronunciation) calling in from public transit. since last tuesday met 25-30 leftist/antifascist orgs keen on collaborating on cybersecurity and digital sovereignty. Things are looking movement-like.

Agenda: - orgs that jacob met - diatom: paths forwards on new website - sarma: multi-node storage setups - diatom: security best practices

Minutes: - d: having trouble keeping up with matrix lately. - d: rate of vulnerabilities is increasing quite a lot, security landscape is changing - spinning the wheel to choose topics ... jacob's orgs! - j: met Solidarity Commitees for Kurdistan & Palestine. One of the members also involved Ship to Gaza in Somuz Flotilla. After events 2011, Norway has very active democracy/participation center in (island name). Keen on civic society and the population not being radicalized to the far right by ad companies and social media Algorithms. Keen on collectives and reclaiming control of democratic discource. - j: Socialist Party made exit strategy in case the US holds state of emergency. Keen on helping antifascist orgs get started making their exit strategy. Testing alternatives, making migration paths. - j: Youth Workers' Committee organizing shop & office workers' admin stuff. National meeting was this weekend. Care about digital sovereignty. (Friend) pushed sovereinty through so they're gonna do it. - j: 15-16 more orgs in norway, another 5 abroad. Don't have a list on hand, but giving updates on mastodon, hackaderm.io(?). Might make a blog about it someday. - s: what' the event you're at and how did it get organied? - j: just me. I'm very active in various leftist woekrs' movements in Norway, somewhat active in solidarty/climate movements. So this is me reaching out to people I know, going to their places and meeting as a fellow member of their org, or as a participant in their movements. Sometimes just showed up at their offices. - j: the biggest planned event, which paid for my ticket, was a Union Political gathering for the young unionized workers of the workers' confedertion I'm part of. - j: also meeting the minister of municipalities and districts, who has some responsibility for digital stuff. Asking, what do we do when the AI bubble bursts. Norway's sovereign wealth fund is invested 30% in US, heavily in tech stock. Estimated loss 10% when it bursts, plus cost to society reliant on big tech actors. - j: I go to people, say "you and I need to acknowledge there's a threat here. Let's work on it with similar movements, so you don't have to handle it in isolation and we can learn from each other". Orgs find that reasonable and want to be part of it. - c: inspirational! - s: wildly impressive - d: What's your next step with these orgs? - j: first step: organize workshop "how does your org take first steps to digital sovereignty". Mapping needs, exit strategy. Plan to do this end of may and invite all the orgs to that. There, we can discuss exchanging information between orgs so I don't have to be the linchpin. - j: some orgs want a forum, like the Red Party. Other orgs (esp. unions) don't want yet-another-platform to sign into and relate to. - j: once orgs share needs with each other, situation will become easier. Collaboration between relevant orgs. - sa: Sociocracy has models of circles with people interfacing between them; wonder if the orgs need a central digital solution, or if it'd be enough to do a smaller scale thing where representatives can meet? - j: logging off, may reply later. - choosing next topic... security - d: some people were working with ansible to have a reasonable set of defaults on a new VM. firewall, making it hard to expose your docker port to the internet, general docker stuff. Some people were writing "you should know best practices and apply them". Recommendations for securing installation are ~400 pages long. Is anyone talking about this stuff? - c: no chatter about this recently. We have an FAQ on container security. Agree that there's an overly large attack surface. FAQ talks more about the containers themselves - like whether they're built on versions with security issues. - c: dockerhub shows vulnerability infomration; maybe we can make that more visible to operators/users - c: wrt ansible - if you just install UFW and deploy docker, the firewall won't work, or nothing will work. There's some magic to make it work but if you have anything we should add it. - c: if you try to connect to like port 9000, it'll be accessible from the internet. Because of the iptables rules that are required for docker to interface with UFW. - c: failing closed. When you do try to publish port and open them in UFW, they're not accessible on the internet. - d: we could let people know that if they're using an experimental recipe it might have security exploits. Think about how to manage risk. At least link to somewhere that talks about this stuff. - s: I like the thought of pulling dockerhub warnings to the operator's eyes. - c: might end up with a popup going "there are 500 security issues; is anyone gonna do anything about them? probably not." - sarma: multi-node storage setups - s: recently took small server with a couple of users, in order to make it run less slowly, added a worker node, then found out how painful it is when databases / volumes get moved around. One person suggested bad idea to have DBs in containers -- using postgres, switch config of anything that requires DB container to refer to static database somewhere. And wherever we're using S3 buckets, mounting those on the system. Hacky, awkward - some existing document / best practice for less of a headache to convert single-machine setup to multi-machine setup. - c: don't know of a document, in coop cloud or swarm. Agree with using postgres+s3 garage (recipe). Unclear how one points an app to db. We've been looking for a good storage solution. Hetzner was proposing a proprietary volume driver. It's a hard problem. - c: all the multi-node configs I've seen either are stateless application, or only scale up the bits of the application that are stateless. - c: would be cool to have both all-databases-on-one-node and dedicated database as options; when maintaining recipes we could add this. - s: proposal for convention - c: we've been bikesheding this for 5 years, so if you want to take autonomous action it'll give the rest of us something concrete to build on. - s: procrastinating on pushing my solutios because they feel hacky - c: Something would be better than nothing; everything starts as a hack.

• next topic: website
• d: one option being offered: written in ruby, editor with admin view. Static sites with tags/categories. Seems like it'd make sense. They're a federation member, and they have a decent number of sites with features added for different orgs.
  • c: activitypub integration too
• d: we can be part of the development process if we want to.
• d: two paths forward: (1) we host the git repo for the site source, including data for the site. (They - name?) host the CMS/editor sevice - this pushes data to our git repo, and pipelines publish the changes to the web. (2) Move the CMS onto coop cloud infra.
• d: I don't have knowledge on build pipelines, curious how this sounds
  • c: I like having a CMS, but trust y'all to decide what feaures are important, balancing ease of editing/reliability/performance
  • c: going from (1) to (2) seems sensible
• s: any reason not to host the CMS on coopcloud infra?
  • c: from what I understand, (Famo?) tried to build a CMS for coop cloud. But no one involved in coop cloud could give advice/support. Maybe people have joined now who are more able to help.
  • d: motivation was decreasing time to launch, so we can start testing what we need. Decoupling that from the labor of finishing the recipe. Once the recipe is ready, we just point it at the git repo; anything needed for the site we'll have in that repo.
  • d: assuming we don't want them to also host the site.

Success! We got through 4 agenda items. Check-outs: - c: feeling warm, in a phone booth which is also a sauna. Next, speaking about a website project and hackerspacing. Future kiteflying: would love to do a themed one. - s: had a pair programming experience; it was spoons-positive. Next, will tend to dog seeking attention - d: enjoying the weather. We have momentum with the website project. Gonna practice music for a gig on sunday. Got sucked into a reticulum network stack rabbithole, trying to resurface and not think about that. Going to a noise festival.````

2026-04-09, 12 UTC

Steven, Wouter, Sarma, Jade, Randy

Checkins: - st: was hoping to see more people - W: voice issues, happy, just heard that DTF is invited to pitch its proposal for transition work to help people in Amsterdam move to self-owned tech - J: in Portugal, rather than Aus. Learned a lot about Internet shutdowns, beek talking to Myanmar and other places. - R: New Jersey. new to community, and new to devops. Happy with any way the conversation goes.

Agenda: - st: motivating maintainer roles - W: redesign of the new website - J: issues with traefik recipes (probably need different people) - J: opportunities to sync in eur over the next month

Minutes: - sa: New website topic tabled to matrix channel, since no one here has updates since lat meeting - sa: datakollektivet.no meeting in April, cableresist.de this weekend - st: hackathon next weekend - small scale friday evening presentations, saturda all day spent together coding whatever - st: last couple weeks, signed up for maintainer jobs. I'd like people to either join me or take up one that's unmaintained. - sa: the maintainer role was unclear to people in previous meetings, - st: it feels clear to me. I'm just doing what was defined previously, and the rest will be decided together. - sa: considering maintaining some - r: is there an on-ramp to becoming a maintainer? I'd like to contribute but don't think my skills are up to snuff yet. - sa: proposing mentorship/training where Randy helps with steven's reicpes? - st: would be open, but it's good for a maintainer to also host services - maybe start with that? - r: coop cloud convergence @ Queens. Figure nextcloud is a good starting point, for family. I have zero context for how much effort would be required. I have some front-end, and a bit of full stack background. But no devops. Would like to collaborate with an experienced person. - w: it's good to have a buddy to accompany someone in the process. - w: Also interesting, IT people have been using Kollicloud. Understand that abra lets you deploy but requires manual process, and colicloud orchestrates all kinds of applications. Scheduling a call soon with Local-IT people working on the Kollicloud project. - s: it's necesary to go in that direction, but it's a different approach than coop cloud. Coopcloud is not opinionated with how apps interact with each other; Kollicloud makes choices, like restricting to a SSO system. This makes it more automatic, but less flexible. Also, reduced set of apps - only 10 or so compared to ~100 on coop cloud. - J: similar at lores.tech, curating a list of opinions on top of coop cloud and apps which work well with neighborhood-first hosting. - J: I don't think this is a better way of getting into coop cloud; better to use pure coop cloud first. Wrt Nextcloud, it's a complicated recipe with a lot of moving parts. For a simpler example to start maintaining, consider docuwiki (single container, no db). - R: Thank you for feedback & grounding. Jade: I've seen a video of yours talking about neighborhood-first. Got me excited about this project. I'm from Haiti and work with a Haitian org that does edu around tech & entrepreneurship. Building a community center until the recent chaos. Been thinking about decentralization, which is needed there. Thank you, and I'm glad to talk. - J: feel free to reach out on Matrix. Other projects also do offline resiliance, incl. badabox (spelling?) which you deploy on rasp.pi for offline hosting - St: Nextcloud is one of the more complicated recipes, but I think you should try it out and host it for yourself before you go into federation mode. Don't know how federation mode works, how much effort, and if it needs to be included. First step, host wht you're interested in. Next step: check out nextcloud. The recipe is currently stable & usable, but additions can get tricky. - R: Thank you for feedback. Being new to fediverse, hard for me to locate people's handles. Not sure how to connect, follow up. I am on matrix channel for coop cloud. - Sa: recommend also trying writing your own recipe: find a service that you'd want to use, and follow the maintainer getting started guide. Ime it's not a lot of work, and the steps in the guide will explain aspects of how recipes work better than just looking at existing recipes.

• J: federation resolution - maintainers in the metadata of the recipes is not very structured. Some people put in git handles, others put emails. But it's not very machine readable.
  • Sa: I like that proposal. Would be helpful for writing indexes in new website. Maybe at least mark what type of contact info you're providing.
  • st: I hope this doesn't discourage people from becoming maintainers. For now we should just get things running, and work the details out later. Consider writing a formal proposal?
  • J: it's not been a huge itch. Most of the time we're talking about git handles. Agree that it's not going to be an obstacle.
• st: only about 10 recipes have a named maintainer atm. Lots of opportunity to take maintainer roles.
  • J: I wouldn't want to run an org that hosts anything unmaintained. So it feels like if you want to host something you need to become a maintainer for it.
  • st:
• sa: should we motivate maintenance monetarily?
  • J: in a lot of projects, it's easier to find funding for features than maintenance. So it'd send a good signal.
  • st: no opinions. Priority should be higher membership fees & increasing hourly rate - and then we can talk about paying for this wok.
  • sa: it would be a good incentive for me, personally. Might ask someone to write that proposal.
• J: I've been thinking about money flow; a lot of the member coops have been trying to figure out funding. We invisioned ourselves initially as a non-profit, but are considering becoming a coop and charging a small amount for hosting. Not thinking about an hourly rate or if we can pay an amount for a task, but as pipes. E.g. For every dollar that we make, 20% is for servers, 40% is for labor, etc. And some would go to coop cloud and open source projects. But with the amount of money we have it'll be more of a game, an idea - but would like to see how this could work. And this might make people realize that software costs money to maintain. We wouldn't set a minimum wage, but a maximum wage (e.g. local salary of primary school teacher or hospital worker).
  • st: we are aiming for current median wages.
• Sa: I have been trying to figure out how to get money for rent/livelihoods. So the focus has been on EU grants and private/high-income clients. Interesting to me that you're going in the opposite direction, would like to hear more.
  • J: we essentially don't have any tech grants available; we might get resiliance or climate grants, but politicians usually want that money for bridges/forests, not wages. We don't need more money right now. Our reasons for moving to coop and taking in a small amount ($1/mo for income individuals) would be to get people thinking about money. Want to participate in a solidarity economy. Even if it's play money, I want to practice fair money flows. Because these flows might get pumped in the future. But it's easy for us to play with because we have savings from big tech.
• Sa: seems to be a tension in a lot of open source spaces between people who have a flow of income from big tech and those who need income from this work; difficult to find ways for both groups to contribute.
  • J: Had this conversation a lot recently. At Enspiral (group out of NZ incl. loomio), we did income sharing pods. A hosting coop might be a group that provides services to customers and also handles income sharing. But income sharing could also come from networks of trust. We have a chapter on that in the inspiro book.
  • Sa: that's an interesting thought; I've been restricting my income-sharing plans to other people in tech, but I imagine there are people outside that sphere that might also be interested.

Check-outs: - R: really excited to be in conversation with you all, don't have enough context to provide constructive criticism. This conversation was fascinating; appreciate that it went into economics too. We are whole beings who have to live in the world - st: Nice meeting Randy. Enjoyed the conversation; always inspiring to talk about different approaches that different orgs in the federation have. Encouragement to note yourselves down as a maintainer - J: really enjoyed it, thanks for facilitating. Always join these calls not knowing what I'll talk about. Glad to be in the same timezone this time. - sa: these meetings always generate spoons. Thank you Jade for humoring my financing questions.

2026-04-02, 19 UTC

3wc, papiris, Sarma

Agenda: - moving organizations which aren't technically focused off Google & Microsoft infra

Minutes: - Q(3): what groups (size&mission), where are you in the process? - p: Red Party in two regions of norway, Norwegian Solidarity Committee for Latin America, and a Patient org. Different needs, but all handle sensitive information via google docs/google meet as their primary means of organizing. All commited to moving off that infra. Patient org started before we started helping. - p: Gathering info is difficult: Where are we currently, what do you need? Only interacting with a few people in the org, and they don't have much technical know-how. - 3: if the orgs are already commited that's a big step - Q(3): are these orgs paying for Google? - p: Red Party: national party pays a couple hundred €, and offers the infra for free to regional chapters. If we move away, we both have to pay for infra and might have difficulty communicating with the rest of the party. - p: Solidarity Committee is paying some amount. Trying out options, and will present conclusions at assembly. - p: Patient org hasn't gotten back to us yet. - 3: These orgs seem to be getting a non-profit discount from Google, not paying market rates. In all the cases, you're working to develop a technical plan and what it would take to maintain it. - Q(3): Do people have frustrations with existing stack, beyond the ideology of moving away from US surveillance capitalism? - p: people don't really care. It's annoying to have to sign in for everything, even filling out a form. And a dislike for google docs. Otherwise, a recognition that we can't keep doing this the way we are ("but what else is there"). Abstract pain. - Q(3): Does any group use non-google platforms, with independent logins? - p: varies. SC use more secure platforms, like Signal, during brigades (going to LA). RP gives freedom to local chapters, so varies. E.g. email threads - which is a terrible way to organize. - p: we put up a Discourse forum for two regional RP chapters. We don't have people involved who are great at organizing, moderating the forum. Not much activity. I want to enable stuff to get done. Not in a position to do all the stuff myself. - Q(3): do people log in to Discourse with google accounts, or independent accounts? Do these groups have an existing membership database? Is membership in a database or a spreadsheet? - p: RP has a membership system, we've tried to get access, but central RP has denied API access, even to a test db. Provider of membership system also declined access to a test db, unless customer pays. National level wants to test regionally before any action taken. - p: In SC, I've never been asked to log in with my membership. But I expect the membership is in a spreadsheet. - 3: Great start that people are independently motivated. In my experience, when there's political/operational consensus to move away from big tech, people have more patience with bugs, learning to do things differently, etc. - 3: SSO: if promise of switching is that login becomes easier, that also increases patience. Ideal: DB exists somewhere which does a SSO protocol. But, it doesn't seem like the situation is terrible. For RP, it might be worth setting up an SSO just for the local branch and replacing with national db later. - 3: If there isn't tech already: the most successful deployment I've done was for a new collective with no established practice. Individuals had experience, but the group as a whole had no way of doing things. Here, we're looking at different histories of established practice. - 3: Google Docs, Google Sheets. For the other products (e.g. google meet, google drive) have equivalent or better alternatives. But Docs & Sheet are hard to achieve parity with. The least successful switches to open source I've seen have been either moving Docs&Sheets power users or if they're used generically. - 3: easy to move a group if there's a specific defined usecase for google sheets. But if they're using hundreds of spreadsheets for all sorts of purposes, it becomes difficult to move the org off them. - p: Bridge between membership system and forum would automatically create and synchronize accounts for party members and give them appropriate access levels to local,regional and national subforums. There's no local membership system, only national. - p: managed to move people onto jitsi for individual meetings, but harder to get it to stick; meetings I'm not part of revert to google meet etc, whatever is on hand in their daily lives. - p: fortunately, we don't use sheets much. Some use it as a personal tool or to create graphs/analytics. But not a deliberate part of digital infra. - p: docs is used by convention for writing proposals. But it's a basic usecase. During general assembly my group used hedgedoc. Teaching markdown was a learning curve, but easy. Lack of a way to export to PDF was a problem. Also need to submit by email but MD isn't great for that. - S: Hedgedoc lets you export to HTML, should be feasible for email? - 3 sharing screen perfoming demo: copy-pasting from hedgedoc into email picked up bullet lists but no emoji. Downloading HTML picked up teletype formatting, bullet lists, emoji, but no images. - p: seems useful, but still need a PDF export tool. - 3: in a group we drafted everything in markdown, but when we needed a PDF for clients we used pandoc to move from md to libreoffice and then manually do editing in libreoffice, which was painful, e.g. copying all imags manually. - S: could try printing to pdf from hedgedoc - 3 performs demo: probably wouldn't send this to a client but good enough for internal use. - 3: "different people do things different ways" is real. Can help with rollout since people get introduced in a human way, more approachable, more social. But might lead to inconsistency and confusion on what platform to use. - 3: Atomic Parts: it helps to start with one complete thing. Even if not "all meetings will be on jitsi", do "this monthly meeting has a jitsi link which is in all the calendars, reminders, notes". This can help get people in the habit and get them used to including this when they're deciding where to put a meeting. Do things in complete parts. - 3: Document things. If your "how to organize a meeting" doc has instructions on how to use jitsi, it increases chances people will use that method. Maybe not enough, but it can help. - 3: Really in favor of SSO. If you ever want to do it, do it from the start. Because it's painful to migrate from non-SSO to SSO. And it's a clear functionality benefit. In a lot of situations people will need multiple SaaS accounts, and reducing that to one account relieves people. This also reduces admin work a lot (password resets, password confusion, etc.) - 3: By the time people ask for support they're frustrated and might give inaccurate information. - 3: Support. People seem to have a limited amount of patience. With exceptions, this will be secondary to their main work. If you force them to prioritize this over their main work they will resist and want to stay on google. Make sure people are happy. The best rollouts had tech people writing docs and helping other people, and that was only possible because they received prompt answers from us. - 3: If a new platform allows you to do a specific task (e.g. a forum letting you hold an online vote), do a test of the whole e2e process first. - 3: I've seen rollouts do too many things at once. Better to do a few things really well as a proof of concept. - p: RP has 15 thousand members. Forum would let people talk across local and regional chapters and have ad-hoc discussions. So it would provide new value. RP does a lot using facebook groups, which is a pain to admin and make sure only current members have access to. Two years ago they settled on trying discourse, but central staff don't want this to be centrally mandated. - p: SC are aware of the security implications of using big tech, so they don't store sensitive info about partner orgs on google disk. Generally willing to try stuff. - p: these orgs have committed to collaborate with other orgs to achieve this. Rising tide lifts all boats. - S: SC group has explicit security concerns. RP more fluid. Within that context, you want to prove the benefit of the thing you're using and expanding out. Forum - not having moderators, facilitators. Personal experience: always needed to be the main actuator / performer / actor within new social context to get people to understand how to use it, know to reach out to me. Leading by example. Trying to normalise it. Present conclusions to a larger group - "look how cool and normal this is". Regular meeting link = not just makes it easier to find, but specific structure of "when i'm having meetings, there's an agenda, jitsi link, instructions on how to join". People see a nicely-formatted thing, "what you expect a meeting invite to look like", or votes for random things on discourse -> gravitate towards it.

Ideas for future KF: 3: How can we do themed kite flyings? S: Like themed kite-flying idea. What do we mean when we call people "technical" vs. "non-technical"?

p: https://matrix.to/#/#disco-space:data.coop - matrix space where people and tech co-ops are trying to get orgs to move off big tech. Might be good to do cross pollination

2026-03-26, 12 UTC

Sarma, Danny, stevensting, Paul, d1, Simon, andrew, jacob

Agenda: - monitoring

Check-ins: - Stefano (he/him): want to monitoring / kafana monitoring stack. - Paul (he/him): organized the monitoring discussion - Danny (he/him): only here for 15 minutes - andrew (he/him): first kite flying, trying to get more involved - d1 (he/him): responding to the gajilion notifications coop cloud generates - Simon: joined wrong room at first (calendar has wrong link). Hasn't been at kite flying since CCC discussion. Needs to leave 45 minutes in. - jacob (any): watching over animals on family farm. Affiliated with a tech workers' co-op and the cooperative digital services association datakollektivet.

Minutes: - Da: super happy to help out w/ monitoring recipe. If we can organize a plan, would love to contribute. Can do testing images, develop something, make dashboards. Using current recipe w/ updated images. Want to look into log management. - Sa: request an overview - Si: sharing screen and speaking - containers included: grafana, loki, others - version is out of date. - showing a dashboard of all the VMs (available disk, load, etc). When we have a new customer and want a new coop cloud instance, we use this dashboard to find where we have space. The dashboard also shows some bigger issues. - Showing a vew of applications: dashboard showing logs of various services. For me it's ugly, would like to have logs more standardized + block formatting. Not sure how much effort that'd take. - Showing alert rules dashboard. - Si: users can start losing data if max children is too low. So we have an alert if the max is approcahed by an instance. - St: we're getting false positives with that. - Q (d1): what does this look like day to day? Do you fire it up every day, or just check when there are notifs? - Si: used to use the abra commands. Workflow changed with monitoring. We use the alerts. We sometimes check the system for mem usage. Useful to have 30 days of history on VM performance. Also easy to see which instance has a memory leak by watching the memory graph. Worst case, app uses too much memory, others get stuck in restart loops and database can get corrupted. It helps to see everything side by side, since you can see how services affect each other. - Pokemon server naming convention :) - P: how do we want to proceed with this recipe? There are some issues and need effort to get this working stably. - P: https://git.coopcloud.tech/coop-cloud/monitoring-ng/issues/14 - do we need to split the recipe, since you don't always need everything one each instance and it's a lot to maintain. - St: suggest holding the recipe in one piece, but split up maintenance to multiple maintainers (maybe per container?). Can do flexible splits, where maintainers can support each other within the recipe. - P: Like the idea. There are 3 components we could split into - Sa: was there any concern about making instances more lightweight? Or was the split only about maintenance? - P: it was mostly about maintenance. There were multiple breaking issues in multiple containers which made updates difficult. - S: sharing screen, showing container list: app cadvisor grafana loki prometheus promtail - P: goal is, not every collective needs to define its alerts. There needs to be customization, but most alert setups will look similar. Currently, disk space (<10%) and memory usage (>85%) are in the template. We should review these. Threshold for memory usage should be configurable. - Q (Si): is this just the initial config, and you can change it in the UI? Or do you need to use envs? - P: you can't override this in the UI; need to change the envvar. - Q (Si): can you explort rules? - P: yes, from the UI. - St: need to be cautious with the export; need to define the data source ID. datasourceUid is sometimes a hash which changes every instance. Probably need to define these and document them, or make them configurable. - Si: Can we do a call where you guide me on doing these exports? - St: we have a call tomorrow 16 UTC - link in the monitoring matrix chat. (P: for people who couldn't join today) - Sa: did you want to discuss the dashboard sharing? - P: only if there are no other topics - J: Can I get an intro to coop cloud, to decide if the stack is ther ight directio for our org? - d1: you can ask questions - Sa: let us know about your needs! - J: datakollektivet.no - we run internal infra on some VPS. Thinking about decentralizing, whether we want one big server or distributed across the country, and how we'd admin distributed infra. And the social aspect - deploying and developing. - Sa: sales pitch: whenever you set up a new service, you have a lot of things done for you. And when you do need to do work on a service, others benefit. - d1: how are you currently doing your server? Package manager? - J: thank you, good reasoning. Our infra is docker containers deployed with ansible. It takes a lot of dev effort to deploy new stuff, to know a config is secure. There's a big mood in datakollektivet to be open to people coming in with members initatives, who can deploy what they develop themselves. Question to Sarma, how difficult is it to create a new recipe? - d1: When we started autonomic, we used ansible for years. It created skill silos, where not a lot of people could do infra work. We thought "the coop is gonna die if we don't fix this". We tried ansible training for a year or two but that didn't stick - maintenance was expensive. Coop cloud is a direct development of a frustration with ansible - not a technical critique, but that we couldn't share the work. The colaboration/sharing with lots of people on the internet is working. - Sa: The recipes are a little more work to create than docker compose, but provides much more stable deployments. Even without the collaboration aspect. Final note; Co-op Cloud is easily removable and plays well with other stuff. - J: feeling confident we should at least try. If we hit a roadblock we can remove it and do stuff manually. Really feel the skill silo stuff. - P: For me and my collective, coop cloud isn't just a technical tool we're using. It's also a really nice community of other tech cooperatives and collectives that organize together. It's nice to get together and meet each other. big value for us. - P: we still use a tiny bit of ansible to automate initial server setup: install coop cloud, setup backups and monitoring (with arba) etc. After that everything is co-op cloud only. There is also discussion how to integrate something like that into co-op cloud

Check-outs: - J: In april we're doing a national meetup, if people in coop cloud want to participate. Going to feed animals. - a: aspirations for setting up a server w/ coop cloud. Might show face around more often. Back to work. - P: good to meet up, more work next - d1: snowed in the garden, so can't work on it :<. Meeting later tonight about starting a tech coop. - st: good meeting, good energy, energized. Now going to automate backup/uptime - Sa: energi - i: glad to see the messge in chat to drop by. Good to see people are doing things iwth monitoring because it broke on my server a few months ago. Happy to set it up again. In the process of writing a new proposal for operators

2026-03-19, 19 UTC

calix (lowkey facilitating), diatom, edu, Wouter Tebbens, Sarma (minutes), may, LP

Agenda: - new website

Minutes: - Information architecture and structure for new site. Goal: feedback/comments. None of this is focused on the design. - Top Level Navigation: - Main page: paragraph about community, paragraph about tech, blog posts, contact, get involved - Menu will contain the same info. - Semantic Progression through community/tech stack pages: Understnd->Use->Get Involved - Contact: Matrix and other suggested ways to get in touch with project and member orgs. - Each page is a node, and nodes have links to each other. Additionally, nodes have tags. - Goal: holistic design. In initial implementation we might only migrate the current landing page, but we can integrate the reference docs and recipe catalogue using the tagging system. - Recipe Catalogue - Recipe-specific tags, like stability/stars. - If all recipes are nodes, we can turn the recipe catalogue into an index node. - As part of community nodes we have member orgs, but we might also consider a directory of who to ask for what expertise/domain knowledge. - Members could have topics they've indicated you can reach out to them for - Members might offer specific services - Q (S): How large do you expect the nodes to be? Will you be combining them to display inline? - A (e): Depends on the node type. A member node might be very short, a design rationale might be very long. Any node that represents a tag might have a similar structure but a different size. - Some nodes (community + tech stack) will be manually indexed. - Everything is documentation. - Q (W): Wrt the menu structure, do you plan to extend it? - A(e): At first, we want the simplest thing that will work. But this will be easy to change in a CMS. - Q (W): Wrt the flexible strucutre, you need a proper CMS. Any plans? - A(e): Scope of this is a website that can then integrate other sources. The CMS (if we have a CMS, which we think we should) must make it easy to collaborate. But the proposal does not specify a CMS. We'd like to use our own. - Q (S): How will we manage watchers? - A(e): There are multiple solutions; we don't need guardians here. One solution is to have a tag which tells us when something is pending. In the proposal, there is a group of "Status" tags: pending, in progress, active, archived (these can be changed; this proposal is not set in stone) And you could flag as "pending" things that need attention. - Q (S): Concerned we might not have people reviewing these nodes. - A (e): Any changes in the tech stack should be accompanied with a documentation change. So, I agree. But, the federation will have to decide how to do this process. - Q©: How do we make it obvious who the members (and thus, funders) are? Is it envisioned that the homepage would be extended? General rule: anything accessible in 3 clicks - is satisfied here - members -> who we are. - A (e): this is a low fidelity prototype so we can debate this. The 3 click idea is very general. What's more important is the information sent, not just clicks. Of course it's easier if you have things in fewer jumps - but the extreme case (everything on one index) doesn't work. We want to group information like a human mind would. We don't want either extreme: too much traversal, or too large indexes. 3 click idea is good, but if people know where to look we can break it. - c: "Information Foraging" - e: supermarket analogy. You don't want 1 mayonaisse or 20 mayonaise or people won't buy it - you want 5-7. If we set up the prototype, we can test and adjust this. The CMS should make it easy for technical and non-technical people to collaborate on documentation. - Q (m): Wrt finding members who can help - like the front door approach, relationships to tools/installations. So, where there's a tutorial/how-to, or where there's a recipe - I should be able to find members or people that can help me. Different entry points than just the main menu. - A (e): whole idea of this structure is that any entry point is valid. E.g. you can start with "who we are" and funder founding/current/past members. Each of those can be tagged with particular knowledge/responsibilities. And those tags can be followed from other pages. Any entry point should give access to adjacent&relevant objects - whether those are members, how-tos, tools, etc. - m: I'm talking about something with guardrails, like a wizard or step-by-step tutorial. Especially if someone is visiting the first time. - e: The Understand -> Use -> Get Involved paradigm proposed by (sec. note: whose?) research. So we give an overview from general to particular in the main pages. If there is information missing in the main pages - for someone just starting to look around - we should modify this proposal. - d: One of our goals should be reviewing the design - to see if we missed anyone. Following on may's proposa, a radically different way, like clippy or chatbot. We have at least 4 different types of audience (developer, maintainer, activist, teacher). We need to meet the needs of all parties. Please review: https://pad.riseup.net/p/Zr6t8vrguHuVNZCGfGBn-keep - c: what do yo uneed from the community? - e: Main thing we need is the general idea, is it opaque to you? First we need the ok that the general idea works, next question will be whether we use a CMS - and only afterwards figure out what CMS to use. - d: if you have further suggestions/thoughts/changes we feel strongly about - please bring them to the matrix channel in the next week.

Check-outs: - W: amazing to see this, thank you. Would like to use this for democratic tech fund. - m: happy to see attention&care. Great stuff. - c: super inspiring. Well done. Next up, trying to heat pis with a hair drier. - e: thank you for having me - happy to be helpful. Energized to help with this going forward. Thanks for all the coop cloud work. - d: feeling good, pleasure to share, great working with eduardo. Next, teaching people to use walkie talkies and get an intuition about radio at workshop. - L: druple and wordpress might be glossed over, both are mature communities. - S: might have comments in Matrix, tried to do this sort of "many sources same graph" thing in other projects but never with this much success, looking forward to a prototype. Going to sleep to watch the sun rise for the equinox.

2026-03-12, 12 UTC

psfried: new from Ohio, US Jade: new and just joined the federation! Stevensting: dropping in, no topics Danny: from NL, listening in for the vibes Sarma: sleepy. Could review agenda items from last sessions? Chasqui: from Abya Yala Network

Agenda: - none, initially.

Topics covered: - Starting a democratic tech org, or a coop - how to find people, network, what structure to choose? - Abya Yala - Lores.tech

St: question for new people - are you using coop cloud alone or in groups? psf: been testing it out. Just quit a startup, and using time between jobs to set up work hosting bonfire for local orgs. Did some test instances. Really want to join a group of people. J: from a Melbourne group, doing neighborhood scale hosting for a 180k-person administrative area. We got volunteers, will be doing practice sessions wednesday installing recipes on pis, with the goal of resiliance. Sa: have you checked matrix, psf? The "so you want to start a tech coop" channel has some American people trying to organize. J: Would want to chat about coops. We're an association, not a coop. Don't know if that was the "correct" option. P: Been talking with public health, private schools, churches. Schools & churches responded positively to a consumer-owned coop; public health didn't care one way or another. Goal: social networking that's more trustworthy; consumer ownership seemed to conect Sa: might be a pitfall to go blindly into a coop structure. Each region and each group has different needs. St: we're in the process of creating a coop, but we also have a separate foundation. We can't do service work in Germany under some structures, which is why we need the coop so we have a dual structure. It's good to have a discussion and write a code of conduct. St: we're working closely with bonfire, and have projects to deploy them for a US org. Sa: I'm in the early stages of St: It's difficult to find someone locally, but it might be good to do international coop work to see if it fits your style. In our case, we started with pro-bono community work in activist areas; after some years we could do it professionally. https://www.hostsharing.net/ - german-based coop for hardware sharing. J: Worked with inspira - a coop that did professional services. You're always locked into what your client was. A lot of consultancies dream about being a product house, but that's not easy. Small trusted groups ("pods") are good at organizing, and can survive when people leave orgs. E.g. we had an income sharing pod, where people pooled money when they had income. J: which part of websites should be commons P: definitely relatable, trying to give people an online life that doesn't suck. Haven't found anyone who was able to commit to getting this off the ground here; it's a challenge to find collaborators. To offer a valuable service I'd need redundancy, so the project doesn't die if I can't work on it. Like the thought of letting the first interactions dictate the administrative form. C: From Free People Laboratories. We work with indiginous communities helping defend life processes and land. Teaching them how to build their own digital infrastructure. The groups do human rights & env monitoring (watching cops, enterprises, militaries) and members are risking their lives. So the security of their infra is important, but they tend to use amazon/google services. Working with 5 other orgs that do digital autonomy in LA. . Doing schools, one last year, now another school next week. Talking about how to archive/store data, to enable using them for criminal processes. Building a spanish translation and certain recipes to help local sysadmins St: do you run your own hardware, or use cloud hosting? C: We're giving these communities their own computers, and using local solar power generation. In a way, by using google drive these communities are funding their own destruction. J: What recipes are most useful for you? C: Nextcloud, wordpress + timeagain plugin for archiving: collection, interconnection, taxonomies, filters. Specific tech stacks here: http://archivo.yanapak.abyaya.la/rabt/ (monitoring orgs) and http://defiende.yanapak.abyaya.la/ (orgs collecting news and info about killings). We also use Tela, which we created. Tela is a safebox for your phone, which is sent to their server. We call servers kitchen garden in these projects, because we allow people to "grow their own digital food" in opposition to corporate servers. We also have a tool to archive video streams (Facebook deleted streams, so we need a VoD+streaming place). J: where can we read more? C: http://abyaya.la/ , school: http://escuelacomun.yanapak.org/, blog: http://cuidados.yanapak.abyaya.la/ Sa: Is there specific support you need from people at coop cloud? C: We like connecting and collaborating, so we want to learn what others are doing. And we like sharing how to do workshop and how to accomplish this, so more people use this software. Sa: sounds like Jade and Chasqui could collaborate? J: I'd love to share Merri-bek Tech's project lores.tech, for keeping networks running when the internet/power goes out. Which seems similar, though we don't have anything working atm. Really interested in local-first apps, mesh networking between end devices. But also interested in mesh networking between servers. Can we use eventually-consistent mesh network radio to hop across servers? (Using p2panda.org). Starting with quix (spelling?) for wikipedia backups, sso, user directories. Lets you register coopcloud apps for a region, and the network will do peer backup, peer monitoring, and DNS modifications to point to a known working node. Phase 2 will be static websites. Phase 3 will be email: which works normally when the internet is up, but routes internally using p2panda/lora when it's not. C: We're looking for exactly this. We need our servers to be available when the internet goes down. We could test lores in different places in Latin America. We have raspberry pis that sample water and send over wifi; it'd be great to connect those without internet reliance. Sa: Jade and Chasqui, sounds like you could coordinate? C: We're working with coop cloud because the political vision.

Checkouts: Sa: energized, recovering from mental health issues and going to migrate a server. J: been able to work for unpaid projects, but starting a paid project. Flying to Berlin in a week, for a month. St: energized, didn't mind the lack of technical topics. Jade invited to southern germany. C: energized, happy to talk P: energized, impressed, inspired. Got a lot ahead of me. Hopeful for the future. Ending startup job end-of-month. D: Interesting initiatives, so much happening in the world. Going for a walk, then back to work.

2026-03-05, 19 UTC

Present: 3wordchant, Jackie, Steve, Sarma, papiris (Jacob), kawaiipunk

Agenda: - Ways to get involved if you're not hosting an instance - Backup-bot questions - "How do you get people who want to work on a server together (shared resources) to trust each other before they have to go into production" (from Chaos Congress) - Technical / nontechnical split - nontechnical roles, technical language - What is Coop Cloud - Federation vs Centralization - Upcoming blogpost

Notes: digital services co-op / association in Norway: https://datakollektivet.no/

Ways to get involved if you're not hosting an instance

Sa: Bunch of issues in a bunch of repositories. Or more community engagement roles? Lot of work on abra specifically. Callout for recipe maintainers.

https://docs.coopcloud.tech/maintainers/maintain/

St: We've talked a bit in the past about keeping up-to-date. Struggle is motivation -- we don't track who's using recipes. Is there a list of issues with recipes?

Sa: Discussing paid contributions to coop cloud recipes -- there's a budget for "critical" fixes. Supported by Gitea API. Haven't found a good overview.

3: Can you share API calls? 👉👈

St: Need git.coopcloud.tech account? How to get one? And: how to surface # of open issues on recipe catalogue?

3: DM me desired username, ! Generally: ask in Matrix channels.

Sa+pa: API call for list of issues tagged with "critical fix": curl "https://git.coopcloud.tech/api/v1/repos/issues/search?state=open&labels=critical+fix"

Jackie: Are maintainers also responsible for looking at tickets?

3: https://docs.coopcloud.tech/maintainers/maintain/ think "yes", could be clearer

Backup-bot questions

Jackie: How to download a backup locally? Command didn't seem to work.

Jackie: The latest release of backupbot 2 is quite old and there are newer commits we want to use for some fixes

kp: Autonomic using backupbot across 20-30 servers (!!). Loving it. Haven't done loads of restore testing. No problems so far. Haven't been involved in developing it. Working out what are plans are to maintain ecosystem.

https://git.coopcloud.tech/coop-cloud/backup-bot-two/

kp: Are there any changes which affect core functionality which we need to give people a headsup about?

Jackie: https://git.coopcloud.tech/coop-cloud/backup-bot-two/commit/4b4371ed3f61dee80acd0bdd09132e44ad62dbdb

Jackie: basically without this fix, the previous instance of the app needs to be running to restore it, which is sort of counterintuitive

papiris: For backupbot backup+restore testing, could we compare hashes in some form? e.g. query db API before and after restore, and compare hashed values?

How do you build trust between people who want to work on a server together

Sa: Getting a group started co-operating. Starting with a small server. Help people start doing local work but don't have the infrastructure for it. Help groups who are trying to get off of corporate VPSs.

St: If 2 co-ops want to use co-op cloud together, making an on-ramp for that? What's the need for a smaller server first?

Sa: Issue of trust. Existing clients - don't want a stranger to come in and poke around. e.g. - currently running a small server for ~10 people, need someone else to admin it occasionally? Happy to provide the same service for someone else. Save money through combining onto the same server... but without access to my clients' data. Within that environment, possible to get some people working together in a sandbox, build trust, merge resources. Does this exist?

3: Also applicable with e.g. an existing collective trying to build admin capacity, community member volunteers might not be well-known to existing admins.

kp: "growth at the rate of trust" (possibly from black panthers?). Ways to slowly allow people to help. Start with moderator position / admin within dashboard of particular app. Separate VPS with one app (e.g. wiki) on it. Access to files but not other things. Process of building trust over time. Organisations with "flat" system (small groups, high-trust), and groups where people don't know each other as well in person, but have shared politics/goals. Haven't really had problems, could have been good luck? Limiting the damage someone could do - technical & interpersonal.

St: Feel like it's more of a building-trust problem than tech. In any tech admin role, this is going to come up. Up to those co-ops / groups. Cool if you could maintain co-op cloud instance for someone without having access to data, is that feasible? Make it easier to trust admins?

kp: E2EE?

Sa: Would it make sense to have any kind of social infrastructure within Co-op Cloud community? Seems like Steve is saying no. Thinking about this -- channel for people organising co-ops -- is this a direction we want to push in? Broadly doing the work of connecting people. Or outside the scope of co-op cloud?

Jacob: It might be an idea to have separate replicas of backups, under the control of different subsets of admins.

2026-02-26

12:00 UTC

Present: Sarma, Sarah, Nick, kawaiipunk, Wouter Facilitating: Sarma

Agenda Proposals

• abra 0.13 released
• feedback on timeslot
• maintaining the mastodon recipe

Notes

• Nick calling in from a boat
• Nick has a deployment of mastodon. Used to do hometown deployments, switched to mastodon, did a few PRs. Now discussing doing official maintenance.
  • https://git.coopcloud.tech/coop-cloud/mastodon/issues/38
• S: I'm a non-technical enthusiast
• N: It's a struggle for people who don't do coding to feel valued. There are so many other valuable things to do.
• S: Here to start the process/see how things work/cooperate.
• Sarma: I'm curious about your experience with
• Sarah: no negative experiences at coopcloud; in other open source communities there has been exclusion but not here
• K: not a lot of time to contribute to coopcloud,
• Sarah: here at the behest of jade. Volunteering with https://www.merri-bek.tech - neighborhood-first community infra in Melbourne. Hoping to join the coop cloud federation. Interests in community-centered rather than user-centered tech. Experience as business analyst, project mgmt, user research, usability testing, workshop facilitation/codesign.
• N: I'd like to do something similar - wondering how to get local tech stuff. I can host, but community outreach is a big part; getting something going long-term is overwhelming
• K: also working on local tech initatives. Working on a housing coop with fast internet; will be starting a hackerspace there. Trying to work out a collective broadband agreement/starting our own ISP; for now to provide internet for the building. Foci: data sovereignty, p2p tech, resiliancy
• N: getting people off whatsapp is my big blocker. Making it an in-person thing - a coworking/hangout cozy space is a great idea.
• K: less about replacing things, more about fun and play. It can become more than that eventually. Rather than trying to get people off whatsapp, work on other interesting stuff that isn't working against billions of $ of UX design
• Sarah: lots of resentment towards attention economy/big tech. We're in a good place to help people make balanced choices. And find where tech isn't the answer
• W: from the free knowledge institute. Not at the abra level yet, set up commonscloud.coop in Barcelona, some years ago (now 4 worker members serving 2000 users of which 200 organisational members and a few hundred individual members). We have a need for the digital transition to lead towards digital autonomy. Helping to establish the democratic tech fund and with FKI/dtf we became part of the coop cloud federation.
• A: question about scope of democratic tech fund

• W: we work towards increase of social capacity. We don't focus on the development of new technologies. Can we mobilize people to use the tech, set up collectives that use these services. Raising awareness, short movie production, joining & building collective campaigns that are already out there.

  • We just posted some updates: https://social.coop/@fkinstitute/116136763656834969

• W: working towards a decentralized web camp in berlin, in July. We've just set up initial working groups, opening up in matrix space

• K: really happy to see the initiative starting. We're reaching a critical point. Cory Doctorow argued that the door has opened a crack, and a non-US state should set up resiliant/local infrastructure. We have an opportunity to divert public sector money to open source infrastructure.
• N: Agree w/ above. As a developer of karrot.world I'd like to move away from tech and to ecotherapy and reintegrating with nature.

• N: lots of other small platforms with 1-2 developers doing interesting things

• Jitsi issues, Consider alternatives? (Matrix, Carrot)

• K: Coop Cloud is stalled on paid admin worker roles. We're struggling with recruitment, as a volunteer org. We want someone who manages the open collective and keeps track of finances. Autonomic was supposed to do this, but their finance admin doesn't have the capacity for the extra work. We've had 4 applications, so high hopes. Main worry about coop cloud is recipe maintenance. Proposal: move to debian-style system, where some recipes can live in the unstable category.

• Sarma: question to Nick, what could have been improved when you were getting into Mastodon maintenance?
• Nick: it's not too much work to maintain the mastodon recipe once the maintenance is set up. The previous maintainer took a while to reply. The method for a new release was unclear. I have a lot of other responsibilities, so a step-by-step would be helpful. Part of the invitation was "you can get involved in shaping the process" but I want to stay in my bubble.
• W: Talking with people interested in OpenDesk (and others) - govt projects that offer open source apps as integrated services. Where are we at that point? Could we provide that service?
• K: Autonomic is preparing a pitch (with Digidem Lab, Stockholm/Malmo) - to Swedish municipalities, pitching software suites. People in the public sector have their ears open for this stuff. The thing about coop cloud is that it suits smaller deployments; govt level might require k8s. But coop cloud is good for PoCs and small govt deployments, up to 10k users. I'm curious about the business model. Autonomic sells to small orgs, and wants other business models - bigger scale is promising but would require a lot of work. We're being asked to do service agreements, which we can't do unless there's a lot of money - we don't have capacity.
• K: E.g. Bermingham has a contract with Oracle, which brought them close to bankrupcy but delivered no software. They'll be looking for people to fill that gap, but Autonomic's coop model might not be able to handle that. Digidem has the staff of a small tech corp, so might be better suited.
• W: Think of the use case for a collaborative workspace service. Goal is to have a service that local coops could deploy. What is needed to get this off the ground? Crowdfund that with the d:t:f.
• K: no clear process on security updates in docker apps. Debian sits on unstable versions until a security release is tagged; but docker apps don't have that upstream.

Sign-Offs

• A: first time facilitating; lots of topics but tried to connect them.
• N: good job facilitating. It was hectic, with connection issues and people dropping in/out - and with topics shifting between big-picture and specific issues. Would prefer a bigger focus on specific
• K: More of a meeting stucture than I'm used to, but useful with this many people. Happy to be here, lots of thoughts in my head. Autonomic is deciding whether to pay members for kite flying.
• W: Glad to work in the coop cloud ecosystem.

2026-02-19

19:00 UTC

Sarma, 3wc, Steve, Christian, Tod

Agenda thoughts: - 3wc: rolling the dice on new meeting slots

Resources

Poll on new times: https://crab.fit/coop-cloud-kiteflying-660087 Financial compensation for attending or facilitating kite flying: https://docs.coopcloud.tech/federation/resolutions/passed/024/ Malta workshop https://github.com/nextlevelshit/malta-digital-independence-workshop

Notes

Sa: Set up some co-op cloud infra for a co-op 👏 And considering setting up freelance hosting thing

New slots: let's just go for 12 UTC / 19 UTC. Sarma down to facilitate 12 UTC 🎉

Sa: Any way of async continuation of topics at kiteflying?

3: There was a suggestion of a discourse forum, any opinions on that? - Sa: we could have a thread, each minutes would be a post - 3: Unsure about if a Resolution™ would be needed - Sa: Benefit for kiteflying... but what about wider? What risks would spinning up a forum entail? Communities splitering between people in DMs, forums, etc. - Ch: Assumed Discourse or something? Cool to have a forum for Co-op Cloud

St: Best way to get people to facilitate is directly reach out to them!

Sa: Also helpful to have a more-experienced facilitator around for the first few to help new facilitators or minutes writers.

3: fora encourage a certain type of discussion, which becomes unmanagably long. It's difficult for a moderator to facilitate (you don't want to edit and misrepresent) but it's difficult to cut off people when something has already been said. Q: where is discussion currently happening? - kite flying + matrix St: moderating a forum might be easier than moderating a chat, because it's slower, and because it's easier to ignore posts.

T: Want to run a workshop for getting started with abra. Do we have workshop material? 3: Have notes from getting started workshops. More organized workshops were held in Malta run by nextlevelshit and upstate NY, run by Marlon

Sa: what are your plans? T: Still trying to get comfortable with the environment, but would like to get people together in the county

Sa: Forum discussions get long → cost of getting into a space. Punishes anyone who leaves for a bit and comes back. Any alternative which has more transient focus points? Unsure if tech solution exists. IRL: community message board, things go down after active discussion.

T: Can we use an existing forum instead of setting up a coop cloud specific one? 3: Agree about not setting up a huge mountain to climb. Indiehosters had a forum, but no more I think? Sa: Model of essentially writing letters - only ever referencing the last few things talked about. And sufficient to read last few letters. Wiki / forum / hedgedoc - if you only ever want to read the minutes from the last week of kiteflyings. "Thanks for writing, here's what you said, here are responses" C: Clarify what Sa is saying about "transient nature" of posts in forums. What is the concern? Being overwhelmed by how much there is to catch up on? Posts auto-locking? Trying to understand the problem being articulated -- is it that there might be so much content that it's overwhelming? Couldn't we also argue that the current model, Matrix = lots of channels. If you went 2 months without checking them, overwhelm coming back to it? 3: Agree on Matrix, can be overwhelming to come back to so many notifs. Gitea has a similar problem. I also don't think there's a tech solution to this. Like Sarma's framing: What is the conversation we're trying to make space for, and what existing metaphors is it close to? Forums do exacerbate "free as in free time" dynamic. The UI of matrix psychologically discourages long messages by showing their length. There's still a risk of prioritizing terminally online people, but not of prioritiing people who have time to write 2k words. C: Agree. Possibility: lock everything except Discourse. The current model does prioritize terminally online participants, since you'll usually miss things if you're not active. Some weird dynamics form with badges in forums, e.g. "prolific poster": I have 30k posts in this forum so my words have gravity. Forums enforce trust systems/level systems; by default 4 levels of trust/permissions. - complexity with understanding how to use discourse - different tags and subforums - additional features - tags, notifications

https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/

But there's an opportunity to centralize discussions, closing any structured documentation by redirecting people to the forum. Biggest risk is fragmentation. And we need to organize discourse in a way that people are comfortable and no strange social dynamics arise. 3: Discourse has unexpected behaviors, like being allowed to edit based on nr of posts, or minimum message size on dms. We could explore nodeBB or flurm (spelling?). S: Lightbulbs that get brighter when they're talked about. Solutions like fediverse account, email thread. Take the brightest lightbulbs of the given meeting. e.g. today: forums, async communication, allowing people to reënter environment without feeling overwhelmed. After each kiteflying, whoever is the facilitator / secretary compiles a little couple of bullet points with emoji. If I'm following fedi account then I get a quick overview of what topics are currently active, so i know to reply to those topics, or join next kiteflying. Fedi has that advantage of people generally don 't read history, expected that folks will only check last few messages. Emphemeral 3: I like the idea; will do this after this meeting and see if it sparks conversations or encourages people to join

Sa: Background with meetings: set goal, deviating too much requires setting up a new meeting. Alternative: meetings which don't have an agenda, and run overtime. So this is an interesting experience. Allowed to ramble about not-fully-formed ideas, goal of meeting emerged naturally. Appreciated!

Check-outs (what are we doing next?) 3: Nap, then going to the NY coop cloud meeting on a road bike, to help with food prep. Themed kite-flying on ansible and deployment orchestration. Wonder how we can gather ideas + interest for other themed kite-flying. C: Meeting Uni of Wisconson about cooperatives. Will ask questions about tech coops to see if anyone's talking about it in UW. T: Lunch, then Digging into links and reach out to Marlon St: Enjoyed the conversations. Want to attend the ny convergence, hope there'll be more Sa: Adopting dog, will poke at abra issues when time allows.

2026-02-12

Here: p4u1, mo, apfelwurm

two things to automate: 1. server setup https://git.local-it.org/local-it/ansible-debian https://git.local-it.org/local-it/ansible-docker https://git.local-it.org/local-it/ansible-maintenance

1. app deployment

2. This is nicely covered with alakazam, but with limitations:

   • only one app per instance (domain), so no wordpress1.example.com and wordpress2.example.com
   • apps of one instance (domain) are all deployed on one server
   • alakazam uses ~/config/alakazam.yml as root. Therefore it is not possible to use multiple different project on one computer

traefik:
wordpress:
nextcloud:

potential future config:

traefik:     -> DOMAIN: traefik.example.com (from sample env per default)
  subdomain: proxy -> DOMAIN: proxy.example.com
  DOMAIN: foo.org
wordpress:   -> DOMAIN: wordpress.example.com

wordpress2:
  recipe: wordpress
nextcloud:

-> let's focus on alakazam

• we need docs
• we need tests
• then we can think about upstreaming stuff to abra

Next steps: - Make a resolution to adopt alakazam as an official project (https://docs.coopcloud.tech/federation/resolutions/in-progress/037/) - Get others to try alakazam - Start collaborative effort on teaching, writing docs, writing tests

@room I'd like to propose Medium Decision 037: Adopt alakazam as an official project in the Co-op Cloud Federation - 12-02-26.

Deadline for votes is Monday, 26^th of February - let me know if you need more time to vote than that.

Please send absolutely any and all replies in Co-op Cloud Federation not here 🙏

Each member organisation can vote once, if you have multiple people in this channel then please coördinate among yourselves who will Press The Button

👍 this message for “enthusiastic consent”, 🤷 for “stand aside” or 👎 if you need to indicate your extreme disagreement with this idea.

2026-02-05

Here: Calix, diatom, Max

• d: New website meeting reportback
  • d: Questions we want to ruminate on before meeting next week
  • d: I met with Sutty comrades, who are doing design / implementation work on new website. They're saying: work done so far in gathering feedback, doing qualitative analysis, was all done on population of people already involved in the project. Those needs will definitely be addressed, feedback incorporated into design. But what they want us to make sure we spend some time doing is enumerate all the types of people, groups -- what they're doing, what their interests are, what their technical capabilities are -- to make sure we're considering them when we think about audience of new website. To make sure we think about needs they have, ways they participate, onboarding steps. Part of that: thinking about groups currently using infrastructure that's deployed via co-op cloud; those groups are a part of the CC community. Maybe presenting some of those groups as "users", not as "supporting" / "supported by", but "these people are a part of the community".
  • C: Believe the initial website survey was posted as publicly as possible - but maybe there was an effect where "why would people have filled it out if they didn't understand or didn't see the usefulness of CC", unsure how to solve. Def agree with going deeper into groups using CC, people using CC-hosted apps, to go deeper into at least one further degree away, folks who might not necessarily consider themselves / be considered part of "CC community". Unsure how much existing work already was done on enumerating types of groups, users, what they're doing / interests / tech capabilities - more definitely seems great.
  • d: Yes probably some selection bias.
  • d: Another group: folks using CC as an educational tool for teaching people how to do community self-hosting.
  • d: Fun working with Sutty! Interesting webinar on Sociocracy, systems etc.
  • d: Initial work: migration & implementation = landing page, splash page. They still want to include design recommendations on documentation & recipe sites. But won't be a priority to actually implement it.
  • C: Wow super cool, would love for someone to save us from halfbaked bootstrap recipe catalogue design (improved as best it was by design comrades)
• M: Permacomputing meeting happening @ Ridgewood commons next tuesday, will spam to NYC groupchat
  • M: Could factor into picking theme-or-date for next coopcloud NYC thing.
  • C: Do we want to ask Calyx Institute to do some outreach?
  • M: Lee Tussman (sp?) maybe not super trying to grow things. Could ask.
  • d: One thing: event will be in basement, not upstairs. And other events. So won't be able to relocate if it grows. Probably only 20 people.
  • M: Permacomputing not super popular, maybe even if we promote it there won't be a huge crowd.
  • M: What is Calyx?
  • C: Tech privacy & security NGO, based in Brooklyn. Funded Co-op Cloud / Escuela Común in their new "Sepal" fund. CalyxOS, Seedvault.
  • d: Similar to Deepmay?
  • C: Think so? At least marlon's workshop, not sure about the rest.
  • M: Lean towards asking Calyx to promote next CC event, not necessarily permacomputing.
• C: Picking a theme / date for next NYC local event?
  • M: Could even do multiple themes?
  • d: Doing it before dinner on Sunday was good. Sundays are difficult personally, 5h rehearsal. But - while I'd love to be there, don't need to be. Plenty of others who can help.
  • M: Happy to do a different day. Is the kitchen workable other times?
  • d: Y
  • M: Would be happy to cook food for folks at the thing if we did
  • C: Great great. No strong prefs. Seems a bit of a bifurcation between folks who can make evenings'n'weekends vs weekdays. Maybe majority of people in general can do evenings'n'weekends, but is that the same for NYC liberatory tech community? And do we even care about Numbers™.
  • M: Wow cool calendar.
  • d: Fullcalendar.js library pulling from santised ICS link from internal calendar.
  • d: Not a lot of times free. Next sat 14^th? (Val day)
  • d: Basement: smaller, focussed hack session, much wider availability. Every Thurs night available there. Sometimes a bit warm but definitely tidier etc.
  • C: Maybe related to theme? Also wouldn't be surprised if event #2 is naturally smaller anyway.
  • we gaze into Max's list from the Signal chat:
    • deploying a discourse forum to supplement the matrix tech chat
    • how does backup bot work? (i don’t know, and so far none of the recipes i have made have backups 👼)
    • let’s try to fix a bug in abra
  • C: Space for 2 parallel groups? Could do a RC-tech-specific thing, plus one of the above?
  • d: Yeah possibly 2×10 people. Some fiddly RC tech stuff to do - migrate apps from beta domain to normal one. Upgrading vikunja recipe.
  • d: Cohack or intro for RC tech?
  • C: Whichever!
  • d: Cohack maybe more useful, enough people who know some stuff.
  • M: Sounding good.
  • C: Any timing preferences? Personally no plans calendar empty, would just choose "how much is optimal notice for folks", and maybe "at least 2 weeks"?
  • d: Tentatively 19^th?
  • M: Could see it. Could imagine doing something monthly.
  • d: Brainstorming recently: what if tuesdays = hardware, thursdays = software @ RC? "Autonomous infrastructure day".
  • M: And then coop cloud could be occasional theme?
  • Action diatom event booking request to RC, scry the calendar a little more.
  • C: Dare we try and pick a theme now?
  • d: Personally backupbot very compelling.
  • M: Agree.
  • C: Agree.
  • C: Time for circuithacking? Can we just copypaste that?
  • d: 8-11pm.
  • d: Solidarity mending circle / DOI craft night happening upstairs @ same time.
• M/C: Also something in Boston? [skippin']
  • M: Feeling more positive about it!
• M: Updates / getting rid of swarm galaxy-brain
  • M: Recap: ongoing thread about updates / swarm https://git.coopcloud.tech/toolshed/organising/issues/682. Inside intel from Docker Inc: swarm is effectively abandonware, nobody really knows how it works. Maybe counter to coop cloud project goal of resiliency? And also seems like some attributes of swarm runtime holding us back functionality-wise. Personal brainstorm, sketching out "something like abra but atomic operations, backed by ZFS, declarative, snapshottable". Tension between having the right tech vs doing stuff with good people. Toying with "what if there was another thing that was more along the line of this but also using coop cloud recipes as source material", keeping interdependency. Tension between greeanfield writing things, vs wanting to work with people using stuff in a cool way even when it has tough dependencies. Feedback / therapy?
  • d: Swarm hasn't been developed by Docker for some time? Bought some time ago? https://www.mirantis.com/blog/mirantis-guarantees-long-term-support-for-swarm/
  • M: Maybe we talked to the wrong people?
  • C: So confused?? https://github.com/moby/swarmkit/ is under "moby" namespace, which is maybe docker core? Max, call you had about Docker secrets, was that with Docker?
  • M: Yes. Told them we were using swarm. Didn't really get that answer.
  • C: Secrets were originally docker swarm. That was a killer feature for swarm over compose. But now it's in docker compose too? Does that mean the whole "raft" stuff is in there too?
  • d: Would be good for us to understand "where swarm is"
  • M, C: 100%
  • d: Micro thinking a lot about swarm alternatives.
• C: Thoughts on matrix channel perestroika?

2026-01-22

Moods: tired (x2) + happy (x2) + fewspoons + buzzy + curious + excited/inspired/frantic + good Where: at least two different continents Here: Calix, Ammar, Danny, Sarma, micro, ivykim, notplants, marlon0, decentral1se

Q: What's kite flying like: - ad-hoc agenda - kite flying if there's a topic ready - hackathons, sometimes

Things to talk about: - Report on abra webui - https://git.coopcloud.tech/BornDeleuze/coop-cloud-front - https://github.com/DuwYAnne/coop-cloud-back - design proposal: https://git.coopcloud.tech/toolshed/organising/issues/681#issuecomment-27738 - m0: concepts relatively easy to explain, but folks with less ops experience = CLI difficult. lot of work to teach. "what would it take to make a webui" - m0: frontend drafted, golang backend in progress. soliciting feedback. en route to MVP - Sarma: 2 things I tend to do when managing apps: editing files. pushing configurations to VCS - m0: intention is for user to be able to edit config text in browser. don't think anyone has plans on how to make that a good experience. git: thinking about this. relevant question to me: is this in-scope for webui? or abra itself? remain unopinionated. - 3wc: where to give feedback? matrix channel? issues? - m0: maybe matrix channel if there are enough conversations to warrant it. issues in frontend would be great. also an issue in general about web interfaces. - np: so much more room for error in terminal. webui: encode possible states. simplifies things especially with managing lots of instances. related: thinking of making TUI, same reason. - reportback on NYC convergence - 30+ people, many of them technically adept - ridgewood commons had concerns, that it woul dbe hard to follow, but no issues. - tables set up - talks/presenttions - breakout sessions, about various topics including tech coops and internet infrastructure - had a raspberry pi which peered with other ASNs, including NYC mesh. We got coop cloud running. - ended in a dinner - wish: smaller meetup might be more focused - d1: Q: more individuals? or orgs? - micro: most had visions about their org, but no org showed up "as a group". A minority ran homelabs. Many people heard about it via org signal groups. - orgs included: ABC No Rio, Comp Coop, IWW, Tech Workers Coalition - notplants still wants to solicit feedback on yunohost-style updates for coop cloud (https://git.coopcloud.tech/toolshed/organising/issues/682) - np: "configuration commons" = missing out on the potential for one person / group doing the work, everyone else benefitting. while recognising some people will want unique configurations, escape hatches to opt out of happy path. Some path to more automation on updates (and e.g. changing URLs) - sa: any specific escape hatches in mind? - np: the way coop cloud already works is already "escape hatched" and customizable. this would stay - adtion1s: recipes extremely configurable. design choice: 6-7 organisations commiting at random to main on specific recipes, "it works". that's where we're at today. you can let so many people do their own thing from the same git repo. how do we make a blessed path work for folks who don't need combinatorial choices for databases, caches, etc. - m0: on the right track with reasoning. reduce / streamline maintenance load for recipes. - comparison to yunohost: there are 6 bash scripts for upgrades/backup/etc. We could also use bash for this, since we're talking about stateful changes not contained by .env. Challenges remain. - d1: initially we thought "docker swarm will just deploy when you say deploy". In practice it's much more chaotic, and we can get inconsistent states. Yuno has checks on whether each step works, and can rollback. We lack control over that deploy operation, because we hand that off to swarm. - d1: this calls into question (again) reliance on swarm. - 3wc: agree that updates on coopcloud are painful. One probblem is a lack of service dependencies in swarm - 3wc: timeouts are difficult to set, because of hardware variety. Maybe we can should make this configurable for operators - np: my initial vision was to poll state after some timeout and revert, but now see that's challenging with swarm. - marlon: Could ask the user to do a manual smoke test? "Did your upgrade complete successfully? Y/NY" - np: URL changes as another small example of atomic operation - d1: could we talk with docker about this? I'd like to understand deploy better, so we can have this control over failure modes. - np has a contact from the convergence - Recipe maintainers - pushed to later session - Danny has some questions - pushed to later session - marlon has some technical things - in a proxy network, all "app" services have the same hostname: "app". This creates security concerns. - Q: is a proxy network internet-accessible? A: no, only accessible to traefik - 3wc: helps to specify hostnames as ${STACK_NAME}_app instead of app. - d1: stacks should be namespaced... can we reproduce this later? - alternatives to docker swarm (micro) - low prio, pushed to later session

checkouts

@3wc - working on cursed RoR app from 2012. code archeology. fun. super hyped about convergence and kiteflying. @ammar - just feeling good, hard to go back to dayjob. will have time for RTM and coopcloud stuff @chris - whoosh @marlon - excited about CC. people in minneapolis in the us right now, mounting organized campaign to follow :). requires lots of infra and data processing and mapping. people interested in turning this into something that can be re-producible and secure. want to use this framework to create a stack for re-use for this kind of monitoring and reporting work. @notplants - very cool. echo excitement feeling good about the project. grocery shopping next. @d1 - yeah great! so nice to hear everyone's voices. gonna just return to the couch, its late here. so good people are turning up to kite-flying. frontend/backend setup is mind-blowing. @micro - turned a corner in understanding how linux containers are supposed to work. prepping for difficult weather this weekend. @sarma - convergence super hype. glad it worked out. stressfull day, tough meetings. this meeting has been a releif that i could show up and listen without eating my last spoons. exhausted so time for bed.

looking forward to talking about swarm and swarm alternatives for kite-flying in the future.

@danny - very nice to look into this part of the world. screens off, maybe cup of tea. @3wc - lets say bye! @everyone - bye bye bye bye byebyebyebyebyebye

2026-01-08

Here: Calix, Steve, Ammar, kawaiipunk, diatom

• IPv6
  • A: Next step for fedi = documentation. Imagining myself using it a dozen months in the past, running into documentation, following it, seeing "double-check your docker bridge supports dual-stack for ipv6 support", plus step for how to do that immediately, link to blog post talking more in-detail.
  • 3: Wonder if rm'ing the stacks, tweaking config, redeploying, could work?
  • A: Testing this could be good.
  • A: Assuming most existing set-ups probably won't care for a while, especially if people are using it. But good to have docs ahead of time.
• Recipe scores / maintenance
  • https://git.coopcloud.tech/toolshed/recipes.coopcloud.tech/issues/44
• kp: Just an interesting sidenote, the CC meet up at Chaos Congress was attended by like 15 people .
  • kp: alakazam demo!! definitely encourage more IRL meetups. conversations about moving things into abra. v political. CCC = 15k people! makes it feel not so ambitious to be taking on big tech.
  • d: what is alakazam?
  • kp: Local-IT's tool to help manage large deployments. layer on top of a layer on top of a layer. https://git.coopcloud.tech/moritz/alakazam
  • kp: only record what you change - don't need to think about default stuff in .env files. Supports their platform SaaS offering, spinning up many copies of various apps. Logos, SSO secrets. Ways to better deploy & maintain. Kollicloud.
  • kp: I'll post in signal chat to see about cleaning up notes from the meetup to pass onto matrix.
  • https://matrix.to/#/!JSVYWCRXSVMrAzgeKB:autonomic.zone/$vb496hRtO0oGdqyBIYbMBcxwrg3PUyLeyB1h0rPGaFg?via=autonomic.zone&via=matrix.org&via=tchncs.de
• kp, A, 3wc: co-op cloud on AWS?
  • A: tried it out! possible but Very Annoying. All you want from them is a VPS + public IP address. Scope creep of other services - need to use their firewall, different types of disks, filesystems. The way you do backups = can't do backups to external disk without paying for egress. AWS is built to be used only to be used with other AWS services and not with others. Possible to use AWS with kafka.
  • 3wc: would be cool to publish even that much info about it, for folks who likewise have AWS credits, or at orgs which are forced to use it?
  • A: not excited to revisit that but could do if it would be useful to someone
• kp: any progress on creating redundancy for recipe repositories? heinous git.coopcloud.tech issue due to broken local gitea repo. Caused git.coopcloud.tech outage, halt to systems, members, wider community. Talk about decentralising / creating redundancy for recipes.
  • 3: remember some messages about making e.g. codeberg mirrors of repos, can imagine putting this as a fallback in abra. But not sure how to decentralise further or how other projects could handle this
  • kp: https://forum.yunohost.org/t/yunohost-mirrors-are-bugged-broken-during-installation-process-cannot-continue-installation/26091 -- only 1 debian repo
  • A: potentially an offline mode to use whatever is available locally?
  • 3: think there is --offline for most commands, think it didn't work in this situation - can't fully remember, maybe local copy was too old?
  • kp: think part of the problem was deleting local copy.
  • A: could have domain resolve to multiple IPs, network tools could retry different IPs if one is not working. can have some federation members maintain copies, wouldn't need to be super up-to-date, weekly or even monthly. then git.coopcloud.tech could resolve to all the IPs.
  • kp: maybe having debian repo is slightly more resilient than having whole gitea server. imagine cloudron is probably the same. could feed this back to community, federation.
  • https://git.coopcloud.tech/toolshed/organising/issues/674
  • 3: wonder about documentation for updating co-op cloud infra itself, is there any way that other fedi members can help? in parallel with ideas like Ammar's. also: maybe working out what the critical pieces of infra are, then documenting which fedi members are holding those and how to restore from them.
  • A: https://fireye.coffee/blog/FEDERATE-GIT/ interesting thoughts
  • 3wc: https://codeberg.org/coop-cloud
  • kp: what i could have done, without any fancy automation, would have been to pull that repo from elsewhere, get going again. mirroring all repos to a different git instance - manual restore without having to tweak abra, do fancy DNS stuff.
  • A: i like path of least resistance to start with vs thinking about fancy stuff.

2025-12-11

Here: Calix, notplants, Steve, micro, chartruce

• m: sutty design volunteers
  • m: joined website redesign chat last week. Sutty is doing a co-op cloud website redesign, they need people to be engaged, every 2 weeks, 20 minutes to either use current site or explore sketches of design changes / improvements. Don't think there's a strong starting date yet. Ideally there would be 4-5 people providing different viewpoints, focuses. Expectations were set last week to be less ambitious, we don't want to promise there will be a lot of people. If you want to influence information design, messaging, whatever - join the Element chat! https://matrix.to/#/#coop-cloud-new-website:autonomic.zone Starting January-ish.
  • m: 2 priorities - attracting donations. And giving more advice on how people can get involved.
  • c: Personally did find website to be slightly unintelligible about what exactly the website was, that there was a community. Unlikely I would have ended up here if I hadn't been pulled in through personal connection.
  • 3wc: Context: website slammed together in < 1 week for an initial funding application in 2020, not updated much since then.
  • PDF: https://matrix.to/#/!eIqyKcHZprdKdYUbai:autonomic.zone/$RDc22bt2c0uQPyhNELgwWN822mIBCYqKicZ5QKH08JE?via=autonomic.zone&via=matrix.org&via=sutty.nl
    • m: 2 sections: tangible preliminary work they've already done, what do people care about. Second half - statement of how they'd like to work. Most important page imo explains cycles of how they want to move forward. 5 phases of gathering / absorbsion / research / feedback. Thought-out process, sets the stage of how much work they're looking for from volunteers, small time committment.
• n: lasuite-people (is there more docs on this somewhere: https://git.coopcloud.tech/toolshed/recipes-catalogue-json/src/commit/01c170192b0539d9d5e9acd3bec62f5820b9a086/recipes.json)
  • n: went to this repo, not much in readme
  • https://docs.coopcloud.tech/maintainers/catalogue/
  • manifest.toml in root of repo for yunohost packages. includes imagelink, description, other metadata
• n: how does co-op cloud handle upgrades, vs yunohost (chatting with d1) (postponed to another time)
• c: reportback on beta deployment for ridgewood commons
  • easiest way to test out backups of backupbot? deploy entire site backup to server or local server and see if the backups are broken. to do this right now: would set the stack name in the recipe to an explicit value (abra is using this internally to decide the names of all the volumes and service names in docker swarm etc.). would copy the containers and secrets onto the other service and then do a full snapshot restore. potential blocker around traefik being fussy about certs. could be a useful story to have an answer to.
  • found the experience of authentik to be nicer than keycloak, but also it was slower.
  • 3wc: the ux maybe a bit better for authentik. authentik has some wrinkles. keycloak is very corporation-brained. extending authentik is slightly neater as you can write python in the UI. keycloak you are writing a java plugin or in no-code hell. rauthy is a third alternative. why do all these UI suck. but maybe there are fewer clicks in rauthy. the identity providers are oriented towards the enterprise (with all the heaviness and mismatched priorities that entails). m: have migrated domain names once and boxes twice. mabye worth it to separate out users and passwords and maybe even roles and use an LDAP provider. https://kanidm.github.io . they say, if you are small org and want decent defaults, try rauthy. https://pocket-id.org (passkey fundamentalists). notplants will report back with what people actually looks like.

2025-11-27

Here: 3wc, micro, Huincul, chartruce

• Changes and tradeoffs
  • Hedgedoc → Bookstack → maybe Outline
  • Docker → Podman → Incus?
  • (comms / chat platform - Element, Matrix, Zulip)
  • Check-in / check out / inventory, sharing system
  • Supported, sandboxed environment for experimentation
  • SSO: Keycloak → maybe Zitadel? https://zitadel.com/docs/guides/integrate/identity-providers/introduction
  • https://v.st/Main_Page#
  • Changed physical machines & domain names was relatively straightforward (podman volume export). Certs, links. Switching internal IDs changed, had to relink them in bookstack to maintain ownership. If it was LDAP-backed we could swap out providers.
  • Keep things understandable by a single person. Group of 5-6 available but usually only one available at a time. Built-in resiliency on knowledge-sharing.
  • New abra "app move" command https://git.coopcloud.tech/toolshed/abra/pulls/605 . Data migration interesting? Application specific. Some have major issues e.g. mastodon. Others include it e.g. Bookstack convenience tool, Wordpress CLI command
  • Secret management
  • Anubis bot protection
  • Portability - STACK_NAME
  • Incus
    • Nothing in terms of ergonomics in same level as docker swarm.
    • Podman → Quadlets
• Local workshops about co-op cloud, also build capacity
• How to know if each recipe is "functional, usable"
  • https://docs.coopcloud.tech/federation/resolutions/passed/025/

2025-10-30

Here: d1, Cas, 3wc, forest

(freewheeling intro chat about delta.chat, email hosting etc.)

• Capsul status upd8
• Maintainers proposal
  • Resolution 25 https://docs.coopcloud.tech/federation/resolutions/passed/025/
  • p4u1's right-on Traefik "let's make this maintained" proposal https://git.coopcloud.tech/coop-cloud/traefik/issues/60
  • New issue in toolshed/recipes.coopcloud.tech? https://git.coopcloud.tech/toolshed/recipes.coopcloud.tech/issues/42
  • d1: How did Debian go from "everyone can push to main" to "rules"?
  • Cas: They were doing what we were doing (chaos merge) but they didn't call it a "release". Sort of following BSD. Treating every unmarked recipe as "unmaintained", opening tickets against all evidently-maintained recipes (or al of them?) could be a way to approach that? Existing everyone-can-push-to-main = testing, prerelease
  • 3wc: +1 +1 +1. Love mass-opening-tickets. What about timing? Do we announce e.g. "By $date of $month we will turn on scary warning in abra and scary warning on recipes.coopcloud.tech" or define it as "we will flip those switches when a certain number / certain set of recipes is 'stable'"
  • Cas: We need some way of this being arbitrated before we remove permissions. Examples: what if a maintainer vanishes? What happens to hand over? Doesn't need to be super-rulesy. maybe unmaintained for whatever reason just reverts to open commit until somebody steps up .
  • 3wc: Yeah definitely see a risk of structural cookie-licking. What about Cyberia's "responsiveness" criterion for remaining a member?
  • F: Not working super great unfortunately 😔 Not much process for doing a good job of backup person / backup process. Solution: full-time 6-figure salary 🙃 Necessity is the mother of invention. Every time someone complains about a recipe not being maintained
  • Cas: debian handles this by making it so any maintainer can upload a version of the package, and if nobody objeocts takes over the maintenance if the old maintainer is absent or whatever
  • 3wc: So any maintainer of any recipe?
  • Cas: Yes, any maintainer / developer can upload to archive, takes precedence. Social contract not to upload other people's packages unless it's security critical, or holding up a release etc. Matter of conflict resolution to violate that conflict resolution. Translating to coop cloud = social committment not to make changes to others' recipes without PRs.
  • 3wc: At what point in Debian process does the listed maintainer change?
  • Cas: Someone notices it's unmaintained, files a bug against package "remove unless maintainer found" -- it often sits in that status for a year. Not going into new releases, release managers will start filing bugs against it. Doesn't get removed from unstable archive but doesn't get added to stable archive -- then separate step to remove from unstable archive.
  • d1: Sounds do-able. Timeline? Seems like the kind of thing that would happen over the course of a year? Would be cool to see if we could make a plan for it? Does it need to come in more decisions, "hey we'll all try and do this jan-march"? Or something people can just do? Blasting issues to repos with the steps - sounds practical.
  • 3wc: Could feasibly make it so that only maintainer can push direct to main, other maintainers can approve PRs on other recipes -- so they could still merge critical stuff in an emergency, but there's an extra little friction to stop accidental driveby "main" commits.
  • d1: Do like pressure valve release, allowing people to roll with rhythm they have, do their shit... but needs some limits. Just checked, Traefik repo, releases tab -- we're just pushing regular old tags. But maybe we switch over and "anyone can make tags", only maintainers can make releases?
  • Cas: Possible to access releases from git CLI? Or using ZIP / .tar.gz instead of git repo? Encapsulate state of the release?
  • 3wc: Unsure. Accessible by Gitea API / tea CLI for sure. Would it make --offline mode less useful? But release info would be in catalogue
  • d1: Marking tags? Naming convention?
  • 3wc: Can't make a PR for new tags?
  • d1: Indeed. Can make them from UI. Maybe social convention, tags are only released by maintainers?
  • Cas: Idea - keep everything as it is now, except add a different kind of catalogue entry, presents as a URL you can obtain tarball from (which is a particular release) rather than a git repository. So "download a version of the recipe" involves downloading a tar.gz rather than git. So eventually more-arbitrarily create releases, out-of-band of recipe catalogue.
  • d1: That seems like the way. Parallel text file / JSON, point back. Current layer remains in all its chaos and beauty.
  • 3wc: Supply chain attack possibility with tarballs / zips instead of git repos? And maybe something needed for people who want to contribute to a recipe?
  • Cas: abra recipe developer $recipename
• Recipes.coopcloud.tech design council
  • Does the site only show "stable" recipes by default?
  • Should we turn the existing "Status" → "Features" dropdown into checkboxes?
  • Do we remove the "Features" dropdown? Maybe kinda useless?
  • Cas: imo: - definitely checkboxes; - highlight stable in some way, maybe badges or something so that it's clear that these are stable ones; it'd be nicge to have some notes about what the levels of stability mean
  • 3wc: How does Debian handle this?
    • Cas: Totally different distros. More like "suites", optional additions.
  • 3wc: How about Yunohost?
    • d1: Everything shown at once, with score, but warnings for less-stable stuff.
    • 3wc: Could be cool to show a warning running abra app new when you deploy?
    • Cas: Show but don't stop. abra.yml?

2025-10-23

• kite-flying calendar where?
  • bi-weekly changing between 12 UTC and 19 UTC
• 39c3 talk proposal
  • mayel: could bring to the table how awesome coop cloud is as an app developer

2025-10-09

d1, Ammar, Simon, stevensting, 3wc

• co-op cloud chaos competitor comrade comparison

  • look at https://docs.coopcloud.tech/intro/comparisons/, anything need updating / clarifying?
  • add any new ones which aren't on there yet. https://dokploy.com/ https://cosmos-cloud.io/
  • webui inspo? 🧑‍🎨 https://git.coopcloud.tech/toolshed/organising/issues/681
  • anything neat we can see on other projects' homepages? (darn we should have done this before the website survey 🙈)
  • any interesting chatrooms we could drop into to make some links with other projects?
  • dare we... try some of them out?

• postgres upgrades

  • pgautoupgrade https://git.coopcloud.tech/coop-cloud/loomio/commit/1a937addc2a76abce532cbf93347ab206ac202c9
  • or entrypoint https://git.coopcloud.tech/coop-cloud/outline/src/branch/main/entrypoint.postgres.sh.tmpl
  • general recommendation?
  • LIT has 130+ postgres containers 😵‍💫

postgres

quirks with pgautoupgrade

steven: loomio recipe had many issues. quirk was that ruby is somehow also managing the postgres-db and runs migrations when you upgrade the database structure via a loomio upgrade - so if you do both at the same time it might result in issues people who are running the recipes need to do step-by-step upgrades, they shouldn't skip the in-between releases -> release Notes! 3wc: postgres needs only help with major version upgrades

3wc: pgautoupgrade handled postgres initial deployment different from standard image - upgrade worked fine but init deployment not?

maintainers

single vs multiple maintainers social process for handing over maintainership commit bit?

upcoming talk!

governance vs tech demo

2025-09-25

present: iexos, d1, cyrnel

• recipe stability release brainstorm: #663
• hacking on the update: https://pad.f0x.link/26j2hTJ-SFapBkN_VlsiwA#
• hack-a-thon in stuttgart coordination

recipe stability release brainstorm

https://git.coopcloud.tech/toolshed/-/projects/31 https://git.coopcloud.tech/toolshed/organising/issues/663

• d1: we started super automated, nobody really understood how it worked. we reverted to doing everything more or less manually. we feel like more people understand how it works now tho so we can maybe go back to automation
• i: its complicated and now were all making little mistakes
• c: it's kinda annoying yeh. would be nice if abra recipe ... didn't require you to run it in $ABRA_DIR/recipes/... and just did stuff in the $PWD.
• d1: lets go from the question "what annoys you?"
• i: confused in beginning why there were so many release commands. understand it now. updates to repos made are often not published so then they dont end up in the catalogue and we cannot upgrade to them with abra. the tooling is the culprit for this. when looking at a release commit, you only see the label bump and not all the changes that happened since the last release - missing transparency. you type 3 commands, get 1 commit, tags/labels pushed and done. but you don't see the previous changes. also it's possible to include changes in compose.yml along with the label bump. why are the sync/release command separate? could we make release only deal with "release things". release requires clean working directory.
• d1: abra recipe release is then just "i want to tell the world the latest commit is the new release". bonuses for testing/automation probably!
• i: also possible to check other stuff then
• d1: ...recipe release churn...
• c: maybe dealing with recipe release churn is more important. check-list approach? (to balance magical and manual)
• i: agree churn may be more important but release process is probably easier to fix
• d1: we really need a test suite
• c: what do we mean by testing? browser tests?
• d1: yunohost test suite is expansive: https://ci-apps.yunohost.org/ci/apps/
• d1: nextcloud horror: https://ci-apps.yunohost.org/ci/job/22480

Level results

Level 1 (Installable in at least one scenario) OK Level 2 (Installable in all scenarios) OK Level 3 (Can be upgraded) OK Level 4 (Can be backup/restored) OK Level 5 (No linter errors) OK Level 6 (App is in a community-operated git org) OK Level 7 (Pass all tests + no linter warnings) OK Level 8 (Maintained and long-term good quality) OK

• i: there aren't 100000s ways you can configure the app in yunohost like we have in coop cloud
• d1: compare our current CI: https://drone.autonomic.zone/coop-cloud/nextcloud/54
• d1: source code: https://git.coopcloud.tech/toolshed/stack-ssh-deploy/src/branch/main/plugin.sh
• d1: https://git.coopcloud.tech/toolshed/stack-ssh-deploy
• d1: abra integration test suite: https://git.coopcloud.tech/toolshed/abra/src/branch/main/tests/integration

Takeaways: d1: i need to test https://playwright.dev c: mastery of unactionable action points i: not releasing changes, this should be fixed. testing is hard to do, bigger topic

action point: explain like 5 years old next steps for improving release process, open tickets, check brains, implement it

2025-09-18

present: iexos, marlon, 3wc

• there was a coop cloud talk at HOPE! 🤯
• and a coop cloud teach-in at an event in upstate NY

• (A conversation about accessibility, CLI, web UI)

• Web UI:

  • https://swiftwave.org/
  • https://komo.do/

2025-09-11

present: d1, 3wc, stevensting, cyrnel

• Hackathon DE
  • S: Good idea to have a specific co-op cloud online collaboration session regarding maintainers proposals? Automate stuff, add renovate bot → make it easier for maintainers. Maybe we set the timing depending on who is open to join? Heard from RTM.
  • d1: Great idea! I will know by the 22^nd if I can join.
• Maintainer stuff now, The Sheet™
  • 3wc: multiple maintainers? Adding status to recipes?
  • d1: the sheet: https://cloud.klasse-methode.it/s/yc9tg4P2tsF7LQA
  • S: the proposal: https://docs.coopcloud.tech/federation/resolutions/passed/025/
  • S: For me the key is automation
    • 3wc: Agreed. Maintainers' job is approving PRs from e.g. renovate bot
    • d1: Imagine this: today you have a maintainer, they run abra recipe {upgrade,sync,release} - hopefully they run something before a release to check it works. We just said some automation would be good. Some paths: one of them, automate everything you could ever want, e.g. check login once the app is up. Saw Moritz was using Playwright for Mega Test Suite. Another path, just the basics - make sure it can deploy, undeploy, backup, upgrade, minimal shit → give the logs. When someone pushes a new release, a CI job runs some basic checks, "I am now going to try and deploy what you've just released", provide some text logs, maintainers can view that, click "this is good" / "this is not good". Most primitive version of "stable" / "not stable".
    • S: sounds like a good start
    • M: renovate works?
    • 3wc: works but got stuck on some SSL issue. currently borked.
    • d1: Some way for renovate to know about recipes?
    • S: private repo currently. we have a system that goes through our recipes, makes PR. but this is for recipe users, what we would need in co-op cloud git repo would be to check for docker upstream images.
    • d1: that's one part, "do we need to do an update?". Could imagine a repository which has a JSON file with keys like "stable", "testing", "unmaintained". Renovate could update JSON file and CI could run test based on pull requests.
    • M: how it works at my job: enable branch protection, merges to main trigger CI to tag and release (or use a manually triggered job). Tests run on PRs. Result: I review 30 renovate PRs per day and release to prod that frequently.
    • 3wc: notification from gitea that wallabag has an update (using renovate)
    • S: Make a list of "what a recipe maintainer would currently do" then "how we might automate it"
    • 3wc: can renovate run recipe sync / recipe release?
    • M: No, would need a CD job for that. Renovate not turing-complete
    • d1: abra recipe sync --minor, /slash command in PR?.
    • d1: Just automate abra recipe upgrade, then you still need to manually run abra recipe sync / release
    • M: renovate bumpVersions docs: https://docs.renovatebot.com/configuration-options/#bumpversions
    • S: At least CI could try sync on the branch.
    • d1: Does this mean adding method to sync to auto-detect upstream version bump?
    • S: Even just defaulting to minor would be good. But even better: using upstream version.
    • d1: Sometimes an upstream "minor" becomes a "major" because of adding secrets etc.
    • S: Up to maintainer, try it out, decide what's up.
    • 3wc: Utopian vision:
      1. Renovate Bot proposed compose.yml update to new upstream image versions, opens PR
      2. CD runs abra recipe sync on PR (M: or renovate can do this, bumpVersions)
      3. Maintainer tests recipe and either accepts proposed label update, or tweaks it
      4. Maintainer merges PR
      5. CD runs abra recipe release on PR merge, catalogue updates, woohoo
  • M: There isn't a running renovate instance pointing at the coopcloud git - that's probably the first step.
  • M: Will deploy an experimental renovate instance on his own server and report back

WHAT WE THINK MAINTAINER SHOULD DO	HOW WE AUTOMATE MAINTAINER
check for new upstream versions	renovate on recipe repository
test proposed new versions	???
bump the labels when a new upstream version happens	https://docs.renovatebot.com/configuration-options/#bumpversions
do abra recipe release to push the tag	???

{"testing": {
    # renovate: data-source=docker...
    "nextcloud": "1.0.0+0.21.1",
}}

# read json file
# pick up version
# do abra app deploy <app> <version>

a layer between the "testing json" and our "catalogue.json" so when a maintainer releases a version there is tests before it goes "live"

yunohost https://ci-apps.yunohost.org/ci/apps/

---

name: renovate

on:
  push:
    branches:
      - 'renovate/**' # self-test updates
  schedule:
    - cron: '0 0/2 * * *'
  workflow_dispatch:

env:
  RENOVATE_REPOSITORIES: ${{ github.repository }}

jobs:
  renovate:
    if: ${{ secrets.RENOVATE_TOKEN != '' }}

    runs-on: docker
    container:
      image: ghcr.io/visualon/renovate:41.97.9

    steps:
      - name: Load renovate repo cache
        uses: https://code.forgejo.org/actions/cache/restore@040.... # v4.2.4
        with:
          path: |
            .tmp/cache/renovate/repository
            .tmp/cache/renovate/renovate-cache-sqlite
            .tmp/osv
          key: repo-cache-${{ github.run_id }}
          restore-keys: |
            repo-cache-

      - name: Run renovate
        run: renovate
        env:
          LOG_LEVEL: debug
          GITHUB_COM_TOKEN: ${{ secrets.RENOVATE_GITHUB_COM_TOKEN }}
          RENOVATE_BASE_DIR: ${{ github.workspace }}/.tmp
          RENOVATE_ENDPOINT: ${{ github.server_url }}
          RENOVATE_PLATFORM: gitea
          RENOVATE_REPOSITORY_CACHE: 'enabled'
          RENOVATE_TOKEN: ${{ secrets.RENOVATE_TOKEN }}
          RENOVATE_GIT_AUTHOR: 'Renovate Bot <renovate-action@...'

          RENOVATE_X_SQLITE_PACKAGE_CACHE: true

          GIT_AUTHOR_NAME: 'Renovate Bot'
          GIT_AUTHOR_EMAIL: 'renovate-action@....'
          GIT_COMMITTER_NAME: 'Renovate Bot'
          GIT_COMMITTER_EMAIL: 'renovate-action@...'

          OSV_OFFLINE_ROOT_DIR: ${{ github.workspace }}/.tmp/osv

      - name: Save renovate repo cache
        uses: https://code.forgejo.org/actions/cache/save@040.... # v4.2.4
        with:
          path: |
            .tmp/cache/renovate/repository
            .tmp/cache/renovate/renovate-cache-sqlite
            .tmp/osv
          key: repo-cache-${{ github.run_id }}

{
  "extends": [
    "config:recommended"
  ],
  "schedule": [
    "* 0-4 * * 1"
  ],
  "prHourlyLimit": 10,
  "packageRules": [
    {
      "matchPackageNames": [
        ".*"
      ],
      "matchUpdateTypes": [
        "major",
        "minor",
        "patch"
      ],
      "enabled": true
    },
    {
      "description": "Automerge renovate updates once a week",
      "matchDatasources": [
        "docker"
      ],
      "matchPackageNames": [
        "ghcr.io/visualon/renovate"
      ],
      "matchUpdateTypes": [
        "minor",
        "patch",
        "digest"
      ],
      "automerge": true,
      "groupName": "renovate"
    }
  ],
  "customManagers": [
    {
      "customType": "regex",
      "fileMatch": [
        "^servers\\/.*\\/.*\\.env$"
      ],
      "matchStrings": [
        "(RECIPE|TYPE)=(?<depName>.*?):(?<currentValue>.*.*?)"
      ],
      "datasourceTemplate": "gitea-tags",
      "depNameTemplate": "coop-cloud/{{depName}}",
      "registryUrlTemplate": "https://git.coopcloud.tech"
    }
  ]
}

2025-09-08

3wc, d1

https://git.coopcloud.tech/toolshed/-/projects/34 https://git.coopcloud.tech/toolshed/-/projects/38

2025-08-28

sef, Stefan, 3wc, Edu, d1

• community survey
• what we did
• what we received
• what is still up in the air

Link to survey replies: https://cloud.doop.coop/s/yYsAeAEW6Xi9fam

Link to work (in a mural): https://miro.com/app/board/uXjVI0qDbrY=/

Process: 1. Questions 2. Replies 3. Semantic analysis + product field 4. Common topics 5. Proposal

Meeting ideas: - Emphasize "this is real", alive and moving. - "Collaborative blog" with members sharing thoughts of what they're appreciating with CC - Show what people are deploying - Show what people are discussing about CC - Convey the idea of a living project - Stronger fediverse prescense - Public roadmap - Live map/list of apps deployed with CC - Live map/list of coops enrolled with CC - Pace layering https://jods.mitpress.mit.edu/pub/issue3-brand/release/2

We will wait a few days for feedback before going forward. :)

2025-08-04

Calix, d1

• weblate / abra hackin'

The brief wonderous life of a po file

1. Goose-hacker dev adds a new command (abra app toilet) to abra, including a bunch of strings (command output, --help content, etc.) which should be translated (flush)
2. Dev runs xgotext <something> to add the new strings to locales/default.pot (The Template)
3. Dev runs msgmerge <something> to add new strings to each language file, one for each language
4. Dev commits and pushes to the repo
5. Weblate pulls changes and updates translation status
6. Translators edit the .po files through gettext, Weblate commits back to main
7. Someone/something runs msgfmt <something> to compile the PO files to MO and commits the result to git
8. Anyone who compiles abra sees the translated strings

Automation thoughts

There is a Weblate extension for msgmerge https://docs.weblate.org/en/latest/admin/addons.html#update-po-files-to-match-pot-msgmerge

xgotext needs to be "automated by hand" - git hook / drone step to only run on changed dirs - run it in drone -- new drone-xgotext drone plugin (immense co-op cloud outreach hype) which will produce updates locales/default.pot (template) - auto-commit back to the repo on merge to main? (and maybe also CI check on PRs)

automating msgfmt - just a drone job on main which compiles all the POs every time they change

questions for Later

• pull requests or direct commits for Weblate?
• adding msgfmt / xgotext calls to any or all of:
  • go build process (makefile)
  • release process
  • CI/CD
• separate gitea user for weblate, add SSH key?
• better OIDC key algorithm for SSO

2025-07-28

Calix, d1

• platform6 migration / resolution / etc.
• PG payment upd8
• sheets / budget wrangling?
  • is the format OK? / activity budgets
  • what do we port?
• abra dev
  • timeline / milestone
  • check hours

platform6 migration / resolution / etc.

current status: 5 👍 and 1 🤷 / 8 votes (quorom)

TODO: 3wc: get Autonomic do do a vote on this ASAP, handing over to probable Aadil TODO: d1: target ping the diff of remaining members

P6 payment upd8

Invoice submitted from Autonomic to PG Caveats for the federation: * there is a higher rate ($50 an hour) * 3wc/d1 kinda just "doing it" but wanted to share * going through PG -> Autonomic -> $us vs. PG -> OC (PG6) -> $us

"we tried"

sheets / budget wrangling?

We should probably add resolution # / budget # to Projects.

TODO: 3wc: find all budgets, add them to sheets TODO: d1: move 030-docs-naming-survey to stalled vs. in-progress TODO: 3wc: Make "Project overview" more read-only

docs/federation/resolutions/in-progress/030-docs-naming-survey.md
27:## Budget 0YY: Docs / naming survey
29:* Budget amount: up to EUR 160

docs/federation/resolutions/passed/029.md
64:- Budget amount:

docs/federation/resolutions/passed/011.md
5:- Topic: Budget 005: Backup improvements
18:**Budget amount**: Up to EUR €200

docs/federation/resolutions/passed/004.md
5:* Topic: Budget 001: Budgeting
24:> **Budget amount:** EUR 960
36:**Budget amount:** EUR 100,000

docs/federation/resolutions/passed/008.md
16:**Budget amount**: EUR €20/month

docs/federation/resolutions/passed/023.md
5:- Topic: Budget 012: Feedback gathering and content architecture for the new Co-op Cloud website

docs/federation/resolutions/passed/006.md
5:- Budget 002: Resolution Writing-up
16:**Budget amount**: EUR 100

docs/federation/resolutions/passed/024.md
39:### Budget 013: Kite-flying 2024-2025
41:> **Budget amount:** EUR 2000

docs/federation/resolutions/passed/021.md
5:- Topic: Budget 011: Migrate to Cobra

docs/federation/resolutions/passed/014.md
5:- Topic: Budget 008: Critical Fixes
39:**Budget amount**: 1900€/95 hours at maximum

docs/federation/resolutions/stalled/013.md
11:- Budget 007: Operator sync
69:**Budget amount**: 200 EUR (10 hrs * 20 EUR/hr)

docs/federation/resolutions/passed/010.md
5:- Topic: Budget 004: Critical fixes

docs/federation/resolutions/passed/012.md
5:- Budget 006: Abra integration test suite
27:**Budget amount**: 600 EUR (30 hrs * 20 EUR/hr)

docs/federation/resolutions/passed/026.md
5:- Topic: Budget 014: Backpay for `v0.10.x` abra release work

docs/federation/resolutions/passed/016.md
5:- Topic: Budget 008: Backup-bot-two Documentation and Specification
45:- Budget amount: 200 EUR (10 hrs * 20 EUR/hr)

Things to add: * 013 Kite-flying * 010 Yearly critical fixes * 012 Feedback gathering and content architecture for the new Co-op Cloud website

abra dev

let's log this meeting, let's log PG admin hours autonomic has invoiced for milestone 1 invoice timeline: end of august, end of september

translations: website: separate markdown files in hugo docs: probably the same 👆 abra: weblate / gettext

weblate: sso (usese git connect to update via web ui (!)) abra: sub-cmds are strings "app", good "hello, world" there! gettext: catalogue file per lang, e.g. *.pr.po, messageIds are generated from the english strings, all the langs get piped in and then locale / config flag to specify the language + runtime lang switch will happen

weblate/gettext etc. wont really affect the build so much. everything gets

2025-07-24

Calix, Jackie

2025-07-02 Continuous Deployment / recipe catalogue disco

3wc, kawaiipunk

The Problem: several recipes are not being included in the catalogue https://git.coopcloud.tech/toolshed/recipes-catalogue-json/issues/8#issuecomment-25016

The Probable Cause: automatic recipe catalogue regeneration is not using the latest version of abra; it's using an old one which required the "recipe" Topic to be set on Gitea repos.

The Probable Solution: update automatic recipe catalogue regeneration to use new abra. https://git.coopcloud.tech/toolshed/auto-recipes-catalogue-json/issues/5

Bonus / sidebar #1

pondering making docs clearer. Readme improvements for these repos? - https://git.coopcloud.tech/toolshed/recipes-catalogue-json - https://git.coopcloud.tech/toolshed/auto-recipes-catalogue-json/

And structural changes / improvements to this? https://docs.coopcloud.tech/maintainers/handbook/ - We did this, new page https://recipes.coopcloud.tech/recipes.json

Oh and there's a PR to review on auto-recipes-catalogue-json https://git.coopcloud.tech/toolshed/auto-recipes-catalogue-json/pulls/6

kp: Docs confusing about "manual" but then all these mentions of "automatic" 3wc: It's "manual" for new contributors.

kp: Missing some kind overview? 3wc: Agreed 3wc: There is this page but it's pretty wrong: https://docs.coopcloud.tech/abra/recipes/. "Our Catalogue is a web interface" well really it's a JSON file.

kp: What situations would you want to generate a new recipe catalogue? 3wc: Almost none now, because abra upgrade will look at git tags. So we could heavily deprioritise this, or even remove it.

Draft text for catalogue intro

The "recipe catalogue" is a list of all the recipes that can be deployed with Co-op Cloud (see "recipe" in the Glossary), including which versions of each recipe are available.

If you're familiar with apt or yum, this plays a similar role to their package index.

The machine-readable recipe catalogue lives here: https://recipes.coopcloud.tech/recipes.json

And, there's a human-readable version on https://recipes.coopcloud.tech/

The recipe catalogue is generated automatically from the recipe repositories here: https://git.coopcloud.tech/coop-cloud

Bonus / sidebar #2

• there's this issue on recipes-catalogue-json https://git.coopcloud.tech/toolshed/recipes-catalogue-json/issues/7

2025-06-30

3wc, d1

(semi-secret kite flying)

• Legal shenanigans for red abya yala work
• Budget shenanigans for red abya yala work
• Co-op Cloud legal form brainstorm

Notes

Legal shenanigans for red abya yala work

• autonomic still super busy
• lai picking up finance work, K not involved atm. 3wc cant help with finance work "soon". beach factor = 1
• unclear who has overview of the MOU in the autonomicz
• TODO: 3wc/d1 write to autonomicz that we will do what it says in the MOU

Budget shenanigans for red abya yala work

(We consult las estimaciones)

• 42.9 hrs: general improvements to abra (30h dev, 9h testing, 4h project mgmt)
• 42.9 hrs: translation of abra (30h dev, 9h testing, 4h project mgmt)

• (??? )

• total: 85 hrs / 4290 total

• 4290 * 0.15 = 643.50 (potential PG cut? see below)
• rate: 50$

TODO confirm with fauno where the recipe packaging time is TODO ask fauno if "project management" contains PG time or if we should deduct that on top

TODO: Monthly checkin on assigned tasks? * 28^th july, last monday of the month 15:00 CET ($other_timezone) TODO: gather list of work: https://git.coopcloud.tech/toolshed/abra/issues + organising + assign * split total in half, checkin monthly on progress, done.

abra work

general improvements

d1: * https://git.coopcloud.tech/toolshed/abra/issues/580 * https://git.coopcloud.tech/toolshed/abra/issues/577 * https://git.coopcloud.tech/toolshed/abra/issues/575 * https://git.coopcloud.tech/toolshed/abra/issues/574 * https://git.coopcloud.tech/toolshed/abra/issues/573 * https://git.coopcloud.tech/toolshed/abra/issues/568 * https://git.coopcloud.tech/toolshed/abra/issues/567 * https://git.coopcloud.tech/toolshed/abra/issues/564 * https://git.coopcloud.tech/toolshed/abra/issues/561 * https://git.coopcloud.tech/toolshed/abra/issues/560 * https://git.coopcloud.tech/toolshed/abra/issues/558

3wc: * https://git.coopcloud.tech/toolshed/abra/issues/557 * https://git.coopcloud.tech/toolshed/abra/issues/556 * https://git.coopcloud.tech/toolshed/abra/issues/554 * https://git.coopcloud.tech/toolshed/abra/issues/553 * https://git.coopcloud.tech/toolshed/abra/issues/550 * https://git.coopcloud.tech/toolshed/organising/issues/638 * https://git.coopcloud.tech/toolshed/organising/issues/657 (maintain machine readable output) * https://git.coopcloud.tech/toolshed/organising/issues/646 * https://git.coopcloud.tech/toolshed/organising/issues/497

translate work itself

• https://git.coopcloud.tech/toolshed/abra/issues/483

https://weblate.org/en-gb/features/ !!! https://poedit.net

Website? Docs? Part of this? Maybe not but would be gr8.

half / half on these hours

42 / 2 = 21

TODO: weblate investigation

Co-op Cloud legal form brainstorm

another fiscal host? or separate org? * fiscal host * pros: preserve what we have as-is, decision making/membership/etc. save $$ on admin work. * cons: they take a cut from our income. reproduce beach factor in new fiscal host. might make it harder to reclaim, OC europe experience. * legal form * cons: might get stuck in specific form (just need a shared bank account). needs more engagement at a time it's hard to get input.

umbrella co-op in estonia? well-paid finance admins. sol fund. minimal structure around bank account. "the well". "watering hole". wild amount of research required to find out how we could find a legal form which fits how we run e.g. how the actual fuck is coopcycle actually set up and does it truly reflect how things are done in practice?

nonprofit fiscal host fiscal host that wants to be a fiscal host (main focus) opens doors for our funding efforts (not for-profit structure) ~ 5 % cut would be ok, 0 ideal (maybe co-op cloud federation membership)

ideas: * platform6 (?) (fiscal host for meet.coop back in the day) * graham innovation coop lead (hazy memory), to ask * waag (?) (NL-based permacomputing convo via d1)

TODO ask graham about P6 / I.C fiscal hosting (3wc) TODO ask Waag about fiscal hosting (d1) TODO ask Patio for reccs for fiscal host (3wc) TODO ask Cotech for reccs for fiscal host (d1)

10 - 15 members paying dues, 2300 EUR annually (5% = €115 / year) ~ 6000 EUR in the bank discussion about paying % of income as dues (will increase out collective income) we are actively searching for grants and have received ~ 4300 USD recently active participation in CC and we can help with first-line queries about finances

if this falls down, explore separate legal form / umbrella estonian chaos

2025-06-26

3wc, Tasha, Be

• New community members, hello!
• Podman, probably not making something like docker swarm

2025-06-05

3wc, kawaiipunk, trav, d1, ammar

Tagging abra maintenance issues (d1)

(d1 does a tour of toolshed, organising & abra repos)

migrating to abra going well, some issues still on organising but not so urgent.

cross-repo kanban board.

"Abra next" https://git.coopcloud.tech/toolshed/-/projects/34

Asked about some issues for "critical fixes", decisionmaking process, 👍 in the chat. Don't have a way of identifying critical fixes issues, they should be prioritised and so on.

A: Could we have voting done in Gitea? Doesn't need to be complicated (but could have a complicated bot if we like, check member list against reactions, adds label approved as critical fix). But also manually - "two comments from members, add label".

d1: Usually identifying priority comes from someone who is stuck, asks in chat, emoji put on there. Participation in project is probably highest in Matrix. But also quite a lot of activity on the issue tracker. Sometimes comes from an individual vs other people, maybe people don't see it.

C: Like Ammar's idea. So process could be, "post link to bug in federation chat, then +1s in gitea". Nice to have record of +1s

d1: Noticed resolution outofdate, pointed to board which doesn't exist. Maybe write in ticket where emoji came from? Could update resolution with additional decisionmaking.

A: Definitely thinking about having info in one place. Avoid frustration finding out how and when something became a critical fix. Don't want to create more manual work. Voting on Gitea = more work for people voting, less manual labour for person trying to get critical fix.

Action d1 make a label

Action d1 will make amendment to critical fix resolution

Abra troubleshooting thunderdome (3wc)

FATA Unknown server

Add to "SSH connection issues" some example error messages

and debugging command: ssh swarm-test.autonomic.zone docker ps

Not in docker group. Add ssh swarm-test.autonomic.zone groups

A: would be nice to link to troubleshooting, steps

d1: links to web can change. sudo abra man. could be more future-proof than writing in docs.

A: manpage online, build pulls in manpages.

Can't connect to server

f, d1: what is the context of the cursed oneliner? abra app ls -S -m | jq '.[].apps | select( . != null )[] | [ .appName, .upgrade ] | @csv'.

f: could have different branches for different recipe releases. gitea released a security update, couldn't upgrade because of interim releases.

d1: Postgres change published as a minor upgrade. Try to find a collective solution for everyone in one go. Some way to agree that releases need to be checked, greenlight. Currently "push'n'hope". Stability pipeline.

k: Maintainers proposal. First building block. Meta that we've created "forever maintenance thing" with a lot of recipes.

C: Maybe a followup resolution / working group for maintainers proposal rollout.

k: afaik two isses with maintainers implementation - me no capacity - no budget

d1: think this will be a big thing, maybe we have some money? currently upgrader needs to have a lot more knowledge about how co-op cloud works than they should.

k: is there automated testing that can happen?

d1: https://git.coopcloud.tech/toolshed/-/projects/31 + https://git.coopcloud.tech/toolshed/organising/issues/514

C: gold standard is yunohost, CI tests deploy, backup, delete, restore. current state: tests clean deployment, but only really checks for syntax problems etc. -- huge loophole.

f: we want abra recipes to be stable so it's a great goal. but not much budget. meeting yesterday about making things more stable. didn't get to auto-upgrades, but think it will be something we need. avoid desperate calls at night because someone installed a botched release. for me: micro release for an app, shouldn't be any new major changes on the recipe side.

d1: the current no budget workaround is to look very closely at what changes get made to the recipe and to understand all the *.compose.yml files purposes. and to understand the versioning scheme. and to understand that other comrades might not honour the versioning scheme

k: the way that debian does it, only backporting security fixes, is really hard to do. most projects - release notes are the best bet. some issues patched before announcement.

d1: i believe having a test suite for a recipe is possible, and reliable. test suite for e.g. nextcloud deploy first version, upgrade through all the way to the end. we know as the maintainers that steps might be required, could include those as patches / scripts in the tests. also what yunohst is doing. but we'd need to have a prototype for this, we should try to move towards something like this in general. our goal is to support people with little resources, a lot of mental load maintaining a recipe that is used by others.

c: agree. down to help. how much money might be avail in CC after radmin?

d1: can try to find answer.

f: maybe i can illustrate with an example? i feel we're talking about different things. gitea tags:

https://git.coopcloud.tech/coop-cloud/gitea/tags

f: people will need to go two minor recipe versions higher in order to get security patch release.

c: https://git.coopcloud.tech/toolshed/organising/issues/578#issuecomment-21839 - would this help? or make the situation even worse?

f: git branches?

d1: a little wary of git branches. people make config changes, but not every collective needs that change.

A: perhaps moritz's proposal solves things, because we don't always have to upgrade to latest.

2025-05-08

3wc, Abe, kawaiipunk, fauno, BillySmith

• kp: maintainers proposal. structural problem with docs - lots of material in resolutions which is kind of inaccessible.

  • 3wc: maybe resolutions should specify where stuff will be added in docs?
  • 3wc: also we talked about maintainers in march. noted that there's no budget for maintainers proposal rollout https://pad.autonomic.zone/VtyrLUl9RWaJGgEDrncQUw?view
  • kp: some docs reform happened. there is a bylaws page. maybe expanding pages, converting pages into collections.
  • 3wc: thoughts on p4u1's point about commit access from non-maintainers?
  • kp: would have to do a decision? otherwise would end up with multiple systems. some with maintainers & locked down, some with no maintainers.
  • 3wc: how would proposal work? would an individual or group be responsible for finding maintainers? or maybe opt-in cut-off, if nobody volunteers by a certain time then the recipe is unmaintained?
  • kp: could open issues on recipe repos? maybe even in bulk?
  • 3wc: yep relatively easy to bulk-open issues

• f: planning Escuela Común / Co-op Cloud funding

• f: defending against LLM scraping

  • https://marcusb.org/hacks/quixotic.html

2025-04-24

3wc, d1, Abe, cacu, p4u1

• Yunohost + Co-op Cloud

  • A: Yunohost feels complementary to CC. CC = good for 100 clients. Moving people between servers. Personal experience - part of a group that isn't a registered nonprofit, but can't afford fullprice "cloud" services. Hesitant about running Yunohost without some kind of backup.
  • C: (IN WITH A BOAT PUN) Probably a lot of similar orgs out there./
  • A: Lots of halfassed crappy services out there online, groups paying for
  • C: seems interesting. membership orgs (dont qualify for non-profit), needing services. Autonomic work a lot with NGOs but qualify for nonprofit discount pricing. Yunohost + auto apt updates = manageable amount of work? Easier to be cost competitive with larger number of users.
  • A: Reasonable amount of setup needed with yunohost. Backups, DNS. Ynh updates. Password recovery, that kind of stuff. Got Nextcloud & Friendica running on it. Struggling to get Jitsi & XMPP running. Exploring membership management - Wordpress, CiviCRM - but how to set things up? Most effort is the same independent of # users, would it be enough revenue? Several amateur sports clubs in the UK who could be interested.
  • L: Managed Yunohost for a sailing club. Model is "everyone can be a sysadmin". Under that layer - loads of really gnarly shit, you need patience and skill.
  • A: Emails from Yunohost every day "there are problems with your setup"
  • L: Not really designed around "friendly local sysadmin dropping in and doing stuff for you". Docs: "if you give someone access you must absolutely trust them".
  • A: Talking about different usecases. Most of the applications you would use on YNH are useful for >1 person. You want to run it for other people. "If I break my/your bike"
  • L: Seems like what is needed is "friendly local tech collective who will maintain yunohost for them"
  • C: Tend to agree and think the core question is the cost of setup/maintenance in relation to usership/usage/etc.
  • L: Can still do that to an extent with an existing kvm / incus / "system virtualisation" (and this also matches yunohost expectations)
  • C: coop developer, "open web systems", doing research into looking at templating setup of apps. findings: every group wants different things from their apps (customisation, etc.). systems that exist are as templated as they can be to match the needs of groups.
  • A: How many yunohost instances would be needed for it to make sense to manage them as a group?

• p: Co-op cloud's own infra

  • https://git.coopcloud.tech/toolshed/coop-cloud-apps
    • share ssh keys for access
    • swarm-1 will be added to the repo
    • shared management is welcome
  • L: sef/kpunk/myself willing to help with rauthy (SSO) setup
    • https://git.coopcloud.tech/toolshed/organising/issues/669
    • https://git.coopcloud.tech/toolshed/organising/issues/665
    • let's go slow on this / config churn / SSO logins are maintained
    • hooking up kimai
    • ALERTA: no SAML implemented in rauthy which kimai requires
      • any alternatives to kimai?
      • we could use authentik? (non-ideal UI but $better than Keycloak)
    • requirements for the single sign on
      • internal infra for CC
      • we need to manage logins for that
      • e.g. time tracking, (future) documentation, gitea, ci/cd, $other_future_stuff?
      • currently, people have a gitea and can access there but for the rest, new account time (sad emoji)
    • requirements of time tracking
      • collective budgeting (for features/things that require coordination against multiple people)
      • overview of budget, how much is spent/left over, etc.
    • gates of oidc hell in kimai: https://github.com/kimai/kimai/issues/2469

keys for access - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCjARl0db62BbWA74TxyCvqxUlVZmuAAyiVElfRmXIiEyOSgs0kF9mH4CmFkR3OkMM/kS3ImutH3PJGX2uuxml+l5gIXjqzQ6K/3tzg80J5rr6j/i41vG3bqlOQyI3+cYTdYnBprBqakfFSA3M04gwXYA+MODyqh1lH8DeS2k7EbobOM5vWdPaRaxD+/njkzLgKz462+i2xckSbPN/98jQTHgrhjpy/FbJzkQXxQahlP6DCmc+ZsKacydSrlJBBCDsRTMUTK7+WTCC1jXba+rAF1myTjmcT5GofGqeuCnE67pAd1V1jAWa8+LbJWjEVI3guqQHoOJ5cw0RkLvRqNz4LTxlnKJPvt0mQiZDyuGPK784kohavZXpv6wWabnRNALykAoxKFdaoEdl3mZA5WFXuj+5R1ERzAMDmDCH+U8k8wKVQmh4CKwCSQK45goYjooUUb+kIjIRQcwduvbcqr1l7BX4m2gjBaa3jBiy1ALPdpm8r4yZxR6poiD57ZMHS2cHjTYWmy3cZqOlEPQsy/fqkWTiAW63ETHWfLC75zRx0L0I0HQ9O1EVe7lFUxxpst9HcrkdtuFKvwh1ifG5CVauNBqlNtetXXkx3DKChBWr+uWCy1N0kuS6m2M+VYjb/ufd9G2o8Vh+wN/fgR6j7IEO7aXfCPAGcTeSfsi5wzNsOZw== decentral1se

2025-04-03

3wc, fauno, sef

• 3wc: Resolution hacking:
  • Joining in.fra.red / nominating spokeperson
  • Docs survey proposal pushin
• Website survey
  • 3wc: HYPE!
  • s: about 7 responses so far. thinking deadline next friday (11^th)
• f: Offering hosted services as the federation?
  • We have a client who would like more advanced web analytics than what's included by default in the CMS that they're using. But as Sutty we would prefer to focus on development, and static site hosting, and give "host X app" work to $someone_else. Obviously there are federation members (e.g. Autonomic) who could do that. But is this an opportunity to talk about having some shared services for the federation? Either / both:
    1. "Join the federation, get voice and vote as well as access to " (including Plausible) = ends up being a mutual, or user/service co-operative model (similar to Mayfirst), "pay $X, get access to Y service"
    2. don't join the federation, pay members of the federation to host things for you. if someone can't do it anymore or they don't get along, etc. another member can take over
  • 3wc: there are effectively already some shared services (Gitea, Drone, owncast) which members can use. So #1 would be kind of a natural extension of this. Maybe something to list under membership incentives. And #2 is also what we're doing already.
  • f: mentioned on the survey - the website makes it look like the audience is just people looking for a tool to do their own deployment. Doesn't mention that co-op cloud federation members can host services, and/or that joining federation includes access to some services. "If you want co-op cloud services here is a list of federation members who can do this work for you", each co-op can decide their costs/wages. "You've been using Google and then you want to host with someone else but they disappeared". Federation could say "this is a common tool that this many co-ops are using, you can switch between co-ops without having to switch the stack"
  • 3wc: Timescale of need for plausible?
  • f: Preparing a proposal by next tuesday. Plausible hosted service ~$50/month up to 500k monthly visits. Prefer not hosting it ourselves.

2025-03-27

3wc, Fauno

(discussion of paid radmin proposal)

2025-03-13

kawaiipunk, Adrian, Fauno

Radmin proposal

d1's radmin proposal: https://pad.riseup.net/p/VL-XDQ6i8HkyJPgMSXb1

kawaiipunk added some feedback down the bottom.

not actually a meeting, kite flying is just hanging out

Co-op Chat

Adrian - Empowering learners to master college curricula through free resources. Choose a major and start today! - Open Source Society University https://github.com/ossu

Founders and Coders https://www.foundersandcoders.com/

Cool Firefox fork https://zen-browser.app/

Co-op projects similar to Co-op Cloud

https://localgovdrupal.org/ https://www.igalia.com/ https://opendigital.coop/ https://localgovdrupal.org/news/2024/achievements-spending-and-value-contributions https://mayfirst.coop/en/structure/ https://mayfirst.coop/en/official-documents https://mayfirst.coop/files/bylaws.en.pdf

Budgets

2025-03-06

p4u1, 3wc, fauno

agenda: - p: simplifying deploy overview, automatic dependency pull requests - p: simplifying deployment overview: get rid of chaos version, don't think we need it, already in version field. - p: also move forward with fixing integration test suite. then another RC - current proposal:

┃ CURRENT DEPLOYMENT ┃ ┃ VERSION unknown ┃ ┃ ┃ ┃ CURRENT ENV VERSION ┃ ┃ ENV VERSION ff2c04c9+U ┃ ┃ ┃ ┃ NEW DEPLOYMENT ┃ ┃ VERSION 1.0.0 ┃

Then "version" can be: - version: 1.0.2 - commit: dd2c04c9 - chaos commit: dd2c04c9+U - [future] branch: my-necxt-cool-feature - p: tried this, didn't work, weird git hackery going on

• f: currently weird that you have to remember what you deployed. and sometimes the env isn't updated properly.

• f: who will be contact for infrared mailing list http://aspirationtech.org/

  • f: got the OK to propose, just need to send an email. process = if nobody is against it in 2 weeks then we would be subscribed. can be several but currently have 0
  • c: someone from autonomic could probably do it. but worried about overcentralisation -- email, servers, bank account all totally / mostly with autonomic already.
  • p: reminder of what it is and what we're hoping from?
  • f: 2016, collectives and orgs who have been working on autonomous infra. idea is support network. little tricky to explain it because policy of not disclosing members. invited to devsummit last year http://aspirationtech.org/ -- took the chance for inperson meeting of infrared. had monthly meeting today. some people still there since 2017, new people (including some from devsummit). lots of funding opportunities. co-op cloud seems like it would be a nice member. so far - 1 monthly meeting, yearly inperson meeting.
  • p: makes sense. is it mainly about funding or?
  • f: also: campaign about abandoning big tech. research on how to get activist collectives off gmail. interesting things happening.
  • p: is it mostly other tech collectives? or what kind of people / orgs are part of it?
  • f: people providing email and hosting for organisations. small co-op / company providing nextcloud hosting. area of activism, nonprofit work.
  • c: wondering how to entice people into doing this.
  • f: today = 40m meeting. email list starting to get more active, 1 email / week or something.
  • p: do we need a resolution for that? could also be an opportunity to spread the idea, get commitment from someone.
  • c: not sure if the idea of co-op cloud joining another group has ever come up. so don't know if we have any guidance on criteria. personal instinct is we don't need a resolution but agree that it could be a way of getting more visibility.
  • f: first thursday of the month.
  • c: proposal: i can signal boost the request in federation chat today. then let's discuss at kiteflying next week. if no volunteers by end of kiteflying then let's make a resolution, and if no volunteers during resolution process autonomic could volunteer as backup.
• f: conversation about sustainability
  • f: d1 raised some good points. kp had responses. maybe can table until they can attend.
  • c: feel a bit in the dark about our current finances, to know the urgency of improving them. responsibility gap in following up with members. then participatory budgeting.
  • f: was expecting more instructions on how to pay dues. didn't find in docs. some inconsistency in contribution levels.
  • c: yes, some orgs are contributing more.
  • f: how to decide who's being paid for labour, who's contributing it. work on recipes subsidised by sutty.
  • p: have a feeling that maintaining recipes is something that many collectives are already paying themselves. but stuff like coding on abra, community stuff, finance admin = harder to get paid for by own collective.
  • c: d1 had a suggestion of "federation organiser" role / budget at one point.
  • f: could help to track time on recipe maintenance, federation admin - currently invisible. tracking stuff personally with hamster. could lead to an estimate of how much work is needed to keep things going.
  • c: same. so we could get some details for past stuff from that. and maybe ask folks who haven't been tracking to give us an estimate of time spent, or start.
  • p: time tracking feature in gitea, could use that? also discussion of raising the wage. not paying everything, but more specific stuff, paid better so the incentive is higher. steven spent a comically large amount of time on loomio recipe 😬
  • f: fair enough to have the discussion. we all need to be paid fairly for our labour.
  • p: collectives that need the money can claim it, ones which don't can leave it there for others.
  • c: also consistency of hours. maybe the fact that work is in such small bits means that the only people who could do it are people with free time, who don't need the money. federation organiser proposal, similar for abra maintenance, paid recipe maintenance roles?
• 3: maintainers proposal
  • c: how to roll this out? no budget, not entirely clear who is expected to do the work. maybe we do it gradually with a few trial recipes.
  • p: role of the maintainer? updating recipe. but also reviewing pull requests. that seems like it could be split between multiple maintainers.
  • c: anything we can take on right now? recipes we're already responsible for.
  • p: stumbling in the past on the fact that everyone can commit to every recipe and release new versions. think we should limit that. low barrier but high chaos. at least with the stable recipes we should try to limit who can do changes to them. maybe this would require a change to the resolution?
  • c: agree, otherwise could be very frustrating for maintainers.
  • f: personal experience: sent a pull request, approved, unclear who would release a new version. ended up doing it myself.
  • p: agreed. currently unclear.
  • c: happy to start a pad to draft a resolution for these changes.
  • p: before the maintainer role was just duties - now it would include powers. is there any process for that, how would someone become a maintainer?
  • c: copypaste more from debian?

checkout: - p: wanted to do more coding. a lot of talking, which is also good. but could be using this opportunity to get feedback really fast. - f: similar! fediverse apps coworking session was great but we ran out of time. would be nice to finish hacking on funkwhale. maybe we can schedule to continue that. - c: yeah agree :)

2025-02-27

3wc, Iexos, Bug

I: https://fuchsmuehle.org/

Authentik, Outline, Nextcloud, Mattermost

B: Status of abra dev? 3wc: Feature freeze for 0.10 release https://git.coopcloud.tech/toolshed/-/projects/29 (d1: please send halp, as per usual)

3wc: How's backup-bot rollout? B: Going well. Could use some more docs maybe.

2025-02-06

Another Co-op Cloud Event hitting the calendar: Extended Fediverse Kite-flying, 19-21 (7-9pm) UTC on Thursday 6^th February – we'll be reviewing and updating recipes and documentation for our Lemmy, Funkwhale, Mastodon, Hometown, GoToSocial, and Writefreely recipes, and maybe even packaging some new apps!

Present: Calix, Brooke, Ammar, d1, fauno

Test server

fediflying.coopcloud.tech

How 2 get access:

1. Send SSH key in Jitsi chat
2. Add this to ~/.ssh/config

Host fediflying.coopcloud.tech
  User root

1. Clone this repo: https://git.coopcloud.tech/toolshed/fediflying-coop-cloud-apps
2. cd fediflying-coop-cloud-apps && make link
3. abra server add fediflying.coopcloud.tech

Test it works:

abra app ps traefik.fediflying.coopcloud.tech

Recipes

Recipe	Uptodate	Tested	Who?
funkwhale	?	N	fauno
glitchsoc	?	N
gotosocial	Y✅	N	brooke
hometown	Y✅	N
lemmy	N❌	N?
mastodon	Y✅	N
owncast	Y✅	N
peertube	app yes, but ancient postgres	N	calix
pixelfed	???	N	Ammar
writefreely	N❌	N❌	d1

calix: flying column hacking

d1: got as far as https://git.coopcloud.tech/coop-cloud/writefreely/issues/1 managed to set up self-publishing image also https://git.coopcloud.tech/coop-cloud-chaos-patchs/docker-writefreely more to come...

2025-01-30

Present: Calix / 3wc (they/them), p4u1, fauno

• Uptimekuma image switch
  • 2.0.0-beta is released with MySQL support
  • Autonomic hasn't tried a normal 1 -> 2 upgrade because we switched DB
• abra app deploy issues with latest version
• Escuela Común Calyx Sepal fund
  • F: Estimates prepared, need input on abra costings
• Infra.red
  • F: Speaking to person from the network next week
• Fediverse Recipe Extended Kite-flying Hour
  • 3wc: Maybe do some outreach today / soon
• Fediforum https://fediforum.org/

Fediverse kite-flying

Another Co-op Cloud Event hitting the calendar: Extended Fediverse Kite-flying, 19-21 (7-9pm) UTC on Thursday 6^th February – we'll be reviewing and updating recipes and documentation for our Lemmy, Funkwhale, Mastodon, Hometown, GoToSocialm, and Writefreely recipes, and maybe even packaging some new apps! https://vc.autistici.org/CoopCloudKiteFlying#config.disableAudioLevels=true

2025-01-23

Present: Calix / 3wc (they/them), Marlon (he/him), fauno (he/him)

(intros)

Fedi apps * f: many people moving away from X and Meta platforms and landing on fediverse. Some fedi recipes not up-to-date, not working correctly. And: typing "fedi" on search on https://recipes.coopcloud.tech doesn't show anything. Good idea to work on them so we can promote co-op cloud as an alternative for selfhosting fedi apps? * c: we can also owncast a session for installing them. some recipes have receiving work lately but not all. as for "fedi" not appearing on the recipe site, we need to add them to their descriptions. question: what apps to focus on? and what changes beyond bringing them up to date might be good? * f: gotosocial being worked on? others: mastodon, lemmy. found some funkwhale issues, some manual stuff which could be automated. other fedi apps in the catalogue? * c: writefreely also? * f: hackathon? budget? * c: maybe extended kite-flying session as fedi hackathon? * f: might be able to spend some time on this next week * m: search might just be based on ellipsized descriptions? * c: will investigate * m: will tell the MIR comrades, see if anyone wants to pitch in * c: is next "west" kite flying too far away? * f: seems fine. fediparty on feb 1^st.

MIR * f: devsummit in oakland. aspiration tech. collectives doing hosting & infra should come together in a network. started in 2017. co-op cloud interested in participating? next meeting 1^st week of the month, closed meetings. could ask about having a separate meeting? proposal: ask if they're interested in talking to co-op cloud, and likewise * m: is infrared physical hosting provider? * f: notes from last devsummit: https://devsummit.aspirationtech.org/index.php?title=2024_Agenda * c: maybe post in co-op cloud federation to see who else

aspirationtech.org https://in.fra.red/

Gitlab recipe code review?

2025-01-15

Present: decentral1se (facilitation), fauno, Calix / 3wc (notes), Lai (from bus), Chasqui, Eli

Ideas: * round of check-ins for (new) people * escuela comun funding speedrun * feedback on UI for #484 * what info do we want to see from the deployment?

Notes: * checking in 🌈 * locations: U.S, Argentina, Netherlands, U.K, Mexico * organisations: Sutty, Escuela Común, Autonomic, Popular Laboratorio * Funding _speedrun amble? * f: Looking for funding for next year. Holding meetings across Latin America. Also adding features to abra/co-op cloud, particularly language translations for abra into Spanish and others. And adapting recipes for our uses. Mentioned this in Matrix room, "let's look for funding together". Found some open funds: coop fund, Calyx institute. * Ch: co-op cloud really useful for us. Simplified how we can teach "how to deploy your own server". We need to improve possibilities to make the tool more accessible to people who don't speak English. Hence two things, translations of abra - and help to maintain new recipes. Communities in land defence process, free media organisations, human rights defenders. Contact with these groups across Latin America. Survey of these groups to see what apps they want * Ca: Deadline is 19 Feb? ~5 weeks. * Ch: We have a presentation. * F: Shared it with d1 * (a screenshare happens) * Ch: Strengthen communities involved in land defence process. Consolidate their communication or legal teams through giving them more tools, better documentation of things. If a megacorporation comes to your land to try to set up mining, and you have a legal process to resist it, you need to gather evidence, but many organisations don't have good tools to gather that evidence in a good way. Also good for communication process, can use footage to reinforce struggle, disseminate into the media. Can put the communities' narratives about the problem in the media instead of the corporate / state narratives. 3 main axes in the school: documentation, archival, autonomous servers. documentation: how to use drones, how to use cameras. archival: how can you put information in order so that it can be useful. many organisations put everything in one hard drive. servers: where are you going to put that information? if you put it in google, you're supporting the people who are buying the minerals from the corporate that you're fighting. Data monetised by Google, buy more minerals to build bigger data centres (under the pole, in Spain, in Chile). And processes with corporation and state against you - important to protect your privacy. Say to these communities: "you have to document in a better way, you have to archive in a better way, you have to host in a way that's autonomous". Documentation and archiving more solved, working on that. And building narratives. But technical stuff presented challenges. Learning curve. Co-op cloud was the solution! Try in the moment to translate the execution words into Spanish so people can understand better. Really useful, we can do it! We had people in a few days in the middle of the rainforest to build their own server. Technical limitations: really broad the difference across Latin America. Lot of equipment, legal differences. Bolivia, cannot open ports. ISP says you are an "enterprise", have to pay more. Offline really easy - but online with DNS, SSL = really difficult when you want to get 12 servers running in 12 months. We built our own VPN and proxy so they don't have to manage SSL, open ports = centralised in the VPN. Beautiful thing in doing that = building a critical sysadmin community that are part of social movements. * F: Working with autonomous infra in Latin America for many years. Discussion is "you need to do this by yourself", need to use an infrastructure that works for yourself, not just what's been developed in the north. Before Escuela didn't have this kind of collaboration where 4-5 autonomous infra collectives have worked together on infra. Been a dream to be able to do it there * Ch: 12 communities have it working. Interested to see how it goes. Server transported to Peru via river. VPN + proxy really working, very happy. Groups already starting to set up and use services which weren't part of the school. Program just includes nextcloud, traefik, wordpress. Some of them starting testing with other recipes: funkwhale, discourse, etherpad. Really useful for us and for the communities that we didn't do all the work to show them our way. Common way to do stuff with abra -> they did stuff that we didn't show them. Creating a formal network, Red Abya Yala, autonomous infrastructure. Work team that's supporting VPN and proxy. Knowledge and exchange network, community based in the organising groups, plus 12 in the school. Second cycle of the school = make it bigger, grow the sysadmin community. Also creating online documentation, all the tutorials for deployments of autonomous servers. First systematisation of our pedagogical method. >15 hours of masterclasses in the peertube repository, really good information. 6-7 hours of autonomous servers, others about documentation and archival. Open to this kind of collaboration, extend recipes, extend abra. Even collaborate in the school in some way? Timings: open call in September, selection in November, virtual sessions in Jan, in-person in Argentina in February, follow-up in April. * d1: Been very excited to hear more! Really want to support. Question: trying to release a newer version of abra since the first one. How can we make it easier for people to follow? Development kind of chaotic. How can we let people know what is coming up, ask for input. How to get requests for changes, currently getting it via issues trackers, but open to something else? Also during the school. Communication would be great. * Ch: Video? * 3wc: What input do folks want on the funding proposal? * Ch: What do folks think about it, where do we think we could collaborate? * 3wc: clear, closely aligned with calyx call, impact is explained and potential impact laid out. will look more at presentation. * F: Sutty is a co-op, also develops its own platform for hosting and manging static websites. Don't have funding for working on CMS, do it as we can with the other work we have. Considering also applying to Calyx grant. Question: is it a conflict of interest? Strategically is it OK to also apply? Can we find a way to add work on CMS to the grant? * 3wc: 2 things. Grant is unrestricted, so could use some budget for Sutty if there's room. And second thing, they say only one application per organisation. Probably fine but might be nonideal to have the same group's name on 2 applications. https://calyxinstitute.org/projects/the-sepal-fund/faq-the-sepal-fund * E: Could be risky. Still thinking about it. Not worth thinking about a strategy to disguise sutty, could risk the EC application. * F: Hadn't seen that FAQ. Another approach: making better recipes for Co-op Cloud, translating it into language, also adding support for Sutty in Co-op Cloud. $150k budget over 3 years. * Ch: Better to have one proposal for funding. Technically, we can do two, but not good for anyone. Understanding - interested in integrating ideas into one. Calyx open to changes during the project. "We need to build a more safe website because the people we're supporting need this kind of security in their website" * F: Work on CMS - "these organisations need to host their stuff in a more secure way", so we need to support SuttyCMS in Co-op Cloud. * E: We're working in securing our infra. Still need funds for development, testing. Also need to work in holistic, general approach for digital security and digital care. Everyone needs facilitation / mentorship. Something about internal politics involved. Not our place to interfere there. Need to find balance. Investing a lot of time, passion, effort - not paid. Everybody is expected to maintain process & project as something sustainable. Risking burnout. * F: Let's put all these ideas together so it can be generative for the application. * d1: https://pad.riseup.net/p/tbN-4l63F8jbmd2EgGsE-keep * d1: Can help write, let's get some bullet points down? Can also help with more abstract question of the concept. You all know better what that should be. * A Check Out * Ch: Nice to meet again, maybe in a week. Meantime = build bullet points async. * F: Happy we got to meet! Want to make sure co-op cloud work is paid for. Not golang devs. Asked for Escuela Común & Abya Yala to become federation * 3wc: Hype hype hype * E: Happy to be hear, developing together, sharing principles and communities * d1: super inspiring, thanks for sharing! continuing surprise that co-op cloud works, does something for them.

2025-01-09

Present: 3wc, Ammar, d1 (from bike)

Ideas: * New year blogpost hacking: https://pad.local-it.org/G1TOcidEQtyArJU9gI0SDw?edit) * Proposing MIR join the federation https://mirnet.org * The Naming Survey * Ammar: got some feedback on the docs from some people who don't know co-op cloud, not familiar with docker sysadmin. Main feedback was that the documentation is very verbose, they didn't have specific issues with the naming * 3wc: Do we continue with the survey plan? * Ammar: Think so. We might end up getting some feedback beyond the naming * 3wc: Maybe some open questions? Ask for references of docs people especially like? * Ammar: People like the "governing" pages. * 3wc: Some websites have quite literal approach to user journeys, "I am a" * Ammar: Would be nice if we had enough resources for a "co-op cloud academy" * Are there any restrictions on who can become a federation member? * 3wc: Don't think so, there's some language about organisations but in practice some one-person organisations have joined. * d1: And there's a vouching / resolution process * (Hype about Escuela Común and No Tech For Apartheid) * "your idea here"

2024-12-25

Present: 3wc, Ammar, fauno

Naming things (hosters vs. operators)

• is operator a good name? does it translate well?
• users & contributors
• operator is old school!
• users of coopcloud reverses power dynamics
• how to make this decision?
• survey?
  • "What do think this word means"
  • "What would be a better word to explain it?"
  • How would we process the survey? Qualitative approach rather than statistical
• Operator / developer
• Escuela comun: server collective = community garden
  • Operators = gardeners
  • Any ideas about accompanying word for "Maintainers"
• reach out to a wide audience, not just operators :P
• ideally wouldn't change again for ~4 years
• publish the survey results later!
• what are other projects doing?

• this should inform the survey

  • k8s: uses operator for another concept, but it uses "administration" as the action of working with it: https://kubernetes.io/docs/tasks/administer-cluster/
  • Yunohost:
    • uses administration to refer to what we call operator, uses user as the person who does the administration (?) https://doc.yunohost.org/en/admindoc
    • administrator https://doc.yunohost.org/en/admindoc
  • Docker uses "developers" for people who will be building a container but doesn't seem to have a separate name for who's running them
  • dokku
  • libreserver: uses admin for operator and developer for maintainer - https://libreserver.org/
  • heroku
  • ansible: https://docs.ansible.com users write playbooks

• reasonable pace: 2h/week

• steps:
  • collecting information 1-2h
  • design survey 1-2h
  • distribute survey 1-2h
  • analyse survey 1-2h
• 4-8 hours

2024-12-19

Present: 3wc, kawaiipunk, abe

• chatted to abe about the project
• 3wc tried to set up Gitea as SSO provider for Kimai, no OIDC, WTF?
• 3wc fixed up (most of?) the docs links
• kawaiipunk created a new branch with autogenerated menu for the mkdocs https://git.coopcloud.tech/coop-cloud/docs.coopcloud.tech/src/branch/auto-menu
• kawaiipunk confirmed that https://kimai.coopcloud.tech/ is online. Send them a dm with desired username and email. We are considering SSO however.
• kawaiipunk resubmitted the co-op cloud donation from social.coop

2024-12-12

Present: 3wc, kawaiipunk, Ammar

• kp (and slightly calix) span up Kimai
• kp: kimai setup. Still need to setup email and invite folks.
• kp: patched Kimai readme https://git.coopcloud.tech/coop-cloud/kimai/commit/ff926f9e3d7c65e57f443115b446ba8dac2076fd
• kp and Ammar worked on docs, added proposa 025. Docs shuffling. Hit issue with hardcoded menu

2024-12-05

Present: 3wc, kawaiipunk, mirsal

• 3wc: https://git.coopcloud.tech/toolshed/organising/issues/369
• 3wc: moving coopcloud.tech onto co-op cloud server https://git.coopcloud.tech/coop-cloud/-/packages/container/coopcloud.tech/latest
• 3wc: moving docs.coopcloud.tech onto co-op cloud server https://git.coopcloud.tech/coop-cloud/-/packages/container/docs.coopcloud.tech/latest
• 3wc: moving recipes.coopcloud.tech to selfhosted docker image https://git.coopcloud.tech/coop-cloud/-/packages/container/recipes.coopcloud.tech/latest
• kawaiipunk: deployed https://kimai.coopcloud.tech but can't login, opened issue: https://git.coopcloud.tech/coop-cloud/kimai/issues/3
• kawaiipunk started Resolution 025: maintainer's proposal: https://pad.autonomic.zone/42Ier8ZgQ-CUgBsFKUmdpQ?view
• kawaiipunk opened an issue about copying policy out of resolutions and onto it's own pages: https://git.coopcloud.tech/toolshed/organising/issues/654