One of the common misnomers around the migration away from toxic tech stacks is that the options are either 1) services managed by a company or 2) everyone #selfhosting themselves.

There is however an often overlooked 3rd option of community-scaled infrastructure. Here a group identifies their needs, plans & deploys to meet them. Much like a community garden, that infrastructure has people skilled & dedicated to its upkeep in providing for that group, working bees & skillshare as needed.

1/n

Here are some examples of this at work, in this case the Slack alternative Mattermost:

1. Our own instance in DE, used for online training
2. My friend's instance served from under her desk, on which I teach her students in CA
3. An instance in CH hosting thousands of environmental defenders that I deployed
4 An instance we deployed in IS hosting a US immigration support NGO, resistant to ICE warrants

There is no one deployment for all here, each instance meets the unique needs of the group

pub.solar

You should have control of your data! We host Matrix, Nextcloud, and Mastodon for you to use.

@lechimp @crew that is really great and I fully support it. However I would not recommend that fine service to a civil disobedience group, or front line NGO, so putting them and the coop at risk. At some point, for some communities, meeting their own needs is the ethical and resilient direction.
@JulianOliver @crew didn‘t mean to recommend them for any of that. just an implementation of what you are talking about, i think: a community running services to meet their members needs. although there are some folks there that sure will support civil disobedience =)

@lechimp @crew That is great they are so willing, and I think what they are doing is super.

To unpack what I mean regarding risk it is that warrants for server seizure can implicate all staff looking after that infrastructure and also mean data loss or downtime for others hosted adjacently - even if they are not involved in the org being investigated in any way. It is for this reason an at-risk org is better off running their own stack.