What happened to the earlier version of Organ?

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 c