We can't read
your messages.

01Developer, scope & who controls your data

• Developer: QxChat team (open-source organization lqxp). Website getqxchat.com. Contact [email protected]. Security contact per /.well-known/security.txt.
• In scope: QxChat Android app (Google Play + direct APK), iOS, desktop (Tauri) and web clients, and the LQXP reference server (lqxp/lqxp) when operated by us as the qxch.at demo instance.
• Controller model (important for a self-hosted product): LQXP ships software; the operator of the server you connect to is the data controller for server-side data. Your own server → you are the controller. A friend's or community server → that operator. The qxch.at demo instance → us, under this policy with default settings.

A modified or malicious server is technically possible (the code is open). Client-side end-to-end encryption exists precisely so message content stays unreadable even then. The strongest setup is a server you operate yourself.

02Principles

• Data minimisation: no email, no phone number, no real-name field exists anywhere in the protocol.
• Purpose limitation: every datum below is used only to operate messaging, calls, sync and safety — never advertising.
• No sale: we do not sell, rent or trade personal data. No advertising, analytics, attribution or crash-reporting SDK is bundled in the app.
• Verifiability: server (lqxp/lqxp), clients and this site (lqxp/site) are MIT open source. Claims below map to documented protocol behaviour (see handbook).

03Data we collect and why

“Collect” means transmitted to, or stored on, the server or the app. The table lists Play Data Safety categories in parentheses.

Legal bases (EEA/UK): contract (operating your account and messages), legitimate interests (security, anti-abuse, integrity of the service), consent where you opt in (e.g. Tor mode, public STUN, Discord Rich Presence). You may withdraw consent by disabling the feature or deleting the account.

04Google Play Data Safety summary

Keep this page's declarations and your Play Console Data Safety form identical. If you change SDKs or data handling, update both before rollout.

05Android permissions — what each is for

All dangerous permissions are requested at runtime, in context, revocable anytime in system Settings. Denying a permission only disables the feature that needs it.

Production builds use HTTPS/WSS only. Cleartext HTTP is used solely for local self-hosted development over loopback (e.g. 127.0.0.1:4560 via adb reverse), never for production traffic. No background location, no contacts import, no SMS/call-log access.

06How data is used — and not used

• Operate accounts, rooms, DMs, voice/video signaling, file relay, device sync, profiles and blocking.
• Enforce rate limits and anti-abuse challenges (RAM-only windows, no profiling).
• Maintain the service (aggregate load/connection counters, RAM-only).
• Never: advertising, behavioral profiling, selling data, training ML models on your content, or sharing with data brokers.

07Encryption note (what “we can't read” precisely means)

• Private room payloads are encrypted on your device (AES-256-GCM, per-message keys via HKDF, ECDSA P-256 signatures). Servers check routing labels and size bounds — not plaintext.
• Live message buffers are RAM-only (~150/room, FIFO, lost on restart). There is no message-history table.
• Friend-request dead-drop (PHANTOM) and device sync (QxCloudSync) are blind relays: anonymous HTTP slots (24 h TTL) and same-user device envelopes the server cannot decrypt.
• Deliberate exception: an operator's optional official channel (default_room) requires the server to hold that room's key for redistribution — treat that room as operator-readable.

08Sharing & third parties

No advertising, analytics or attribution recipient exists. Discord Rich Presence is local IPC only (app version + OS, opt-out). The app opens only qxch.at/*, github.com/*, metrics.torproject.org/*, mailto: and tel: links.

09Storage & retention

• On your device: local vault (qxprotocol-messenger-v7: token, keys, recent rooms/messages ~500/room, settings) + extended history in IndexedDB (~2000 items). Sealed with PBKDF2-250k + AES-GCM when Client Lock is on; live secrets are RAM-only and wiped on lock.
• Ephemeral server-side (lost on restart): live room buffers, PHANTOM envelopes (24 h), challenge/rate-limit stores, preview cache (5 min), session counters.
• Persistent until deletion: account row, sessions, prekey bundles, block tags, encrypted roster blob, rooms table, uploaded files (files/uploads/, ~10 GB instance cap). SQLite file or operator's Postgres.
• Sessions expire after 7 days of inactivity. Poll votes are unlinkable hashes. Operator backups, if any, are the operator's responsibility and rotate on their schedule — ask them directly for third-party servers.

10Deletion — how to delete your account and data

• In the app (any platform, including Android): Settings → Profile → Delete account → confirm → enter password. The server then removes sessions, prekey bundle, block tags, the account row and your avatar/banner files, and disconnects all live sessions; the app wipes local state.
• Local-only wipe: Settings → Clear local data removes the on-device vault and history without touching the server account.
• Messages/rooms: deleting a message writes a tombstone and removes its attachment file; room owners can delete whole rooms; deleteMessagesOnLeave drops messages on leave.
• By email: [email protected] (demo instance qxch.at). State your username and server; we verify via a signed challenge or password-equivalent proof before acting. For third-party servers, contact that operator.
• Timelines: in-app deletion is immediate on the live server; RAM buffers vanish at latest on restart; backups (if the operator keeps any) expire on their rotation. Recovery words cannot be recovered after deletion — the account is gone.

11Security practices

• In transit: TLS (HTTPS/WSS) for production; E2EE content layer on top; TURN credentials never logged or committed.
• At rest: passwords and recovery phrases as Argon2id hashes; session tokens as SHA-256; no plaintext secrets persisted. Uploaded images stripped of EXIF/metadata chunks.
• Abuse resistance: fixed-window rate limits, quota tokens, VDF/CAPTCHA, dummy-hash login to block user enumeration, SSRF-hardened link previews.
• Limits: no software survives a compromised unlocked device or a malicious modified server for metadata. Keep devices locked, enable Client Lock, verify binaries via checksums/signatures, and self-host for maximum assurance.

12Children

QxChat is a general-purpose messaging app not directed at children under 13 (and not at under-16s where local law sets a higher digital-consent age). We do not knowingly collect data from children. If you believe a child provided data, contact [email protected] and the relevant server operator for deletion.

13International transfers

There is no central QxChat cloud: data resides where your chosen server (and its TURN/file storage) is hosted. Self-host to choose jurisdiction. Calls may traverse a TURN relay in another region when P2P fails; link previews cause a server-to-site fetch. Transfers rely on encryption, minimisation and, for EEA/UK users, the operator's safeguards (SCCs/adequacy) where applicable.

14Your rights

• Access: GET /api/auth/me returns your stored profile; the app shows the rest.
• Rectification: edit profile, status, username (max 1/week) in-app.
• Erasure / restriction / objection / portability: delete account, messages and rooms (§10); ask your operator about restriction; object to optional features by disabling them. No automated export endpoint yet — request a copy via your operator or [email protected].
• Always contact your server operator first — they hold your account row. You retain the right to complain to your supervisory authority (e.g. EU DPA, UK ICO) or use Play's reporting for the Play-distributed app.

15Changes to this policy

Material changes are committed in the open (lqxp/lqxp, client, site), announced in release notes where appropriate, and the effective date above bumped. Continued use after the effective date constitutes acceptance. Previous versions remain in git history.

16Contact

• Privacy & data requests (demo instance): [email protected].
• Security issues: [email protected], see /.well-known/security.txt. Do not post secrets or recovery phrases on Discord or GitHub.
• Community (no sensitive data): Discord · GitHub.