Privacy & Trust

What Recline knows.
What it doesn't.

Privacy isn't the whole story — it's the trust layer that makes private communities actually private. This page is the unvarnished version: what we store, how encryption works, where the current gaps are, and what we're doing about them.

Alpha software — we're honest about current limitations. This page is updated as the model improves.

TL;DR

The short version.

Three things Recline is built around. The rest of this page is the detail.

Encrypted by architecture
Channel messages are encrypted in your browser before they leave your device. The server stores ciphertext it cannot read. Direct messages use ECDH key exchange — Recline is a blind relay. This is a technical constraint, not a policy claim.
No email. No phone. No ID.
Signup requires a username and a password. Nothing else is asked, at signup or at any point after. There is no email field in the database. No phone number field. No way to tie your account to your real-world identity unless you choose to share it yourself.
Open-source client
Every line of client code is public on GitHub under AGPL-3.0. Every function that handles encryption, key derivation, and message sending is readable and auditable. The code is the contract — not the policy page.

Data model

What the server stores.

Every piece of data that touches Recline's servers — and what form it's in when it arrives.

⚠ Stored in plain text
Your username
Stored as-is. Used for login and display. Choose it accordingly — there is no account recovery tied to an email.
Message timestamps
When messages were sent. Not encrypted — message timing is visible to the server as metadata.
Community and channel membership
Which communities and channels your account belongs to.
Online presence and activity status
Whether you're online, and when you were last active.
Message send events (not content)
The server knows you sent a message to a given channel — just not what it said.
Argon2id password hash
Your password is never stored. Only the irreversible Argon2id hash is kept. Even a full database leak would not expose your password.
Sparks balance and transaction history
How many Sparks you have and a log of how you earned or spent them. Required to operate the economy. See the Sparks & Payments section below.
Uploaded file metadata
File size and upload time. Files use 128-bit random filenames — unguessable, but not encrypted at rest. See the limitations section.
✓ Not stored, or inaccessible
Message content (channels)
AES-GCM-256 encrypted before leaving your device. Server receives and stores only ciphertext.
Direct message content
E2E encrypted. Server is a blind relay — it cannot read or meaningfully store DM content.
Your encryption passphrase
The channel passphrase used to derive your encryption key never leaves your device. It is never transmitted.
Email address
We never ask for it. There is no email field in the database schema. It cannot be stored.
Phone number
Same as email — no such field exists anywhere in the system.
Voice and video streams
WebRTC calls are peer-to-peer. Recline's servers are never in the media path — only signaling passes through.
Your private encryption key
ECDH private keys are generated on your device and stored locally. They are cleared on logout.
Payment card details
Stripe handles all payment processing. Recline never sees, touches, or stores card numbers, CVV codes, or banking details.

Under the hood

How encryption works.

Plain language. No marketing. Here is exactly what happens to a message between your keyboard and the database.

1
You type a message
Your plaintext lives only in your browser. It has not been transmitted anywhere yet.
2
Key derivation from your passphrase
When you joined the community, you entered a passphrase. That passphrase was fed through PBKDF2 with a per-server salt — 200,000 iterations — to produce a 256-bit AES key. The key is held in memory on your device only. It never leaves your browser and is never sent to the server.
PBKDF2-HMAC-SHA256 · 200,000 iterations
3
Message encrypted in the browser
Before the message leaves your device, it is encrypted using AES-GCM with a randomly generated 96-bit IV. A unique IV is generated for every single message. The result is ciphertext that is mathematically unreadable without the key. Even a complete server compromise would expose only random bytes.
AES-GCM-256 · random 96-bit IV per message
4
Ciphertext sent to the server
The encrypted blob, the IV, and a channel identifier travel to the server over TLS. The server stores this in PostgreSQL. It has no way to decrypt it — the key was never sent and is not derivable from anything the server holds.
TLS in transit · ciphertext-only at rest
5
Recipients decrypt locally
When another community member loads the message, their client fetches the ciphertext and IV. Using the same key — derived independently from the same passphrase — AES-GCM decrypts the message entirely in their browser. The decrypted content is never returned to the server.
6
Direct messages use per-recipient key exchange
DMs use ECDH P-256 key exchange so only the two participants can decrypt. Each user generates an EC keypair on their device. The shared secret is derived via HKDF-SHA256. The server routes the encrypted payload but cannot read it — it sees only the ciphertext envelope and delivery metadata.
ECDH P-256 · HKDF-SHA256 · server-blind relay

Honest accounting

Metadata.

Encryption protects content. Metadata is a separate and harder problem. Here is what exists and what it can reveal.

