In early 2024 I shared some early work on a privacy-preserving social media network oriented around event organising that I’m now calling organ-social. My work on this project was motivated by a desire to support activists and community organisers to become less reliant on corporate social media. I’ve since indefinitely suspended work on this project and wanted to share why.

The short story is that 1. building the proof of concept showed me that the design wasn’t viable for privacy protection, combined with me deciding somewhat late in the game that 2. privacy protections were a non-negotiable feature. To add to this, I was (and still am) a relatively inexperienced developer, who had spent the better part of the previous four years working on what turned out to be a wildly overambitious passion project, having fallen victim to a combination of scope creep, naivety and a touch of righteousness.

What was organ-social?

The earliest iteration of the concept was called ‘radical directory’ and aimed at replicating something like radar.squat.net but with a prettier UI. In order of how my work on this progressed, I tried:

• A Github Pages site with Netlify CMS, where data would be stored in a Github repo.
• Self-hosting the popular forum software Discourse and trying to build a custom theme for it, in which organisations and events would be represented by ‘topics’
• Building a React frontend to the Discourse API, trying to use the forum as a kind of headless CMS
• Self-hosting Directus headless CMS
• Self-hosting Keystone headless CMS with a Next.js frontend

Over the course of these experiments, accompanied by research about the history of independent online media platforms, I started to grow wary of what it would mean to create another centralised platform that, due to network effects, would not only compete with mainstream social media platforms but also other independent projects. I quickly became an advocate for interoperability between platforms or at least platform providers, as in decentralised or ‘federated’ networks.

Radical Directory was also the name of a small volunteer collective of people interested in the role of online media in organising for social justice. When we talked about platforms, we envisioned the role of the collective as basically stewarding it into existence and governing the content on it. The collective was a bit dysfunctional though, because I was the only one interested in coding, I was kinda obsessive about it, I had a lot of confident and ambitious ideas about what I wanted to work on, but I was also quite reluctant to act as an organisational, rather than just a technical, leader. To be honest, the idea of governing a media platform for social justice organising actually scared me; I could imagine the high standard we would be held to by the community (with a name like Radical Directory no less), and I was also myself deeply skeptical of the non-profit industrial complex and the legal and economic ties that neutralise non-profits as political actors.

Perhaps it was partly this fear that motivated me to pivot to building a web app on a federated network. With no clear direction for the organisation to head in, it started to disband, and I continued mostly alone on my weird path. I wrote a grant application for some money from NLNet to create a social media-style app for event organising based on the Matrix protocol. The more obvious choice for social media was ActivityPub - in fact there was already such an application built on that network called Mobilizon (which I snobbily dismissed as ugly and uncool - sorry Mobilizon devs). Matrix’s support for real-time applications was interesting to me, but I was mostly compelled by its claim to support for end-to-end encryption for large groups and the Matrix.org Foundation’s early work towards a peer-to-peer version of the network. While I knew these complex features were somewhat beyond the scope of what I could realistically achieve in an application, I reasoned that if a simpler version of the app could take off, donations could potentially support me to build in these features in the future.

The grant application was knocked back, and I let the idea ferment for a while, but when the latest genocidal siege on Gaza began in late 2023 and radical social movements started feeling newly energised, I decided to try to build it anyway. That’s what eventually led to organ-social, as well as a supporting client library simple-matrix-sdk because I was frustrated with Matrix’s official JS SDK. I also ran the radical.directory Matrix server which I tested on and encouraged my friends to use with Element for a while, until they all got sick of its encryption bugs and Signal launched usernames (phone number privacy being the only edge Element had over Signal that was meaningful to my friends). I even got the app functioning to the point that I shared with my friends that the launch was coming soon.

What wasn’t viable about it?

I worked really hard on organ-social, so I was reluctant to admit that in the course of building it I actually had learned enough about the limits of Matrix to know that my long-term ambitions for a privacy-preserving peer-to-peer application were going to be very challenging if not impossible to achieve on top of that protocol. It also didn’t help that Matrix.org Foundation announced that they were cutting funding for their P2P Matrix project, or that I had discovered that there was an organisation in Europe, Acter, that was building its own app for activists on Matrix, or that I had been really struggling to pay the bills for myself and my family.

