This commit is contained in:
@@ -8,6 +8,829 @@ From https://pad.autonomic.zone/VtyrLUl9RWaJGgEDrncQUw?edit#
|
||||
|
||||
[Schedule (ICS link)](https://coopcloud.tech/ics/kite-flying.ics) (subscribe in your calendar app)
|
||||
|
||||
|
||||
## 2026-08-27, 12 UTC
|
||||
|
||||
Attending: Jade (they/he), hex (he/him), Sarma (they/them), muris, papiris
|
||||
|
||||
Intros:
|
||||
- J: portugal at team retreat, but have a cold
|
||||
- h:
|
||||
- p: norway had the sun for the third day this summer. Spent the night in a common house (which used to be a lord's house) where the doors are never locked and anyone can use it. Fed up with k8s. Gonna migrate to abra.
|
||||
- S: low energy, but that should improve during the meeitng
|
||||
- m: listening in
|
||||
- I'm Murilo, I'm from the land of Tupi-Guaranis people (also known as South East Brazil) and I currently live in Stockholm! I'm here because I'm a full stack developer/creative technologist, I do a lot of sysadmin and would like to get closer to tech cooperatives as it seems aligned with what I want to do with my life 😃
|
||||
|
||||
Topics:
|
||||
- security related stuff
|
||||
- high availability distributed clusters
|
||||
- K8s/abra
|
||||
- [US anarchist blogging platform designated as terrorist orgs](https://www.state.gov/releases/office-of-the-spokesperson/2026/08/designation-of-autistici-inventati-as-a-specially-designated-global-terrorist), people looking for alt hosting.
|
||||
|
||||
Minutes:
|
||||
- h: short intro to noblogs
|
||||
- noblogs is a host based in italy
|
||||
- people with riseup accounts can use them
|
||||
- treasury is trying to freeze financial transfers, imprison people who give donations
|
||||
- connection with KKK
|
||||
- some anarchist groups trying to move to wordpress. Smaller hosts, distributed.
|
||||
- h: if you're looking for clients, advertising on mastodon might be a good idea.
|
||||
- Q(S): do we have US-based members?
|
||||
- h: it'd be nice to have a tool to find coopcloud hosting based on location.
|
||||
- J: noblogs is running by the Autistici Inventati collective. If we step up to provide servers, this might help get around blocking - but will that cut income streams to the collective? Anything we should do in solidarity with them? US sanctions tend to affect global payment (Visa, Mastercard, etc) so they might be affected.
|
||||
- J: can we do mirroring, to prevent noblogs from being blocked?
|
||||
- h: the service is free, so moving people off the sites won't harm them. Giving them money might be good.
|
||||
- h: If other collectives pick up this work - there's a risk the US govt could target a different provider.
|
||||
|
||||
- S: maybe we could suggest the location-based member search to the new website?
|
||||
- h: https://docs.coopcloud.tech/intro/managed/ and https://docs.coopcloud.tech/federation/membership/ have information, so at minimum we could link to these.
|
||||
- h: The anarchist book fare shared [A list of hosts](https://riseup.net/en/security/resources/radical-servers).
|
||||
- h: These people generally aren't paying for hosting, but they might be willing to pay.
|
||||
- p: Patio is another federation of tech co-ops, would be good to contact them:
|
||||
https://patio.coop/
|
||||
|
||||
- Q(S): how much time/resources do you have, hex? Can you coordinate this?
|
||||
- h: I have a bit of time. Getting radical collectives to use coop cloud might be a good strategy, but it would increase the security profile - gaps we'd need to close.
|
||||
- S: cool, sounds like you're the perfect person for the job <3
|
||||
|
||||
- p: I'm in a group that hosts on noblogs, but not in the US. I'm not sure if this affects us, but we'll be making sure we have backups.
|
||||
- h: not sure how the US decision will impact AI's finances, getting people outside the US to donate money would be good.
|
||||
|
||||
---
|
||||
|
||||
- p: frustrated about k8s. Moving off of it would be a case of deploying some apps and restoring databases into the new deployments. Might take time to replicate the infra I have. I'd like to give it a go and discuss in future.
|
||||
- S: when I tried migrating an existing system onto coop cloud, Only spent half an hour, but didn't want to move nginx into traefik. Would be worth asking if you have other apps that you'd need to switch out.
|
||||
|
||||
---
|
||||
|
||||
- h: wrote some scripts to go through each recipe, read each image mentioned, and running a vuln analyzer - to produce an SBOM. Some recipes should probably be delisted because of vulns. In total, found ~30 000 CVEs, of those 3000 critical. Because a lot of these require you to have local access, the real vulnerability count is probably pretty low - 10 or so.
|
||||
- h: softsonic(?) has been running LLMs to do a similar kind of check. Given the scope of our problem and amount of data, we may want to use an LLM to flag high level patterns.
|
||||
- h: additional layers of problems.
|
||||
- h: Let's say we flag all vulns, upgrade recipes - there's no communication channel to tell everyone to upgrade their services. Matrix's General chat is not sufficient. Operators not reading matrix won't find out about them.
|
||||
- h: supply chain attacks which can't be fixed by upgrades - need a way to tell people about those.
|
||||
|
||||
- h: we should have an automated scanner, a manual process to filter CVEs, a way to tell people about CVEs, and a way to get people to quickly upgrade: we need the upgrade process to be easy and not break everything.
|
||||
|
||||
- h: I know there are vulns that are not listed, and many won't be scannable. Not sure how to address those yet, open question.
|
||||
|
||||
- J: I feel nerd sniped. Want to dive in and fix them all, but already have priorities.
|
||||
- J: So, we have difficulties getting information to maintainers and to operators; different problems. As a maintainer, I'd enjoy if I could be easily informed about that. Maybe a dashboard. We don't want to announce our vulns publically, ideally an internal vulnerability dashboard.
|
||||
- Q(J): Could merribek pay a collective each month to provide tooling around specifically our recipes? Don't know if we can pay enough to be useful, but could pool resources.
|
||||
- J: alternately, we have a security expert who could join a working group.
|
||||
- J: in lores, we're not a tech cooperative; we're a tech commons. Our server operators are beginners. Each local server has ~2 stewards whom we've taught linux. So we want big flashing alerts for these people. We're thinking of doing this on the lores node app; but it'd be better to have it on a separate/dedicated monitoring app.
|
||||
- J: monitoring apps should probably install something not in docker, to have OS access.
|
||||
- J: eventually, I'd like the stewards to also be informed about OS security upgrades etc.
|
||||
- h: We need an easy way to contact maintainers directly. We don't want vulns to be out there. If we don't have a fix, we need a backchannel way to communicate that. Pipeline: vuln data collection->identification->vuln management. We need a point of contact which isn't broadcast, a closed/security communication path.
|
||||
- h: some stuff is going to be public anyway; everyone knows wordpress is vulnerable. I'd lean more to moving fast than to restricting access to information.
|
||||
- h: getting every operator to update - should be public. Suggest an RSS feed, other announcement systems exist. Each vendor (redhat etc) has a feed like this, with clear security announcements and instructions. We should have that channel, too.
|
||||
- h: endpoint monitoring is another issue, but low on time
|
||||
|
||||
- Q(S): Would it be enough to DM maintainers based on README contacts?
|
||||
- h: this information should be accessible by automated tools, like in the recipe json.
|
||||
- Q(S): do we want abra to print warnings? Like, any time you call an abra command it prints existing vulns?
|
||||
- h: yes!
|
||||
- Q(S): is this a 'critical fix'?
|
||||
- h: no, we need detection first before this makes sense.
|
||||
|
||||
- h: for financing - it'd be good to have a security federation within the coop cloud federation, so some members can work on
|
||||
|
||||
---
|
||||
|
||||
Checkouts:
|
||||
- S: thanks hex for sharing your expertise! It's fascinating to listen to. For future KFs, I know calix is planning some beginner courses and comparing coop cloud to other similar projects.
|
||||
- h: thanks for letting me dump a bunch of stuff. Want to follow up on these security topics.
|
||||
- J: feeling buoyed. These talks always feel awkward/slow at the start, but really good at the end. These topics will be very distrcting for me, lots to think about. Busy with lores. Might find some people to nerdsnipe. In a 2 week work retreat for an offline-first messenger. Will be doing bug fixing in a nice locaiton in Portugal.
|
||||
- p: thanks for facilitating & notes <3 Always impressed with how Sarma manages to write while holding a conversation. Topics really interesting. I like finding out what's happening outside coop cloud, stuff that matters to us. Good security deep dive. Things went a bit too quickly for me, not sure if we decided on points of action: what do we do in the coming time? Once I get more experience with abra, it'd be nice to have a topic: *Experience with k8s vs abra*. Next, gonna play with the animals and sleep before night shift.
|
||||
- m: I feel good, first time! I like the range of topics and looking forward to contribute and join next meeting. I am going to continue monitoring a freaking database migration until it's time to run outside.
|
||||
|
||||
|
||||
|
||||
## 2026-08-20, 19 UTC
|
||||
|
||||
Attending: calix (they/them), hex, Chasqui (he/him), Sarma (they/them)
|
||||
|
||||
Intros:
|
||||
- C: Mexico, worried about droughts.
|
||||
- S: back in Kraków, drained from tax/invoice learning
|
||||
|
||||
Topics:
|
||||
- distributed data storage for volumes
|
||||
|
||||
Resources:
|
||||
- https://articles.usulnet.com/articles/swarm-storage-solutions
|
||||
- https://rclone.org/sftp/
|
||||
- https://www.haproxy.org
|
||||
- https://github.com/gluster/glusterfs
|
||||
|
||||
Minutes:
|
||||
- distributed data storage for volumes
|
||||
- S: different layers. Docker volumes etc. Fun things you can do with rclone. abstractions over data storage protocols. SFTP, googl drive. Same API, just different URI. Poking at it with SFTP. Idea: different laptops with different storage locations, each with different storage capacity. Rclone to sync to single source of truth. Use rclone as a proxy to attach to single source of truth.
|
||||
- S: Benefit: volumes created on central machine, but in case of outage, can rotate load.
|
||||
- H: Heartbeat, HA configuration - pinging primary, rotate to secondary. Writes go to one system, reads distributed?
|
||||
- S: Currently, writes and reads go to the same system. Protecting against unreliability of machines, frequent downtime.
|
||||
- Q(ca): is there a system in place already for failover?
|
||||
- S: No system, still in planning phase. Considerations: timeouts in rclone, SSH. Because we're in VPN, we could rely on the security of that layer. Nothing satisfactory so far.
|
||||
- Q(ca): does rclone have automatic sync, or is there a scheduled job?
|
||||
- S: Not AFAIK. Just thinking of doing a cronjob, sync every 5-15 minutes or something.
|
||||
- Q(ca): about to try out garage, which does distribute storage and makes it available through s3. Did you try it out and it didn't work, or using apps that don't support s3?
|
||||
- A lot of apps still need non-S3 storage. When you have containers on different machines, need to communicate, garage not sufficient. Lack of file locking. Locks and sync of reads/writes does happen somehow in rclone, not sure how. Garage / S3 dangerous to rely on for that.
|
||||
- Q(h): what is the goal?
|
||||
- S: Reliability. Solving the question of how you get reliable systems out of unreliable machines. A bunch of co-op cloud members have attacked that from different angles. e.g. for Merri-Bek, important not to drop connections during power / internet outages. And: use case of building cloud of random laptops in people's apartments.
|
||||
- h: are we talking about availability, or data backups? Disaster recovery vs HA.
|
||||
- S: Both important. Can't have availability if the data is gone. "Back up to a stable system as quickly as possible in an automated way"
|
||||
- Ch: we're working with low-cost computers, good usecase for us. We're trying to do something similar: distributed storage. I don't know if they use S3 or not. Could share the work.
|
||||
- ca: wrt mounting S3 as disk storage, I saw all the same warnings: anything that expects file locking will break because it's not a real POSIX file system.
|
||||
- Q(ca): say we have nextcloud, with a constellation of laptops. If I upload a file, this gets stored on a regular disk, which gets synced. What happens when rclone syncs while I'm still uploading?
|
||||
- S: If we're talking about storage large files, then this is probably not a good solution because of (missed it?). Apps that need to store large files, e.g. fediverse instance or nextcloud have good S3, would definitely suggest using S3. Garage or dozen corpo object storage providers. System I'm describing is not efficient for large amounts of data. But what it can do is be fairly robust for small amounts of data. Target: files max few kB each. If sync happens while files are being modified then I think you'd have partial files — need to look more into how locking happens, how that interacts with sync. Regardless, you might get incomplete versions. Not sure how to protect against that, other than through more rigorous layers of backups.
|
||||
- Q(ca): how easy would it be to manually start an instance on a different node?
|
||||
- S: In principle, assuming you have config files, only thing you'd need to change is the config file of where you have the data. All the backup nodes are equivalent.
|
||||
- h: have done this in the past with drbd - where youre seeking the block device at the kernel level. GFS, clusterFS which might do this.
|
||||
- S: First time hearing about these. Biggest thing for me is finding something that has a ready-to-go docker volume plugin. Blunt instrument idea would be just mounting whole docker volumes directory, but then each node needs a full copy.
|
||||
- h: DRBD running @ kernel level, probably can't just plug in. First thought: separating things out. Configuration in LDAP, application layer. Data store makes more sense to have at a lower level, more efficient storage for that.
|
||||
- ca: vaguely remember docker volume storage options. Reasonale to avoid NFS ime. GlusterFS and CEPH both have docker volume plugins.
|
||||
- Q(ca): Any thoughts on rubric for deciding which nodes get which pieces of data?
|
||||
- S: Assumption is: very little data cached. Play around with cache once we have basic MVP set-up. In that scenario: worker nodes with almost no data stored locally, pinging single source of truth. Other option: some kind of local copies of vols. Not storing data that isn't used by that node. 2 ways of looking at it: #1 when a docker volume is requested / mounted, that's when data is requests. Or #2, whenever node performs read/write operation, only that particular file is touched. Like #2 for prototyping, #1 for efficiency. Biggest difficulty: 2 services which need same volume mounted, option #2 would be great for that.
|
||||
- Q(ca): Example of 2 services using same volume?
|
||||
- S: Hometown, mastodon fork. Has "app" volume storing some stuff, but because there's a lot of situations where individual posts on mastodon need to be handed off to different services to be sync'd with other servers or stored appropriately -- certain data stored in common volume which other services in Hometown stack (e.g. sidekiq) rely on.
|
||||
- h: FYI, this also sounds related https://www.haproxy.org/
|
||||
- Q(ca): Is every place that rclone copies data to a docker swarm worker node? Or not necessarily? Say I connect my laptop to your system - would it still be useful without connecting to the swarm
|
||||
- S: Formal distinction between worker nodes and storage nodes. (Also category of manager nodes). Thought is: manager nodes prioritise reliability but can be very tiny, small VPSs which don't know much about data. Or small cheap-ish machine that happens to be located in a place we know won't go down. Worker nodes, usually require fair amount of 🐏. Data storage nodes, usually require a fair amount of HD space. Each requirement is independent, so given machine can do 1, 2 or 3 of those, doesn't have to do all of them.
|
||||
- h: wrt mastodon - there's a postgres backend, and traffic on the load balancer. For high-availability configs, having a postgres cluster is the best approach for pg. These kinds of edge cases are baked in. If you had two mastodon clusters with traffic between them, and pg over multiple machines, you could use HAProxy to switch automatically between them at the application layer.
|
||||
- S: Only really considered 3 categories of data: databases (handled independently, handle their own decentralisation), S3 (handles own decentralisation), then $all_of_the_rest, data which needs to be handled in a generic way. Because I want to find a solution that assumes low amounts of data, low traffic, any time that an application requires a heavy load then it would be a better idea to find an app layer solution.
|
||||
|
||||
- S: h mentioned HAProxy as a solution for detecting dead servers and doing failover properly. Kind of assumed that failover would be a fairly common thing in various load-balancers but haven't really done a comparison. Can I get a quick haproxy infomercial?
|
||||
- h: 10-15 years ago I built a hi-avail system, two servers in different buildings so we'd have 100% uptime. I don't remember the details of it. At one point someone drove a forklift into the fiber connection between the two buildings and no one noticed until people were working on different LDAP systems. We were running docker at the time, DRDB, a heartbeat between the machines which would switch heads if one of the systems went down.
|
||||
- h: the split brain failure scenario is something to be aware of.
|
||||
- h: interest in talking about this further
|
||||
- ca: wonder how much is possible to do in traefik
|
||||
- Ch: Propose to make a post in the channel, so I can show to my people - it seems similar to what we're doing.
|
||||
|
||||
Check-outs:
|
||||
- h: going to bed. Would like to talk about the security situation in terms of CVEs, how to report them, how to fix them
|
||||
- S: also head to bed, listen to the rain. Like distribution is a growing topic, appreciate so much interest. We had a dedicated kiteflying on it recently, could do another one. Maybe also a dedicated work group? Central knowledge store?
|
||||
- C: Jealous about Sarma's brain <3. Travelling to Mexico City to gather posters. I like the KF format of "put something in the oven and let things happen".
|
||||
- 3: Filled with inspiration. Love the idea of working group on distributed stuff, hearing more and more people interested in it. Future KFs: "what is coop cloud" - introductory talk. Going to fix an eink screen for friend.
|
||||
|
||||
## 2026-08-13, 12 UTC
|
||||
|
||||
Attending: may (they/them), Sarma (they/them), Chasqui (LPML)
|
||||
|
||||
- Sarma: recently installed a coopcloud server + apps for a client, estimates about 8h labour total, incl meetings and admin
|
||||
- Chasqui (LPML):
|
||||
- working more on translations, improving command docs
|
||||
- talked about global gathering in september, seems a good event to attend: https://www.globalgathering.community/
|
||||
- gallinero project: a network, using coopcloud and backupbot2 (and maybe restic and garage?) for storing (3 copies) each others' backups, fauno from sutty and others working on it, first iteration already in place with 10+ TB and working
|
||||
- may:
|
||||
- talked about managed hosting network inspired by Community Supported Agriculture (CSA) https://bonfirenetworks.org/hosting/
|
||||
- we talked about the importance for people learn low level tech (eg command line, config files) but in a calm slow way, with entrypoints to first be empowered and then dig deeper
|
||||
|
||||
## 2026-08-06, 19 UTC
|
||||
|
||||
Attending: Sarma (they/them), hex (he/him), Danny (he/him), stevensting (he/him)
|
||||
|
||||
Topics:
|
||||
- CVE: how we can share info about security patches
|
||||
|
||||
Intros:
|
||||
- Sarma: got a client! Art collective.
|
||||
- hex: turning a shed into an office, after a year
|
||||
- Danny: starting a court case against a construction company
|
||||
- stevensting: crowdfunding campaign went well; 2600€ after two weeks, more than expected! Crowdfunding is for hard drives for a new server. Will be hosting coop cloud federation services.
|
||||
|
||||
Minutes:
|
||||
- Q(st): where are hex and Danny using coop cloud?
|
||||
- h: volunteering with ecommons, working with a lawyer to exit current employer. Will have to volunteer for the next month, won't work until september. Then, will finish starting a BV, start a company, and do pen testing + blue team security engineering. Helping orgs, collectives with threat modeling and security program.
|
||||
- D: work with cc for a half year; sevring apps for a few housing cooperatives in amsterdam.
|
||||
|
||||
- st: proposal: let's go through the [document we have](https://cloud.klasse-methode.it/s/aNitMQjeo5QpHs4) and talk about it.
|
||||
- h: three things: lack of funding (maybe talk later). QA/security stuff. As we read through document, we could discuss usecases - make sure we're trying to solve the right problems.
|
||||
- st: high level. Without having a lot of security knowledge, I can sketch what we have. Then your expertise can put that in the right frame. See if this is an achievable first goal.
|
||||
|
||||
- st: what I imagine is not related to QA. Rather, as a group of maintainers in coop cloud, we'd get notified about security issues which might get exploited soon. Highly critical CVEs like we had with wordpress. The top 1% or 5% CVEs that pose a likely exploitation risk, that we get notified about those right away. I've seen lots of databases about CVEs. I'd lke that when these get put into these databases we get a notification in matrix chat and we coordinate, who can put in a workaround or fix and we all upgrade right away. Everything else is nice to have afterwards.
|
||||
- Q(st) Is this feasible? Are these also your conclusions from our chat?
|
||||
- D: sounds like a solid plan. Is it possible to get a short list of CVEs we need to address?
|
||||
- h: sounds reasonable and achievable. I wrote a step-by-step plan at the end of that doc: suggested longer term strategy. Each of these items could be a phase, a step forward.
|
||||
```
|
||||
1. Create OpenCVE recipe (I can take this action, because it would be useful for me to know the tooling)
|
||||
2. Add SBOM functionality to abra using syft as a library to get SBOM by server deployment
|
||||
3. Set up a central OpenCVE instance for Coop Cloud
|
||||
4. Write a tool that runs grype (or similar) on SBOM to get issues, checks against a central for accepted risk, and reports any unaccpeted CVEs by recipe.
|
||||
5. Write tool to sync SBOM from abra to OpenCVE (using abra). Add config to OpenCVE recipe to sync against another repo.
|
||||
```
|
||||
- h: (3) would enable the matrix notifications.
|
||||
- h: (4) with a centralized openCVE instance, we'd have a team looking over it, more people looking at what we can accept. Individual maintainers can run a tool that can check if their recipes have vulnerabilities.
|
||||
- h: (5) allows individual collectives to have different objectives than coop cloud as a whole.
|
||||
- h: I think this gets us close to what you were talking about. One thing that's easy to miss is the top CVEs, what is *going* to be exploited. CVEs have a CVSS rating: a number.
|
||||
- st: CVSS: the higher = more critical
|
||||
- h: a high CVSS means it's bad, it will be exploited. CVSS accounts for ease, where the attacker is located, etc. E.g. "a network accessible thing that's easy to exploit." Usually, if you don't have a good threat ingelligence system, you go by "what's high or critical". When you talk about "what's most likely to be exploited" you're talking abotu a threat intelligence system: honeypots, monitoring, looking for attack patterns. Large companies have a dept for that, which is supposed to tell you if there's a CVE actively being exploited.
|
||||
- h: I was working at amazon when log4j came out. Internally, we found out because there's an agreement between google and amazon and other companies, to get early intelligence on this stuff. One thing they share are Indicators of Compromise (IOC). When there's an incident they'll share with the other orgs in the agreeement.
|
||||
- h: on our scale, we could also share IoC with eac other. So we want to see information when something affects a given collective. That's the goal.
|
||||
- h: For now, we'd rely on CVSS - but we'd get a lot of noise from that. Something flagged as CVSS 9 might be e.g. "an auth exploit in saml". If you have saml disabled, it doesn't affect you. It's gonna be hard to filter down the high CVSSes. But we can do better than nothing.
|
||||
|
||||
- st: wrt IoC, this might be nice in the future/long-term, maybe.
|
||||
- Q(st): what is the real advantage of using openCVE? It looks like a collaborative approach, shared UI for a database?
|
||||
- h: there are other tools, doesn't need to be opencve. This appears to be one of hte easiest ones. Minimalist. In the long term I'd like to migrate to something that's SIEM. Though that's a different department than I usually work in, there'd usually be a group dedicated to this: endpoint monitoring, sharing information back and forth. E.g. all your customers would be reporting their endpoint monitoring back to your central thing, which reports back to some cloud coop one. And you're looking for indicators of something being compromised. In addition to CVEs you also want to check config issues, you want to run vulnerability scans. Then there's cloud security on top of that.
|
||||
- h: this is all stuff that doesn't need to be built right this second. Instead, let's look at 'how do we get value at each step' so we start taking steps forward. OpenCVE is the lowest bar that gets something going.
|
||||
- Q(st): why is it abra that should create SBOM? I imagined our CI could run syft. Is abra the right place?
|
||||
- st: abra can already parse information from the compose files, is that it?
|
||||
- h: yes, CI should be doing this. And also, prod and testing might differ. I understand abra as the last step - which knows exactly what's being deployed. I want to work backwards from deployment; start at the last point - so it gets caught at the very end - and only then push left to catch it earlier. We *should* have something that scans the recipe as it gets added, something to tag it as tainted, warnings during deployment ("this has an open CVE; are you sure you want to deploy").
|
||||
(secretary's note: connection issues here; I missed a question and answer)
|
||||
- st: how deep do we want to go? I made a supply chain levels table. With SBOM we're digging quite deep; we're checkig every lib/package used in a container. I don't want to do that in the beginning. We should start focusing only on the app run by the docker container. E.g. we're running wordpress, so we want to know the wordpress CVEs but (in th ebeginnning) not about a package/php library used by the container.
|
||||
- h: agreed. However, did not see an easy way to automatically figure that out for every application version.
|
||||
- st: Static angle where we look only at coop cloud's git, and do the process for the most recent versions there (what autonomic is doing) - then look at older versions. This does not tell us if anyone is using it in prod, but we can tag this information and inform people.
|
||||
- st: Other angle where each collective running deployments can get custom information about their own deployments based on what versions they have live.
|
||||
- h: similar to NVD (national vulnerability database, US so questionable trust) - the big thing that feeds openCVE. These are reports by a vendor of a specific software. Coop cloud could do the same thing, go thorugh the same mechanism: CC security figuring out which recipes are vulnerable and put out a report when one is vulnerable. (could be in chat, wherever)
|
||||
- st: I thought that we could run both angles. But, when we create an openCVE database, every coop could just pass their own server folders (maybe with abra) - then use openCVE to make a personalized vulnerability databse.
|
||||
- h: openCVE has a good APi and hooks. Point is that wyou can get an alert about a CVE and fling that where you need it, then come back - own, track it in the application. This approach is more similar to the distributed teams model in a large organization; you have central tracking and then someone comes to a team and yells at them to fix it. You might have a ticket that gets kicked up and 300 teams get thrown onto it, anyone affected, to go fast. I'd like a less tough approach which empowers the end groups: let collectives have information - it should be simple 'just upgrade' but sometimes they can't upgrade so we should give them all the information so they can work through it. I do want just a little bit of centralization.
|
||||
- Q(st): what's the difference between step 4 and step 5? Is step 4 optional?
|
||||
- h: we should be able to say 'we don't have a functional system yet but here's a tool you can use now'. Maybe I'm deploying a custom recipe. I get the app, get the SBOM, see some vulns I don't know about - this checks against a central repo and says "these are the ones we haven't accepted".
|
||||
- h: We could simplify this. A tool where collectives can track vulns. So you can manually tack this thig.
|
||||
- Q(Sa): Given that coop cloud deployments look very different from corporate clouds, should we look at
|
||||
- h: the NVD is the root for tools like openCVE, there's a mailing list/RSS for the newest CVEs. Tools like openCVE let you filter that down (e.g. only care about wordpress, nextcloud, etc). Then, there will be issues not tracked there - interactions between specific components
|
||||
(Secretary's note: connection issues again)
|
||||
- st: unsure if each collective has its own openCVE instance
|
||||
- h: optimally you'd want to offload that to a specialist.
|
||||
- st: unfortunately we don't have that
|
||||
- Sa: It would actually be nice to have a specialist in the federation: someone to hire to review clients' configurations.
|
||||
- h: I'd like to build a business around this and make it feasible. Ideally, there should be a security federation within the feeration - a few providers who can share information back an forth. So a collective can choose a vendor to work with.
|
||||
- st: we're working on a proposal to come up with a process to finance these sorts of tasks. It's complex because members have different amounts of turnover/money.
|
||||
- h: potential govt funding, nlnet, etc.
|
||||
|
||||
Checkouts:
|
||||
- st: good stuff, need some more conversations
|
||||
- D: interesting stuff. The minimal solution seems feasible
|
||||
- Sa: got lost in all the acronyms, but want to hear more about this.
|
||||
- h: apologies for letter salad, not as scary, well only half as scary as it sounds.
|
||||
|
||||
## 2026-07-30, 12 UTC
|
||||
|
||||
Attending: papiris (he/they), Sarah, Sarma (they/them), stevensting
|
||||
|
||||
Topics:
|
||||
- FOSS Maturity
|
||||
- CVE - how can we share info about security patches quickly inside Coop cloud
|
||||
|
||||
Intros:
|
||||
- Sm: bracing for the upcoming heat wave, looking forward to hearing Sarah
|
||||
- p: hopeful, not a lot of sun in norway. Fields are too wet for the tractor.
|
||||
- Sh: LoRes is trying to transition from a one-person team (Jade) to additional coders. Hope to find a good basis for our next steps.
|
||||
- st: 38 degrees :fire: outside, but ok inside for now. Loooking forward to discussing organization growth. Sounds like a broad topic, but useful to Klasse Metode/coquest.
|
||||
|
||||
Minutes:
|
||||
- Sh: Reading lots of documents, lots of ground to cover. Want to know: what would be useful to your orgs and for coop cloud - to narrow the scope.
|
||||
[Shared Document](https://drive.proton.me/urls/94BRVTXBJW#JmdYMOUKXVEs)
|
||||
- Goals: allow an org to assess maturity day/to/day, how to handle things when they go wrong. Also improve operations, maintainability, resiliance in a way appropriate to an org's maturity.
|
||||
- Maturity models are good for step-by-step improvements to an org. Rather than assuming all orgs must be level 5, we can set goals appropriate to your level. Jumping straight from 1 to 5 is not sustainable,
|
||||
- Q: where should this documentation live
|
||||
- Q: what format should this documentation have
|
||||
- There's a convention to use tables, but it can be messy. We also have a pdf document that's more linear.
|
||||
- I haven't included: how big is the team, who are the copyright owners, how big is the roadmap, etc.
|
||||
|
||||
- st: where is the table from?
|
||||
- Sh: I synthesized this from maturity models listed later in the document, to make them more usable
|
||||
- st: in the automotive industry as a product manager, the maturity models were important to software development. Assessments could run for days to establish the maturity of a project. How feasible is maturity assessment for underfinanced open source projects? Even in a mature project, it all stands on the availability of the maintainers .
|
||||
- st: Lauti community calendar, I'm there as a voluntary basis. If no one on the core team could work on it, the project would collapse even if ok processes were in place.
|
||||
- Sh: I'd like this paired back to the essentials, for whatever coop cloud wants to get out of it. Not a checklist of what you have to do, but things to look out for when you have time for improvements.
|
||||
- Also, I've deliberately kept some things here as ideas to discuss; we should delete things rather than add things.
|
||||
- Q(Sm): since we have different orgs, some maintaining foss products, some doing hosting, and coop cloud as a supportive federation.
|
||||
- Sh: if people can choose the categories they find relevant from one document it might make sense to have everything in one, or we might break it up.
|
||||
- Q(Sm): which type of org did you have in mind when writing this table?
|
||||
- Sh: focused on development.
|
||||
- st: our org does all three. But financing is crucial. We need clients for funding, and we need to make sure our work is all being paid for. As we move away from a focus on development to a more mature org, the focus on organization should be larger: data protection, passwords, customer interaction. And that's the focus for hosting/services. For the federation, money is also important; the better funding we have the more possibility there is to establish proper processes and be reliable as an org.
|
||||
- p: Regarding format and hosting of the doc, when we in datakollektivet were starting to organize ourselves, we found the format of this helpful:
|
||||
https://demo.common.guide/
|
||||
- Sh: priorities will change depending on orgs depending on stakeholders etc. So hosting and development might need separate models.
|
||||
- Sh: not sure what that looks like from the federation point of view.
|
||||
- Sm: since the federation wants to make a certain org type viable, and
|
||||
- Sh: sounds more like a horizon roadmap than a maturity model; taking stock of where members are now and where want to be in 5 years time. What we want to achieve, but also what we expect from ourselves.
|
||||
- Q(Sm): what's the difference between roadmaps and maturity models? Both point us from "further from o goals" to "closer to our goals"
|
||||
- Sh: my table is a checklist style maturity model. For a roadmap, we'd show horizons for now, 2028, 2032. And we can see what we can expect of the org. It provides a benchmark/baseline of what the org can be expected to deliver at different phases, and helps us not to jump ahead to 2032 levels of delivery in 2026
|
||||
- st: We could say "in 2028 we want maturity level X in our org"; it can be one element alongside others. The maturity model comes out of various existing orgs, and can be used to judge an org. But horizon looks at possibilities, and looks at the future.
|
||||
- Sm: Circling back to funding: coop cloud talks about money differently than a corporate environment does. Since a lot of open source environments have VC - and our orgs need to focus on securing funding early on - do we need to account for that?
|
||||
- st: evaluating where we spend money is a no-brainer for a cooperative. A corporate environment has a profit motive and we have an environmental motive. It still makes sense to examine where we spend money, but we need to apply our own goals/values to our spending decisions.
|
||||
- Sh: we might have differences for non-profit or volunteer work. Comparing to existing FOSS work is a good starting point, but we should modify these models to our orgs.
|
||||
- Sh: working for an org with one coder, there's a passionate core group behind these projects which can put up barriers to risk management. So in organizing I focus on what passionate developers can overlook, and what users might need as we move from a small group of users to more widely used.
|
||||
- Q(Sm): since a lot of projects have infinite growth models, and coop cloud members generally want to reach a set size.
|
||||
- Sh: we'd have to look more carefully, but there aren't many criteria in these models that assume growth of any sort. There are a few, and we can easily look at those
|
||||
|
||||
|
||||
## 2026-07-23, 19 UTC
|
||||
|
||||
Attending: calix (they/them), Sarma (they/them), Sixsmith (he/him), j2
|
||||
|
||||
Topics:
|
||||
- Wordpress: how does updating work?
|
||||
- Web UI that Sixsmith's collective has been working on
|
||||
- Workshops, ideas and resources
|
||||
|
||||
Intros:
|
||||
- c: travelling
|
||||
- Sa: a little crunchy audio. Gonna commit to multinode when spoons allow. Also planning to do talks/workshops to teach people about what can be done with the internet.
|
||||
- Si: Atlanta. Using Co-op cloud with some folks, and evangelizing coop cloud to other collectives who need data security and data autonomy. Bursty activity, but inside of a burst now!
|
||||
|
||||
Minutes:
|
||||
- Si: working on frontend for managing apps, servers. Split into components, Want to publish this as a container, then as a recipe. Looking for thoughts to figure out next steps.
|
||||
- Si: demo currently not cooperating
|
||||
- Q(j): are we still trying to get a tagged release?
|
||||
- Si: we have a tagged build, builds succesfully.
|
||||
- Si: [here's a link](https://git.coopcloud.tech/toolshed/-/packages/container/coop-cloud-webui/nightly)
|
||||
- Si: We use an automated builder, but it's not drone. At the moment builder lives independently, but ideally we want a CI w/ drone.
|
||||
- Q(Si): do we want the web ui as a recipe, so people can deploy it on the internet? Or do we want the container as a local application, which uses the user's configuration?
|
||||
- c: very excited, amazing stuff
|
||||
- c: lot to be said for encouraging people to run it as it has been. Main question is about git handling; how does this interact with git? That might affect where to run it. Also: what is your intended public? People come to coop cloud with different levels of sysadmin experience; different populations might want different options.
|
||||
- Q(Sa): haven't seen this before, curious about parity with abra/docker commands, how safe is this to give to an operator, how limiting? Would it be difficult to make local+deployed both options? I assume most of these questions would be answered by the demo or video.
|
||||
- Q(c): clarifying git question - how are env variables handled?
|
||||
- Si: no handling of environment, secrets, server configuration, or sharing. Everything is consumed from the user's abra directory. So this would be on top of whatever existing sharing solution you have.
|
||||
- Si: we're seeing this as interchangeable with the abra CLI. Feature parity and used the same way by a single operator - but without requiring comfort with the terminal.
|
||||
- j: screensharing
|
||||
- c: agree, there's no support in the CLI for version control/sharing, so it makes sense not to have it in the web ui
|
||||
- Q(Sa): flexibility - do you imagine someone in an org has
|
||||
- j: the inflexibility can be a good thing. There are clear bounds on what you can/cannot do with the tool. So it's not a drop-in replacement for the CLI.
|
||||
- Q(Sa): how difficult would it be to make "local vs online" a configurable option?
|
||||
- j: sounds reasonable!
|
||||
|
||||
Wordpress!
|
||||
- Si: how does the upgrade process work, across recipes, across container images?
|
||||
- Si: way I sketched it out is: recipes use latest+greatest version of an upstream image that they have tested. There's been discussion in wordpress, if there is an RCE in an image should people find out about it?
|
||||
- Si: some recipes use non-standard versions of wordpress and they're nontrivial to upgrade. There's various levels of out-of-date packages.
|
||||
- Si: how do we consider there might be a different upgrade path, since operators are on different versions.
|
||||
- Sa: for different versions, I've seen recipes use "checkpoints" - like asking operators to upgrade to 4.0.0 and make sure verything works before they move on to 4.1.0
|
||||
- Sa: for security updates, I've never seen conversations internal to coop cloud about them. I tend to follow upstream maintainers on fedi or RSS, to find out about security updates.
|
||||
- Si: renovate is a good tool. I've been playing with the digest ping feature. With pinning my label you don't know the image you're getting because labels are immutable.
|
||||
- Si: afaik no recipes use digests, only labels. I don't think abra has support for them. Ideally, maintainers should see a label but have it be a digest behind the scees.
|
||||
- Q(Sa): not familiar with what a digest is
|
||||
- [https://docs.docker.com/dhi/explore/security-concepts/digests/]
|
||||
- Si: there was an issue recently where someone took over the github account, and published a compromised image to an existing label. So pulling from the same label you got different images depending on time.
|
||||
- https://socket.dev/blog/checkmarx-supply-chain-compromise
|
||||
- Si: in renovate, you can just set "pin-digests=true". I would like to see if that works with our recipes. Check if this works with PRs in our recipes, and whether upgrading uses the digest sensibly.
|
||||
- Q(Sa): how big a concern is this for us? Should we prioritize this? Maybe a critical fix in abra, to use digests?
|
||||
- Si: on docker hub, I assume there;s some verification to protect against that. There's a setting in docker hub with an existing tag. But, the API does not tell you whether a given image has that setting. So this is an unknown, and yes, a vulnerability.
|
||||
- Si: only a fraction of recipes use renovate. I'm envisioning that renovate would be best practice, and recipes that don't use it's next action should be to use renovate. But the next step would be to have renovate use this digests-true setting. IIncremental deployment, since recipes are at various stages of readiness.
|
||||
- Q(Sa): I wonder how you'd communicate this to all maintainers. Maybe modify MAINTAINERS.md templates?
|
||||
- Si: I'd like to bring this up on matrix. Could also modify MAINTAINERS. Maybe there's a renovate default config we can modify?
|
||||
|
||||
BigBlueButton recipe development:
|
||||
- p: as part of Near (spelling?) I've been working on the BigBlueButton recipe for most of this year. We made a breakthrough last month. But we can't get video calling working. We seem to be running into issues with interactions between WebRTC/coop cloud/docker swarm. If anyone has experience with webRTC, please open an issue on the bigbluebutton recipe.
|
||||
- Q(Sa): do you have a budget for this, or asking for voluneer work?
|
||||
- p: asking for volunteer work
|
||||
|
||||
WebUI demo link (hopefully it stays up):
|
||||
https://vid.curls.soy/w/3K58ACBGSi9L9pwiR9uega
|
||||
|
||||
Outros:
|
||||
- j: looking forward to covering more topics/questions next meeting
|
||||
- Si: glad to interact with other humans working on coop cloud, want to come back!
|
||||
- p: should start coming to these more regularly, and use matrix more regularly
|
||||
|
||||
|
||||
|
||||
## 2026-07-16, 12 UTC
|
||||
|
||||
Attending: Jade, Sarma, Tom Idar, Papiris
|
||||
|
||||
Topics:
|
||||
- M-m-m-multinode
|
||||
|
||||
Intros:
|
||||
- Tom: new, doing something similar and wondering if I should join you
|
||||
- Jade: keen to jump into multinode
|
||||
|
||||
Minutes:
|
||||
|
||||
- Sarma: Vision
|
||||
- Deam of having a cheap VPS that acts as a proxy and gives access
|
||||
- A network of various machines, laptops etc that sit behind NAT and do the processing and storage
|
||||
- This is partly to keep costs down and give us control on our infrastructure
|
||||
- Much of the equipment is unreliable and cheap
|
||||
- Q Tom: Why would a cluster of machines be good?
|
||||
- Co-op cloud initially established by co-ops doing web hosting for clients. For these co-ops, it was efficient and effective to have a cnetral VPS that would post everything.
|
||||
- Tom: We have next cloud servers, centralised login would enable the use of seperate servers that aren't connected.
|
||||
- Nextcloud servers can connect to each other and share between them
|
||||
- Sarma:
|
||||
- The above describes federation between servers, supported by Nextcloud, Matrix, etc. Doesn't require servers to be in the same cluster
|
||||
- Having services on the same cluster (or swarm) allows for:
|
||||
- single load balancer, provides control of traffic
|
||||
- shared resources, eg (redis, storage)
|
||||
- Tom: If you have services in a cluster, you need to be in the cluster to access. And you need to collaborate in a highly trusted way, not a federated way. Big clusters are often used by big tech.
|
||||
- Sarma: Let's dive into how clusters work with Docker Swarm
|
||||
- Some magical things happen in docker swarm. Services start and stop automatically, but:
|
||||
- Each server/node has it's own data storage, its own copy of a volume.
|
||||
- One way to solve this is with custom rules in the compose file. [The `deploy` section](https://docs.docker.com/reference/compose-file/deploy/)
|
||||
- Docker swarm can restrict particular services to particular nodes. Nodes can be tagged as having data storage, good compute, etc, and certain services can require those tags.
|
||||
- The solution we currently have is to have a single node that is both the manager and the data storage node. Any service that will break if it loses access to its data storage runs on the manager.
|
||||
- Many apps have a container that is resource intensive but doesn't care about persistance, and another that has the opposite needs. In those cases, our solution works well. The difficulty is in apps where a container requires both persistence and resources.
|
||||
- If we can get a container to use (something that looks like) S3, then we can run a distributed object storage service (Garage)
|
||||
- S3 usually requires us to work upstream. If a container relies on volume storage (rather than object storage) we did consider s3fs, but the folks working on Garage have told us that's a bad idea - S3 is missing many fs features like file locking.
|
||||
- Other solutions I've glanced at are: nfs (network filesystems), docker volume plugins, and manually syncing.
|
||||
|
||||
- Q(S): I'm curious to hear about your usecases
|
||||
- J: only a subset of people will want distirbuted. But here's Merribek's usecase:
|
||||
- We're running separate servers at separate community facilities, and reling on federation between them. So there's no docker swarm extending between locations. We wish to connect between locations with low-bandwidth and often unidirectional technologies (e.g. lora).
|
||||
- We picked raspberry pis, because they're easy for beginners to get running with $200 of technology. Each raspberry pi is also a unit of storage that everyone can understand.
|
||||
- But pis don't scale vertically. As a given location expands, we could move up from pis to a bigger computer. Or, we could cluster our pis. Some of our members are excitedd about shoebox racks or 3d printed cases.
|
||||
- Downside of clustering: marries us to buying new tech, rather than permacomputing.
|
||||
- If we use multiple pis in a single location, we'd probably centralize storage. The SD cards would not hold volumes, only OS.
|
||||
- We aspire to running our servers entirely off renewables and batteries. Having lots of small computers allows us to prioritize them and power them down. E.g. we might power down the minecraft server when batteries are low. So we might want to tag services and power them down at low battey levels.
|
||||
- S: really interesting question of prioritizing services for shutdown; I'll definitely look into this.
|
||||
- Sarma usecase:
|
||||
- 200 AUD for a Pi server is actually quite a lot. In some communities, a laptop with a broken screen is actually more achievable.
|
||||
- You can often find these fairly cheap at various local marketplaces.
|
||||
- I have some concern that this might not scale well in terms of energy usage, but the upfront cost is more achievable.
|
||||
- Q(J): Would a non-docker-swarm solution fit this usecase better? e.g. k3s?
|
||||
|
||||
- p: Have asked garage people how garage handles nodes falling offline/coming back online. It does not handle that very gracefully with redistribution of blocks. In an unstable network or unreliable nodes, to guarantee availability would require that each node holds all data.
|
||||
- Q(S): papiris has more experience with k3s
|
||||
- p: K3S is... ok ... . If you're a k8s engineer and work with it daily an keep up to date with it... If you use it anyway and are compensated, I recommend it. But if your time spent to keep your knowledge up to date is not being compensated, it's a very expensive tool to learn. I've used it for thousands of hours and am still faced with walls I struggle to overcome.
|
||||
- k3s handles nodes falling off and coming back on, but it can be sketchy.
|
||||
- S: based on this, I feel intimidated to try k3s. I'm actually considering splitting the problem: have docker swarm handle container disribution, and do data replication with a different system entirely (not sure which). Then the single reliable node that's handling load balancing can also function as the data proxy: from the perspective of docker swarm, data is centralized in that node, but in reality data is stored elsewhere.
|
||||
|
||||
- S: my concern with garage is that it's not a universal solution: if a service doesn't support S3, then garage won't cover file locking. E.g. in mailu, I think emails are transferred between services by saving a file to a docker volume;
|
||||
- J: good to consider what level of the network stack we do our distribution. If we want to install not just swarms but also databases and other things, we want something that acts like a single distirbuted computer/operating system. On the application level, we also have a lot of services that have opinions about replication and their own implementations. Servers like stalwart have their own replicaiton. Identity/management system (authentik etc) have their own replication strategies. It's frustrating. I don't know if there's any way to build systems where we use a general system to network our machines, which provides enough networking/routing information that we can hand off to application-level synchronization.
|
||||
- Things get weird when we do distribution, and we want users to understand that. Application-layer solutions have ways to communicate to users. But if we want a lower-layer solution, users might get frustrated because they either expect clear error messages, or they're used to the reliable pipes of big tech.
|
||||
- S: I've seen users get frustrated when a container goes down somewhere; their confirmation emails don't get sent and they don't know why.
|
||||
- J: Many downsides to application-layer sync, I'm not promoting it and it's not winning the battle in comercial software. Cloud as absraction is the model we use globally for everything comercially. There are open source cloud options that move beyond just block storage. But they tend to be complicated because they're targetted at orgs much bigger than us.
|
||||
- At LoresTech we are doing application-aware networking. And this means we're going so slowly we're delivering nothing.
|
||||
- We need both strategies.
|
||||
|
||||
Checkouts:
|
||||
- Jade: always glad to have these meetings, appreciate that people find the time out of their day. Next, working on p2panda
|
||||
- Tom: starting a new company with 4 people. Found coop cloud through a collective in norway. Still gathering information, will definitely follow this group.
|
||||
- Papiris: inspired & enlightened about the various challenges and limitations, realizing that to know my usecase I need to get further in the organizing, to understand what people's needs, capabilities, and wishes are. Meeting was nice! Informative. Too bad about bad connections but such is life. For future KF, no new suggestions, review my previous KFs. Doing next - paying a benchful of unpaid bills, as well as paying the horses, sheep, and chickens. And setting up a bonfire instance :fire:. Already have a test instance, this will be prod!
|
||||
- Sarma: might want to introduce a 5-10 minute segment at the end of KFs to touch on topics we didn't get to, especially from people new to the community.
|
||||
|
||||
## 2026-07-09, 19 UTC
|
||||
|
||||
Attending: Steve, Calix, Papiris, Ben, Sarma
|
||||
|
||||
Topics:
|
||||
- what is the support intention for coop cloud across multiple machines
|
||||
- report back from Rojava
|
||||
- LLM use
|
||||
|
||||
Intros:
|
||||
- Steve: I've been doing self-hosting, coop cloud has been interesting in that space
|
||||
- Ben: member of a tech coop that does consulting, interested in decentralization and etc, just checking this out.
|
||||
- Sarma: glad to see more people! Setting up hosting business. Slow & difficult.
|
||||
|
||||
Minutes:
|
||||
- St: muliple machine question is connected to the docker swarm topic. Especially wondering if coop cloud is intended to be run on a single VPS
|
||||
- c: Sarma and Merri-bek are probably our experts on multiple nodes
|
||||
- Sa: Short answer to "does co-op cloud support having multiple worker nodes" is "no". But: co-op cloud very adaptable, gotten it to work fairly fine. A few considerations. Biggest difficulty is data storage: wherever you need to hold your volumes and databases, creates restrictions how many machines you can run a particular container on. For example: Mailu has database container; if you try to move that container to a different device, docker swarm won't move that data for you, it will spin up new (empty) database. In most cloud set-ups, you want special handling for databases generally. At the other end of the spectrum: webmail container, just presents frontend by connecting to other containers. Can run anywhere! From the perspective of docker swarm, you want to have constraints on containers which need to be bound to separate machines. Separate compose file, attach to recipe. At some point I would like to standardise, normalise, make it part of regular recipes. Still WIP.
|
||||
- St: Generally abra, recipes, whole stack assumes single-node docker swarm. Talking about putting a database on separate machines. More traditional configuration, docker compose?
|
||||
- Sa: All the configurations are stored in one place, running abra only on manager node. Where can I find information about that?
|
||||
- c: You're correct that the answer you'd get in the matrix and documentation is "abra will probably not work for multiple node docker swarm configurations". There's nothing in abra or the recipes that tries to prevent that. If you run the abra quickstart and attach worker nodes, you'll run into issues because the recipes have no defaults on where to deploy specific containers.
|
||||
- St: So, the design standard of recipes is to assume a single node? What I want from a pay-to-play tech coop is resiliance. If I'm running my storage from a small local machine, then when that machine goes down I lose access. What people say on self hosting is, if you want resiliant servers just rent a VPS. Problem with privacy is that the hardware owner can see the data. The solution to this would need to be on the recipe level of coop cloud. Some software has application-layer data replication, e.g. Sirus IMAP. And the deployment would need to be aware of that, of a swarm of Sirus IMAP nodes. I want to guarantee something durable, and not use a VPS. Hardware can take weeks to replace if something breaks.
|
||||
- Q(St): is multinode a direction that coop cloud is trying to go?
|
||||
- Q(St): how does this connect to the docker swarm question?
|
||||
- Sa: Definitely want to explore this. Active concern I'm currently looking into. Merri-Bek. Don't know about if "whole of co-op cloud" wants to do multinode, but at least two members are exploring it so there's space for conversation/work
|
||||
- b: S3 as a backup, peer to peer backup storage
|
||||
- c: [Sutty](https://sutty.nl) is trying to build a coop based around [garage](https://garagehq.deuxfleurs.fr/)
|
||||
- p: also interested personally in multinode coop cloud. Trying to do something similar to lores in Norway and Rojava. Acces to high-spec machines is difficult and having stuff in single locations is vulnerable. K8s is too complicated and unreliable in emergency situations, e.g. in areas with unreliable internet connections.
|
||||
- c: coop cloud's founding coop was focused on vertical scaling, and that led to the single node preference. The first few member orgs were all hosting on VPSes, likely because their threat model was different. But that's changing. Merribek Tech's Lores project seems to have a similar usecase to yours.
|
||||
- c: for the specific example of a mail server: if you want reliable failover need to consider what's handling network ingress. Coop cloud recommends traefik (most recipes have support for it). And since v2 you can't do network ingress for free, need to pay for premium. No one's looked extensively into whether caddy can handle this for us. If docker is trying to figure out which instance to send mail to, then if your reverse proxy is down it's like the whole server is down.
|
||||
- St: email is one of the protocols that doesn't need a reverse proxy; can do failover in DNS -- MX records are progenitors of SRV records. Jabber can also do this. For this type of software you don't need a big vertical stack.
|
||||
- St: for anyone interested in self-hosting, getting away from big tech at a bare metal level, [15h](https://15h.org/index.php/Home) is developing coreboot open source firmware that can push the bare metal level towards independent and self-owned setups.
|
||||
- p: tried a cloud with multiple traefik installs. In the current k3s I'm using there's a tiny load balancer that shims traffic back to the main traefik container. So multiple ingress nodes only need one traefik container. Maybe we can explore that?
|
||||
|
||||
- c: there's a lot more to say on multinode and we could be nerdsniped into exploring that now, but we could move to other topics.
|
||||
- S: would be good to have a structured conversation on multinode. I can bring that up on matrix.
|
||||
- c: agreed, could do a merribek demo and different visions
|
||||
|
||||
#### Rojava
|
||||
- p: spent 10 days with a European delegation in Rojava. tech was not main focus, so these are Observations and questions I've asked. My experience with the people of Rojava is that they mostly use big tech. They use WhatsApp for messaging. They use proprietary video editors for most of their content. I only saw Windows installs. Only in particular locations was it Linux. A lot of the Windows installs might have been pirated.
|
||||
- p: secure communications and secure digital services, anything digitally secure, was practiced only by the most sensitive aspects of society. People working in technical stuff are interested in, willing, working to implement better security. They'd appreciate contributions of time or advice.
|
||||
- p: cellphone towers are existant but vulnerable. Anything except talking to your family is not advised. The backbone network is very slow and unstable. Only 7-8 hours per day of electricity, inconsistent across the network.
|
||||
|
||||
- p: there are no hackerspaces, digital independence days, linux parties. There is some interest. Especially alternative social media days/seminars for the youth. A lot of youth use instagram, tik tok, youtube - exposed to the same right-wing/sexualized/capitalist/misogynistic content and propaganda that we are in europe. There's a lot of willingness to change that, but not a lot of knowledge.
|
||||
|
||||
- Q(St): What are people trying to do with local LLMs in the middle of all that's going on?
|
||||
- p: various parts of society want to use it. Media studios want to create low-budget video works. Education is limited. Since 2021 there's more places ([Peymangeha Bilind a Hunerê ya Rojavayê Kurdistane](https://instagram.com/peymangeha.bilind.huneri)) that teach painting, dance, theater, music, film, but not animation. Currently there is no animation education.
|
||||
|
||||
- Q(Sa): Drawing a parallel with talking about how the youth approach social networks - feels so familiar. Same things happening in Europe. "I would like to be using something else", with little knowledge. Is there space to coordinate on that, collect teaching materials?
|
||||
- p: that rings true. The focus has been, until now, a lot about communication - how we enable resiliant, secure, distributed communications. But that's only one aspect, one area where people can contribute (e.g. mesh networking). Youth networks in the kurdistan freedom movement and rest of europe are definitely facing that problem so there's room to collaborate.
|
||||
|
||||
Checkouts:
|
||||
- c: lovely to meet new people. Always appreciate tales from papiris's travels spreading democratic tech. Saw coolify in matrix and again want to do kite flying session where we try alternatives to coop cloud.
|
||||
- b: interesting to hear different perspectives. Gonna work on OAUTH2 and some Rust. Then playing a Colorado Springs gig; 2 hours away through denver traffic.
|
||||
- St: Gonna work on my 15h board, get it booted. Going to read more on Rojava, too.
|
||||
- p: feeling fulfilled in having brought the messages from Rojava to you. Glad to be part of this bigger struggle of democratizing all the things. Will be hopping on a night train, because the train network ran out of power during my previous train attempt. Silver lining: I had stable connection during Kite Flying. For Future Kite Flying, would be interesting to discuss/learn organizing events around moving off big tech.
|
||||
- Sa: Cool topics as always, especially happy that there are still unanswered questions! Dug into a lot of things, opened up even more. Event idea seems interesting, not sure how to facilitate it, who should be invited. Multi-node seems like interesting topic for kiteflying. Will bring it up in matrix.
|
||||
|
||||
|
||||
## 2026-07-02, 12 UTC
|
||||
|
||||
Present: Sarma
|
||||
|
||||
No meeting held, due to lack of attendance
|
||||
|
||||
## 2026-06-25, 19 UTC
|
||||
|
||||
Attending: Sarma, calix, Dieu (pronunciation "like you and me")
|
||||
|
||||
- LLM discussion seems to be needed, to generate a policy
|
||||
- requires: knowing what the points already mentioned are
|
||||
- S: I think d1 mentioned they're making a list?
|
||||
- c: He seemingly explicitly didn't volunteer for facilitation or to share that?
|
||||
- S: there was a lot of crosstalk, so not-volunteering doesn't mean not-willing to share
|
||||
https://git.coopcloud.tech/toolshed/organising/issues/678
|
||||
- c: not too much here, because most of the conversation has been in Federation chat
|
||||
- c: one other thing to do is map out what the options are, unclear if d1 has done that.
|
||||
- Q(S): have we had any LLM contributions?
|
||||
- c: sort of. 3 total. 2 linked from [thread](https://git.coopcloud.tech/toolshed/organising/issues/678). Plus one [nextcloud maintenance.md draft (same author as one of the PRs)](https://git.coopcloud.tech/coop-cloud/nextcloud/pulls/81)
|
||||
- c: Autonomic has been using LLMs for recipe maintenance tooling; unclear if recipe changes are LLM generated.
|
||||
- S: Nextcloud maintenance doc is Claude.
|
||||
- c: depends what we mean by "LLM contributions". since there's no policy that you have to declare, we don't know if other contributors use LLMs.
|
||||
|
||||
Dieu joins
|
||||
- D: first time here; heard about you from the What We Will org
|
||||
- Q(c): haven't head of WWW, talk about them/how you're involved?
|
||||
- D: https://wwwrise.org/ - associated with Tech Worker Coalition. I'm actively involved.
|
||||
- D: The What We Will coop is recently incorporated!
|
||||
- Q(D): So what are you up to?
|
||||
- everyone: being a mess
|
||||
- c: used to be part of the founding coop. Now independent trying to start a new thing.
|
||||
- S: hi, independentish Polish-based person, facilitating on other weeks
|
||||
- c: recap. 9-month-long conversation about what our LLM policy should be. One member of the coop is already using LLMs and brought the topic forward. Conversation has been federation-internal. Current goal is to map the current views.
|
||||
- D: currently working on a dev environment; want to be a fly on the wall and meet people, get touchpoints in orgs like this.
|
||||
- D: I'm interested in the high level concept of coop cloud. I have a few years experience front-end/react/web. Left tech and movement tech has been in the back of my mind. Not enough people know anything about this, even though it's not rocket science.
|
||||
- S: Curious what D's perspective is. "Even though not rocket science". Comparing apples to oranges. Problems that tech work prepares you for - problems fairly divorced from human stuff. "Software exists in a vacuum". Co-op Cloud is a group of people who are trying to make sense of those social problems. Finance, outreach, organising chats etc. Building software tools that make that more possible.
|
||||
- D: "not rocket science" is more something I tell myself - tech can be framed as reserved for an elite group to gatekeep. I get anxious, and telling myself this reassures me that it's not so bad/learnable. Might not be easy to figure out a solution, e.g. a non-hierarchal approach. What I meant to say is that given a better understanding of profit, surveillance driven architecture - reasons/tradeoffs, data sovereignty, privacy - why should an individual person or org care. There's a fear on the left that all tech is bad, because of exposure to corporate tech.
|
||||
- S: All valid!
|
||||
- c: two brief thoughts. coop cloud is three things:
|
||||
- 1. community of 300-ish people (figuring out solidarity, economy, liberatory tech) governed by intl democratic federation.
|
||||
- 2. configuration commons: collection of our recommended deployments of open source apps. We're synthesizing the wisdom from across the community how to run wordpress, jitsi, nextcloud, etc. A lot of people use this, but deployment is difficult because while each software publishes guides, you need to learn a lot about each to do security, sso, backups, etc. Recipes represent quite useful shared learning. In some cases, people have made contributions/recommendations despite not using Coop Cloud tooling. Configs touch on devops concepts: infra as code, etc. Goal: less duplication of work between orgs.
|
||||
- 3. Tools: built around docker swarm (an unloved mode of docker). The docker CLI is bad, swarm CLI is worse, so we have abra - which keeps app configuration separate from recipe configuration. This solves the problem that if you have 10 nextcloud deployments you need 10 repos. We also made (?), reluctantly.
|
||||
- Calling all this coop cloud brings some misconceptions. People imagine Coop cloud either provides hosting, or software to enable paid hosting - we do neither.
|
||||
- D: Maybe there is a barrier of entry, "technical knowhow". Appreciate the context.
|
||||
- Q(D): How long has Coop Cloud been around?
|
||||
- c: project started 2020, federation started 2021/2022
|
||||
- Q(D): do people come in with these expectations often? Does it reflect a need of what people are looking for?
|
||||
- c: yes to both. Speaks to two unmet needs:
|
||||
- 1. not enough cooperative hosting providers for standard VPSs
|
||||
- 2. not enough IaaS/SaaS providers. There are people who will host Nextcloud for you, and some of them are cooperatives. And there are paid services (picapods, cloudron?). But orgs that want to use open software probably want a values-aligned org, not silicon valley. And because cooperatives usually do things manually they can be more costly.
|
||||
- S: don't personally run into that confusion. Personal set-up: all "cloud" software eventually hosted on people's laptops under their beds. But yes there is a need for this for others probably. Might not be enough of a need for this particular use-case to make it economically viable. But a lot of people who want it to happen. Seems like a difficult problem to solve compared to what we're trying to do. I do want to see a future where more organisations that are values-aligned with us would prefer to have some amount of geographically-local, spatially-local infrastructure. Ideologically "infra as a service" clashes with software autonomy.
|
||||
- Q(D): If I want to learn more about the problems you're aware of, are there groups having these conversations, articles, books, thought leaders? Does existing content inherently support capitalism?
|
||||
- S: Absolutely do not need to know devops or any particular tech to participate in conversation. Big need for people knowledgeable in other human aspects. Sutty has a good [blog](https://sutty.nl/en/blog) about the issues.
|
||||
- C: [hour video](https://2025.counterspy.zip/assets/presentation-platform-autonomy.mp4) discussing community tech - as opposed to corporate hosting and tech hosting
|
||||
- Q(D): so, pooling resources?
|
||||
- C: Not just resources. In self-hosting, each collective needs their own sysadmin. So if a collective doesn't contain a god-tier tech nerd... And we end up with the most radical groups using objectionable software
|
||||
- D: Grassroots group - "how do we use different tech", inconvenient, beyond capacity. Those who most want to use it have least resources, know-how.
|
||||
- Q(D): how do I stay in touch?
|
||||
- c: matrix or signal
|
||||
|
||||
Checkouts:
|
||||
- c: feeling better than at the start. Really nice meeting D, thanks for joining. Still feeling stressed about the LLM conversation; worried it will spiral out so that participation becomes impossible for people without infinite free time. One of these days, I'll propose a theme. E.g. "trying out alternatives to the tech side of coop cloud", or a hackathon
|
||||
- D: thanks for everything. I think there's too much of a gap between activists and technology. wrt LLMs, gotta think about the impact of the decision. Open source contributions exploded, but burnt out a lot of people. Questions around sustainability and inclusivity of newcomers. No need for FLOSS to churn out features that then break.
|
||||
- S: Hackathon was indeed great, fun to repeat that. Also constantly promise myself that I will come up with a theme then forget. Hoping that I will find a theme in the Matrix chat. I can try to help moderate the matrix. Cozy games.
|
||||
|
||||
|
||||
### Mapping out the options?
|
||||
|
||||
Hosted vs open source
|
||||
Hosted: US vs EU vs other
|
||||
- S: there's a legal argument for EU LLMs because of GDPR
|
||||
-
|
||||
|
||||
## 2026-06-17, 12 UTC
|
||||
|
||||
Attending: Sarma(they/them), steven (he/him), Jade(they/he), papiris (any), c (they/he/any)
|
||||
|
||||
Recent events (backup topics)
|
||||
- Wouter's LGBTQ+ outreach
|
||||
- Lores's shiny new app: https://lores.tech/blog/example-chat-app/
|
||||
- Discussions around database/redis containers shared between recipes
|
||||
|
||||
Topics:
|
||||
- mesh networking / reticulum
|
||||
- local-first, p2panda
|
||||
- digital autonomy for Rojava
|
||||
- decentralized comms
|
||||
|
||||
Check-ins:
|
||||
- J: lores chat example!! Solarpunk meetup with people trying it out. 15 volunteers focused on getting through the instructions, but it's slow - people struggling to get through. Excitement around mesh networking.
|
||||
- common problem: offline installation
|
||||
- s: in the last stage of starting a big bonfire instance. Postgres troubles, long request timeouts. Interested in the AI discussion - we should have that in lauti and <couldn't hear>. A few PRs came in with AI contribution.
|
||||
- p: Headed to Rojava this weekend. Excited about what is to be and has come about, intl collaboration. Anxious due to unknowns, mostly in local (Norway) activities.
|
||||
- c: NZ, investigating how to get a longer life out of old hardware - refurbishing, rehashing, reworking, debloat. Resiliance: big storm that knocked out power. Mobile + fiber ran out of batteries/generators.
|
||||
- sa: Staying at a friends. I have a website now, which is great.
|
||||
|
||||
Minutes:
|
||||
- J: reticulum/Lora - seems like mesh networking has one main usecase: messaging. And that's a killer usecase, necessary. Everything else is mesh-native apps. What I'm pitching is an unholy marriage of web servers and mesh networking. Serving up sass, especially in domains other than messaging. We started with a messaging app as a demo ,though.
|
||||
- J: What would be the most interesting non-messaging app? Though about this a lot. Some of it is geographical in nature: library of things, etc, if the objects come from the same place the server is. Want to avoid trap where we build th software from scratch. So, what existing software could use messaging for sync?
|
||||
- J: kanidm - already have p2p message based sync. What else?
|
||||
- p: new to the mesh networking biosphere and p2p stuff. If the peering is on the backend, how do we make this transparent for people using and administrating the services/servers? So it doesn't require patience, grit, technical knowhow?
|
||||
- p: I put a surprising amount of hours into getting reticulum working. It's mostly there now, but wouldn't expect others to put in the same effort.
|
||||
- J: reticulum is the wilder west option of the mesh nets. there are non-technical people using [missed] . It's on us as technologists to hide that transparency from users. There's something to be said for eventual consistency. Users are used to low-latency high-bandwidth web apps that ship huge amounts of js and provide their own experience. Changing that might be necessary. Trying to solve the problem: how do you make a good user experience, e.g. "your message has left your phone, but hasn't necessarily arrived at the others". Users have to get used to very different experience. If we build custom mesh-native (event-sourced + eventually consistent) apps, they can provide good feedback to users. We mostly see those developed in the local-first space, not the server space. Interesting question if we can create this unholy blend. A sweetspot might be email - people already expect event sourcing & eventual consistency. I use emails as an example when describing lores. We could even use existing email servers as underlying infra.
|
||||
- J: the groups that are using mesh apps are largely rugged individualists and libertarians, not a lot of conversations about commons.
|
||||
|
||||
- Sa: comparing to an old system of SMS messaging, evey member of a decentralized group
|
||||
- J: don't think it's a requirement that things are event-sourced, but there are examples that aren't, e.g. Willow. Some protocols p2p sync large data structures rather than messaging. Most of the local-first space is using event sourced
|
||||
- st: how would bittorrent fit into this, as a decentralized version of file storage?
|
||||
- J: bittorrent is another example of a non-event sourced eventually consistent tech. docuwiki is based on a file system structure, not a relational database. So it could work for that.
|
||||
- J: bittorrent is a p2p network across existing inernet infra, there are other examples (Iroh). Meshcore/meshtastic ignore the eixsting strucutre of the internet. They make a new data link layer on existing network intefaces.
|
||||
|
||||
- J: wrt email, there was a geographical parallel: each domain would correspond to a building. As the internet was more interconnected - there are still controlling nodes - but we've moved away from geography. Wondering what it'd look like to have something based on local geography.
|
||||
- J: contrast with fediverse - your local organizers manage tech themselves. Your server can have its own policies and be isolated from the big bad world. But if it's in a specific place, you need to be able to connect to that place. How does that work in a mesh world? If each neighborhood has its own server and each runs its own mastodon - in a Mad Max "no internet" future it's cool that you can go to your local library and check your feed. But in a world *with* Internet, it's awkward - "why do I have to lose access when my library's server goes down?"
|
||||
- p: Same thoughts, geography is a natural organizing structure. For organizing/social aspects of building tech autonomy. Our local area loses electricity often - it'd be good to maintain a connection w/ outside world. We often have cell reception but no home electricity. Maybe a k8s cluster in the region, plus duplicate workload in another region would let you keep access. But doing k8s is hard. Pitfalls wrt running servers + databases geographically distributed. It might not be the best avenue to approach it. Haven't used docker swarm; is that viable?
|
||||
- S: usecases, where either a malicious actor or natural disasters are attacking internet infra. Are those good examples of non-messaging usecases for mesh nets?
|
||||
- J: in these cases, local-first software might be better. E.g. sneakernets. Scuttlebut had its problems but did really well. A different thread: as people who run centralized infra, we can support the rolout of local-first apps by providing syncing servers (not necessary but useful)
|
||||
- J: local-first, some talks
|
||||
- J: local-first usually want something to start the handshake between peers, and cloud backups of your data. Sometimes that's the business model. But what if that was a general protocol: a standard syncing/backup server that you can use with any range of local-first apps. I don't think local-first apps are there yet, but we can keep abreast of that.
|
||||
- J: do we build SaaS, local-first, or neighborhood-first tools?
|
||||
|
||||
- S: let's talk about digital autonomy for Rojava
|
||||
- p: requests no notes
|
||||
|
||||
Check-outs:
|
||||
- st: I'm interested in meshnets, may want to pursue in future. Want to hear more updates.
|
||||
- S: love the chat, Jade you're a fountain of knowledge, thank you for sharing. Papiris, all the support.
|
||||
- J: a bit guilty that we focused on my special interest
|
||||
- p: thought-provoking talk, fog is lifting on what avenues are interesting to pursue.
|
||||
|
||||
## 2026-06-11, 19 UTC
|
||||
|
||||
Sarma, calix
|
||||
|
||||
Q: Why are these slots drying up so much?
|
||||
- FOMO around 12 UTC ones
|
||||
- Seasonal stuff
|
||||
|
||||
Topics:
|
||||
- PR review
|
||||
- docs, some old/wrong kite flying info
|
||||
|
||||
Minutes:
|
||||
- code looks good
|
||||
- Q(S): where do I see the build process?
|
||||
- c: in the README there's a link
|
||||
- build failing, due to authentication
|
||||
- c: would be good to move off of my credentials, and use the abra bot token
|
||||
- switching to the abrabot auth fixed things
|
||||
|
||||
Discussing https://docs.coopcloud.tech/federation/organisers/#kite-flying-hours and https://docs.coopcloud.tech/federation/handbook/#kite-flying-hours
|
||||
|
||||
- Proposal (S): let's have just two toots, one for 19 UTC one for 12 UTC kite flying, and boost them at set times before each meeting
|
||||
- c: let's start next week
|
||||
- Q(S): taking a step back, why does KF need to be mentioned in these docs?
|
||||
- c: could see an argument for "how to attend kite flying" and "how to organize kite flying" for facilitators: posting on mastodon, facilitation structures, etc.
|
||||
- c: neither of these two places do this. Organizers' intro is slightly more focused towards facilitators
|
||||
- S: nothing on Federation landing page about organisers / organisers handbook. Have to find the menu, hidden by default on narrower screens. Who needs to know about kiteflying, that it's paid, how to run it? Could sometimes be someone's first way of learning about CC. Or for really gnarly questions.
|
||||
- S: Also envisaging how this will show up post-new-website.
|
||||
- S: Nothing on homepage about kiteflying. Need to scroll down to https://docs.coopcloud.tech/intro/get-involved/
|
||||
- c: could be bigger
|
||||
- c: what you noticed about organizers, it used to be a top-level section but got moved to federation. Agreed that it's missing from the federation landing page. Good to think about the intended public, and agree that people new to coop cloud are an intended public. Agree that it should be bigger on the get involved page, and we should add it to the contact page. New website should make it more obvious in general; in the short term... worried about the scope of moving the organizing pages.
|
||||
- c: at least, we could remove the duplication between the two pages
|
||||
|
||||
Pause in conversation, time for the build to finish. It succeeded!
|
||||
|
||||
- c: it only published one image?
|
||||
- nevermind, they images are listed under different versions in https://git.coopcloud.tech/coop-cloud-chaos-patchs/-/packages/container/hometown/v4.5.6-hometown-1.2.0-streaming
|
||||
|
||||
- S: should be quick to add a new chaos patch version. Abra recipe will have its own tag-based versioning referring to these 2 images.
|
||||
|
||||
back to kiteflying docs:
|
||||
|
||||
- S: Not sure docs belong in either of these places.
|
||||
- S: Not sure about formalising kite-flying, currently personal. Don't want to put pressure on facilitators.
|
||||
- S: Seen reminders as part of individual responsibilities of facilitating. Goal is to get people in the room and get them talking. Complete holistic strategy of where, how to announce. Make it flow with your own style. Of we want to make a "how to do facilitation" doc, keep it light, focus on goals. If we want to make "how to find us and how to join" then we definitely need an uptodate link (calendar?). Big Shiny Button, as close to homepage as possible. Under BSB = link to calendar ICS, basic boilerplate and call to action. Remove both of the things we have now. Mention compensation.
|
||||
- c: support that idea. what about "Get involved"? and https://docs.coopcloud.tech/intro/contact/?
|
||||
- S: can't find contact from the homepage... need to click docs first, then "get in touch".
|
||||
- C: "Contact" should be one of the big links at the top of website homepage. 2× BSB
|
||||
- Q(C): is any of this controversial?
|
||||
- S: Shouldn't be, but we should give the PR a few days if we're changing the main page, out of protocol if not necesity
|
||||
|
||||
spending a few minutes working on:
|
||||
- https://git.coopcloud.tech/toolshed/docs.coopcloud.tech/pulls/322
|
||||
- https://git.coopcloud.tech/toolshed/coopcloud.tech/pulls/60
|
||||
|
||||
Check-outs
|
||||
c: good to do something during KF, hackathon style
|
||||
S: was concerned, hoping people would be on, finishing off with getting a thing done felt good! hometown++.
|
||||
|
||||
## 2026-06-04, 12 UTC
|
||||
|
||||
Sarma, d1, kawaiipunk, jacob
|
||||
|
||||
Intros:
|
||||
- some connection issues
|
||||
- bird noises on Sarma's call
|
||||
- d1 in barcelona heading to hacker village thing, well rested, no notifications in 8 days, Local-IT talk was inspiring, made me want to talk about
|
||||
- k: jitsi unreliable from one instance to another.
|
||||
- j: any pronouns, overwhelmed/low energy, dissapointed with many of the left politics workers orgs I'm organizing with
|
||||
|
||||
Topics:
|
||||
- Local-IT/DTF talk
|
||||
- how to keep motivation up, not burn out
|
||||
- Economics
|
||||
|
||||
Minutes:
|
||||
- starting with motivation
|
||||
- d: jacob, you called in with sheep and cows sometime, right?
|
||||
- j: we have two horses born two days ago!
|
||||
- d: my standard is "go touch grass", but you seem to be touching a lot of grass. Where is the motivation running dry?
|
||||
- j: so much work at the farm, little time towards what I want to do. Farm work is unpaid (family farm), financial situation is dire; no economic capacity to do the opportunities I have. Orgs that I'm part of are doing digital stuff top-down; not consulting IT members. Invited to a youth delegation to Rojava, but the orgs (radical left, workers) require a formal application a long time in advance, which I can't do. Not enough support to help me achieve their level of bureaucrac. So why bother? Wrt digital sovereignty collective, lacking space to follow up, lost potential. Not doing, thinking about it fills with guilt, saps energy.
|
||||
- S: figure out which orgs make you happy and can support you, focus your prio on them
|
||||
- d: prio of people's happiness and community care, not sure what to add, but v. important and relatable
|
||||
- j: appreciate the advice. I'll take it up with my orgs, especially asking for something the person is bad at doing. Thanks! Animals need tending, doing farmwork so the animals don't starve <3
|
||||
- d1: farm work sounds super citical important, life giving sustaining
|
||||
- S: was having a chat with mikemh about organizing a meeting of experts to discuss how infra can be financed. They wanted to get people in who have experience financing (non-digital-infra) community orgs, as well as people with experience running global federations/syndicates where local orgs can benefit from the global. (I'm concerned that with the groups proposed the topic would be too vague, and if we focus on specific questions we'd end up with very different participants). Someone in matrix said we're asking people to pay for something they get for free. And we're offering a necessary and brighter future.
|
||||
- d1 coops usually put a "coop veneer" on it but this is just like bio veg, kinda better, more expensive. this is social change and not social transformation. thr basic strucure of domination is maitained. so i think we also need to "fight" a conflict with the users lol. they are not our enemies but they somehow stand in our way because they need to do real mutual aid and pay us more.
|
||||
- S: would love to see a career path that's just getting people into collectives that can act as clients - so that service providers don't have to also provide the service of community building.
|
||||
- j: Users' union?
|
||||
- d1: we always imagined this, though it doesn't exist; multi stakeholder coop is the more liberal form
|
||||
- S: Reason I want this as a career path and not an organizational form, is that there are lots of ways to connect people - along region, ritual, etc.
|
||||
- d1: what are our interests ultimately, and why are they so divergent now? users and hosters
|
||||
- S: two visions of money, one being a marker of "here's how much I've contributed/benefitted", one being something contorlled by capital, where the bulk of money earned/spent is with capital. Hard to ask someone underprivileged, who spends most of their income to capital, to go to their farmer's market instead. We'd need a kickstart, money which can be spent into the community.
|
||||
- j: skipping the money question, could we focus on what people need? find providers for these needs (housing, food, transportation) so even without money we can ensure people have necessities.
|
||||
- S: are you proposing a barter system, or am I oversimplifying?
|
||||
- j: more like mutual aid. People provide what they can, and get what they cannot provide met themselves.
|
||||
- d: this reminds of that point that you cant make succesful economic interventions without considerin the cultural and political dimensions. interdependent fields. we should be careful not to mix what should be with what is. When speakin of money, we need money now.
|
||||
- S: Thinking of myself as a contractor, along the lines of a plumber, electrician, bike repair. The closest thing in IT is computer repair work; the smallest "leap" towards community infra. Gonna talk with a small local marketing firm to figure out how to communicate to people that I'm making this leap - that I can provide services for their friend group, or get them off instragram. Because if I can get an individual to buy a server for their friend group, I can start charging projects to the group as a whole.
|
||||
- d: these problems exist for our neighbourhood, city, region etc. i struggle to believe that this work can be made sustainable with solutions for individuals. e.g. "getting on fedi" looked like https://prikbord.page/ for rotterdam. a mass mobilisation in effect. this experiment is not finished but i am looking at it closely. i think the conversations are a really good idea
|
||||
- j: are you part of any community associations? The associations near me haven't taken me up on offers to run their infra (podcasts etc). But local associations are aware that digital infra is infra, and are open to paying me for running that for them. Might be the case for you as well.
|
||||
- S: I've tried to be, but a lot of the orgs respond with "we don't have enough to pay ourselves, so certainly can't pay a contractor" and only accept volunteer work.
|
||||
- d: that is the thing to fight in that sense - the relationship of volunteer with associations
|
||||
- S: I do want to work with associations, long term. But the work of convincing them that hiring me will be beneficial (over volunteer work) can take months, years. I need a financial base first, and starting with individual clients and working outwards feels faster than starting with associations. Once I have a base, I'd like to actually do volunteer work - not to write infra, but to do workshops and get people talking about infra.
|
||||
- d: nubo.coop got up to 100k in city funding (public). It's super inaccessible; we need a way to start that doesn't take years.
|
||||
|
||||
Closing: (what will stick with you, feedback on KF, what are you doing next)
|
||||
- j: Thanks for reading the chat out loud (accomodating I'm outside). Big topic, touched on interesting points. Want to do more stuff, but know I should do less. I'll start by making the orgs I'm part of aware I can't keep doing stuff the way I'm doing them. I'll have to get back into thinking about more stuff after.
|
||||
- j: enjoyed the format today. Might feel lonely with one person on voice and the rest in chat. But hearing a voice feels more human than reading text.
|
||||
- d: enjoyed it! Need to keep thinking about the economic question; it needs focus.
|
||||
- S: feeling heavy after the economic question. I want it to reach the ears of people who have success stories; will give more thought to supporting mike's proposal. Feeling a bit more confident in what I'm doing, trying to place my work in the context of an individualist culture without becoming part of it. But, it's still scary. Next: server work, mentoring someone on how to make oss contributions.
|
||||
|
||||
|
||||
## 2026-05-28, 19 UTC
|
||||
|
||||
3wc, Sarma
|
||||
|
||||
Sarma: chilling and grilling (vegetables)
|
||||
3wc: catching up on 100 gitea notifs
|
||||
|
||||
Sarma is a member! 👏
|
||||
|
||||
Conversation about commons.hour / economic sustainability.
|
||||
|
||||
"How do we take a product that a lot of people don't pay for and convince them it's a good idea to pay for it" a.k.a. how do we use bottom-up, collective funding strategies, and apply them to any of our groups / coöps / members. Currently brain-wrapping, what is the question?
|
||||
|
||||
https://docs.democratictech.fund/s/7c2a75d9-fb21-4bd3-a8a9-145b13225b3b/doc/economy-of-infrastructure-commonshour-LG80tBJyvi
|
||||
|
||||
Unknown status on whether FKI/DTF is hosting these commons.hour
|
||||
S: might want to touch on these topics in future KFs, if the commons.hour doesn't pick up.
|
||||
|
||||
c: will read this. If you can think of any ways that CC can help push this forward, it'd be cool if these happened. A lot of people in the CC community would be interested in these topics. It'd be cool to have collaboration.
|
||||
|
||||
Q(c): how was last week's session?
|
||||
|
||||
S: Last-minute change of format! Different venue, recording. Brief panic. Kollicloud is a cool thing! Tech: alakazam, refined into ready product.
|
||||
c: really interesting they're targetting associations rather than cooperatives.
|
||||
|
||||
S: Better word? "Collective"? "Community"? Solving process problems of an Association, easier than companies (or other non-association).
|
||||
|
||||
S: Social/economic aspect: 3 options, self-hosting, community hosting (hybrid approach, federating with Local-IT), managed hosting. Community / hybrid has been floating around in Co-op Cloud community, Kollicloud is the first write-up I've seen.
|
||||
|
||||
c: wondering about it in combination with what we discussed 2w ago, of contributing your compute to a group you're joining. Different ways of collectivizing - sysadmin and the service provision
|
||||
|
||||
S: Agree it feels connected, hard to define.
|
||||
|
||||
### Permissions
|
||||
|
||||
S: Chat with d1, explaining "optimistic merge" approach of encouraging new contributors, let them break things -- rather than making people go through a long process. Did similar with own infra recently: radicale crashing every few days, gave a friend root on server, "try and fix it".
|
||||
|
||||
3wc: Anything outstanding?
|
||||
|
||||
S: Fedi
|
||||
|
||||
3wc: Uhh I lost the password. Let's ask the federation.
|
||||
|
||||
S: "Radical trust" compared to usual IT interactions.
|
||||
|
||||
3wc: in opposite situation in some groups. Improving opsec, partition access. So not everyone in the org has easy access to the full contact list. Haven't heard any good answers. Permissions for everyone else + permissions for tech admins. Admins don't operationally need contact access, but since the -
|
||||
centralization of access/security assets based on tech skills. Maybe we can expect tech people to be more careful, but it feels weird from a decentralization/democratic perspective.
|
||||
3: a lot of the systems we work on tend to inherintly centralize to who has admin access. With CC, we operate in the open and (almost) everything we do has a version history. In our threat model, it's not a bad thing if random people get info from our servers. So radical trust makes sense.
|
||||
3: The usual IT interactions don't solve this either. Even if you have 10k layers of access cntrol, sysadmins can still do anything; tey're exempted.
|
||||
|
||||
|
||||
S: Definitely something I've felt. Weird disconnect. Historical anarchist perspective, organising during the development of tech. Pre-encryption comms: sending message to 2 people (redundancy). No-one in the org has a full list. 2 copies of every message. A lot of systems make the assumption that centralised power is a good thing (corporate context). Wonder if decentralisation of power/access requires the lowest layers of communications to change… or can it be done with the way things are working now? Merri-bek, Lores — for a different purpose, but also a lot of small machines. Maybe a central system currently, but aiming at fully-distributed? Sysadmin can push software changes, push those through the network. But what if they only have knowledge of the 2 nearest nodes? Make a fix on my laptop: instead of deploying in once place, send out across other places, propagated to other servers?S:
|
||||
|
||||
3: curious what the capabilities of p2panda are. Agree there's something in human-powered redundancy/partitioning practices that could be useful for inspiration. Don't know if feasible to apply these practices to client/server model. In our labor union, we wanted to split a key to open a door between multiple people - to enforce a rule of doing something on the server with someone else. To prevent me from downloading the entire member db, I can only access the server when someone else is there. But we couldn't figure this out - wherever the key is entered is the weak point where one of us could grab the other part of the key. Analogy: box with multiple locks, that will only open when everyone with a key shows up.
|
||||
|
||||
S: Still looking at a system where a minority can access - 2/3 people who need to bring their keys. Parsing threat model: union = membership status dangerous to leak. But still need to verify membership status for login etc.
|
||||
|
||||
3: another layer: part of the union incoporates a lot of incarcerated members. Threat model, beyond the normal threats of union membership status being revealed, these groups end up categorized as prison gangs or other bs. So only people in the incarcerated members group should know who is in that group. But everyone's membership is in an CiviCRM instance - in an SQL database. Architectural problem: admin access to the system means you have ac
|
||||
|
||||
3: in a kollicloud style federated hosting, how can I help administer your server without being able to download your users' data?
|
||||
|
||||
S: Laptop-sharing situation: we are storing data that's not meant to be shared. But e.g. someone's roommate could come in and grab the data. Our solution: encrypted VM, which cannot be started unless someone who knows a password accesses from outside and starts up the machine. If you had that sort of solution on a database somewhere: separate, airgapped machine which has specific members of incarcerated group, could you make it so that when someone accesses server and does any work on it, that connection gets broken, cannot access that particular DB? Impossible to do work on server while connected to that DB.
|
||||
|
||||
3wc: So some kind of maintenance mode?
|
||||
|
||||
S: Similar to our case: protected from accessing inside of VM without password. Difficulty there: if someone restarts machine / takes out HD, could open it. Hence encryption, but where to store key?
|
||||
|
||||
Closing:
|
||||
3: a lot of enthusiasm about doing a multinode demo on a KF sometime
|
||||
S: really busy, but eventually will do.
|
||||
|
||||
## 2026-05-21, 12 UTC
|
||||
|
||||
attendance:
|
||||
|
||||
Reference in New Issue
Block a user