In my corner of the internet, a lot of people and groups have been calling for a new kind of social network, not only me: [2013] [2014] [2016] [2017], Its not only an objection to Facebook, but they want community organising tools very different to Facebook. The idea of a 'distributed social network' precedes even the Diaspora project which broke crowd-funding records in 2010 during a popular Facebook backlash. Those four software graduates vastly underestimated the task they had taken on, and it seems nobody yet has succeeding in defining the architecture and raising a team that can finish such a job.
This post outlines a set requirements which I believe are common to all the projects and groups around me. Here are the projects that spring to mind, in various stages of development or abandonment.
- Collaborative Technology Alliance
- Mutual Aid Network
- Secure Scuttlebut
- Open App Ecosystem (requirements)
- Wezer
- Open coop ecosystem (requirements) for FairCoop
- Platform earth
What follows is a set of requirement for a groupware platform.
First I want to talk about decentralisation. The tech giants became giants by building and owning new kinds of monopolies. There are technical advantages to such monopolies but a hidden cost also. Our use of these these institutions feeds them knowledge about us which they deploy against their users, both commercially and politically. The cry for decentralisation really means all that sensitive data should be private, or at least available only to trusted parties. That means either we need agent-centric tools in which the client stores all the sensitive data and the web service may not need to know any of it, OR that members can delegate management of their data to a service they trust. So that means if you want to use a dating app, you shouldn't tell match.com what are your bedroom fantasies, but the matchmaking service should be able to run its algorithm and connect people without needing to know who they are. This demand is quite radical and would upset a lot of web business models.
So requirement #1: Organisational and members' data should be stored in trusted places. Either synchronised accross their multiple devices, or with a trusted online providor.
The community groups who need this software are doing many different things, and some of them can maintain software to their activities. Communities also have common needs, such as membership, authentication, user profile management & governance. The common needs should be handled in a common 'core'. With systems of this type there is a danger of the core becoming very large, but we need to keep the core down to a size that a network without a core can maintain.
Requirement #2: each group should be able to plug in existing tools to a small core. Tools should be open source so that others can modify and improve them and share them back with the community.
The web seems to have evolved into a plethora of platforms. Each platform develops a service and attempts to attract members to that service, often in hope of creating a new monopoly. Activist attempts to democratise the web often involve building alternative platforms, but these things are huge and hard to sustain and hard to reach critical mass in a world where silicon valley always has a bigger marketing budget. Centralised platforms can provide a lot of functionality very efficiently, and they concentrate power and data. But there is another approach which is to define the protocols first. This is clearly demonstrated in cryptocurrencies which are defined by the protocol, not the software, and any software which implements that protocol can participate in that cryptocurrency.
Requirement #3: API first. Not only is there no single piece of software that needs to be relied upon, but also the software is broken into smaller units - either side of the API, so software projects become smaller and more manageable, being either backend or frontend projects.
Some tools are for working in groups and others are for working between groups. The former should be integrated with the group and hosted alongside to prevent data leakage. Examples are collaborative document editing, a calendar of events, reserving a shared car, and group decision making tools. Global services or services operating between groups belong outside of this groupware requirements but still they should be work as far as possible with anonymised data. For example Duckduckgo strips your metadata and forwards your search request to google, this service could be locally hosted and locally owned. Similarly a global hospitality database like bewelcome is not groupware but a group might customise its own user interface say to prioritise in all search results spanish-speaking hosts or hosts known to members of that group. If BeWelcome were only a database it wouldn't need to maintain a web front end.
Requirement #4: Some tools are local some are global.
Actors in social movements have a huge problem when every project uses a different platform. They have multiple groups, multiple logins, multiple tabs and chat programs taking up their RAM and head-space, multiple task lists, multiple chat channels often with the same people. It should not be that every group has all its own software and all its own tools. Groups should be able to form as subgroups and supergroups and share infrastructure. If many groups can use the same service, e.g. a calender service, then members can see all their events on one page just as Google calendars provides 'layers'. People need to be able to search other groups, if say, they are looking for a man with a van, or accommodation in another town.
Requirement #5: Groups would be able to use each other's data. This could be accomplished by groups using one service and therefore sharing a data store, by services coordinating by using the same indexing service, or by the service being on a blockchain or connected to a blockchain.
Any project struggles to on-board developers who must familiarise themselves with the architecture and inevitable idiosyncrasies in the code. So in a project that wants to encourage voluntary participation, the best known design patterns, languages and frameworks should be preferred.
Requirement #6: Standards compliant.. If we are talking about back end services and clients which provide logic and user interfaces, then REST is the first standard and the perfect place to define an API.
Finally, groups need to have relations. Some communities have asked to be able to explicitly state every relation to maximise freedom of association. Elinor Ostrom's 8th principle for building a commons states "Build responsibility for governing the common resources in nested tiers from the lowest level up to the entire interconnected system." My credit commons white paper also suggests that groups should be nested, as would happen naturally with groups defined by geography. Services should be able to find out, from the group architecture, which users have access to which content.
Requirement #7: Groups should be nested. We can't say how many levels of nesting are required so it seems the group definition itself allows either parents or children, and groups need to be accessible according to their location in a tree of groups.
To sum up these requirements, I imagine various teams maintaining software and running different web services, which suit their community's needs. A new community would start with a web server on a docker and configure their governance system. They would then choose from a range of web services, some they would plugin to their docker themselves, others would be hosted elsewhere. Finally each web service would have one (or more) corresponding app components which implement that service's REST API, and it would be simple enough to bundle them together into an app. The technology would force groups to do very little, but would give them many options about who to trust and who to be interoperable with.
These requirements so far all describe a core architecture, but I want to list the kinds of plugins I have in mind. First the ones that offer major functionality.
- Constitution, governance & membership (core)
- member profiles
- events
- accounting
- blog / newsfeed
- feed aggregator
- build a menu for the mobile interface
- smallads
- decision-making/governance
- commercial products & prices
- task management
- ridesharing platformcoop
- accommodation platformcoop
In my next post I'll describe an approach which could work.
Comments