The missing social network

The assumptions of web software architecture.

The most successful organisations are mostly private corporations who jealously guard their members / customers, and seek to grow and squeeze out the competition and establish a monopoly. The software of the web reflects that, as each company has its own web platform, inside of which it seeks to retain its users by being the largest or only player in the space.

This way of organising is leads to huge duplication of effort, with users seeing only a fraction of everything at any one time, until the best funded platform emerges victorious after which all the information is in one place, but it is too expensive and their are no alternatives. Think, Facebook, LinkedIn, Twitter, Instagram etc.

Most of the software tools and frameworks around, including my preferred, Drupal, are geared for this reality so it is even hard for organisations who want to do things differently to imagine another way. Movements from the ground up with local, regional, national and international levels of organising have a terrible time setting up systems that serve, because all the software available expects to be centrally organised according to a plan, not to emerge.

How not to build movement infrastructure

Think about Transition Towns, Extinction Rebellion, the Gillets Jaunes, The Global Ecovillage Network, Time Banks, LETS and the COVID mutual aid networks, all of which have a strong bottom up impetus, and there will be many more in future. In addition to having to decide which existing platform to use, or whether to code a new one from scratch, they face a special architectural dilemma. Either each local group should set up, and maintain, its own site with the skills and money it can find and thus be unable to communicate with the others. Or resources should be concentrated on a central hub which will be unresponsive to the needs of each group. Or they should duplicate effort by doing both. And before doing anything they must decide. What happens is that users are stuck trying to coordinate across a moving kaleidoscope of platforms with different subsets of functionality, then the money runs out and everything goes into decay.

All this pain and waste is a result of all the software being designed for centralised organisations like companies (.com), charities (.org), and governments (.gov). The only good reason networked organisations have to work in this way is that there is no good software to do it more appropriately. Centralised organisations are well served by platforms-as-we-know-them decentralised movements need protocols to coordinate all the moving parts.

What it would be like if a social networking platform was properly built for grass roots organisations?

The main thing is that each local chapter would look after a similar piece of software, and be responsible for hosting (or delegating hosting) of member data. This would enable groups to develop organically. Basic functionality might be a bit like Mastodon, but it would have to be extensible in a way that extensions are not limited to one chapter, but can create their own space. A movement would then consist of many chapters running a similar combination of plugins; many of the plugins would be accessing 3rd party data repositories, which means that data is outside any one platform and accessible to anyone logged in on a member web site. Plugins might be simple or complex and might be maintained by amateurs or professionals.

Many basic components would be already available, enabling movements to get started quickly. For example an events calendar module might be widely used. The events would be stored in a dedicated events repository controlled by a trusted 3rd party which means, not only members of one group, but any member of the network could see them. This would be very useful for national events or for when different groups are located close together.

So a new chapter, or a new movement for that matter would be easy to set up using a standard instance of the software, with whatever plugins the movement is using. the marginal cost of this should be near zero.

This arrangement allows sites to be loosely coupled - somewhat together, sharing technology, costs and data, and somewhat independent when groups have special needs.

Even if each (local) group had its own instance, a movement could club together to host the instances collectively to reduced costs, while retaining the freedom of each break away, or to configure their own platform differently. Or if a movement runs out of enthusiasm or resources, that's no reason for local groups to disband.

As a movement builds its resource base, it would be able to commission new plugins to perform new functions. If a movement wanted to engage in reporting wildlife sightings, they could finance the development of a plugin, and that plugin would automatically be available to all groups in the ecosystem, either to report wildlife sightings, or to alter for some other purpose.

If we think only of our own needs when we build software, or if we imagine our needs to be unique, then we will pay the full cost of developing and maintaining that software. If we break up the software however into components ranging from the general (e.g. knowing who is logged in) to the particular, (e.g. reporting on swallow migration) then it becomes possible to share the general costs with others and focus resources on the particular costs.

Is there no existing software to work with

There are many ongoing attempts to build less centralised network architectures, and there are many differences in approach and emphases, and different meanings of 'decentralised' I could discuss. I strongly feel that, the various movements, their local chapters, and their future should not be defined as a new platform, but defined API first.

ActivityPub / Bonfire

is an API and has the huge advantage of being declared a web standard, but looking more closely it seems to assume that social networking is little more than making posts, referencing users and following users. the protocol is extensible to define different kinds of posts, but the approach feels inherently limiting unless I've missed something. Bonfire is built with ActivityPub and I believe supports different kinds of posts, but the main innovation seems to be the ability to classify and tag other users so as to broadcast in a more targeted way.

Holochain / Neighbourhoods

is beautifully composable, and has an internal meta-API so that every app is a de facto network, but there's nothing special that would enable it to do that with non-holo systems. Neighbourhoods is a social network built on Holo but its starting point is reputation systems and a sort of protocol for making reputations portable between communities. I think the proposition is frankly, a paradox, and besides that, a strange starting point for thinking about interoperability.

Diaspora

was the first widely known and well funded attempt to make a decentralised facebook, but progress was so slow it was overtaken by many things and now is just litter in the landscape of decentralised social networks.

Discord, Slack et al

takes the form of a suite of chat rooms into which bots can be inserted. Chat is potentially a very versatile interface, and there's lots of room for experimentation instructing bots with natural language, but again, in that context how does that type of UI support content creation, curation, search, etc?

Other software I've looked at seems to focus on other issues like self custody of data, or ways to share only certain data with certain people, or sovereign identities, or they start with a blockchain, all of which feels wrong. Sometimes I strongly feel that software is not being built for the communities that need it, but to implement the good ideas of technicians who live in cyber-bubbles.

It seemed to me for one moment in 2015 that I was not alone in calling for this, when the Collaborative Technology Alliance was announced, but the discussion which followed lacked the requisite depth, and soon petered out.

What would it look like?

Since the main platform provides almost no functionality it is very small. Small components are easier and cheaper to manage. Its main function is to manage member identities and and logins and to connect them to the plugged in services.

Plugins would provide discreet functionality and might use a 3rd party server where anonymised data is stored and aggregated. This would enable individuals and small teams to look after small parts of the whole ecosystem, which they could do for money or for love.

There would be a common library of plugins so that if one group developed a plugin others would find it easily - the groups are not supposed to be competing to make the best software or to capture users.

For example if a network wants to have a discussion on a topic, each group should install the discussion plugin, then all their posts are stored on the discussion plugin server. Members login to their own platform, and the platform doesn't know what a discussion is, but it connects them to the global discussion. The discussion plugin could also manage discussions within to any one group.

One idea I've been toying with is to use the new Murmurations protocol for all content sharing between local instances. It could be a major component of a social networking ecosystem but not the core.

I've had a preliminary look for the most flexible platforms out there for building decentralised social networks which provide some core functionality while not defining too much else. I liked the look most of Payload CMS, but think Strapi and Ghost are also worth a look.

What do you think? Did I miss something out? Am I going about this the wrong way? Does something exist already? Or do we need someone to propose yet another social network, aimed at grass-roots communities and movements, to find money despite there probably not being a business-case, and then steward a 2 year development cycle. Sigh. P.S. I've written about this many times since I started down this road in 2008: Capitalism can't build community web-services (2011) - One web site per community is too simplistic (2011) - Solidarity economy networks & Software (2014) - Death Star platforms: Fighting fire with fire? (2015) - Protocol Cooperativism? (2017) - Global groupware requirements (2020) - Decentralised social networks & Holochain mutual credit (2020)