Item Status What it reveals
Message timestamp Stored plain When you were active, conversation rhythm, response patterns
Sender identity (username) Stored plain That you sent a message to a given channel at a given time
Channel membership Stored plain Which communities and channels your account belongs to
Online presence Stored plain Whether you're currently online and last-seen time
IP address Standard HTTP — not persisted by default Approximate location if logged; not logged in the current deployment
Message content AES-GCM ciphertext only Nothing readable — unrecoverable without the passphrase key
DM content E2E encrypted — server never sees plaintext Nothing — server receives and routes only ciphertext
Voice and video WebRTC P2P — server not in path Nothing — media never touches Recline infrastructure

Metadata minimization is on the roadmap. Future versions will reduce timestamp precision, add optional presence masking, and reduce what membership graphs reveal. This is an active area of work, not a solved problem.

Sparks & payments

What Recline knows when you buy Sparks.

Sparks are the community economy — members earn them daily, creators earn them through tips and broadcasts. When you choose to buy a Spark pack or cash out earnings, here is exactly how that data flows.

Recline stores

  • Your Sparks balance
    Required to operate the economy. Stored in the sparks_balances table.
  • Spark transaction history
    Tips sent and received, daily rewards claimed, broadcasts purchased. Used to calculate payouts and display your history in the app.
  • Stripe customer ID (if you purchase)
    A Stripe-assigned identifier that links a completed purchase to your account. Not a payment method — Stripe holds all billing details on their infrastructure.
  • Stripe Connect account ID (if you cash out)
    Required to route cashout payments to your connected bank or debit account. Banking details are stored by Stripe, not Recline.
  • Stripe webhook event IDs
    Stored to prevent duplicate credit on replayed webhooks. No payment content is retained beyond this idempotency key.

Recline does not store

  • Card numbers, expiry dates, or CVV codes
    Stripe Checkout handles all card input. This information never touches Recline's servers.
  • Bank account numbers or sort codes
    Stripe Connect handles all cashout onboarding. Banking details go to Stripe, not to Recline.
  • Billing addresses
    Stripe may collect this for fraud prevention. Recline does not receive or store it.

Recline uses Stripe for all payment processing. Stripe's privacy policy governs how Stripe handles your payment data: stripe.com/privacy

Observability

Analytics, cookies, and logs.

What Recline uses to understand how the product works — and what it doesn't use to understand you.

Datadog RUM (optional)
Recline optionally uses Datadog Real User Monitoring to capture performance metrics — page load times, error rates, rendering latency. If enabled: session replay sampling is set to zero, all user input is masked, and no personally identifiable information is collected. RUM is disabled if no App ID and Client Token are configured in the build.
Sentry error tracking (optional)
Server errors are optionally reported to Sentry for debugging. The Sentry integration is configured with sendDefaultPii: false and a beforeSend hook that strips user objects, cookies, request bodies, and IP addresses from all events before transmission. Error reports contain stack traces and error messages — not user content or identity.
No third-party tracking or advertising pixels
Recline has no Google Analytics, Facebook Pixel, ad network integrations, behavioral tracking, or third-party data brokers. The observability tools above are strictly for product health monitoring — not user profiling.
Session tokens (not cookies)
Authentication uses 256-bit random hex session tokens stored in the server's sessions table. These are passed as HTTP Authorization headers — not stored as browser cookies. There are no tracking cookies, no analytics cookies, and no persistent identifiers set by Recline in your browser beyond what the app itself manages in localStorage and sessionStorage.

Honest limitations

Where we're still improving.

Recline is in alpha. The core encryption is solid. But there are real gaps — and we'd rather tell you exactly where they are than let you assume everything is finished.

Our commitment

"Recline is designed to minimize what it knows about you. The goal is not to promise privacy — it's to make surveillance architecturally difficult, and to be transparent when it isn't."
  • No ads, ever
  • No data sales
  • No email required
  • No phone required
  • No behavioural profiling
  • No third-party tracking
  • No tracking pixels
  • No VC pressure to monetize users

The AGPL-3.0 license means if we ever tried to violate these commitments, anyone could fork the last clean version and keep running it. The code is the contract.

UK GDPR

Your rights.

Under UK GDPR and the Data Protection Act 2018, you have specific rights over personal data Recline holds. Here is what they are and how to exercise them.

