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 splintr.net/alice and splintr.net/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, catching impersonation attempts that TOFU alone would miss.
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 (say, alpha.example) and you visit a node's profile on beta.example. 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. This prevents replay attacks — 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 (again, with a signed request). Both servers now record the friendship between your nodes, and posts shared between friends will flow across the federation link.
Security model
All communication between servers happens over HTTPS, and every request is cryptographically signed using RSA keys. Beyond transport security, Splintr protects data at rest and verifies content authenticity across five layers of defense.
Click a ring to learn more.
Network and transport
The outermost layer controls who can reach the server and how connections are secured.
TLS enforcement ensures session cookies are only sent over encrypted connections. Federation requests between servers verify SSL certificates in production.
CORS uses dynamic single-origin echo against known peers only. Unknown origins receive no headers and the browser blocks the response. Wildcard origins are never used.
Rate limiting caps each remote server at 100 requests per hour, with every request logged. Login attempts are capped at 5 per 15 minutes per account.
Cookie security sets HttpOnly (no JavaScript access), SameSite=Lax (prevents cross-site attacks while allowing federation), and browser-session lifetime (no persistent cookies).
Authentication
Proving you are who you say you are, whether on your home server or visiting another one.
CSRF protection generates a unique token per session. Every API request must include this token, and the server validates it with timing-safe comparison.
Session fixation prevention regenerates your session ID on every login, so an attacker can't pre-set a known session and hijack it after you authenticate.
Federation tokens are single-use, scoped to one target server, and expire. When you visit another Splintr server, your home server issues a token that can only be verified once by the specific server it was issued for.
Federation JWTs use RS256 with 15-minute lifetime and audience scoping, so a token issued for server A can't be replayed against server B.
Authorization and privacy
Controlling what each person can see and do, based on your relationship with them.
Privacy levels range from Public through Friends of Friends, Friends Only, Friend Groups, and Selected Users to fully Private. Each post has its own privacy level, and feed queries filter per-post based on your relationship to the author.
Friendship validation checks both local and federated friendships. Cross-server friend-of-friend access delegates to a federation privacy mesh that queries remote servers.
Block propagation pushes blocks across the federation, so blocking someone on one server is respected network-wide.
Account delegation lets groups, bands, and businesses share accounts with role-based access: owners, admins, and contributors each have defined permissions.
Content integrity
Ensuring content hasn't been tampered with and can't inject malicious code.
Post signing uses Ed25519 to create a digital signature every time you post. Anyone reading your post can verify it hasn't been altered since you wrote it.
XSS prevention escapes all user input before rendering. The rendering pipeline runs htmlspecialchars first, then applies markdown formatting. Federated posts go through the same escape-first pipeline.
Plugin sandboxing runs third-party plugins in an iframe with strict sandbox attributes. Plugins can't access the host page, cookies, or storage.
Federation envelope signing uses RSA-2048 with timestamp validation, DNS identity verification, and deterministic key sorting to prevent replay and impersonation attacks.
Encryption
The innermost layer protects your data at rest and in transit between servers.
Profile encryption uses AES-256-CBC for sensitive fields like email, real name, and phone number. There is no plaintext email column in the database.
Message encryption uses per-conversation AES-256-GCM session keys, with each key encrypted per-recipient using their public key. Only conversation participants can decrypt messages.
Key wrapping protects your private keys with a key derived from your password using Argon2id. Private keys are never stored in plaintext.
Perfect forward secrecy uses ephemeral X25519 key exchange for sensitive server-to-server data. Compromising a server's long-term key doesn't expose past exchanges.
Memory safety zeroes key material from RAM immediately after use.
What Splintr doesn't do
Splintr is not trying to be everything. It 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.
Want to run your own server? See the Download page for setup instructions.
Slivr