Privacy Policy

1. Introduction

Nocx is a privacy-first messaging application. We built it because we believe your conversations belong to you — not to advertisers, data brokers, or us.

This policy explains what data we collect, why we collect it, and what we do with it. We've written it in plain language because you shouldn't need a law degree to understand how your data is handled.

The short version: we cannot read your messages, we don't show you ads, we don't sell your data, and we collect as little as possible to make the app work. There is exactly one exception to “we cannot read,” it is opt-in and visible: a community owner may add a Nocx-hosted bot — Nocx runs that bot's keys and can read the channels it's in, every member sees it labeled, and self-hosting the same bot keeps Nocx locked out. Full statement in the Privacy Policy §5.4.

This policy applies to the Nocx application (available on Windows, Linux, macOS, and Android, with iOS in development), the Nocx website at nocx.app, and the server infrastructure that supports them.

2. Data Controller

The data controller for Nocx is:

Nocx
Registered in Bulgaria, European Union

Contact: privacy@nocx.app

As a company registered in Bulgaria, we operate under the European Union's General Data Protection Regulation (GDPR). This means you have strong, enforceable rights over your personal data regardless of where you live.

3. What Data We Collect

We're going to be specific here. There are no hidden categories.

3.1 Account Data (provided by you)

When you create an account, we store:

Username — your unique identifier on the platform
Email address — encrypted at rest on our servers, used only for account recovery and critical service notifications
Display name — the name others see (you choose this)
Avatar — your profile picture URL, if you set one
Profile bio — a short free-text description, if you set one (max 256 characters; stored as you wrote it so the server can render it in profile-lookup responses)
Status message — a short custom status string, if you set one (max 128 characters; stored as you wrote it for the same reason — only the user sets these)
Public encryption key — so other users can send you encrypted messages (see Section 5)

The bio and status message are self-published profile fields: you choose what they say and you can clear them at any time from Settings → Profile. They are never derived from your messages, contacts, or activity. If you want either field private, leave it blank.

Legal basis: Contract performance (GDPR Art. 6(1)(b)) — we need this to provide you with an account and the service.

3.2 Relationship Data

To make messaging work, our server stores:

Contact relationships — who you've added and who has added you
Group membership — which groups you belong to and your role in them

We do not store what you say in those conversations. We store only who is connected to whom so that messages can be routed.

Legal basis: Contract performance (GDPR Art. 6(1)(b)).

3.3 Encrypted Message Blobs (relay delivery)

When you send a message and the recipient is offline, the server temporarily stores an encrypted blob — a package of data that is meaningless without the recipient's private key. We cannot read it. We don't try. Every blob is deleted automatically after 7 days (or immediately if you delete your account). Delivery marks the blob as delivered but does not remove it early — it stays in the queue, still unreadable to us, until the 7-day timer expires.

In P2P mode, messages travel directly between devices and never touch our server at all. There is nothing for us to store.

Legal basis: Contract performance (GDPR Art. 6(1)(b)).

3.4 Metadata

Last seen timestamp — when you last connected to the server (you can control visibility of this to other users)
IP address — seen by our server during connections, as with any internet service. We do not log or permanently store IP addresses. If we ever introduce IP-based geo lookup, the IP address is discarded immediately after the lookup and is never stored.

3.5 Aggregated Anonymous Statistics

We may, in the future, collect aggregated, anonymized statistics to understand how the service is used at a high level — for example, approximate active-user counts or country distribution. If we ever introduce IP-based geo lookup for this purpose, the IP address is discarded immediately after the lookup and is never stored.

Any such statistics contain no personally identifiable information. They cannot be linked back to any individual user. We would use them solely to understand usage patterns and plan infrastructure.

Legal basis: Legitimate interest (GDPR Art. 6(1)(f)) — understanding aggregate service usage to maintain and improve infrastructure.

3.5.1 Opt-In P2P Reliability Telemetry

