Security

Your Data Stays on Your Device

The single most important security decision RSocial makes is also the simplest: your data never leaves your hardware. Unlike mainstream social platforms that upload everything to centralized cloud servers, RSocial stores all your posts, photos, messages, and connections locally on a device you own — even a Raspberry Pi.

This means there are no remote servers to breach, no third-party cloud providers with access to your information, and no single point of failure that could expose millions of accounts at once. Your social network lives where you live.

READ MORE

To understand why this matters so much, it helps to picture how an ordinary social network is built. On a mainstream platform, everything you and everyone else posts is uploaded to enormous data centres owned by one company. That company decides what happens to it, who can see it, how long it's kept, and what it's worth. You don't have a copy — you have an account, and an account can be suspended, throttled, or closed at any time, for any reason, often with no explanation and no way to get your memories back.

RSocial turns this model inside out. The device in your home is the server. When you post a photo, it is written to storage on that device and stays there. There is no upload to a company in another country, no copy sitting in a cloud you can't see, and no middleman deciding the rules. If the RSocial project disappeared tomorrow, your instance would keep running exactly as before, because nothing it needs lives anywhere else.

This also changes the whole economics of an attack. When a big platform is hacked, a single break-in can expose hundreds of millions of accounts at once, because all that data sits together in one place — a target so valuable that attackers invest years trying to reach it. RSocial has no such jackpot. Each device holds only its own community's data, so there is no giant central prize to go after. An attacker would have to reach every device individually, one at a time, for a fraction of the reward — which simply isn't worth it.

The flip side is worth being honest about: because you hold the data, you also look after the device it lives on. On a normal platform, physical security is someone else's job; here it is partly yours. Keeping the hardware in a safe place, applying updates, and holding an encrypted backup are what turn "your data is on your device" into "your data is genuinely safe." The rest of this page explains the protections RSocial builds in, and the short, well-documented steps that are yours to take.

Encrypted Backups

While your data stays local, RSocial also supports encrypted backups so you never have to worry about losing anything. Before a backup ever leaves your device, it is encrypted using strong, industry-standard algorithms — meaning even if someone intercepted the backup file, they would find it completely unreadable without your key.

RSocial also performs integrity checks on every backup to ensure nothing has been tampered with or corrupted. If any modification is detected, the backup is flagged and rejected. You stay in control of when backups happen, where they are stored, and who — if anyone — has access.

READ MORE

Here is exactly what "encrypted" means in RSocial. Backups are protected with AES-256-GCM. AES — the Advanced Encryption Standard — is the encryption trusted by governments, banks, and security researchers around the world. The "256" is the size of the key that locks the data: there are more possible 256-bit keys than there are atoms in the observable universe, which is why no one can simply try them all. The "GCM" part is what makes AES not only secret but also tamper-evident, which we'll come back to in a moment.

The obvious question is: where does the key come from, and where is it kept? The answer is that it is never kept anywhere. Instead, the key is calculated from a passphrase you choose, at the moment you make or restore a backup, using a process called PBKDF2 with SHA-256, run 100,000 times. Two details make this strong. First, a unique random value called a salt is mixed in, so that even two people who pick the exact same passphrase end up with completely different keys — this defeats attackers who work from precomputed tables of common passwords. Second, repeating the calculation 100,000 times makes it deliberately slow: your own device does this once and never notices, but an attacker trying to guess billions of passphrases is slowed to a crawl. Because the key only ever exists for the moment it's needed and is then discarded, there is nothing on disk for anyone to steal.

Now back to tamper-evidence. Because AES-256-GCM is an authenticated cipher, every backup carries a small built-in cryptographic tag that works like a wax seal on an envelope. When you restore, RSocial recomputes that tag and checks it. If even a single byte of the file has changed — whether from disk corruption or a deliberate edit — the seal no longer matches, and the backup is refused rather than quietly loaded with hidden changes inside. This is the "integrity check" described above, made concrete.

One honest consequence follows from all of this: since the key is derived only from your passphrase and is never stored, losing that passphrase means losing access to that backup — there is no master key and no reset link, because a reset link would be exactly the back door this design exists to avoid. You decide when backups run, where they're stored (a local drive, an external disk, wherever you trust), and whether anyone else ever holds a copy.

Two-Factor Authentication

A strong password alone isn't enough in today's threat landscape. RSocial includes two-factor authentication (2FA) as a built-in feature, adding an extra layer of protection to your account.

