What the server sees, and what it doesn’t.

LockerChat is built and operated by Spergs, LLC, a Florida limited liability company. You can reach us at privacy@spergs.com for anything privacy-related: data export requests, deletion questions, or to point out something on this page that isn't accurate.

We are the data controller for everything described below. We don't sell, rent, or trade your data, and we don't run ads. That isn't going to change.

What we can't see: the contents of your messages, the contents of your attachments, group topics, profile pictures, or the contents of any backup you make. Those are encrypted on your device before they reach us; we hold ciphertext only.

What we can see: routing metadata. Your username, which groups you're in, when messages were sent and to whom, when they were read, what emoji reactions exist, and the timing of the above. The protocol uses this information today; we're working to shrink how much of it the server has to know.

Third parties: for push notifications we hand a small payload (your device's push token plus the group_id and message_id of the new message) to Apple, Google, or Expo. Nothing else leaves our servers.

Account

• Your chosen username (a display version + a lowercased lookup key).
• An Argon2id hash of your password (never the password itself).
• A random user id we generate so nothing else has to be your username.

Devices

• The public keys of each device you sign in on (X25519 for messages, Ed25519 for signatures).
• When the device was added and when it was last seen.
• A session token issued at sign-in. We only ever store its SHA-256 hash; the original lives on your device.

Messages

• The ciphertext body, encrypted per-recipient with libsodium's sealed-box. We can't decrypt it.
• The metadata we route on: sender user id, sender device id, recipient device ids, group id, timestamp, optional parent-message id for threads, and an optional expiry time.
• Delivered-at and read-at timestamps for each recipient device (when it fetched the envelope and, optionally, when it marked the message read). Kept for at most 7 days; an hourly sweep nulls anything older.
• Encrypted read-receipt relay. When a recipient marks a message read, the notification forwarded to other interested devices (the sender's other devices, the reader's other devices) is a per-recipient sealed-box envelope. The server forwards opaque ciphertext only and never opens it. Recipient devices that are offline at relay time miss that notification entirely.
• Emoji reactions are now end-to-end encrypted: each add/remove event is a per-recipient sealed-box stored as an opaque envelope; the server can't see the emoji, which message, or even whether it's an add or remove. Clients fold the decrypted events into local reaction state.
• Whether a message is pinned or starred, by whom, when.

Attachments

• The ciphertext bytes on disk on our server, plus its size, uploader, and the message it belongs to.
• Orphan attachments (no associated message) are deleted every six hours.

Groups

• Group name, description, membership list (with each member's role and mute state), and creation time. These are plaintext.
• Group topic and avatar are encrypted per-recipient (server holds ciphertext only); the "set-at" timestamp is plaintext.

Push tokens

• If your device opts into notifications, we store the platform-specific push token (APNs, FCM, or Expo) so we can forward new-message pushes to the right device. Cleared when you revoke the device.

Invites

• Invite codes you create or redeem, the issuer and redeemer, and the timestamps. Codes expire and are single-use.

Backups (optional)

• If you set a backup passphrase, we store a ciphertext blob of your history plus the salt and Argon2id parameters needed to derive the key. We never store the passphrase itself. If you lose the passphrase, the backup is unrecoverable.

• No phone numbers, email addresses, or real names. We don't ask for them at sign-up and you don't need them to use the app.
• No contact-book or address-book sync. The app never reads your contacts.
• No analytics, behavioural tracking, Sentry, or third-party advertising pixels. There is no SDK on the page or in the app that phones home.
• No IP-address logging at our application layer. Standard nginx access logs may capture connection IPs on the reverse proxy; those are rotated and not joined to your account.
• No typing-indicator records. "X is typing…" is sent over the live socket and not written to disk.

Two categories of third parties are involved:

• Push providers (Apple APNs, Google FCM, Expo). When you receive a message, we send your device's push token plus a small payload (the group_id, message_id, and sender username) to the relevant push provider. The provider delivers it to your device. Apple and Google retain push tokens and delivery metadata per their own policies.
• Hosting (UK-based VPS). Our servers run on a UK-based virtual private server. Standard hosting operations involve our hosting vendor having physical access to the underlying hardware. They do not have credentialed access to our service.

We don't share data with anyone else. We never have.

On our servers (United Kingdom): a Postgres database with the metadata listed above, plus an encrypted attachment blob store. Nightly database backups encrypted at rest.

If you're outside the UK (including the United States and the European Economic Area), using LockerChat means your routing metadata transits to and rests on our UK servers. The contents of your messages are end-to-end encrypted on your device before we see them, so the cross-border transfer is of the metadata listed in "What we collect", not message content. The UK is a jurisdiction the European Commission has formally recognised as providing an adequate level of data protection, so EU/EEA users transferring data here are covered by that finding; for US users, we rely on the international transfer provisions of UK GDPR.

On your devices:

• On mobile, your device's secret encryption keys are stored in your OS's secure storage (iOS Keychain, Android EncryptedSharedPreferences), hardware-backed where the device supports it.
• On web, your device's secret encryption keys are wrapped at rest in browser IndexedDB under a passphrase you choose at sign-in (Argon2id-derived key + secretbox). An attacker who copies the IndexedDB store has to brute-force the passphrase to lift the keys. We cannot protect against anything with code execution inside an unlocked tab (extensions, XSS) since those can read the unlocked keys from memory.
• Your decrypted message history is held in memory while you use the app, and (on mobile) cached locally in a SQLite database to support offline reading.

• Messages stay until you delete them or until their per-group expiry timer fires. The expiry sweep runs every minute.
• Attachments are deleted with the message they belong to. Orphans are deleted every six hours.
• Sessions last until you sign out or revoke the device. No silent expiry today.
• Devices live until you (or another signed-in device on your account) revoke them.
• Delivered-at and read-at timestamps are nulled by an hourly sweep once they're older than 7 days.
• Push tokens are kept while the device is active and dropped when the device is revoked.

When you delete your account, we soft-delete your user record, zero your password hash, and cascade-delete every device, session, push token, prekey, message envelope addressed to you, group membership, starred-message row, reaction, and backup blob. Two things survive by design:

• Your username is kept (without password or device records) so nobody else can re-register it and impersonate you.
• Messages you sent stay visible to the other people in those groups. They already have the plaintext on their devices and we have no way to reach into someone else's history. Your sender slot becomes an "unknown sender" tombstone.

You can:

• Export your history using the in-app encrypted backup. It contains your decrypted messages and group state.
• Delete your account from Settings → Account → Delete account.
• Change your username or avatar from Settings.
• Email privacy@spergs.com for anything else: a copy of the metadata we hold on you (UK GDPR / EU GDPR / CCPA access), correction, deletion confirmation, or to raise a complaint.

We try to respond to email requests within 30 days.

If you're in the UK and aren't happy with how we've handled a data request, you can complain to the Information Commissioner's Office (ICO). EU/EEA users can complain to their national data protection authority. We'd appreciate the chance to fix things first, but it's your right either way.

LockerChat is for adults. Our terms of service require you to be at least 18 years old to register. We don't knowingly collect data from anyone under 18; if you believe we have, email privacy@spergs.com and we'll delete it.

We aren't done. Things we're actively working on to reduce metadata exposure before the public 1.0 release:

• Anonymous-credential sends. Validate a sender's permission to post without knowing who they are. The biggest remaining metadata-graph improvement; needs a real blinded-credential protocol on top.

Already shipped since v0.1:

• Browser-side key wrapping. The web client's device secret keys sit wrapped behind a user-chosen passphrase, so an attacker with IndexedDB read access can't lift them without bruteforcing Argon2id.
• Encrypted read-receipt relay. The relay envelope forwarded to other interested devices when a message is read is now a per-recipient sealed-box. The server forwards opaque ciphertext only. (The bare read_at timestamp on the recipient's envelope row is still recorded server-side and nulled by the 7-day sweep noted above.)
• Encrypted reactions. Each react/unreact event is a per-recipient sealed-box envelope; the server stores the opaque ciphertext for offline catch-up but can't read what was reacted to or which emoji.
• Reactions backfill on join. When a new member joins a group, existing members re-fan-out their reaction history to the newcomer's devices, so the new member sees pre-join reaction state too. Same envelope shape as a fresh react; one elected sender per join keeps fan-out bounded.
• Sealed sender for receipts and reactions. The WS relay frames for those events no longer carry sender identity in cleartext; recipients read it from the decrypted payload. The server still knows internally via the session that sent the frame; closing that gap is on the "what's next" list under anonymous-credential sends.
• Sealed sender for messages. Same per-recipient sealed-envelope pattern extended to the main message-send path. Each envelope is signed with the sender's Ed25519 key inside the encrypted payload; recipients verify the signature and derive sender identity from a local pubkey cache instead of a cleartext field on the wire. The server still records the real sender internally (via the authenticated session) for edit/delete ACL; that's the gap anonymous credentials would close.
• Aggressive sweeps. An hourly job clears delivered-at timestamps on envelopes older than 7 days. (Read-at is now off-server entirely; see above.)

When any of the above ships, this page is the first thing updated.

If something material changes, we'll update the "Last updated" date at the top and post a notice in the app. We won't make changes that surprise existing users. If a change would expand what we collect or who we share with, you'll see it before it lands.

Spergs, LLC
privacy@spergs.com