Moreover as I saw friends confronted with brutal political repression, and learned more about mass surveillance in general, the urgency of preserving privacy became central in my mind, and in that context I arrived at the opinion that my early stage non-privacy-preserving social media network was not only totally unhelpful to activists but potentially even harmful. That coupled with my conclusion, based on a deeper understanding of the protocol, that meaningful privacy required metadata privacy, which couldn’t be built on Matrix (except potentially through a weird kind of overlay network which would then need its own protocol specification to be decentralised).

A P2P system for asynchronous messaging was also essential for the economic scalability of the network. Central servers are expensive, and both Signal Foundation and Matrix.org spend obscene donated amounts making their servers free to use. organ-social depended on not just the Matrix server but also an application service, which needs to be configured at the server level, meaning that not only was the server centralised in the near term, but it also couldn’t really make use of the matrix.org server infrastructure.

What now?

As you probably saw, my new goal is to create a platform for building static web pages and publishing them to the web, and I’m offering a convenient interface to the hosting of those web pages as a paid service. No baby is born into the world hoping to start a business but I do need to put food on the table and am not so privileged to spend limitless time working on passion projects. I feel hopeful about taking this project in interesting directions - I would love to explore peer-to-peer distribution of static web pages, sidestepping the public web, and I’d love to explore end-to-end encryption of those pages.

In terms of organ-social - the problems I described above are not just problems for the project of building a privacy-preserving social media network for event organising - several of them sit at the heart of significant ongoing research and development efforts to transform the way applications can be built and deployed in general. I want to share some of my learnings here about the state of the field and why these problems are so challenging, and what that might mean for this project.

Secure group messaging

While we can take the security of messages in transit to and from the server more or less for granted now thanks to the Transport Layer Security (TLS) protocol that underlies your ‘https://’ URLs, end-to-end privacy takes us to the essential next step of preventing the server itself from accessing the content of our messages. That said, the less we trust centralised services, the more technically complex these systems need to become to enable cryptographic (rather than sociopolitical) privacy guarantees.

Signal protocol is widely recognised for having set a new standard in end-to-end (E2E) privacy guarantees that can be offered in usable applications. As well as ensuring that each individual message is confidential, untampered, and verifiably from the sender, the protocol protects long messaging sessions against both past and future attacks, using two systems for updating cryptographic keys to achieve what is called forward secrecy (FS) and post-compromise security (PCS). Signal then extended their system for secure communication between two parties to the case of group messages, but they did so in a way that was relatively inefficient, making very large groups impractical. These issues have subsequently been addressed in extensive research culminating notably in the publication of the Messaging Layer Security (MLS) protocol.

To be clear, Secure Group Messaging (SGM) is not just about chat. In the abstract, messaging technically differs from communication in that it can be completely asynchronous, absent any requirement that both devices are online at the same time or directly connected ever. Chat is just one application of such a system: it could be social media, collaborative document editing, calendars, practically anything. When messages are combined with eventually consistent algorithms for converging on application state (or consensus algorithms, if transactional consistency guarantees are required), they can stand in for most functions traditionally played by a centralised database. A performant system for secure group messaging such as MLS, which by its nature needs to account for changes in the group as members are added or removed, with all the security features of Signal given above, can be considered the general case for privacy-preserving social applications.

Metadata security

MLS still relies on a server to function though, and like Signal protocol still leaks metadata about messages to that server. This is a serious concern: such metadata has been used as evidence in the criminalisation of activists and can be deeply valuable for state intelligence agencies conducting social network analysis. We tend to not have to worry about this too often with Signal Foundation, but only because of sociopolitical conventions not to store our metadata within that organisation. Meta, which now uses versions of Signal protocol for its WhatsApp, Facebook Messenger and Instagram Direct Messages products, has by contrast happily integrated such metadata into their offering to advertisers.

Rather than securing metadata at the organisational level, we should be aiming to secure it at the application protocol level (i.e. various metadata-hiding cryptographic schemes) and/or at the network level, through anonymity networks (like Tor) or through reducing the exposure by reducing our reliance on central server infrastructure. Ultimately my interest is in the latter: making secure group messaging completely peer-to-peer, such that there is no infrastructural dependency on a central server that is inherently positioned to accumulate and exploit metadata. This would also serve to reduce the scope of attacks on the availability of that service.