Default: OFF. Enabled only if you explicitly toggle Settings → Network → Reliability to ON.

When enabled, your device aggregates daily counters of how often the peer-to-peer fallback path succeeded or failed, and uploads the resulting daily snapshot once per day to our servers. This helps us detect and tune regressions in P2P reachability across the user population.

What is collected (16 counters per day):

Probe attempts to other users' devices, broken down by outcome: reachable, unreachable, no_route.
Probe latency, bucketed into six fixed bands: ≤100ms, ≤250ms, ≤500ms, ≤1000ms, ≤2500ms, >2500ms. Raw millisecond values never leave your device.
Fallback outcomes by stage: transport (success/fail), handshake (success/fail), ratchet-not-found, ciphertext-rejected.
Your client's build version (e.g. 0.9.876).
The UTC date the counters cover.

What is NOT collected:

No per-peer data — counters are population-level. We do not know whom you tried to reach, only how many of your attempts succeeded.
No per-message data — counters do not record what you sent or to whom.
No precise timestamps — only the UTC day boundary is uploaded; latency is bucketed.
No identifiers — the upload is authenticated for rate-limiting, but the user identifier is discarded at the storage layer. The database row is keyed by (build_version, UTC day) only; uploads from many users collapse into the same row.
No retention of your individual contributions — once your snapshot is merged into the population aggregate, no copy of the per-user input survives.

Schema is locked at version 1. Future additions require a privacy review and a coordinated client + server release. Older clients' uploads are accepted; payloads with an unknown schema version are rejected.

Storage cap on your device: at most 7 days of unsent snapshots in memory, FIFO-evicted. If uploads have been failing all week, the oldest day is discarded rather than retained indefinitely.

Revocation: flipping the toggle OFF immediately drops the in-memory ring buffer (both the active day and any sealed-but-not-uploaded snapshots). Snapshots already uploaded cannot be retracted from the population aggregate — they are no longer associated with you anyway.

Legal basis: Consent (GDPR Art. 6(1)(a)). You may withdraw consent at any time by flipping the toggle OFF; the effect is immediate.

3.6 What We Do NOT Collect

To be absolutely clear:

