Last updated: 5 September 2026
This document describes how PairNook protects your data — precisely, and including the parts that are deliberately not end-to-end encrypted. We believe a privacy product should be able to explain itself.
The content of your conversations, photos, voice notes, shared passwords, and documents is end-to-end encrypted: through the protocol, the server cannot read your messages in transit or at rest — it operates on ciphertext. There is one deliberate exception in the current release: to make account recovery zero-effort, an encrypted copy of your recovery key is escrowed server-side (§4). A fully compromised server — or a malicious operator — could combine that escrowed key with your encrypted key backup to access message history. We treat this as a disclosed usability trade-off, not fine print; §4 explains it and the hardening path. Day-to-day, what the server can see is the metadata needed to run the service, plus the Life-planning items described in §7. We do not defend against a compromised end device: if someone controls your unlocked phone, they can read what you can read.
PairNook's messaging is built on the open Matrix protocol, using its audited end-to-end encryption stack:
matrix-rust-sdk on iOS and Android, and as
the WASM build via matrix-js-sdk on the web app. We do not
write our own primitives.Losing a phone shouldn't mean losing your history — but backup must not weaken the encryption. PairNook uses Matrix server-side key backup:
The honest trade-off: because we hold both the escrow secret and the escrowed blobs, a fully compromised server — or a malicious operator — could unwrap your recovery key and use it to decrypt the key backup, i.e. your message history. This is a deliberate, disclosed usability trade-off of the current release: recovery works even if you lose every device and remember nothing. The encryption of messages in transit between your devices is unaffected. On the roadmap: user-held recovery keys and an opt-out of escrow, which close this gap at the cost of you safeguarding the key yourself. And if you delete your account, backup and escrow blobs are deleted with it.
Push notifications are a classic E2EE leak — most apps either show nothing or let the server read the preview. PairNook does neither:
Shared passwords, documents and vault photos are transported and stored as ordinary encrypted room events — the same Olm/Megolm machinery as messages. The server is blind to them.
On the device, the vault adds protections that are deliberately local:
Life planning and activity items are readable by the server. To-dos, chores, groceries, reminders, important dates, calendar entries, expense records, notes, date plans, shared links and the watchlist, travel lists, photo captions, game boards and scores, and your answers to the daily Question for Two are stored server-side in readable form so that the server can schedule and send reminders and notifications when your apps are closed, and coalesce updates between partners. This is a deliberate, documented trade-off — not an oversight. If something is sensitive, put it in chat, not in a to-do title or a daily answer.
Also visible to the server, as with any messaging service: account data (email, display name), which devices you have, when messages were sent and to which room (but not their content), push tokens, and IP-level connection metadata.
| Server sees | |
|---|---|
| Messages, reactions | Ciphertext only |
| Photos / videos / voice notes | Encrypted blobs only |
| Passwords & documents | Ciphertext only |
| Files sent in chat (PDFs, documents, marked-up copies) | Ciphertext only — encrypted attachments, same as photos (§2) |
| Notification previews | Ciphertext only (sealed per device) |
| Key backup | Encrypted under your recovery key — but an escrowed copy of that key is recoverable by the operator (§4) |
| Life & activity items (to-dos, notes, date plans, links, travel, photo captions, game state, daily-question answers) | Plaintext, by design (§7) |
| Account & routing metadata | Plaintext (required to operate) |
The apps request a small set of device permissions. None of them create new data on our servers.
READ_MEDIA_IMAGES, READ_MEDIA_VIDEO) are blocked
in our manifest, so the app cannot enumerate or read your library.Three features send content to OpenAI, and only when you invoke them: the Nook assistant (the message you hand it, or the recent messages you explicitly ask it to scan), voice-note transcription (the one clip you submit), and the Memorial companion (after explicit, revocable consent). In each case your client decrypts the content and submits it for that single request; we relay it and keep no text or transcript. The assistant's scan deliberately excludes vault items, call logs, location and SOS. See the privacy policy for the full description.
Invites are 8 random bytes (64 bits) rendered as 16 hex characters, are single-use, expire 14 days after they are created, cannot be redeemed by the person who created them, and are rate-limited per address and per account so they cannot be guessed at scale. The shared encrypted room is created and both partners are joined to it server-side at the moment the invite is accepted.
Found a vulnerability? Please email support@pairnook.com with details. We commit to acknowledging reports quickly and fixing verified issues as a priority. Please give us reasonable time to remediate before public disclosure.