With 2FA enabled, signing in requires both your password and a second verification step — typically a time-based code from an authenticator app on your phone. This means that even if someone somehow obtained your password, they still couldn't access your account without physical access to your second factor.

RSocial supports standard TOTP-based authenticator apps, so you can use the same tools you already trust for other accounts.

READ MORE

The reason a second factor helps so much is that most account break-ins don't involve "cracking" anything. They happen because a password was reused on another site that got breached, guessed, or typed into a convincing fake login page. In every one of those cases the attacker ends up holding your password — and with two-factor authentication, that still isn't enough to get in.

Under the hood, RSocial uses TOTP, which stands for "time-based one-time password." It's an open standard supported by apps you may already use, such as Google Authenticator, Authy, and 1Password. Setting it up works like this: RSocial shows you a QR code once, which your app scans to learn a shared secret. From that moment on, your app and your instance can each independently produce the same short code — usually six digits — that changes roughly every 30 seconds. The clever part is that after that first setup, the secret never travels across the network again. Your phone calculates the current code entirely on its own, even in aeroplane mode, and RSocial calculates the same code on its side to compare. Because each code is valid for only about half a minute, a code that someone manages to glimpse or intercept is worthless almost immediately.

To make sure 2FA never locks you out, RSocial provides one-time recovery codes when you enable it. These are a short list of single-use backup codes you save somewhere safe in advance — a password manager, or printed and stored offline. If you ever lose your phone, you use one of them to get back in and set up a new authenticator. Each recovery code works only once, so a used code can't be replayed by anyone who later finds your list.

Secure Login

Every connection to your RSocial instance is secured with TLS encryption (the same technology used by banks and major websites). This ensures that any data transmitted between your browser and your RSocial device is encrypted in transit — protected from eavesdropping or man-in-the-middle attacks.

RSocial uses secure session management with signed tokens, automatic session expiration, and protection against common web attacks such as cross-site scripting (XSS) and cross-site request forgery (CSRF). Your login credentials are never stored in plain text — they are hashed using modern, salted hashing algorithms.

READ MORE

How your password is stored. When you create an account, RSocial never writes your actual password to disk. Instead it stores a hash of it. Hashing is a one-way process: it turns your password into a scrambled fingerprint that cannot be turned back into the original, no matter how much computing power you have. When you log in, RSocial hashes whatever you typed and compares the two fingerprints — it confirms you know the password without ever needing to know the password itself. Specifically, RSocial uses PBKDF2-HMAC-SHA256 with 100,000 iterations and a unique salt per account, the same deliberately-slow, salted approach described in the backups section. The practical result: even in the unlikely event someone reached the account database, they would find only irreversible fingerprints, not a single readable password.

How your session is kept. After you log in, RSocial doesn't keep asking for your password — it issues a signed token (a JWT, or JSON Web Token) that your browser presents with each request. Think of it like a tamper-evident wristband: it is signed with HMAC-SHA256, so your instance can instantly tell whether it's genuine, and any attempt to change what's written on it makes the signature invalid. These tokens are deliberately short-lived — an access token is good for only about fifteen minutes. Working quietly behind it is a longer-lived refresh token (valid for around seven days) that automatically gets you a fresh access token as you keep using the app. That refresh token rotates every time it is used — each use issues a new one and retires the old — and it can be revoked instantly on the server if anything looks wrong. The upshot is that if a token were ever captured, its usefulness is measured in minutes, not months, and a stolen session can be cut off centrally.

How the connection is protected. RSocial is designed to run behind TLS, the same encryption that puts the padlock in your browser's address bar. TLS uses a certificate — a small file that both proves the server is really your instance and sets up an encrypted channel — so that everything travelling between your browser and your device is scrambled and can't be read or altered by anyone in between (this is what stops "eavesdropping" and "man-in-the-middle" attacks). You switch TLS on with a standard reverse proxy and a free certificate, for example from Let's Encrypt, and our deployment guide walks through it step by step.

How the app resists common web attacks. Two attacks are worth naming plainly. Cross-site scripting (XSS) is when someone tries to sneak malicious code into a page through something they typed — a comment, a name, a post. RSocial's interface treats everything a user types as plain text to be displayed, never as code to be run, so injected code simply appears as harmless characters. Cross-site request forgery (CSRF) tricks your browser into making a request you didn't intend, relying on login information the browser sends automatically. Because RSocial proves who you are with a token the app attaches deliberately — rather than an automatic cookie — this whole class of trick largely doesn't apply. On top of that, user-supplied content is carefully escaped before it's ever used in a database query, closing the door on injection attacks.

