Why federation — and what it actually means

When we were deciding how optional sharing should work in PluralLog, we spent a long time on the question of trust. Specifically: how do you build a sharing system where users don't have to trust us?

The short version

Federation means there's no central PluralLog server that everyone connects to. Instead, anyone can run a relay — and when you share with a friend, your data is encrypted before it leaves your phone. The relay is just a secure courier. It can't read your mail.

Why not a central server?

The data in PluralLog is sensitive. Names, pronouns, journals, the record of who was fronting during a hard day — this is exactly the kind of data that shouldn't live on a company's server, subject to subpoenas, breaches, or business model changes.

There's also something more practical: it's genuinely difficult to ask users — especially in communities that have good reason to be cautious about data — to extend trust to a developer they don't know. A federated model means that trust can be extended incrementally. You can run your own relay. Your community can run one. You only need to trust the infrastructure you or someone you know controls.

This also felt more sustainable long-term. A single central server is a single point of failure — financially, legally, operationally. Recent changes to Octocon and SimplyPlural are examples of this. A federated ecosystem distributes that burden, or at least provides a mechanism to.

What the relay actually stores

Encrypted blobs. The relay knows a version counter and a timestamp rounded to the nearest hour. It does not know member names, who was fronting, what you wrote in your journal, or anything meaningful about your system.

Current limitations

We want to be honest: the current model isn't perfect. There are attack surfaces we're still working through — for instance, a relay operator acting in bad faith could interfere with message delivery in ways we don't fully prevent yet. This is one of the reasons we're taking our time before publishing the relay server code. We'd rather delay the open release than publish something that creates a false sense of security.

We're not aiming for a trivial security model, but we also can't claim a perfect one right now. The cryptography is sound; the protocol is still maturing.

Coming soon: open source

When we publish the relay code, you'll be able to read every line, run your own instance, and verify our claims. That's how it should work.