About Splintr
A federated social network where you own your data and your server.
Nodes and clusters
In Splintr, each user account is called a node. A node is your identity on the network — it holds your profile, your posts, your friend connections, and your privacy settings.
A Splintr server can be set up in two ways. A single-node server is a personal site where one person owns the whole domain. A cluster is a server that hosts multiple nodes — several people each with their own account, like example.com/alice and example.com/dan. Under the hood, both run the same software and speak the same federation protocol.
What is federation?
Most social networks are centralized — one company runs the servers, stores your data, and decides the rules. Splintr is different. Anyone can run their own server, and servers talk to each other so nodes on different servers can connect as friends, see each other's posts, and interact — all without needing accounts on every server.
Think of it like email: you can send a message from Gmail to Outlook because they speak the same protocol. Splintr servers work the same way. Your node lives on your home server, and federation handles the rest.
How servers discover each other
Every Splintr server publishes a discovery endpoint at /.well-known/splintr. This is a small JSON file containing the server's public key and basic metadata. When one server needs to talk to another for the first time, it fetches this endpoint to learn how to verify that server's identity.
Public keys are cached for 24 hours to reduce network traffic. This follows a trust-on-first-use (TOFU) model — once a server has seen another server's key, it remembers it. For stronger assurance, a server administrator can publish their public key in a DNS TXT record. When present, receiving servers will cross-check the handshake key against the DNS-published key and reject any mismatch.
The friend request handshake
Adding a friend across servers involves a multi-step handshake between the two servers that ensures both users consent and that identities are genuine.
Step 1 — You visit a remote profile
You are logged into your home server and you visit a node's profile on another server. Your server generates a single-use federation token that proves you are who you say you are.
Step 2 — The handoff
Your browser is redirected to the remote server with a signed handoff token. The remote server contacts your home server to verify the token is valid and hasn't been used before. Each token works exactly once.
Step 3 — You send the friend request
Once your identity is verified, you can view the remote user's public profile and send a friend request. The request is signed with your home server's private key so the remote server can confirm it's authentic.
Step 4 — The remote user accepts
When the other user accepts, their server notifies yours with a signed request. Both servers record the friendship, and posts shared between friends flow across the federation link.
Security model
All communication between servers happens over HTTPS, and every request is cryptographically signed. Beyond transport security, Splintr protects data at rest and verifies content authenticity.
Encryption
Profile data is encrypted with AES-256-CBC. Messages use per-conversation AES-256-GCM session keys, encrypted per-recipient with X25519 public keys. Private keys are wrapped with Argon2id-derived keys and never stored in plaintext. Server-to-server traffic travels over HTTPS, where modern TLS gives every connection its own short-lived key.
Content integrity
Posts are signed with Ed25519 so readers can verify content hasn't been tampered with. All user input is escaped before rendering. Plugins run in sandboxed iframes with strict permissions. Federation envelopes are signed with RSA-2048 and verified against DNS-published keys.
Privacy controls
Each post has its own privacy level — from Public through Friends of Friends, Friends Only, Friend Groups, and Selected Users to fully Private. Cross-server friend-of-friend access is verified through a federation privacy mesh. Blocks propagate across the network.
What Splintr doesn't do
Splintr focuses on direct connections between people you know, not on algorithmic feeds, advertising, or viral content. There is no central authority that can shut down your node or change the rules. If you disagree with how a particular server is run, you can move to another one or start your own.
What splintr.net counts
This site keeps a few anonymous counters so we know which releases and plugins people use. It counts; it doesn't track.
- Downloads — one tally per file per day (how many downloads, and roughly how many different people).
- Active servers by version — Splintr servers with update checks turned on ask this site once a day whether a new release exists. That request includes the server's Splintr version, which is tallied per day.
- Plugin installs — when a server installs a plugin from the directory, it reports the plugin's name and version, nothing else. Only when update checks are on.
To tell repeat visits apart for one day, the site keeps a scrambled code made from your IP address and browser name mixed with a random value that's thrown away after two days. IP addresses themselves are never stored, there are no cookies, and nothing links one day to the next. Server operators can turn update checks off in Admin → Settings; nothing is sent after that.
For the full technical details, see the Security Architecture document.