Role-Based Access Control

RSocial implements role-based access control (RBAC) to ensure that users only have access to the features and data they are authorized to use. Administrators can define roles and permissions at the community level, giving you granular control over who can do what within your space.

This means a regular member can interact with content without having access to administrative tools, and moderators can manage discussions without having access to system-level settings. Every action is scoped to the user's role, minimizing the risk of accidental or intentional misuse.

READ MORE

The most important thing about these permission checks is where they happen: on the server, not just in the interface. It's easy to hide a button from someone in the app, but hiding a button isn't security — a determined person can bypass the interface entirely and talk to the system directly. RSocial guards against this by checking permissions on the backend, for every protected action, on every request. An administrative action is gated by an authorization policy that the server enforces itself, so a restricted feature stays restricted even if someone goes around the interface completely. The interface hides options you can't use as a convenience; the server is what actually stops you from using them.

RSocial also follows a principle security professionals call least privilege: by default, an account is given the minimum access it needs to do ordinary things — post, comment, and take part — and nothing more. Elevated powers, like managing members or removing content, are granted deliberately to specific roles rather than being switched on for everyone. This keeps the blast radius of any single compromised account small: if an ordinary member's login were ever misused, it still couldn't reach the administrative controls, because that account was never handed those keys in the first place.

No Ads, No Tracking

Most social media platforms are designed to harvest your data. RSocial is designed to protect it. There are no advertising systems, no analytics trackers, no data brokers, and no behavioral profiling.

RSocial does not use cookies for tracking, does not embed third-party scripts that monitor your activity, and does not sell or share your information with anyone. The platform has no incentive to collect your data because it doesn't rely on advertising revenue. Your social life stays your social life.

READ MORE

It's worth understanding why mainstream platforms track you in the first place, because it explains why RSocial doesn't. On an ad-funded network, you are not the customer — advertisers are. The product being sold is your attention and a detailed profile of your behaviour, and every "free" feature exists to keep you scrolling so that more of both can be collected. Tracking isn't a bug in that model; it's the entire point of it. RSocial simply isn't built on that model, so it has no reason to watch you.

And this is more than a promise — it's visible in what the software doesn't contain. There are no analytics tools, no advertising libraries, and no third-party scripts loaded into the interface at all. Nothing "phones home" to a company in the background as you use it. Modern websites often quietly load code from dozens of outside companies — ad networks, trackers, session recorders — each one a channel through which your activity leaks out. RSocial loads none of them.

To be precise and honest, there is a difference between tracking and ordinary logs. Like any server, your instance keeps basic technical logs — the kind that help you see that it's running and diagnose a problem if something breaks. Those logs exist to keep your own device healthy, not to build a profile of you, and crucially they stay on your device: they don't leave it, and there's no one on the other end collecting them, because there is no other end.

Data Ownership & Portability

Your data is stored using open, standard formats based on semantic web technology. This means your posts, photos, connections, and metadata are structured in a way that is human-readable, machine-readable, and not locked inside a proprietary database.

You can export your data at any time, back it up to any storage medium, or migrate it to another RSocial instance. Because the data is yours, RSocial gives you full tools to manage, move, and delete it whenever you choose — no export requests, no waiting periods, no hidden limitations.

READ MORE

Let's unpack what "open, standard formats" actually means, because it's the difference between data you own and data you merely borrow. Your social activity — posts, comments, and likes — is stored as RDF. RDF is a long-established open standard from the W3C (the same body that standardises the web itself) for describing information as simple three-part statements: a subject, a relationship, and an object — much like the sentence "Alice — likes — this photo." Storing your world as plain statements like these, rather than as rows in a secret company-specific table, is what makes it genuinely portable: any developer, and many off-the-shelf tools, can read and understand it.

These statements live in a graph store called Apache Jena Fuseki — an open-source database built specifically for this kind of connected, statement-based information, and queried with SPARQL, an open standard query language. Alongside it, your account details and the information about your images and videos are kept in SQLite, one of the most widely used and thoroughly documented database formats in the world. Neither of these is a proprietary black box: both are open, inspectable, and readable outside of RSocial.

This is what makes portability real rather than a marketing line. Because nothing is trapped in a format only RSocial understands, you can take a complete copy of your data, archive it wherever you like, or move it to another RSocial instance — without filing an "export request," waiting in a queue, or hoping a company decides to let you. On mainstream platforms, the difficulty of leaving is a deliberate feature that keeps you locked in. Here, leaving is as straightforward as staying, because the data was always yours in a form you can actually use.

