Lesson from Bridge Seat Co-op #5: Competing Digital Cages or Cooperative Digital Cafes?

Lessons from Bridge Seat Cooperative (2023-2025)

1. Introducing the Bridge Seat Cooperative
2. A Bridge Too Far
3. In Defence of Servers
4. Into the Woods We Go
5. Competing Digital Cages or Cooperative Digital Cafes? (this one)

This piece was adapted for the Bridge Seat blog from one I wrote for the Disintermedia blog in 2018. It's the third and final piece written for the Bridge Seat Cooperative blog that I'm reposting here so people can read them, along with the launch announcement and the shutdown debrief, without going anywhere near SS. Enjoy.

Understanding fediverse servers as a form of hospitality

In the late 90s and early 2000s there was a wave of activist-run, community-hosted servers, many of which fed into (or grew out of), the Indymedia network. Most of those veterans have vanished from the web, and RiseUp, Framasoft, and Comunes (OurProject), are among the few still standing.

As awareness grows of tech corporations like Xitter, FarceBook, Goggle, BorgSoft, grApple and scAmazon putting the people using their platforms in a digital cage, it’s great to see a whole new wave of cooperative groups coming together to replace these Web 2.0 prison canteens with ‘digital cafes’, like CommonsCloud, Disroot, and Social.coop. The Bridge Seat team are (note: were) were excited to be joining them by hosting fediverse servers.

A digital cafe (one example of an ‘Open App Ecosystem‘) is a community of users and hackers providing themselves and each other with web services like social media (social networking, open publishing, or both), and sharing the costs. Since they’re doing many of the same things, rather than reinventing the wheel by writing all their software from scratch, they use a range of Free Code software developed by other groups. Sometimes they donate towards the financial costs of the peer production project that develops the software they use, and in other cases they have the skills and the time to contribute back to the project.

Social.coop began as group of members who set up a cooperative to share the costs of a site running Mastodon. Social.coop users can interact not only with each other, and with users on other sites running Mastodon (”instances”), but they can also interact with users on any site connected to a larger “fediverse” of federated social apps.

The software makes these interactions across the fediverse possible by using common standards for exchanging data between social sites, initially using an older standard called OStatus. In 2018, a new standard called ActivityPub was published by the W3C (World Wide Web Consortium), the body that maintains the official standards for HTML, and everything else about how the web works under the hood. ActivityPub was the final output of W3C’s Social Working Group, which has now been replaced by the SocialCG (Social Web Incubator Community Group).

Social.coop depends on the work of all these other organizations in different ways, to keep their digital cafe running. But what’s the nature of the relationship between a cooperative running a digital cafe, and the groups maintaining the software they use?

Does their sustainability depend more on making sure the project developing Mastodon has good governance? Or working on ensuring the reliability of their own servers, tweaking the software to serve member’s specific needs better, and perhaps adding new services, to help attract more members who can help reduce the costs per member?

You can’t have a cafe without a reliable electric and gas supply to the kitchen (the “back-end” of the server that users don’t see), and good mood lighting so people can feel relaxed but still see what they’re doing (the “interface”1). But you don’t build a successful cooperative cafe by focusing on the internal politics of the energy utility, or the lamp shop. You focus on building your membership / customer base (“users”), and your collective capacity to provide them with good coffee, good food, good service and a pleasant environment (HX or “Human eXperience“2).

If your energy supply becomes unreliable, you switch providers. If a coop-owned energy supplier emerges, great, switch to that. Akkoma (forked from Pleroma) and FireFish (forked from MissKey) are already options for ActivityPub servers. IMHO both their back-ends perform better than Mastodon’s Ruby-on-Rails engine, but other options continue to emerge.

It’s the same with the lamp shop (interface). At present social.coop happens to be buying energy and lamps as a bundled package from Mastodon. But they’re not stuck with either, and they don’t have to get them both from the same supplier. There are already a bunch of other lamp shops around, whose lamps can plug into the same power sockets (server-to-client API) that Mastodon uses. Hopefully, at some point, everyone will be using the same standard power sockets and plugs (ActivityPub server-to-client API), so all lamps will work with all electric suppliers.

In a cafe, the energy supply is the maintenance crew’s problem (tech working group). As long as the lights stay on, the rest of the members don’t have to care about how they’re powered.

The lamp situation, on the other hand, is something the members/ customers have to put up with while they drink their coffee. Decisions about which interface options social.coop offers need to be made by the membership, within the range of options that can technically work right now. Keep in mind that members can also get takeaway coffee to drink somewhere else (using a portal like elk.zone to connect to their current instance), so they do have lighting options beyond what the maintenance crew can set up and maintain right now.

The most important thing, the thing that isn’t a distraction, ever, is the coffee, the service, the food, and the mood. If they don’t get the HX right, it doesn’t matter how healthy or unhealthy the workplace is down at the energy company or the lamp shop, because they won’t keep the digital doors open long enough for their long-term survival to matter.

What the Bridge Seat team aim to do, is to serve as the pre-assembled maintenance crew for anyone who wants to start their own digital cafe. With enough customers, paying a predictable monthly subscription, we can work fulltime on researching electricity supplies and testing lamps, and supporting groups trying to set up cooperatives to supply them. Freeing up each digital cafe team to focus on providing the right coffee, service, food and mood, for the people they want to be their regulars.

Clear as mud? I may have over-stretched the cafe analogy somewhat; as the old saying goes, no metaphor bears close examination. Feel free to hit me up about what I mean by this or that on the fediverse.

Image:

"Time to Unwind @ Earshot Cafe – The Arts House, Singapore", licensed CC BY-SA 2.0.

Thanks for reading Bridge Seat Cooperative! Subscribe for free to receive new posts and support our work.