|
|
|
|
@ -4,817 +4,6 @@ title: Kite Flying "Open Agenda" archive
|
|
|
|
|
|
|
|
|
|
From https://pad.autonomic.zone/VtyrLUl9RWaJGgEDrncQUw?edit#
|
|
|
|
|
|
|
|
|
|
## Next kite flying (open community meeting)
|
|
|
|
|
|
|
|
|
|
[Schedule (ICS link)](https://coopcloud.tech/ics/kite-flying.ics) (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](https://kollicloud.de).
|
|
|
|
|
:::
|
|
|
|
|
|
|
|
|
|
:::info
|
|
|
|
|
[**Meeting and minutes here**](https://de.meet.coop/b/rooms/zi4-9j9-hrr-1et/join)
|
|
|
|
|
:::
|
|
|
|
|
|
|
|
|
|
:::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(c): 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](https://docs.coopcloud.tech/intro/faq/#arent-containers-horrible-from-a-security-perspective). 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](https://garagehq.deuxfleurs.fr/) ([recipe](https://git.coopcloud.tech/coop-cloud/garage.git)). 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](https://datakollektivet.no).
|
|
|
|
|
|
|
|
|
|
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(c): 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. <couldn't catch names>. 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](https://media.ccc.de/v/39c3-a-post-american-enshittification-resistant-internet) 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
|
|
|
|
|
|
