Slivr
Slivr
Common questions about using Slivr.
Splintr is a federated social network that anyone can host on their own server. You own your data, control who sees it, and can connect with people on other Splintr servers without giving up that control.
If this server allows registration, click Sign Up in the navigation bar. You will need a username, email address, and password. Some servers require an invitation from an existing member.
In Splintr, your account is called a node — it is your identity on the network. A server that hosts multiple user accounts is called a cluster. A server can also be set up as a single node, where one person owns the entire site. Either way, your node can connect with nodes on other servers through federation.
From your feed, type in the editor at the top and press Post. Posts support Markdown formatting: **bold**, *italic*, # Heading, and links with [text](url).
Yes. Use the media uploader in the post editor to attach images. Uploaded media is stored on your server and served through signed URLs for privacy.
You choose per-post or set a default in your privacy settings. Options include public, friends only, specific friend groups, selected users, and private. Friend groups let you share with a curated list — for example, a "Close Friends" group — without making content visible to your entire friend list.
Visit their profile on their server. If you are logged in to your home server, you can send a friend request through the federation handshake — your servers will securely verify each other's identity and establish the connection between your nodes.
See the About page for more on how federation works.
You will not be able to see new posts from nodes on that server until it comes back. Your local data — your own posts, your friend list — is unaffected. Federation is designed to degrade gracefully when remote servers are unavailable.
Yes, at multiple levels. All connections between servers use HTTPS (TLS). Sensitive profile data like email addresses are encrypted at rest in the database, and your password is hashed with bcrypt.
Every post is cryptographically signed with your personal Ed25519 key, which lets anyone verify that you are the real author and that the content has not been tampered with — especially useful for posts shared across federated servers.
Private messages use end-to-end hybrid encryption: each message is encrypted with a random session key, and that session key is then encrypted separately for each recipient using their public key.
Once logged in, open Privacy from the sidebar menu. You can control who sees your profile, posts, friends list, and bookmarks. Settings apply to both local and federated visitors.
Splintr uses multiple layers of security to protect your account and data. Click any card to see how it works.
TLS enforcement — cookies are HTTPS-only when TLS is available. Federation SSL verification enforced in production.
CORS — dynamic single-origin echo against known peers. Unknown origins get no headers. Wildcard never used.
Rate limiting — 100 requests/hour per remote server, 5 login attempts per 15 minutes. All requests logged.
Cookies — HttpOnly, SameSite=Lax, browser-session lifetime. No persistent cookies.
CSRF tokens — per-session, timing-safe comparison, origin header cross-check on every API call.
Session fixation — session ID regenerated on every login, old session destroyed.
Federation tokens — single-use, server-scoped, expiring. Consumed immediately on verification.
Federation JWTs — RS256, 15-minute lifetime, audience-scoped to prevent replay across servers.
Privacy levels — Public through Private, per-post. Feed queries filter every post by your relationship to its author.
Friendship checks — local and federated. Friend-of-friend access uses a cross-server privacy mesh.
Block propagation — blocks sync across the federation so they're respected network-wide.
Delegation — shared accounts with owner/admin/contributor roles and optional post approval.
Post signing — Ed25519 signature on every post. Verified on read. Revoked keys show "unsigned," not "tampered."
XSS prevention — escape-first rendering pipeline. All user input goes through htmlspecialchars before markdown processing.
Plugin sandboxing — strict iframe sandbox, postMessage bridge, manifest permission allowlist, server-side enforcement, storage quotas.
Federation envelopes — RSA-2048 signed, 5-minute timestamp window, DNS identity verification.
Profile fields — AES-256-CBC for email, name, phone. No plaintext email column in the database.
Messages — per-conversation AES-256-GCM session keys, encrypted per-recipient with their public key.
Key wrapping — private keys wrapped with Argon2id-derived key from your password. Never stored in plaintext.
Perfect forward secrecy — ephemeral X25519 key exchange for server-to-server data. Past exchanges stay safe if a key is compromised.
Memory safety — sodium_memzero wipes keys from RAM immediately after use.
Security events — auth failures, CSRF violations, and gateway denials logged with identity and IP.
Admin audit trail — every admin action logged with who, what, when, and target.
Federation tracking — every inbound request logged by remote node and type.
API usage — all gateway requests logged with action, timing, success/failure, and client IP.