Great. Yeah. Sorry for the old, the usual show. I'm sure you're used to it now. Great
to see so many people here. Amazing. Thanks for your interest in the Co-op Cloud. Yeah,
I'm decentralized. That's my internet name. And these are my enterprise slides for the
Co-op Clouds. So I've been working on this project now for, yeah, maybe two to three
years, I would say. So there's a lot of knowledge of the project, how it happened, and what came
to pass locked up in my head. But I am only one person involved in this project, what has now
become quite a wonderful project, I'd say, which involves a lot of different collectors, a lot of
different groups. So yeah, this is just kind of like a moment to offload what we've been up to for
the last two years. And yeah, all the hot takes are mine alone. Some of the images are taken from,
yeah, shout out to fellow worker Trav, the internet gardening collection on Arena. I totally
recommend checking that out. It's great. So yeah, Co-op Cloud. This is the official website ready
description of what the Co-op Cloud is, a software stack that aims to make hosting Libre software
applications simple for small service providers, such as tech co-ops who are looking to standardize
around open, transparent, and scalable infrastructure, which is a lot. So I was thinking, how am I
going to explain this? Because we come straight in with a software stack, but actually, it's much
more than that. I think you could argue our project is more a social endeavor, social organizing,
more than a technical thing. But of course, they're overlapping. So I thought, well, okay,
we'll just go back. We'll do a history lesson on how the project started. And I feel like that is an
important angle for introducing the project. So I want you to understand where the project is
coming from. And then maybe you feel welcome to join the project and shape the future of the
project, right? And I think this historical view on where things are coming helps to ground the
project in an actual need, human need. There's a lot of software projects out there that are just
like, why does this exist? But we're trying to show that this is socially useful and why we have
come up with this project and initiated and tried to make it work is based on what we needed at
the time. But that may necessarily be the case in the future. So yeah, put that to one side. And let
me introduce you to the magic brain of autonomic co op. So these are some people in the cop. There's
me on the banjo. That's not all of them. There's 13 of us. As far as I remember, we have a new
website that was just put up last night. So check it out. It's hilarious. I don't know if I can
get up here, but I'll try maybe at some point. So yeah, we're a technology cooperative, a worker
owned cooperative. That means the people who work in the business own the business. It's run and
managed by ourselves. And that means we're, yeah, this is like, you know, we when we come into where
we work, we have the chance to make decisions about every aspect of how the workplace runs. So, you
know, what kind of work do we want to do? How do we want to make decisions? How do we deal with
money? How do we find new work? Who do we want to work with? Another member wants to work with this
group, but someone else disagrees with that. How do we work this out? How do we deal with conflict?
It's kind of an end to end workplace situation where you have the chance to, you know, be involved
in every step of the process. And of course, you don't have to do that alone. You can do that with
your friends. So that's the kind of model of the cooperative. Yeah, and one of the kind of,
yeah, I'll come back to the website maybe in a bit. But so one of the ideas behind what a cooperative
is, is this listing of cooperative principles. You can see them on the right hand side there.
For example, autonomy, independence, you know, economic participation of the members,
open voluntary membership. These are kind of like non-binding principles of what it means to be a
co-op. Principle six, for example, that you will work with other co-ops. So, you know, we want to
expand cooperation in the ecosystem of groups that are trying to do this as well. And a lot of
these hinge on actually having money to survive in order to practice what it means to be a
cooperative. So we're a technology cooperative. And what do we do exactly? And you could kind of
say we do basically everything and anything like we would happily develop a new piece of software,
but we'd also come to your house and fix your toaster. We, you know, we try to work with people
that we want to work with, that we want to support, that we like their work, or that connect with
our values. And one of the things we've done quite successfully, in my opinion, is to run a free
software step internally and for the people we work with. So we have like, you know, all the
things we use our free software. So we're pretty good at that, managing our own internal infrastructure.
And so necessarily, we would then just offer that to groups, like, do you want a website? Do you want
your own chat system, like a matrix, or do you want a wiki, or do you want an xCloud, or whatever
this kind of stuff, this classic hosting situation. And one of these problems that has come up,
Autonomic is running like several years now, five years or so, is that it's difficult to make money
out of. People are used to just getting stuff for free for very understandable reasons. Big tech.
And at some point, you know, we want to scale out the code, we want to involve more people, we want
to be able to make a living from it, we want to be able to survive, pay the rent and so on. And
then we started realizing that, okay, actually, we're making more money, or people are happy to
pay us more when we are doing support. And this is talking to people, getting on a call and being
like, what is software, and then talking about it, or what is a wiki, everyone's saying wiki,
I don't know what a wiki is. And just having a chat about it. But then also, being around later,
so once they ask for the thing, like an xCloud, you set it up, and then you don't disappear because
you're a cooperative, and you intend to continue. So sustainability is one of the core principles.
So we stick with them, we chat, we're contact on mail and so on. So this is kind of the dilemma
of like, we want to definitely do more hosting, because people need digital infrastructure to
do their work. This is just like a base layer of how to organize things. But it's difficult to survive
as a technology cooperative, only doing hosting. So you need to like expand what you do.
And one of the places we ended up was using Cloudron, which is a kind of like,
one click install open source system, which I would still recommend. It's great. It got us really
far. A lot of the next slides criticized us. So I'm just going to say it's great on this slide.
So you can see like, you have your classic selection of open source apps, if you're familiar
with that stuff, like Rocket Chat, for example, we use Rocket Chat to communicate where, you know,
in the co-op. And what this enabled us to do was basically work with different groups that may not
necessarily have money to support us, like to make it sustainable to work with them,
but still support them to do their work. And Cloudron was like a really kind of like,
get out of jail card in that sense. It was like, okay, I can just like hit five times
on this WordPress button. And we've got five WordPress sites and people are going,
they're posting, they're organizing, they're working, we're supporting them. It's brilliant.
You know, and for those that don't know, Cloudron is just like, you fire up a server,
you SSH into it, you run a command, it spins up this thing. And you're going, you can install
multiple apps on the same server. So this really reduces the costs for rolling out digital
infrastructure. Let me check time. Sorry. Yes. Right. So yeah, remember I said at Cloudron school,
but at some point, the core of the product, the front end, the web front end became proprietary.
So they made a switch. In some sense, I can't blame them because, as I said, if you want to
survive, you need to make a book and you need to pay the rent and so on. But yeah, that made us
nervous. You know, when we work with people as a cooperative, we want to say, we'll be around
for you. We want to continue. We want to do this sustainably. And if you remember one of the
principles is like our independence, like how, like, can we exist in this world? You know,
there's, of course, interdependencies, but like, can we continue to do what we want to do
without relying on one specific thing? So when this, so Cloudron made the decision to make the
front end proprietary, you can still use it or whatever. It's a great system. But we thought,
oh no, what's going to happen? And then we started looking a bit deeper. And we realized that
Cloudron, when you click and install an app, the apps are, yeah, they're, it's an image. So it
uses a container system. It's kind of like a light virtualization layer. They're packaging
all the apps themselves. So the people who work in Cloudron Inc. or whatever, when they want to
provide a new app, they say, okay, let's make a new Git repository and let's package this thing.
And that's great. And it works really well. But then we realized that they had packaged,
I can't remember specific apps, but take, for example, NextCloud. They had gone and some
worker in Cloudron had packaged NextCloud. But then we went to the upstream NextCloud repository
and we saw they had provided an image. And then we thought, well, why aren't we just working with
them? Because that would, you know, connect our values of expanding cooperation in different
layers of the software stack and so on. And then the more we looked, we realized that free
software communities were really converging on the idea that you have a packaged image inside your
repository. So you're hacking on your source code, and you just have an image that's building.
And we can use that. That's what Cloudron needs. So we were like, okay, that's interesting. Maybe
let's think about that. Yeah. And then the kind of like, the end of the, the logical end of the
paranoia or whatever it was that like, we have, you know, we're relying on this one company,
this one group, you know, autonomic is a cooperative that supports maybe 20 plus groups,
but like a large selection of them have very little money to pay for the infrastructure.
So if you can imagine that Cloudron would somehow make a bigger step into more proprietary
solutions or somehow increase the cost or who knows what, we'd be in a position where we can
support those groups. And that's not something we wanted to, to deal with. So we, we started to try
to think like, you know, we're a co-op, how do we make this better or whatever. And that is the
start of call clouds. So now we're getting back into another take on that original really long
sentence that had things like software sack in it. Yeah, we were like, let's just eliminate this
issue of proprietary, you know, angles or whatever. Oh yeah, here's where I just couldn't get the
emoji in the slide. So I just gave up. I, yeah, we're just like, we'll just copy left the entire
thing. Let's just do that. That seems sensible. Cool. And then as I mentioned, yeah, you have
a little favorite emoji. We want to work with the upstream developers of the software because
a lot of precarity is in the open source ecosystem and that there's, you know, certain
developers which are doing unpaid labor to develop the software that a lot of us rely on.
And they're providing these, you know, a lot of them are providing these packages and we thought,
well, okay, we can just meet them where they're at, engage with them on the issue tracker,
you know, speak to them, make them aware of our hosting efforts. And, you know, we're, we're in
a sense like closer to end users in that, you know, it's like developers, posters, users,
you know, summarized and often developers, well, they've got their hands full trying to
make the software work so we can like help that connection. So we're trying to bridge that in
that sense. And also, which we'll see later on, they're also providing, so they're packaging up
their apps in images, but they're also providing this kind of extra configuration around it,
which kind of tells you how to deploy the thing, which is great for people who are doing hosting
because, okay, we have an app, but does it need a database, for example? So what, database?
But they're also doing that for us as well. So if you develop open source software, thank you.
Yeah. And then the democratic governance. We were going to initiate this project,
let's say. I wouldn't say we like invented it, we just like collude a bunch of stuff together.
But we wanted to not be in control of that. So not become the new cloud run, which is like,
okay, let's set up some clear rules for how do you interact with this project and also
on what basis are you also a technology cooperative? Are you an open source developer? Are you a user
of this software? Do you want to support the host or do you want to support the... We can
start to engage with it where we're at, but meet in this kind of common project. And obviously,
the goal then is to sustain open source digital infrastructure and expand cooperation.
Yeah. So moving out of the kind of history phase and now into what it actually is.
Yes. So this word kind of pops up if you've checked the website or the docs,
democratic tech collectives. So what is that actually? Autonomic is a... We're
probably registered in the UK. We're publicly regulated. We're a cooperative society.
We have gone through the paperwork to make that happen because we wanted to do that.
But we recognize that not everyone will want to do that or be able to do that.
And this really depends on a per country basis. If you're in the Netherlands,
it's a different model or if you're in the UK, the way you relate to the legal system and the
state is like... In Germany, it's quite difficult. I've been told there's no way to
kind of just slot yourself in. It's not very easy to find information.
And we don't want that to be a limiting factor in working together. So we were trying to
conceptualize this idea of what other groups would we be willing to work with but not close
that definition down from the outside. So we were thinking about other groups who want to work
with their friends or together with other groups and have set up decision making, for example,
collective decision making. So they're able to navigate what they want to do together.
That was kind of like a thing we wanted to do. We wanted to be able to interact with each other.
We wanted to be able to disagree and receive and send constructive feedback, reach compromise,
stuff like this. This is kind of easier to do when people are already organized in their own groups.
But yeah, this didn't really rule out individuals who are active in the project at the moment
and also other technology cooperatives. We're kind of just trying to saddle through it somehow
and be like, just work with us. Let's figure it out together. And this is already in progress.
This has been in progress for some time, the formalization of what this means. And that's
an open process, which would love to invite you to come check out. The configuration commons,
this is a, so as I said before, we have open source apps that we can package them in images.
And then we can specify a configuration around those images to describe how that app should look
like in a deployment on a server live and well, people using it. And one of the things we know
is was that the, as I said before, the configuration that was being provided by the upstream repositories
was useful, but it didn't specify the full end-to-end production kind of scenario.
And that's kind of a big word, but for example, how to back up the app data. Like the thing is
deployed, people are using it and we need to make sure their data is safe. So we need to back it up.
How do we back the thing up? How do we restore it? This is kind of like a step from it works to
it works and it's safe for these people to use it. And we wanted to encapsulate that into our
configuration. So this is a big part of it. We'll go through each one of these deeper. I'm just
going to overview them now. Yeah, ABRA is a command line tool. So our own digital tools, we wanted
to be involved in how the tools are shaped and how we use them. You know, that's a great situation
where you're dogfruiting your own system with your peers and you're trying to figure out how does
this, how does this, you know, best suit us, you know, and according to our own constraints,
you know, we can't spend all day learning this obscure system or we can't, you know,
invest too much time in some things. So we need to cut corners and it's best to be involved directly
in that process. So, yeah, and if we remember back to Cloud Run again, sorry, I'm not going to be
bashing them at all. But yeah, like, how do we interact with the system? In the case of Cloud Run,
it was a web front end. But if we're talking about interacting with technology cooperatives
and other tech collectives, there's kind of a difference to begin with because Cloud Run is maybe
trying to provide for the, say, let's say, non-technical user or someone who can just kind of get
in and click a few buttons or whatever. But we're already dealing with groups that are actively,
like, you know, deeply involved with like Linux system administration and so on. So do we need a
front end? So those are the kind of questions we can ask and answer them ourselves in those moments.
And the collective infrastructure. So there's a lot that goes on in between getting an app out
and someone using it. You know, people have to meet each other and talk and who are you and
what's going on and what do you do and all this kind of stuff. And then money. Where does the money
go? Who, you know, what do you charge? You know, it's just this end to end, all the social process
that go in and around that. We wanted to build those up too because that is a huge problem when
you're starting off as a collective and you're like, oh, no, where's my bank account? Like, how do
I get a bank account? And you can see like open collective, for example, doing this, just like
mutualizing this financial infrastructure and just getting people going. So yeah, docs, yeah,
get hosting, get off GitHub. That's cool. Stuff like that. So I'm going to go through these a
bit deeper. Yeah, we're trying to form so we're our proposal at the moment as autonomic, which is,
yeah, now I can say the sentence and I hope it's a bit clear. We initiated this project and we're
deeply embedded inside it, but we're attempting to step out of the project and reenter on an equal
basis with other collectives. So in order to do that, we're proposing a federation model, which is
based on a great project called Co-op Cycle, if you've heard of it, but basically different groups
can interact with each other. There will be democratic decision making and yeah, some laws and
we'll come up with a constitution together and all this kind of stuff. I couldn't fit in on this
line, but it's not just chaotic nerds, it's also open to, you know, we can imagine the people who are
using the software grouping together and joining our federation as well to say, hey, this button
should be over there. Could you just fix that? But in a more collective sense, like we could be
gathering money, we could be figuring out how to improve things, you know, you don't have to be
able to just write software to join this kind of stuff. We could be, you know, connecting the
different struggles to build up like a better open source ecosystem. So this is a process that's
going on right now. There's invites going out. We have a new round of private funding. Thank you
private funder and yeah, there'll be more news. But check the website if you're interested in this,
if you're also part of a collective love to hear from you. This is a massive problem that we, of
course, experiences being sys admins. And we've seen a lot of people join in on the old matrix
channels. And, you know, that'd be one person setting up a few apps for friends, family, maybe
their local community, food co-op, what have you. And then a few months down the line, it's
completely overwhelming. The email broke, you know, or it doesn't do this, or who knows what. If you
do any sys admin, you'll know the story. But when you step into the co-cloud project, you have this
chance to meet your peers who are also doing this work. They may not be involved in your project
whatsoever, but that's not important. We have this idea of the config comments that means we can
share work on the, again, the next cloud recipe, that's what we call them, we'll come to that in a
bit. So we can work together on the same configuration. And that means we're sharing tips,
tricks, we're talking together, you know, it's like this group of users wants this, do you want
that, oh, I tried this, you know, this kind of stuff. And this is really, yeah, this has been
seen to be like a great feature of trying to just like open the door for people to come in and
work together. Because there's a lot of tools that propose reuse and kind of mind share and a, you
know, collective point of reference, but don't really live up to that, you know, the ideal of
reuse, just not doing it again, you know, repeating yourself. So we were conscious of that, we're
trying to work on that. Yeah, folks on training collaboration, so we wanted it to be easy to
onboard, we want more democratic tech collectors to pop up, we want more technology
cooperatives to be able to start, we want people to be able to decide, I want to own and run my
own workplace, and I want to, you know, bootstrap some infrastructure for groups, I find cool in
my city. And that's what called cloud is about, it's like a tool set for these people. It has to be
easy to use, of course, and we're very focused on that public, so groups who have already decided
that that's what they want to do. They're on the terminal at the moment, we only have the
terminal clients, and they're, you know, they're getting into that, you know, we can't do
everything for everyone, but we can definitely, with that public in mind, we can, you know, be
focused on how we attempt to make it accessible and usable. And yes, cooperating with other
networks, so we want to, you know, within our network, of course, we want to have groups
join, but for the groups that don't want to join, we still want to work with them, if they
have the same values, if they're doing similar things, we can also interface with them. And we've
already seen that happening, and I'll come back to that in a bit, but, you know, once things are
clear, and they're getting clear, like we are a group of cooperators, we have this configuration
columns, we have these tools, we're just like specifying what we are, then it's easier for
other groups to say, okay, I understand what's happening here, and I would like to do this
with you. So there's kind of like, you know, a concrete example, find funding together.
So, yeah. The concrete commons, yes, the open source apps you love. If you, it's this
catalog of software that is out there, and people are developing the next cloud, the
media wikis, the seen apps, the GTIA, the whole thing. So we have quite an expanding
concrete commons, so you can, like, deploy a lot of apps. So that's the thing, like,
people come to us, and they're like, oh, I need a calendar, or oh, I need, you know, a
note-taking app, or whatever, and then we're out hunting in the open source ecosystem for apps
to add to the catalog. So that's that, then the, yeah, so to come back to the, you know,
this, again, this idea of the image is the app, which is the packaged thing, and then
the kind of wrapper around that, which specifies the end-to-end kind of how they should look
in production. And we were conscious to not reinvent a packaging format, and we didn't
really know what to do at that point, because we thought, okay, we need to be able to say
how, you know, in one file, let's say, in plain text, a config file, like, here's the
app, and how do you back it up, how do you restore it, how do you take it down, how do
you bring it up, how do you configure, how do you plug it, you know, this kind of stuff.
Yeah, and as it turns out, the Docker compose ecosystem and Docker has kind of been moving
towards the compose standard they're calling it, and it's basically, yeah, if you've ever
seen the Docker compose file, it's a YAML text file, and it kind of just specifies what
we're looking for. So we just figured, great, upstream developers are already using this,
this is a developing open standard, great, let's just build on this. And I think as it
turns out, that was a good choice and has had many benefits, which we'll come to on the
next slide. Yeah, so we're working with upstream developers, and yeah, we're, so in my background,
I've done a lot of configuration management tool, like for example, working with Ansible,
which was always the grand ideal of reusing roles, if anyone has been, has used Ansible
before, it's kind of like a packaging format for, you know, you have a server and you want
to install like Apache on it or something, and you tell Ansible, install Apache for me,
and then you want to install the new thing, and then you kind of package this into a role.
And at some point, I realized that everybody is writing the same roles, there's like, it's
very difficult to like share and to reuse other people's stuff. It's definitely happening,
but not on the scale that I was looking for, and so I was looking for alternatives. Yeah,
so in the project so far, we've seen people like we have, for example, matrix servers,
Synapse installs, we've seen multiple collectives look at the config and say, this works for
me, I'm going to use this, and then changing the config in collaboration with other groups.
So we're already seeing that people are able to make the changes that works for them without
breaking other people's installs. And then when things need to be worked out, they speak to
each other and things move along. And again, the compose standard really helps here in
that it's quite flexible and helps us, people can move around each other inside the configuration,
which will hopefully become clear on the next slide. Yes, great. So we're calling the app
configuration a recipe, cooking inspired. And it's a good repository. Here you have git
t, git t, so I don't know. And it's a bunch of config files. And as a collective, you come
here and look and say, okay, this is the configuration which specifies, you know, how this
thing should look like in a deployment. And kind of one of the magic source of this format
is that if you've ever used, I think it's a Docker, I think it was a Docker compose
command line client, you can kind of chain the compose files. So you can say like Docker
compose op, compose.yaml minus f, compose.some other thing.yaml. And the system will internally
merge all of these configurations together and then roll out the app, which I never had
occasion to use until I realized that maybe somebody wants to use Postgres and maybe someone
wants to use MariaDB. These simple choices for deployments, if it's not possible to kind
of like make this easy to do between different groups, it would never work out. So very,
very thankful to the people who wrote this standard. So you can see here, you can kind
of, and it'll become clear when we talk about the command line client, you can kind of
specify, okay, I want MariaDB and I want the SMTP config bundle all together, roll it out.
And I don't want Postgres or I don't want this or I don't want that. And this allows
people to just expand the config to suit their needs, document it, let people know this is
a new feature. So it's quite nice. You can be just hosting some software and then somebody
says, oh, great, open ID connect now works with this, just load this thing in. And you
know, this is really helping us move forward and get things done. Yeah, at the moment,
we have a command line client called Abra. And this is the kind of day-to-day interface
for how you manage your cloud cloud install. So you have a server, you deploy stuff to
a server, you're using Abra on the command line. And that was a real, that was a large
decision for us at the time because we didn't have much money, we didn't know if we would
be able to pull off a web front end. And again, as I mentioned before, we were trying to
target specifically like, who is the public of this project? Are they people who know
and are comfortable on the command line? Yes, okay, let's just go ahead with this and try
to make it work. So we wrote in Bash the first one and I still completely recommend it,
just unleash your inner Unix. It was great, it managed to get us to, you know, zero to
hero in relatively short amount of time and have a system that was working. One of the
kind of core ideas behind developing our own tools, we were very conscious that we might
fail, won't be able to get it done. And we wanted to have that, the conflict commons would
kind of live separately. So these would be kind of not interdependent in a way that if
one broke, the other would break. So if you even today, if you just ignore that Abra
exists, you can still drop into the command line, run a bunch of commands and roll out
the app, which is great. And that's kind of how we originally conceived it with the Bash
system, we're just running a bunch of commands. And we had kind of like laid it all out in
a way that kind of said, okay, you can just push that out. So yeah, thanks to Kalex,
a fellow worker who's great at Bash programming. We wouldn't have done it without them. Yes,
so then we read, wrote and go, we actually managed to get some funding, which will come
to you after, I guess they're not Bash programmers, if they read the source, they might have
felt otherwise. But at that point, we were running into issues with the Bash implementation,
which we felt quite proud about that we had like gone ahead and found the limits of the
simplest possible thing that we could do. And the issues were it was difficult to install
on multiple systems. It relied on a number of built in commands that were not always
available on, you know, like a Fedora, Debian or whatever. So yeah, portability. We were
struggling with we wanted to kind of develop other aspects of we like we wanted the tools
to be able to speak to the conflict commons but not directly pairs each other. And that
ended up being a kind of like JSON catalog, but then pirating data formats in Bash is
difficult. So we were we're kind of pulling our hair out on that one. And then concurrency,
we were struggling to manage horizontal scaling. So if you have worked with 18 groups, they
want to have their own VPSes. If you have 10 servers, you know, the tool has to like
fire a request to each 10 of them or whatever. And then if it's going through each one at
the time, you have to wait. And as a result of kind of scaling up and using this absolutely
pre alpha software and autonomic for production purposes, we reached the limits of the software.
So we ended up rewriting it and go somebody knew go in autonomic at the time. That's the
reason. But also, we saw that it was really, you know, we could get this concurrency issue
sorted and the portability. So go kind of gives you a language level feature that it's
like quite easy to say like fire across these 10 things immediately. And you can build
a binary so you can just fire them out. So people just get like a binary on the system
and the stuff is all baked into it. So the new problem with this is that it actually
works. It does what it says and people are starting to use it. So we're now into this
kind of maintenance cycle. It's kind of approach. We've done the public beta. So people are
using it and starting to rely on it. And we've seen people hacking on it and submitting
pull requests and checking it out. And it's all good. Yeah, so in essence, ABRA is a
Docker swarm client. So no, we don't run Kubernetes. We run Docker swarm and no, it's not dead.
Docker swarm is a technology that is still alive. We're kind of we have like a strange
parasitical relationship with like some installs, like some banks have like a swarm install
of like, you know, 10,000 nodes or something. And the current owner, I believe it's Marantis
or something that's been in exchange of who owns it or who I can't remember. But we're
it's still being maintained and we're happy to see that it is being maintained because
we identify that swarm mode in Docker is kind of the appropriate feature set that we need
without having to deal with going into learning how to, you know, roll out a large system
which is built for like large scale. Our, you know, and again, this is like what was
autonomic doing at the time was like rolling out single servers deploying a few apps,
no greater than like 10 to 30, 50, 100 users or whatever. And swarm mode provides you with
the ability to kind of roll out the app. And if it fails, it'll roll it back for you.
And we can bake that into our config. So we were kind of getting the stability guarantees
that we needed. And not a lot of groups were demanding, you know, when they had like a
media wiki installed, they weren't saying there must be 99% uptime in this contract or
not. But we still wanted to push that to the limit, like a high quality, stable service
when we're rolling stuff out. This should be, yeah. And then, yeah, the swarm mode just
covers that for us, the runtime, the Canadian runtime. So yeah, this is a kind of like the
architecture, let's say. So on the left, you will install Abra, for example, on your local
workstation, the command line tool. And then you'll via SSH kind of tell Abra to manage
this server. So it'll read the SSH config and it'll connect to the server and say, okay,
recognize this server. I see there's a Docker demon running on this and it's got swarm mode
enabled. Cool. And then it can, you know, you can do this horizontal scaling where you can
install servers. So you can load multiple servers into Abra. And then you can be sharing the
Abra state between multiple people. So in a co-op of 13 people, you know, each one who
runs Abra app, so whatever to list the apps and the servers, we'll see the same state
come out. And we can go into that a bit later. So yeah, it's built for basically collaboration
in the organization that you're in. And then the other mode is you install Abra directly
on the server and it stores the state on the server, which could be useful if you're,
yeah, for specific scenarios, this was requested. Yeah, some people run this, I don't
know. Yeah, and then the final points. Moving on, collective infrastructure, yeah, docs,
git hosting, recipes.coop, cloud.tech, you can see the list of all the apps we have. We
have an open collective, which is the fiscal host is autonomic. Bank account in the UK.
And that's been nice because we've been able to, once we got the funding, we were able
to tell people, if you work on this, we can pay you just immediately. Anything you do,
you'll get paid. And that's great because we know there's a lot of unpaid labor going
on in open source world. So we didn't want to be a project that said, you know, contribute
to our comments and get nothing back. No, we could actually pay, you know, so we set
like an hourly wage there and we said, this is how much money we have and away you go.
That worked out great, I would say. And the server firm, server's co-op, so I wanted to
plug this other project that's, you can go to the website, servers.coop. Yeah, we've
been working with a group who've been developing software called Capsule, Siberia, great
hackers, and they're trying to develop a system. Well, they have developed a system,
which is basically a server provider infrastructure like Hetsnure, for example. So VPSs, you know,
I need a server to roll one out, I need another server to roll one out. And then we, and a
couple of other people, myself included, were thinking, okay, this is great because a lot
of collectors are centralizing on Hetsnure VPSs, right? And if Hetsnure rolls up the
price or, you know, we've already seen this with the increase in cost in IPv4 addresses
and the 10% increase this year, it's getting more costly to run on Hetsnure, but it's
always been super cheap, and that's been super accessible. But it could change, so what do
we do? We need to build up this aspect of our stack, so we kind of like expand the
cooperative layer down to the servers, and that is the idea behind server's co-op. And
ABRA already supports an integration, so you can do, like, server-new, and if you've got
a capsule running on your server, it'll spin up a VM. So we were already trying to, like,
you know, just take a turn into cooperatively managed infrastructure and build those
integrations from the stack. Whether or not they're working that great is for me to be
seen. Yes, so European Cultural Foundation gave us upwards of 30 grand in funding last
year and the year before, in the context of the Culture of Solidarity Fund. That was
amazing, thanks to them. They were really great, and I would recommend applying to them.
They supported us the whole way through. It was, yeah, just fantastic. We wrote our
application and sent it into them, so pretty happy with that one. Great. Nearly done. Yeah,
I want to just jump, so this isn't vaporware. Again, I want to plug, like, I just find it
so important to explain that people are actually using this, and this isn't just, like, some
idea in our heads, and we think it's cool. It's like, people are actually running, you
know, they rely on some of the things that have been deployed. So Lonely Duck Space is
a project which is about, like, 13 apps, I think, on a server somewhere, which was
initiated by an artist collective called Ron Grupa, which is, like, an Indonesian-based
collective in the context of documentary. And they wanted to kind of approach a group
that connected with their values. At some point they were, so they were invited to
document it, to do the work, and they thought, okay, we're all the way over here.
In Indonesia, we need to work with people who are based in Europe, so we're going to
need digital tools, but we don't want to be immediately going on the Google drives of
the world. So how do we build up, you know, extend our ways of working and our values
into the digital realm? So then they came looking for collectors and co-ops, a friend
who was through to them. Yeah, and here's just some photos of us just engaging in this
massively multiplayer shared infrastructure project. So it was really great. People from
my perspective understood what Core of Cloud was and the mission behind it, and felt
invited to kind of look at the technology and what we were doing and comment on that
and give this critique. You know, we're often in a space where people want to talk about
digital tools, but the first thing they say is, oh, I don't know anything about technology,
which is kind of like a hallmark. You have to excuse yourself or something. But we got
past that in working with this group of people that may not find themselves technical, but
as we moved on, again, Core of Cloud allowed us to just kind of deploy the tech and just
like, just forget about it and then go on with the support work. And we ended up with,
like the last great thing I saw from this project was the people involved in using the
tools were publishing videos about how to use the tools in the stack. So they were like
in the Matrix Chat and on the PeerTube publishing. Here's how you use PeerTube. Amazing. Great
educational practice. Totally check it out. TV.Lumbung.Space is the worst I've done.
Yeah. This was another project we met kind of in the context of Documenta. So this is
a comic group. Aircraft is a comic illustrator's union, which is bootstrapping at the moment.
And they felt, you know, they saw Lumbung.Space and they were like, this looks cool. And I
like the idea of what is going, you know, I understand what is happening here. There
are two groups cooperating here, this kind of like cultural based initiative and this
technology collective. And, you know, I can see the Cloud Cloud website and this looks
like we want to check this out. So we kind of got over that fear and anxiety and moved
through the money exchange and, you know, let's work together. It was quite smooth.
So I would say Cloud Cloud is then helping us just again put these things to rest like
this is the project we're based on, you know, when we work, when we deploy your infrastructure,
it will be contributing to the commons, copy left, democratically managed, you know, you
kind of just get over the hump. And yeah, Kotec is a new co-op which is set in Poland
and that was a major boost. So they've deployed a bunch of services. Some members are in the
room. Super nice. Yeah, it's a software stack which is in its, you know, initiated and developed
by cooperatives. So it should suit other cooperatives. Of course, if you want to start a new technology
cooperative, how do you start? It's overwhelming. But now you've got this off the shelf project
and it's like, get going. And once you enter it, you just see all the other collectives
and you're like, great. We can learn. We can share. And again, it expands beyond the technical
so we have the infrastructure for payment and bank accounts and all this stuff. So people
can really get moving fast, I think, is good. And we want to expand the, you know, we want
people to start technology cooperatives, start technology cooperatives. Yes, Enterprise Matrix
21 collectives. Somebody counted them. Maybe it was me at some point. But there's a lot
of groups involved in this. You can, if you go on the website, it's in the blog post,
a list of them. We've got 160 plus recipes. This is a lot of open source apps. You can
probably find what you need in there. And yeah, we're running 146 apps. I think I ran
Abra app LS at some points. So I don't know because heavily invested in this. And there
are other collectives which are running the stack. Yeah, and maybe just kind of coming
to the end. It's been a lot of details. I'm even overwhelmed myself. The last few slides,
kind of philosophy take, you know, we wanted to be another project in the ecosystem and
not just become the project in relation to decentralization, let's say. We really posit
ourselves in, you know, against kind of this like big tech discourse and what's happening.
And we thought we could contribute to, you know, internet and digital infrastructure
decentralization by proposing Call of Cloud in its form. And we're only one project. So
I thought it would be good to plug some other great projects which I just find super inspiring.
I think, like, I would say Unohost is like maybe one of the gold standards of community
organized infrastructure hosting. It has a different kind of set of priorities and goals.
You know, everyone can be a system administrator. It's kind of their goal. Like, you know, let's
make information available to people. Anyone can do this, get going. Brilliant project.
Whereas we're going for, you know, specific groups, co-ops. You're already in the game.
How can we make it easier to keep going? So it's a bit of the different layers. But absolutely
recommend Unohost. Nubos based in Brussels. Check them out. Chateau's great network.
Cotech is a network of cooperatives based in the U.K. I think it's like 35 cooperatives.
Check them out if you're looking for a job, get stuck in. Social co-op, trying to build
cooperatively managed, master on instances, local IT, great collective already based in,
yeah, being involved in co-op cloud at the moment. Small technology foundation. Always
find inspiring. Check that out. Small tech. Just plug in them. Yeah. Oh, five minutes.
Cool. The roadmap is, yeah, as I said, building the federation. So now is a great time to
join. You know, as you're, you know, again, as an individual, a collective co-op, please
get involved if you want to. We're trying to find more money, of course. One of the goals
of the federation is to kind of achieve financial sustainability. So the co-ops that join or
the groups that join the project will be, you know, we're going to have to decide, all right,
how do we fund development of the tool? And can we pay for hours around finance, admin,
cash, just, you know, all this end to end stuff. Yeah, Cadabra is a kind of new effort to kind
of have a server side component, which is, and this is the thing that Cloudron did amazingly
well, which is just auto updating the apps. So we're trying to replicate that in terms
of the server side component, which understands, you know, oh, someone who takes care of that
recipe has uploaded a new version, I'm going to roll it out. And yeah, web interface, I
forgot to add maybe, because it's still under discussion if we need that or not. Yes, again
to the end, I have, I could do a demo, a chaos demo.
Yeah, okay, maybe I'll just do a chaos demo. So I wanted to like run. Yes, just show you
the command line client. So again, to contextualize this is the tool that people who maintain
the service will be running on a daily basis. So it's supposed to make the job easy. And
I won't go through all of it at the moment. But, you know, it's, it's, you know, we try
to take effort to like explain the concepts that are involved in the project and what
you can do. You know, you can list all the recipes that are available from the command
line, for example. And yeah, you can also do operations on recipes here. So you can like
attempt to upgrade. Oh, I probably don't have internet. Yeah, right. Okay, well, anyway,
you can kind of like do the maintenance commands on the spot. So again, you're on your local
workstation, you realize that there's a new version of next cloud is coming out. Okay,
let's get that upgraded. And then you can run the commands here. And I'll basically
operate on this directory of recipes, where you can see a selection of the apps. And then,
you know, this is just the what I showed earlier, the recipe repository. So the, this is the
configuration that specifies how to deploy this app. Yeah, and there's some other details
that I didn't really go into. But basically, one of the nice things that we've wired up
is that if you deploy this app called traffic that when you roll out next cloud, it automatically
configures the lesson crypt stuff. So you just don't have to deal with this HTTPS issue.
It's already in the config, you just say, give me a thing. Yeah, I don't know, was there
much more? Oh, yeah, I guess. Yeah, and then there's just kind of this like command and
control interface where you can see like, okay, what apps have I got on what servers and,
you know, what do I need to do and you can kind of like, you know, filter it by server
or whatever. I won't type it out now. But yeah, maybe I'll call it a day. Thank you for
listening to me talk for so long.
Thank you.