Skip to content

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

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, 26th 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 14th? (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 19th?
    • 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
  • kp: Just an interesting sidenote, the CC meet up at Chaos Congress was attended by like 15 people .
  • 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: 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"

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

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

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

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:

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 22nd 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

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

  • 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? * 28th 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://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

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

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 (11th)
  • 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 6th 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 6th 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 1st.

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 1st 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

  • 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

2024-12-12

Present: 3wc, kawaiipunk, Ammar

2024-12-05

Present: 3wc, kawaiipunk, mirsal