How It's Built
RSocial isn't one big program — it's a small set of focused parts that run together on your device, each doing one clearly defined job. Splitting the system up like this keeps it light enough to run on a Raspberry Pi, and makes each part simpler to understand, update, and secure on its own.
Here's what's inside and what each part does:
- Identity — handles accounts, logging in, two-factor authentication, and issuing the signed tokens that approve every later request. This is the part that knows who you are.
- Posts, comments & likes — your social activity, stored as RDF statements in the Apache Jena Fuseki graph store. This is the part that holds what you share.
- Media — handles uploading and serving your images and videos, with the details about each file kept in SQLite.
- Backup — creates the encrypted, integrity-checked backups covered on the Encrypted Backups page.
- Gateway — a single front door (sitting behind an nginx web server) that receives each request and routes it to the right part inside.
Read more — how the parts trust each other
The parts don't blindly trust one another. Every request between them carries one of those signed tokens, and each part checks that the token is genuine and unexpired before acting on it — so the same authentication that guards the front door also guards the inner doors. And because the entire system runs on your own hardware, none of this traffic ever crosses the public internet unless you deliberately choose to expose your instance to it. On a normal setup, it all stays within your own device and home network.
To make the picture concrete, here's the path a single post takes. Your browser sends it to the gateway — the nginx front door — which routes it to the posts service. That service first checks the signed token to confirm who you are and that you're allowed, then writes the post as RDF statements into the Fuseki graph store. When someone loads their timeline, the reverse happens: a request comes in, the token is verified, and the posts service runs a SPARQL query to gather the relevant statements and hand them back. The identity service issued the token in the first place; the media service handles any attached image via SQLite-tracked files. Each of these is a separate, focused component, and the token is the common thread that lets them cooperate without any one of them having to trust the others blindly. Splitting the system this way also means a flaw in one component is contained to that component, rather than compromising everything at once.
What RSocial Protects Against — and What It Doesn't
Good security starts with being honest about what a system does and doesn't defend against. Anyone who tells you their product stops "everything" is selling something. Here, in plain terms, are the threats RSocial is built to resist — and, just as importantly, the ones that remain partly in your hands.
RSocial is designed to protect you against:
- Large-scale data breaches — your data isn't pooled on a shared company server, so a single hack "somewhere in the cloud" can't scoop it up along with millions of other people's. There is no central honeypot to breach.
- Tracking, profiling, and data selling — with no ads, no trackers, and no third-party scripts, there is nothing collecting your behaviour to sell in the first place.
- Eavesdropping and interception — with TLS switched on, everything travelling between you and your instance is encrypted, so it can't be read or altered on the way.
- Account takeover from a stolen password — two-factor authentication plus short-lived, revocable sessions mean that knowing your password alone still isn't enough to get in.
- Silent tampering with your backups — authenticated encryption puts a cryptographic seal on every backup and refuses to restore one that's been altered.
- Injection and common web attacks — user input is treated as text and carefully escaped, so it can't be turned into code that runs against you or your database.
Read more — and here's what depends on you
Just as important is what RSocial cannot do for you on its own — the parts that depend on you:
- Physical theft of an unlocked device — if someone walks off with your hardware while it's unlocked, software can't undo that. Full-disk encryption and a locked device are your defences here.
- Weak or reused passwords — a short or recycled password undermines even the best protections. A strong, unique passphrase and 2FA are yours to set.
- A misconfigured or un-updated server — security fixes only protect you once they're installed, and TLS only helps once it's turned on. Keeping the device current is up to you.
None of these caveats is unusual — they're true of every system ever built. The point is that RSocial is upfront about the boundary. The Self-Hosting & FAQ page covers your side of it in plain, doable steps.
There's a useful way security people frame this: every system has a "trust boundary," and it's worth knowing where yours sits. RSocial draws it around your device. Inside that boundary — the encryption, the authentication, the access controls — the software does the heavy lifting for you. At the boundary itself sit the things only you can control: the physical device, the strength of your passphrase, whether TLS is turned on, and whether the operating system is kept patched. No amount of clever cryptography inside the boundary can compensate for an unlocked laptop left on a train or a password reused from a site that was breached. Naming that boundary honestly isn't a weakness in the design — it's how you know exactly which few things are yours to get right, so you can actually get them right.