Right of access
You can request a copy of all personal data Recline holds on you. Use the data export feature in app settings, or email hello@recline.social. The export includes your account details, community memberships, message ciphertext (we cannot decrypt it), Sparks history, uploads, and more — delivered as a structured JSON file within 30 days.
In-app: Settings → Export Data · API: GET /api/auth/me/export
Right to erasure
You can delete your account at any time from Settings. Deletion is soft for 90 days (to allow completion of in-flight financial transactions and any active abuse investigations), then your account and all associated data — messages, memberships, Sparks history, uploads — is permanently and irreversibly removed via database cascade. No manual request needed.
In-app: Settings → Delete Account · API: DELETE /api/auth/me
Right to rectification
You can update your display name, avatar, and password at any time from Settings. Username changes are not currently supported in alpha — contact us if you need a correction. Message content is stored as encrypted ciphertext; the server holds no plaintext and cannot modify message content on your behalf.
In-app: Settings → Edit Profile
Right to data portability
Your data export is machine-readable JSON — documented, structured, and yours to keep. Message content is included as AES-GCM ciphertext with its nonce. If you hold the channel passphrase, you can decrypt messages locally using the same key derivation documented in the open-source client.
API: GET /api/auth/me/export
Right to restrict processing
If you believe Recline is processing your data unlawfully, or if you dispute its accuracy, you can request restriction of processing while the dispute is resolved. Email hello@recline.social with the subject "Restrict processing." We respond within 30 days.
Right to lodge a complaint with the ICO
If you believe Recline has violated your rights under UK GDPR, you have the right to complain to the Information Commissioner's Office — the UK's independent data protection regulator.
ico.org.uk · 0303 123 1113

Legal basis for processing: Account data is processed on the basis of contract performance. Platform security and abuse prevention are processed on the basis of legitimate interest. Sparks and payment transaction records follow contractual and legal obligation (UK accounting requirements). No processing is based on consent alone, and no personal data is sold or shared with third parties for commercial purposes.

Retention schedule

How long we keep data.

Recline retains data only as long as it is needed. These are the documented retention periods for each data category.

Data category Retention Reason
Active account data While account is active Required to operate the account. Cascade-deleted on account removal.
Deleted accounts 90-day grace, then permanent erasure Grace period allows transaction completion and abuse investigations. After 90 days: irreversible hard-delete cascades to all associated data.
Channel and DM messages While account exists Stored as ciphertext. Cascade-deleted on account removal. Per-message expiry is planned for a future release.
Session tokens 30 days from creation Automatically expired on login. Hard cap of 20 sessions per account.
Stripe webhook events 90 days Needed for Stripe retry dedup (72h window). Swept automatically after 90 days.
Payment and Sparks records 7 years minimum UK accounting obligation under the Companies Act 2006 and HMRC requirements.
Moderation reports (all levels) 3 years Legal guideline for abuse investigation records. User references may be anonymised (SET NULL) if the referenced account is deleted.
Audit logs 3 years Admin and moderation actions. Required for accountability and potential regulatory review.
Uploaded files Until sent as attachment or account removed Orphaned uploads (uploaded but never attached to a message) are swept every 10 minutes. All files permanently removed on account deletion.

Online Safety Act

How moderation works.

End-to-end encryption means Recline cannot proactively scan message content. This is the correct trade-off — and here is exactly what moderation looks like as a result.

L1
User-initiated reporting
The primary moderation mechanism. Any member can report a message or user — in their community or at the platform level. When you report a message, the client voluntarily submits the content to moderators. This is the user choosing to reveal something, not Recline breaking encryption. Platform-level reports (for users you don't share a server with) go directly to the Recline safety team.
L2
Community moderation
Community owners and moderators control their own spaces — membership, roles, kicks, bans, and server-level report review. Recline does not moderate individual conversations. Community leaders do. Recline intervenes only for platform-wide ToS violations that community mods cannot address.
L3
Platform safety team
Handles serious escalations: CSAM, terrorism content, credible threats, large-scale fraud, and coordinated platform abuse. CSAM reports trigger immediate access restriction, evidence preservation, and full cooperation with the Internet Watch Foundation, law enforcement, and relevant reporting obligations under UK law. Recline does not investigate CSAM content itself.
What Recline cannot moderate proactively
With true E2EE, Recline cannot scan DM content, private channel messages, or voice calls. This is a meaningful privacy protection with a meaningful trade-off. We rely on user reporting, metadata and account-behaviour signals, account-level enforcement, and full cooperation with law enforcement when legally compelled. This is not perfect. We build incrementally and state the limits honestly.

Online Safety Act 2023: Recline acknowledges its obligations under the UK Online Safety Act. End-to-end encryption does not remove our duty to conduct risk assessments, maintain accessible reporting mechanisms, take action on reported content, and cooperate with Ofcom on regulated duties. This section documents our current moderation architecture in alignment with those obligations.

Questions

Something unclear?

If something on this page is inaccurate, incomplete, or you have a specific question about data handling, reach out directly.

Privacy questions, data requests, and trust concerns can be sent to hello@recline.social. We'll respond directly — no ticket system, no automated responses. The client code for every encryption claim on this page is readable at the GitHub link below.

Email us Read the code