Key Agreement for Decentralized Secure Group Messaging with Strong Security Guarantees is an interesting recent publication in this area, and I would be interested to see an implementation of their protocol (by someone with a lot more security expertise than me) that can compile to WebAssembly and run on browsers and other platforms. It’s not by itself a metadata secure protocol to the extent that servers can optionally be used in this system to relay messages and can see who is speaking to whom, but it might be combined with anonymity networks to become one, and in any case the elimination of big central servers is a positive development.

Broadcast encryption

I’m also interested to learn more about using broadcast encryption as a more efficient alternative to (multidirectional) secure group messaging, for social media-like applications. Broadcast encryption schemes have generally depended on a centralised key escrow system, and only a small handful of papers have addressed distributed or decentralised schemes that remove this requirement. Distributed Broadcast Encryption from Bilinear Groups is a recent paper which made notable advances in the efficiency of distributed broadcast encryption.

Identity

Finally, identity and discovery are two essential components of social networking applications which have also typically relied on central services with privacy implications. Decentralised identity is a thorny problem in that it inherently bridges the gap between technological systems and the social expectations, practices and institutions that enable us to trust each other’s identities. The publication of the Decentralised Identity (DID) standard is a solid basis for future developments in this area - it has, for example, (limited) support within the Authenticated Transfer protocol (ATProto) that underlies BlueSky.

DID provides a standardised interface to various decentralised registries via ‘DID Methods’, each with its own pros and cons. Many of the methods are blockchain-based, in a rare example of an application of that technology that actually makes some sense. Note that while some methods, like BlueSky’s plc placeholder method, are just centralised registries, movement towards decentralisation (which is a spectrum) is the broader goal of the standard.

Discovery

Pudding - user discovery for anonymity networks addresses a usability problem in anonymity networks (like Tor) wherein short, human-readable user identifiers like phone numbers and email addresses need to be mapped to long, specific public keys, without exposing who is part of the network or who wants to communicate with them to network observers or to the central registry where those mappings might typically be kept. The authors’ work is based on Nym anonymity network, similar to Loopix mixnet, which are themselves interesting and valuable developments.

Message availability (distributed storage and computation)

Centralising certain functions of a network or application to some dedicated server definitely makes many problems a lot easier to solve, and even workable for a privacy-preserving system via various cryptographic solutions. That said, servers are ultimately expensive to buy and run (or, as is most common now, to rent) and need to be funded by someone, and this dependency is itself a security risk in the long term for anyone hoping to rely on a system. In the capitalist system of resource allocation, it also constrains the development of software to paths that make economic sense for the developers, meaning that non-capitalist software is systematically not developed.

In my opinion the most promising general principle for the development of non-capitalist software is to make servers redundant, or put differently, to abolish the hierarchy between server and client, and this has more or less been the goal of most peer-to-peer developments. The main technical distinction between the two is that servers are highly available - assumed to be always online. Clients are mostly mobile devices which go offline all the time, and even when they are online, it can be tricky to establish a direct connection for various reasons. A goal for a peer-to-peer storage system might be that data (like messages) are highly available even when many of the peers are not.

There have been a lot of projects over the last few decades aiming to manifest this vision of an internet that doesn’t need servers. BitTorrent protocol was obviously very successful for file sharing, and IPFS has expanded on this over the last decade. Beyond just file sharing, various peer-to-peer apps or app frameworks have been promising: Hyphanet (fka Freenet), Secure Scuttlebutt, Holepunch (fka Dat), Briar, Cabal, Holochain, Veilid to name a few. I’m personally really interested in the new version of Freenet (yet to be launched) for various reasons.

The hope for a peer-to-peer app framework like Freenet is that there can be a network of nodes that can function as relays for each other’s application messages, even if the nodes are not all using the same applications. Creating such a network that works at all, and also doing so safely and with enough modularity for developers to be interested in building a variety of applications on the platform is tricky to say the least.

Conclusions

There is of course a lot more to dig into on all of these topics but I’m going to leave it there for now. Working on Radical Directory and organ-social has been a humbling experience, which is definitely good. I have so much more appreciation for complexity and expertise around privacy, distributed computing, and for the actual expert developers that have dedicated so much of their lives to building open source software in support of such ambitious goals as building privacy-preserving peer-to-peer tech.

I know that I need to focus on taking baby steps for the moment and particularly on getting some kind of income stability that can hopefully serve as a foundation for me to pursue more achievable, specific goals towards the broader visions outlined above.