Community-Level Moderation

Security isn't just about technology — it's also about governance. RSocial gives community administrators built-in moderation and admin tools to enforce their own rules, remove unwanted content, and manage membership.

Because each RSocial instance is independently operated, community leaders set the standards for what is acceptable in their space. There is no distant corporate policies overriding local moderation decisions. You control who enters your community and what happens within it.

READ MORE

On mainstream platforms, the rules are written far away by a company balancing advertisers, public relations, and a billion strangers, then applied to your community whether they fit it or not. A post can be removed by a policy you never agreed to, or left up despite your objections, and there is rarely anyone to appeal to. RSocial inverts this: because every instance runs entirely on its own, with no central authority above it, the people who run a community — not a faraway company — hold the tools and make the decisions for their own space.

In practice, that means an administrator can manage who is allowed to join, lock or remove accounts that break the community's own rules, and keep the content that belongs there. The standards are set by the community they actually affect, and enforced by the people who live in it — a small group that knows its members can moderate with context and fairness that a distant, one-size-fits-all policy never could. Different communities can run by different values, and none of them can override another.

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 (this stops "man-in-the-middle" attacks).
• 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.

And here 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, and the next section covers your side of it in plain, doable steps.

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 described above. 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 earlier, so your data can be saved and restored safely.
• Gateway — a single front door (sitting behind an nginx web server) that receives each request and routes it to the right part inside.

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.

Your Part When You Self-Host

Running your own social platform gives you real control — and, in return, a small amount of real responsibility. The good news is that none of it is complicated, most of it is one-time setup, and our deployment guide walks through every step. Here's how to keep your instance as secure as it's designed to be:

• Keep it updated — install operating-system and RSocial updates when they arrive. Most security problems in the world are old, already-fixed ones that were never patched; staying current closes them before anyone can use them.
• Turn on TLS — set up a certificate (Let's Encrypt provides them free, and the guide shows how) so that all traffic to and from your instance is encrypted rather than sent in the clear.
• Limit what's exposed — only make your instance reachable from the internet if you actually need remote access, and use a firewall to close every door you're not using. The less that's exposed, the smaller the target.
• Use a strong passphrase and enable 2FA — the front door is only as strong as the password behind it. Choose a long, unique passphrase and switch on two-factor authentication so a leaked password alone can't get anyone in.
• Look after the hardware — keep the physical device somewhere safe, consider full-disk encryption, and hold an encrypted backup off the device so a loss or theft is an inconvenience, not a disaster.

You don't need to be a security expert to do any of this. The secure choices are built in by default; these steps simply make sure the parts that depend on your environment are set up properly too.

Security FAQ

What happens if my Raspberry Pi is lost or stolen?

Whoever ends up with the device still has to get past your login, and with 2FA switched on a password alone isn't enough. Any encrypted backups stay completely unreadable without your passphrase, so you can restore your data onto new hardware while the stolen device gives up nothing useful. For the strongest protection, turn on full-disk encryption on the device itself — then even the raw storage is scrambled if someone removes it.

Can the RSocial project, or anyone at "RSocial," see my data?

No. There are no central RSocial servers and no cloud account tied to your instance. Your data lives on your device and never leaves it unless you send it somewhere yourself. There is simply nothing on our side to look at, because there is no "our side" in the path your data takes.

If there are no ads, how do I know I'm not the product?

Because the software contains none of the machinery used to make you the product — no ad libraries, no trackers, no third-party scripts, no data being sent out. A platform that isn't funded by advertising has no reason to collect and sell your behaviour, and RSocial is built accordingly.

How are security issues and vulnerabilities handled?

Because you run your own instance, keeping it updated is the single most effective thing you can do — updates deliver security fixes straight to your device. Security is treated seriously throughout development, and safe deployment practices are documented so your setup starts from a strong baseline.

Do I need to be a security expert to run RSocial safely?

No. The secure choices — encrypted backups, hashed passwords, signed sessions, server-enforced permissions — are built in and on by default. The few steps that depend on your environment, like turning on TLS, enabling 2FA, and installing updates, are explained in plain language in the deployment guide.

Is my data encrypted all the time, even on the device?

Backups are always encrypted, and connections are encrypted in transit once TLS is on. For the data at rest on the device itself, enabling full-disk encryption is the recommended step — it's a standard operating-system feature and means the storage is unreadable to anyone who doesn't have the device unlocked.