Your Data & Ownership

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 the security pages explain the protections RSocial builds in, and the short, well-documented steps that are yours to take.

It's worth being precise about what "on your device" includes, because it's the whole stack, not just a copy of your posts. The graph store holding your posts, comments, and likes, the databases holding your accounts and media, the services that tie them together, and the web interface itself all run on that one machine. When you're on the same network, your data doesn't even touch the wider internet to reach you. The only time anything leaves the device is when you decide it should — exposing your instance for remote access, or making a backup and choosing where to store it. That's the sharp line that separates this model from the cloud: on a mainstream platform, "your data left your control" is the default and the exception is rare; here it's the reverse.

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.

Going deeper, for the technically curious. Every piece of your social activity is described with a small, published vocabulary under the namespace http://raelph.com/s/rsocial#. So a "like" isn't a hidden row in a company table — it's a plain, readable statement roughly of the form <post/123> — social:likedBy — <users/alice>. Related statements are grouped into named graphs (for example, one region of the store for posts, another for comments, another for likes), which keeps the data organised and makes bulk operations clean and predictable.

Those statements live in Apache Jena Fuseki, an open-source triple store that speaks SPARQL 1.1 — the W3C-standard query language for RDF. Reading your timeline is an ordinary SPARQL CONSTRUCT or SELECT query; creating a post is a SPARQL INSERT DATA; deleting one is a scoped DELETE. The important part for you is that these are open standards: any SPARQL-compliant tool, from any vendor, can run the exact same queries over a copy of your data. Your account records and the metadata for your images and videos sit beside the graph store in ordinary SQLite database files — the kind you can open in any free SQLite browser. From top to bottom there is no proprietary binary format holding your information hostage.