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

Next kite flying (open community meeting)

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

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