No message content — we cannot read your messages (they are end-to-end encrypted; the single opt-in, labeled exception is a Nocx-hosted bot's channels — Privacy Policy §5.4)
No analytics SDKs — no third-party analytics, telemetry, or behavioral tracking of any kind
No advertising trackers — no ad networks, no tracking pixels, no fingerprinting
No contact book uploads — we never access or upload your phone's contact list
No location data — we don't request or store your GPS location
No usage telemetry — we don't track which features you use, how long you use them, or when (the optional P2P reliability counters in §3.5.1 are aggregate-only and require explicit opt-in)

4. How We Use Your Data

Data	Purpose
Username, display name, avatar	Let other users find and identify you
Email (encrypted at rest)	Account recovery, critical service notifications
Public key	Enable end-to-end encryption between users
Contact relationships	Route messages to the right people
Group membership	Manage group conversations
Encrypted relay blobs	Deliver messages when recipients are offline
Last seen timestamp	Show online status to your contacts (configurable)
Aggregated anonymous statistics	Infrastructure planning, understand overall service health

We do not use your data for:

Advertising or ad targeting
Profiling or behavioral analysis
Selling to third parties
Training AI or machine learning models

5. End-to-End Encryption

Nocx messages are end-to-end encrypted with modern, standards-track cryptography. Direct messages are protected by the Double Ratchet protocol (initialized via X3DH), an openly-specified algorithm family designed for forward secrecy and post-compromise security. Messages in channels and groups use a per-parent vault key that is rotated whenever membership changes; the vault key is sealed via HPKE (RFC 9180) into a single per-epoch wrap blob with one slot per active member, and each message is authenticated-encrypted under that vault key. The underlying primitives are Curve25519 elliptic-curve key agreement and ChaCha20-Poly1305 authenticated encryption. Here's what that means in practice:

Your encryption keys are generated on your device. Your private key never leaves your device unless you explicitly create an encrypted backup.
Messages are encrypted before they leave your device and can only be decrypted by the intended recipient.
The server handles only encrypted blobs. Even if our servers were compromised, an attacker would get ciphertext that is computationally infeasible to decrypt without your private key.
In P2P mode, messages travel directly between devices over an encrypted channel. The server is not involved at all.
Voice and video calls use WebRTC with DTLS-SRTP encryption. When a TURN relay server is used (to traverse firewalls), it forwards encrypted media packets — it cannot decrypt the audio or video content.

We designed the system so that we are unable to comply with requests to hand over message content — because we don't have it and cannot obtain it.

5.1 Removal from Groups, Channels, and Communities

When a member is removed from a group, channel, or server — whether by being kicked, banned, or leaving voluntarily — their access ends immediately:

They can no longer open the group, channel, or server in the app.
They can no longer send messages to it.
They can no longer receive new messages from it. The underlying encryption key is rotated as part of the removal, so their client has no way to decrypt anything sent after they were removed.
Access revocation applies to the account, not individual devices. Every device the removed user is logged into loses access, and any device they link to that account in the future will also have no access.

5.2 Blocking in Direct Messages

Direct messages use a different model. When you block someone in a one-to-one conversation:

Neither of you can send further messages to the other.
Both of you retain the conversation history that existed at the time of the block, so you can still scroll back through earlier messages. The blocked user appears in your conversation labelled as "Blocked user."
Unblocking restores the ability to send messages. It does not retroactively deliver anything that was attempted during the block.

5.3 Webhooks: the transit carve-out, stated plainly

A community can create a webhook so an outside service — a CI pipeline, a GitHub repository, a cron job — can post into a channel. This is the single place in Nocx where content reaches our server before it is encrypted, and we would rather you read it here than discover it.

An external sender speaks ordinary, unencrypted HTTP. It has no Nocx account, no keys, and no way to encrypt for a channel. So the payload arrives at our server in the clear. Here is exactly what happens next, and what we guarantee about it:

The payload is sealed on arrival. The instant it is received, the request body is encrypted (HPKE, RFC 9180) to the identity key of the bot that the webhook is bound to — a key our server does not hold and cannot derive. Only the encrypted result is written anywhere.
The plaintext is never stored and never logged. It exists only in the memory of the process handling that one request, for as long as it takes to seal it. It is not written to the database, not written to a log line, not attached to a metric.
We cannot read it afterwards, and neither can anyone who takes our database. The sealed payload sits in the delivery queue as opaque bytes, indistinguishable from any other queued message.
The bot — not the server — posts the message. The bot runs on a machine the community controls (or, for a Nocx-hosted bot, on our infrastructure — §5.4), holds the channel's key, opens the sealed payload, encrypts it under the channel's current key, and posts it as an ordinary channel message.

We call this a transit property, and we want to be precise about how it compares: it is weaker than message end-to-end encryption, where content is encrypted on your device and our server never sees it in any form — for that one instant, a webhook payload is present in our server's memory. It is stronger than what a conventional chat service does with the same webhook, where the payload is stored in plaintext and served to readers from that plaintext. No design can remove that instant while still accepting webhooks from generic third-party senders. If that instant is unacceptable for a particular payload, do not route that payload through a webhook. Everything else in Nocx — every message you or another member sends — is encrypted on the device before it reaches us.

Two operational consequences follow from the bot doing the posting, and they are properties of the design rather than faults: while the community's bot is offline, webhook posts wait in the delivery queue and are dropped after 7 days; and a bot cannot post at all until a community admin has rotated the community key to include it. Webhook traffic is notification-grade, not history-grade.

5.4 Nocx-hosted bots: the operator carve-out, chosen and visible

All messages in Nocx are end-to-end encrypted, and Nocx cannot read them. There is exactly one exception, and it is opt-in and visible: a community owner may add a Nocx-hosted bot to their community. A hosted bot runs on Nocx's infrastructure and Nocx holds its keys, so Nocx can read what that bot can read — the community's regular channels, plus any private channels the bot is explicitly added to, from the moment the bot joins and never anything earlier. The owner sees exactly this in plain language before the bot is created, every member sees the bot badged as NOCX-HOSTED, and content in that scope is within reach of legal process served on Nocx. Communities with no Nocx-hosted bots — including those running self-hosted bots — keep the full guarantee: Nocx holds no keys and can read nothing. The message database and serving path hold no decryption keys in either case.

Precisely because a bot is an ordinary member with keys, this changes who operates one endpoint, not the encryption: end-to-end encryption is intact in both hosting models, and a self-hosted bot (the free, unlimited default) leaves Nocx locked out entirely. A hosted bot's key material lives in an isolated, encrypted per-bot store on our fleet — never in the message database or the serving path — and is destroyed when the bot is deleted; suspending a hosted bot (for example after a subscription downgrade) stops it but retains its keys until you delete it (§8.3).

6. Data Storage and Retention

6.1 Server-Side Storage

Data	Retention
Account data	Until you delete your account
Contact relationships	Until you remove the contact or delete your account
Group membership	Until you leave the group or delete your account
Encrypted relay blobs	Auto-deleted after 7 days, or immediately when you delete your account. Delivery marks a blob delivered but does not remove it early.
Opt-in crash diagnostics	Only if you turn on crash diagnostics; stack-only (program addresses + app/OS version), never message content or keys, scrubbed on your device and previewable before sending. Deleted when you delete your account.
Server-side diagnostic events	Crypto-operation shape metadata we keep to debug delivery and sync problems (which operation ran, its outcome, opaque correlation IDs) — never message content, keys, or seeds, and any identity appears only as a one-way fingerprint (a truncated hash). Auto-deleted on a rolling 7-day window, plus a per-segment size cap.
Aggregated anonymous statistics	Retained indefinitely (contains no personal data)

Our servers are hosted in the European Union. Account data (including your email address) is encrypted at rest.

6.2 On-Device Storage

Nocx stores your messages, keys, and settings locally on your device. This data stays on your device and is under your control.

Message history — stored locally in an encrypted database on your device
Encryption keys — stored locally, never transmitted (unless you create an encrypted backup)
Debug logs — the app maintains local debug logs: an in-memory buffer of the most recent 2,000 lines, plus an on-disk log file (nocx.log) that is trimmed back to its most recent ~2,000 lines whenever it grows past ~2,500. In production builds, these logs contain no personally identifiable information. They exist solely to help diagnose issues if something goes wrong, and they never leave your device unless you share them.

If you uninstall the app, local data is removed by your operating system.

6.3 Crash Diagnostics (opt-in, off by default)

Crash diagnostics are off by default. If you turn them on (Settings → Privacy → Crash diagnostics), and the app crashes, Nocx prepares a stack-only diagnostic and lets you preview the exact data before anything is sent. A crash diagnostic contains only:

the crash type and a short, scrubbed error message,
the program's call stack as a list of memory addresses (numbers — not the contents of memory),
your app version, build identifier, operating system, and CPU architecture.

It never contains your messages, drafts, file contents, file names, encryption keys, or any snapshot of the app's memory. A scrubbing pass on your device removes file paths, usernames, access tokens, and identifiers before the preview. We do not use any third-party crash-reporting or telemetry service — diagnostics you choose to send go only to our own servers, and we symbolize the addresses against private build symbols we keep server-side. You can turn this off at any time; reports are deleted when you delete your account.

7. Third-Party Services

We use a small number of third-party services to operate Nocx. None of them have access to your message content.

Service	Purpose	Data they see
Cloudflare	CDN, DNS, DDoS protection	IP address, request metadata (standard for any website/API behind Cloudflare)
SMTP provider	Transactional email (account verification, password reset)	Your email address (only when sending you a specific email)
Coturn (TURN relay)	Relay media for voice/video calls when direct connection fails	Encrypted media packets and IP addresses of call participants

We do not use any third-party analytics, advertising, or tracking services.

Cloudflare's privacy policy: https://www.cloudflare.com/privacypolicy/

8. Your Rights Under GDPR

As a user of Nocx, you have the following rights under the General Data Protection Regulation. These apply to all users, regardless of location — we extend GDPR rights to everyone.

8.1 Right of Access (Art. 15)

You can request a copy of all personal data we hold about you. You can also export your data directly from within the app at any time.

8.2 Right to Rectification (Art. 16)

You can update your username, display name, email, and avatar directly in the app. If something is incorrect and you can't fix it yourself, contact us and we'll correct it.

8.3 Right to Erasure (Art. 17)

You can delete your account at any time from within the app. Deletion runs as a single database transaction that removes or scrubs every piece of data tied to your account:

Deleted immediately:

Contacts (both directions — your list and anyone who had you as a contact)
Group and server memberships (and any role assignments)
Push notification tokens and registered devices
Pending encrypted relay blobs (both as sender and recipient)
Pre-key bundles, key backups, TOTP backup codes
Active message requests, email verification tokens, password reset tokens
Subscription records and server boosts
Your uploaded avatar files on our storage

Scrubbed (the row is kept but every personal field is blanked):

Your core users row remains so that foreign-key references from audit logs and server content stay valid. Your email becomes deleted_<anonymous-id>, and every other PII field (password hash, display name, description, status message, avatar, public key, TOTP secret) is cleared. The remaining row is effectively anonymous.

Intentionally retained (no personal data):

Audit log entries mentioning your account as an actor remain, referring to the scrubbed (anonymous) row. This is regulatory retention, not user content.
Any custom emoji or stickers you uploaded to a server stay with the server (they're the server's content, not yours); the created_by reference points at the scrubbed row.

The action is irreversible. You can always export your data first (Art. 20, below).

8.4 Right to Restriction of Processing (Art. 18)

You can request that we restrict processing of your personal data in certain circumstances (e.g., while we verify accuracy of data you've contested).

8.5 Right to Data Portability (Art. 20)

You can export all your data in a machine-readable format directly from the app (Settings → Privacy → Export my data) or by calling GET /api/users/me/export from any tool you trust. The export is JSON and includes:

Profile fields (username, display name, public key, subscription tier, avatar hash)
Contact list (both your contacts and any users who listed you)
Group memberships (IDs and roles only — message content is end-to-end encrypted and never touches us)
Community memberships and role assignments

Message bodies are not in the export because they never exist on our servers in readable form. You can export your locally stored messages from the app's own export tool; they live on your device.

In addition to the JSON export above, the app offers an encrypted .nocxbackup archive at Settings → Account Backup for device-loss protection: contacts, channel memberships, and (opt-in) ratchet state, message history, and identity keys, sealed with a passphrase you choose using Argon2id and XChaCha20-Poly1305 entirely on your device. We never see the passphrase or the file contents; restoring on a new device uses the same passphrase via Settings → Account Restore (or the "Restore from backup" entry on the login screen).

8.6 Right to Object (Art. 21)

You can object to processing based on legitimate interest (Section 3.5 — aggregated statistics). If you object, we will stop including your usage in aggregate counts.

8.7 Right to Lodge a Complaint

If you believe we're handling your data improperly, you have the right to lodge a complaint with the Commission for Personal Data Protection of the Republic of Bulgaria (CPDP) or with the supervisory authority in your EU member state of residence.

Commission for Personal Data Protection (Bulgaria)
Website: https://www.cpdp.bg

How to Exercise Your Rights

Most rights can be exercised directly in the app (account settings, data export, account deletion). For anything else, email us at privacy@nocx.app. We will respond within 30 days as required by GDPR.

9. Data Transfers

Our servers are located in the European Union. If you access Nocx from outside the EU, your data travels to our EU servers.

For third-party services that may process data outside the EU (such as Cloudflare), we ensure appropriate safeguards are in place as required by GDPR Chapter V, including Standard Contractual Clauses (SCCs) where applicable.

In P2P mode, messages travel directly between you and your conversation partner. If you are in different countries, your data crosses borders directly between your devices — not through our servers.

10. Children's Privacy

Nocx is not intended for children under the age of 13 (or 16 in the European Union, per GDPR Art. 8). We do not knowingly collect personal data from children. During registration, users must confirm they meet the applicable minimum age for their jurisdiction.

If we become aware that a user is under the minimum age, we will delete their account and associated data promptly. If you believe a child under the minimum age is using Nocx, please contact us at privacy@nocx.app.

11. Cookies and Tracking

The App

The Nocx application does not use cookies, tracking pixels, fingerprinting, or any other tracking technology. There are no analytics SDKs embedded in the app.

The Website (nocx.app)

The Nocx website may use essential cookies strictly necessary for the website to function (e.g., session management if you log into a web portal). We do not use any third-party tracking cookies, analytics services, or advertising cookies. The site uses localStorage only to persist your preferred theme palette — that data never leaves your browser.

No cookie consent banner is required because we don't use any non-essential cookies.

12. United States Users — Additional Rights

California (CCPA / CPRA)

If you are a California resident, you have additional rights under the California Consumer Privacy Act (CCPA) and the California Privacy Rights Act (CPRA):

Right to Know: You can request what personal information we collect, use, and disclose. See Section 3 of this policy for a complete list.
Right to Delete: You can request deletion of your personal information. Use the "Delete Account" feature in Settings, or email privacy@nocx.app.
Right to Opt-Out of Sale: We do not sell your personal information. We have never sold personal information. We will never sell personal information. No opt-out is necessary because there is no sale.
Right to Non-Discrimination: We will not discriminate against you for exercising any of your privacy rights.
Right to Correct: You can correct inaccurate personal information through your profile settings.
Right to Limit Use of Sensitive Information: We use sensitive personal information (account credentials) only to provide the service, not for profiling.

Categories of personal information collected (per CCPA definitions):

Identifiers: username, email address, display name
Internet activity: connection timestamps (not browsing history)
We do NOT collect: real name, physical address, phone number, financial information, biometric data, geolocation, browsing history, or purchasing history

Shine the Light (California Civil Code § 1798.83): We do not disclose personal information to third parties for their direct marketing purposes.

To exercise your California privacy rights, contact privacy@nocx.app with the subject line "CCPA Request." We will verify your identity and respond within 45 days.

Other US States

Several US states have enacted privacy laws (Virginia CDPA, Colorado CPA, Connecticut CTDPA, Utah UCPA, and others). While the specific rights vary by state, Nocx provides the same core rights to all US users:

Access your data (Settings → Export Data)
Delete your account and all associated data (Settings → Delete Account)
We do not sell personal data to any third party
We do not use personal data for targeted advertising
We do not process personal data for profiling

If your state grants additional rights not covered above, contact privacy@nocx.app and we will accommodate your request.

13. Changes to This Policy

If we make changes to this policy, we will:

Update the "Last Updated" date at the top
Notify users through the app for any material changes
Post the updated policy at nocx.app/legal/privacy

For significant changes that affect your rights or how we handle your data, we will give you 30 days' notice before the changes take effect and ask for your acknowledgment.

We will never quietly change this policy to start collecting more data. That would defeat the entire point.

14. Contact Us

For any privacy-related questions, concerns, or to exercise your rights:

Email: privacy@nocx.app

We aim to respond to all privacy inquiries within 7 business days and will resolve GDPR-related requests within the legally required 30 days.

Nocx is built on the principle that privacy is a right, not a feature. If you have questions about anything in this policy, we're happy to explain further.