How Voke’s security works

Version 2, 8 October 2026. Sections 1 to 15 describe how Voke works. Section 16 describes the end-to-end encryption design Voke is moving to, which is clearly marked as a design. The shorter summary is on the security page.

1. Principles

Voke stores sleep, heart, activity and workout data from Apple Health and Google Health, works out scores and summaries, and lets you share chosen parts with people you invite. Health data stays sensitive for a lifetime, so Voke is built around a few principles:

• Your data is sealed with your account’s own key. Every account has its own 256-bit key, held under AWS Key Management Service (KMS). Health data, chats and summaries are sealed with keys derived from it, and deleting your account destroys it.
• Nothing readable where it doesn’t need to be. Logs, background job queues and notifications carry no health values. Logs are limited to a fixed list of IDs, codes, counts and durations.
• Your phone is your identity. There are no passwords. Each iPhone holds a key in its Secure Enclave that can’t leave it, and risky actions need a fresh signature from that key.
• Nothing is shared until you choose. People you invite see only the categories and level you set, and that’s checked before any of your data is decrypted for them. Every read is logged.
• AI is off until you turn it on, and AI requests ask providers to keep no copy and not train on your data.
• You choose where your data lives: Canada, the United States or Europe, each with its own database, backups and keys.
• Prepared for quantum computers. Connections and backups use hybrid post-quantum key exchange, and stored data uses 256-bit keys.
• Moving to end-to-end encryption. Voke’s goal is to never store your data in a form it can read. Section 16 describes the design.

2. Protections at a glance

• Health data at restHow Voke protects it: Per-account 256-bit key under KMS; AES-256-GCM per item, bound to its account, kind and dayWhere the end-to-end design takes it (section 16): Sealed on your phone with keys only you hold
• Scores and summariesHow Voke protects it: Worked out by Voke’s server in memoryWhere the end-to-end design takes it (section 16): Worked out on your phone
• Sign-inHow Voke protects it: Sign in with Apple plus a Secure Enclave device key; no passwordsWhere the end-to-end design takes it (section 16): A post-quantum signing key alongside the device key
• ConnectionsHow Voke protects it: TLS 1.2 and 1.3, with hybrid post-quantum key exchange (X25519MLKEM768)Where the end-to-end design takes it (section 16): Payloads already sealed before they’re sent
• Off-site backupsHow Voke protects it: Sealed with age to a hybrid post-quantum recipient (ML-KEM-768 with X25519)Where the end-to-end design takes it (section 16): Hold only ciphertext
• Logs and job queuesHow Voke protects it: Fixed field list; Google fetch requests sealed with the account’s keyWhere the end-to-end design takes it (section 16): Unchanged
• NotificationsHow Voke protects it: A first name and a generic line of textWhere the end-to-end design takes it (section 16): Ciphertext, opened on the recipient’s phone
• SharingHow Voke protects it: Levels checked before decryption; every read loggedWhere the end-to-end design takes it (section 16): Category keys wrapped to each member’s key
• Data locationHow Voke protects it: Your choice of Canada, the United States or EuropeWhere the end-to-end design takes it (section 16): Unchanged
• Key useHow Voke protects it: Every key unwrap is a logged KMS call, kept for a yearWhere the end-to-end design takes it (section 16): Unchanged

3. Architecture

Voke has four parts that matter for security:

• The iPhone app. It reads Apple Health on the phone, signs each upload with the phone’s device key and sends it to Voke’s server. It shows your data, your circles and Ask Voke.
• Voke’s server. It runs as containers on AWS Fargate in your region, behind a load balancer that accepts only HTTPS. It receives uploads, pulls Google Health data through Google’s API, works out scores, enforces sharing and runs the AI features.
• The database and key store. A PostgreSQL database on Amazon RDS holds the sealed health data and account records. It sits in private subnets with no route to the internet and accepts connections only from Voke’s server, over TLS. Each account’s wrapped key is held separately, in an Amazon DynamoDB table.
• Outside services. Apple handles Sign in with Apple and delivers notifications. Google sends Google Health data. AI requests go through Vercel’s AI Gateway. The full list, with what each one handles and where, is on the service providers page.

The voke.co website is separate. It’s hosted on Cloudflare and never handles health data. The web pages at app.voke.co are there for invites and for connecting AI apps; there’s no sign-in on the web.

4. Where your data lives

When you create an account, you choose where your data is stored:

• CanadaServer, database and keys: Montréal (AWS ca-central-1)Off-site backups: Calgary (AWS ca-west-1)
• United StatesServer, database and keys: Ohio (AWS us-east-2)Off-site backups: Oregon (AWS us-west-2)
• EuropeServer, database and keys: Frankfurt (AWS eu-central-1)Off-site backups: Ireland (AWS eu-west-1)

The app suggests a region from your device’s settings, and an invite suggests the inviter’s region.

• Each region stands alone. It has its own server, database, KMS keys, key table and backups. A region’s keys never leave it, and one region can’t open another’s data.
• Nothing is stored centrally. When you sign in, a stateless router asks every region at the same time whether it holds your account. It sends only a keyed hash (HMAC-SHA-256) of your Apple sign-in identifier, and connects you to the region that answers yes. No central table maps people to regions, and each region knows only its own users.
• Circles stay in one region. An invite carries its region, so a circle’s members and their shared data stay together.
• Moving between regions. You can move your account to another region. The account is paused, copied directly from one region’s server to the other’s, sealed under a new key in the new region and checked, and then the old copy is deleted and its key destroyed.

Some data leaves your region to make features work: Google sends Google Health data from its own servers, Apple handles sign-in and notifications, and AI features, if you turn them on, are processed in the United States for Canadian and US accounts and in the European Union for European accounts (section 10).

5. Identity and devices

Sign in with Apple, and no passwords

Sign in with Apple is the only way to create or open an account. Voke has no passwords, so there are none to steal or reuse.

When you sign in, the app first creates a device key (below). Voke’s server checks the identity token Apple returns, and requires that token to carry a value derived from a one-time challenge and the new device’s public key. This ties Apple’s confirmation of who you are to that specific key on that specific phone. The server also exchanges Apple’s one-time code with Apple and checks that both refer to the same Apple account.

Voke stores your name, the email address Apple gives it (often a private relay address) and Apple’s identifier for your account. Apple’s access and refresh tokens are stored encrypted with a server-wide 256-bit key (XChaCha20-Poly1305). Apple’s identity token isn’t kept after sign-in.

Device keys

Each iPhone you sign in on creates its own P-256 key in the Secure Enclave, the chip in the iPhone that holds keys the operating system itself can’t read out. The private key never leaves the phone and isn’t included in device backups. Voke’s server keeps only the public key.

The key can be used once the phone has been unlocked after a restart, without Face ID each time, because Apple Health uploads run in the background and have to be signed. So the key is as safe as the phone’s own lock.

The key signs:

• Every Apple Health upload. The server checks the signature and a hash of the upload before accepting it. Uploads must be recent, and a repeated upload is recognised and ignored.
• Each new session. See below.
• Risky actions. Deleting your account, signing out your other devices, revoking another device, deleting a circle, removing a member, approving or disconnecting an AI app, and turning AI features off each need a fresh signature over a one-time challenge. The challenge is tied to that device, that action and its target, lasts 5 minutes and can be used once. A stolen session token alone can’t do any of these things.

When a new device signs in, your other devices get a notification.

Sessions

Sessions last 15 minutes and are never extended. To keep you signed in, the app asks for a new challenge, signs it with the device key and receives a fresh session shortly before the old one expires. The session token is held in the app’s memory, not written to storage. Every request is refused if the device key behind its session has been revoked.

Signing out revokes that device’s key and deletes its sessions. “Sign out other devices” does the same for every other device at once.

6. Keys and encryption at rest

The key hierarchy

KMS key for your region           256-bit, never leaves KMS, rotates yearly
 └─ wraps your account key        256-bit, one per account, stored only wrapped
     └─ HKDF-SHA-256 per purpose  health data, chats, morning summaries,
         │                        Google tokens, journal, …
         └─ AES-256-GCM           a fresh nonce per item, bound to account, kind and day

1. Creating the key. The first time an account needs it, Voke asks KMS for a new data key. KMS returns the key twice: once in the clear for immediate use, and once wrapped (encrypted) by a KMS key that never leaves KMS. The wrapped copy is tagged with the account’s ID and purpose, and only that exact tag will unwrap it.
2. Storing the key. Only the wrapped copy is stored, in a key table kept apart from the database. It’s never written in the clear.
3. Using the key. When the server needs an account’s data, it asks KMS to unwrap the key. The unwrapped key stays in the server’s memory for up to 15 minutes, in a form the code can’t export, and is never written to disk.
4. Deriving keys for each purpose. From the account key, Voke derives a separate key for each kind of data with HKDF-SHA-256. A key for one purpose can’t open data meant for another.
5. Sealing the data. Each piece of data is sealed with AES-256-GCM using a fresh random nonce. Health data is stored in small blocks, one per day and per kind of reading. Each sealed item is bound to where it belongs, so a block copied to another account or another day fails to open.

What’s sealed with your account’s keys

Health data and everything worked out from it (scores, summaries, naps, heart events), raw Apple Health uploads, Ask Voke chats, morning summaries, journal entries, your body profile, Google Health tokens, requests to fetch Google data, and your reactions and challenge entries.

What the database holds in plain form

To run the service, the database also holds information protected by the database’s own storage encryption and access controls rather than by your account key:

• your name and email address, and when the account was created;
• which kinds of data exist on which days (not the values);
• your circles, their names, who’s in them and the levels you set;
• the log of who read your data and when (section 9);
• which devices and sources you’ve connected, their labels, and the IP address and user agent of recent sessions;
• your agreements to terms and your AI consent;
• the queue of background jobs, which refers to accounts by ID. Finished jobs are deleted after 7 days and failed ones after 30, and a failure is recorded as a code from a fixed list.

The database’s storage, the key table, the backups and the container registry are also encrypted at rest by AWS with 256-bit keys.

7. Encryption in transit and post-quantum readiness

Connections

• Phone and web to Voke. Voke’s API accepts only HTTPS with TLS 1.2 or 1.3. Plain HTTP is redirected, and the API sends HTTP Strict Transport Security for a year. The API’s addresses point straight at Voke’s load balancer on AWS; no content delivery network decrypts the traffic on the way.
• Inside AWS. The database refuses connections that don’t use TLS. Voke’s storage buckets refuse requests that don’t use TLS.
• The website. voke.co is served over HTTPS only, with HTTP Strict Transport Security covering its subdomains.
• Google notifications. When Google tells Voke new data is ready, Voke checks Google’s signature on the message before acting on it.

Post-quantum key exchange

A large enough quantum computer would break the public-key methods most of the internet uses to agree on encryption keys, such as the elliptic-curve exchange X25519. Traffic or files copied today could be decrypted once one exists, so Voke protects those first.

• Your connections to Voke. Voke’s API, sign-in, AI-connection and app addresses use hybrid post-quantum key exchange, X25519MLKEM768, which pairs NIST’s ML-KEM-768 standard (FIPS 203) with X25519, so an attacker must break both. It’s used with iOS 26 and later and current versions of Chrome, Firefox, Safari and Edge. Older devices connect with X25519.
• voke.co, served by Cloudflare, uses the same hybrid key exchange.
• The server’s own connections to its database, to AWS services and to Google, Apple sign-in and Vercel’s AI Gateway use the same hybrid key exchange.
• Off-site backups are sealed with age’s hybrid post-quantum recipient, ML-KEM-768 with X25519 (section 8).
• Stored data is sealed with 256-bit symmetric keys. Known quantum attacks on symmetric encryption at most halve its effective strength, which leaves 256-bit keys with a wide margin.

Signatures work differently: forging one needs a working quantum computer at the moment of the attack, so a signature can’t be broken after the fact the way recorded traffic can. Device keys, TLS certificates, Google’s message signatures and sign-in tokens use today’s standard signature algorithms. Voke’s next step is post-quantum signatures (ML-DSA), which the iPhone’s Secure Enclave supports from iOS 26. Apple’s push notification service uses classical key exchange; section 16 describes how notifications become ciphertext.

8. Backups

• Database backups. Amazon RDS keeps automatic backups that allow the database to be restored to any point in the last 35 days. They’re encrypted at rest like the database.
• Off-site copies. Every night, a backup job dumps the database and encrypts the dump with age to a hybrid post-quantum public key (ML-KEM-768 with X25519) before it leaves the job. The backup job holds only the public half, so it can create backups but not read them. The private key is kept offline in a password manager, not on any server. The encrypted dumps are stored in a separate bucket in your region’s backup location, which has its own KMS key, blocks all public access and deletes each copy after 30 days.
• Account keys aren’t in the database backups. The wrapped keys live only in the key table, which keeps its own 7 days of point-in-time recovery. So a database backup holds sealed data without the keys to open it.

9. Sharing and circles

Sharing in Voke happens through circles: groups of people you invite.

• Nothing is shared by default. When you create or join a circle, every category starts off.
• You set a level per category: none, score only, daily summary or full detail. A per-person setting can override the circle-wide one. If you share with someone in more than one circle, they get the highest level you gave them.
• Some data is never shared: body measurements, heart rhythm events, your Feed, your chats and your morning summaries.
• The check happens before decryption. When someone opens your data, Voke works out their levels first and then reads and decrypts only the kinds of data those levels allow. Anything above their level isn’t read for them at all.
• Every read is logged. Each read of your data by another person or an AI records who read it, which category, at what level and for which dates. If that record can’t be written, the read fails.
• Invites expire. Invite links and codes work once and last 7 days. Voke stores only a keyed hash of each one, not the code itself.
• Removing someone is immediate. When a member leaves or is removed, their access ends both ways at once and the invites they sent are cancelled. Only a circle’s admins can remove members or delete the circle, and both need a device signature.

When someone in a circle has an alert, such as a missed night of sleep, the notification passes through Apple’s push service. It carries the person’s first name and “Something changed in your circle”, never what happened or any values. The app shows the details once you open it.

10. AI features and what providers see

Off until you turn it on

Ask Voke and the morning summary stay off until you turn on “Use AI features” and agree to send your data to AI providers. Voke records that agreement with its version, and checks it before every AI request. Turning AI off (which needs a device signature) deletes your chats and summaries, disconnects your AI apps and keeps your data out of other people’s AI.

The path a request takes

AI requests go from Voke’s server to Vercel’s AI Gateway, which passes them to a model host. Today the model is DeepSeek V4.1 Flash. Requests from Canadian and US accounts are served in the United States, and requests from European accounts in the European Union.

Every request is sent with three settings:

• Zero data retention: the provider should delete the request after answering.
• No training: the provider may not train on it.
• Region pinning: the request must be served in the region above. Voke checks where each answer was served and throws it away if it came from elsewhere. By then the request has already been sent, so this check limits what Voke keeps, not where the request went.

The gateway enforces these settings and routes only to hosts that accept them, and a request fails rather than going anywhere that won’t accept them. What a provider does with a request is governed by these terms.

What the model sees

• Ask Voke: your question, the earlier messages in that chat, your name as it appears in Voke, and the health data the model looks up to answer. That data includes actual values, such as last night’s sleep stages or your resting heart rate. If you ask about someone in a circle, it includes their name and Voke’s internal ID for them, but not their email address. The model can only look up data your levels allow.
• Morning summary: only a few sentences Voke has already worked out from your data, with no raw readings and no identifiers.

Other people’s data

Ask Voke can read someone else’s data only if they share that category with you, have turned on AI features themselves, and have turned on the switch that lets your AI see their data. That switch starts off. If they later narrow what your AI can see, chat turns that used the data they’ve withdrawn are deleted.

The topic check

Before Ask Voke answers, a small model checks the question is about health, sleep or fitness, so Ask Voke isn’t used as a general chatbot. It’s run by TypeSafe AI, also through Vercel, with zero data retention and no training. It sees only the text of your own last 6 messages: no answers and no stored health data, though your messages may themselves mention your health. Its requests aren’t limited to a region. If it doesn’t answer within 1.5 seconds, the question goes ahead anyway.

What Voke keeps

Chats are sealed with your account’s chat key and deleted after 30 days. Morning summaries are sealed and kept until you turn AI off or delete your account. Voke’s logs record timings and counts for AI requests, not the text of questions or answers.

11. MCP connections

You can connect your own AI app, such as Claude or ChatGPT, to Voke over the Model Context Protocol (MCP). This works separately from Voke’s own AI features.

• Standard OAuth. Connections use OAuth 2.1 with PKCE (S256 only). AI apps register themselves automatically, so there’s no shared secret to leak.
• Approved on your phone. The AI app’s sign-in page shows a QR code and a short code. You open it in the Voke app, see what the AI app asked for, and pick which categories to allow. You can allow less than it asked for but never more. Approving needs a device signature. The request expires after 10 minutes.
• Tokens bound to Voke. Tokens are issued only for Voke’s MCP address, and the MCP server refuses tokens issued for anything else. Access tokens last 1 hour. Refresh tokens rotate on each use, and reusing an old one revokes the whole connection’s tokens. A connection lasts at most 90 days before you approve it again. Voke stores tokens only as hashes.
• Read-only. The tools an AI app can call only read data: today’s overview, daily summaries, readings over time, sessions such as sleep and workouts, the journal, your sources and the people who share with you. Each call is checked against the categories you approved and the levels others share with you, and is logged like any other read. Each call covers a limited date range.
• Disconnecting is immediate. Disconnecting an app in Voke deletes its tokens.

Once data reaches your AI app, it’s handled under your account with that company and its privacy terms, not Voke’s. Voke tells you this before you connect.

12. Operations

Access and its controls

Voke is operated by its founder, Rida F’kih, who holds administrative access to Voke’s AWS infrastructure. Because the server unwraps account keys to run features, that level of access, or the ability to change and deploy the server’s code, could reach account data. Voke’s policy is that the operator doesn’t read user data; data is read by the running service, for the features you use. The end-to-end design in section 16 removes this access. The controls today:

• The server’s own permissions are narrow. The role the server runs under can unwrap a key only when the request names an account and the right purpose, and the database user it connects as can read and write data but not change the database’s structure.
• No long-lived cloud keys. Voke’s deploy pipeline has no stored AWS credentials. GitHub Actions gets short-lived credentials through OpenID Connect, and only for Voke’s repository. Roles that change production can be used only from the main branch’s production environment. The role that previews infrastructure changes on pull requests can’t read secrets or data.
• Key use is recorded. Every unwrap is a KMS call tagged with the account’s ID. A dedicated AWS CloudTrail trail records every key use, along with other AWS account activity, in a separate encrypted bucket kept for a year.

Logging

Voke’s server writes structured logs. Every field has to come from a fixed list of IDs, codes, counts and durations: the logger drops anything else, and a test fails the build if code tries to log a field outside the list, an error’s text, a request body or a payload. Errors are logged by their type and a short code, never their message. Request logs record the route, status and timing, without your IP address or account ID. Logs are kept for 30 days.

The database’s slow-query log records how long a query took but not the values in it. Google’s change notices are deleted once they’ve been handled.

Deploy pipeline

• Every push is scanned with gitleaks for secrets across the full history, and type checks, tests and infrastructure checks run on the parts that changed.
• Production deploys run automatically only after those checks pass on the main branch. New versions roll out alongside the old one and roll back automatically if they fail health checks.
• Voke’s AWS infrastructure is defined in code and applied by the pipeline.
• Third-party GitHub Actions are pinned to exact versions from an allowlist, workflow tokens are read-only by default, pull requests from forks never run workflows, and Dependabot watches dependencies.
• Container images are stored in a private registry with immutable tags and scanned when they’re pushed.
• Changes can also be pushed to the main branch by Worm, Voke’s AI engineering agent. They go through the same checks and deploy pipeline as any other change.

Secrets

Application secrets are stored encrypted in AWS Systems Manager Parameter Store and handed to the server when it starts. They’re written outside the infrastructure code, so they don’t appear in it or in its state. The database’s administrator password is generated and held by AWS. The production server refuses to start with the test or local key implementations used in development.

13. What happens if…

Someone copies Voke’s database or a backup. They get sealed health data without the keys to open it: account keys live in a separate table, wrapped by a KMS key that never leaves KMS. They would see the plain-form information listed in section 6, such as names, email addresses and circle membership.

Someone records your connection today and builds a quantum computer later. The key exchange on your connection is hybrid post-quantum when your device supports it (section 7), so a quantum computer alone doesn’t recover the session keys.

Your iPhone is lost or stolen. The device key is protected by the phone’s lock and can’t be copied off the phone. From another device, revoke it; its sessions end at once, and any session expires within 15 minutes anyway.

A session token leaks. It expires within 15 minutes and can’t delete your account, change your devices, remove circle members or approve AI apps, because each of those needs a fresh signature from your device key.

An AI app’s token leaks. It can only read, only the categories you approved, for at most an hour. Reusing an old refresh token revokes the whole connection, and you can disconnect the app from Voke at any time.

You remove someone from a circle. Their access to your data ends immediately, in both directions.

Voke’s server is compromised. An attacker running code on the server could read the data of accounts the server opens while they’re in control. Key unwraps are recorded in CloudTrail, and the server’s permissions are limited as described in section 12. The end-to-end design in section 16 is built to take this case away.

You delete your account. Your key is destroyed and your data is deleted (section 14).

14. Deletion

You can delete your account in the app; it needs a device signature. Here’s what happens:

1. Access ends at once. Your devices are revoked, sessions and notification tokens are deleted, you’re removed from every circle, and your AI consent and AI app connections are removed.
2. Provider tokens are revoked. Voke asks Google and Apple to revoke the tokens it held for you.
3. Health data is deleted from the database, along with Google’s notifications about your account.
4. Your key is destroyed. The wrapped key is replaced with a marker saying it was destroyed, and Voke refuses to ever create a new key for that account.
5. The account record is deleted.
6. Voke checks nothing is left. A final step fails, and the job retries, if any record tied to your account remains.

The job retries until every step succeeds. Records of security events, such as when a device signed in or was revoked and that the account was deleted, are kept.

Backups. For 7 days after deletion, the key table’s own recovery could in principle bring back your wrapped key. After that, the sealed data left in backups (your health data, chats and summaries) can’t be decrypted by anyone. Information that isn’t sealed with your key, listed in section 6, stays in database backups for up to 35 days and in the encrypted off-site copies for up to 30 days, and then it’s gone.

15. Reporting and incident response

Reporting a vulnerability. Email security@voke.co with what you found and how to reproduce it. We’ll reply within 3 business days. Please don’t access other people’s data or disrupt the service while testing. Voke publishes a security.txt file with the same contact.

Monitoring. Alarms on server errors, failed health checks, unexpected server restarts, failed background jobs and database health go straight to the operator.

If there’s a breach. If a breach of security safeguards creates a real risk of significant harm to you, we’ll tell you directly and report it to the Privacy Commissioner of Canada, Alberta’s Information and Privacy Commissioner and any other regulator the law requires, such as the US Federal Trade Commission. We keep a record of every breach for at least 24 months. The privacy policy has the details.

16. End-to-end encryption: the design Voke is moving to

This section is a design. Sections 1 to 15 describe how Voke works today.

Voke’s goal is to never store your data in a form it can read. The design below gets there by moving the keys, and the work that needs them, onto your devices. It has been written up in detail and is being reviewed; parts of it will change as it’s built.

A key only your devices hold

Account root key                  256-bit, made on your first device,
 │                                synced by iCloud Keychain to your Apple devices
 ├─ HKDF → account key pair       X-Wing: ML-KEM-768 + X25519 (hybrid post-quantum)
 │                                the public half is published, signed
 ├─ HKDF → signing key            signs your key bundle and circle actions
 ├─ HKDF → locator key            HMAC: turns "sleep, 3 May" into an opaque id
 └─ HKDF → wrapping key           AES-256-GCM
      └─ content keys             random, one per category and month
           └─ per-item keys       AES-256-GCM

• The root key is 32 random bytes made on your first device and stored in iCloud Keychain, which syncs it end-to-end between your Apple devices. Voke’s server never has it.
• Content keys per category and month. Sleep, heart and activity each get their own key for each month, so access can be granted for “sleep, last 90 days” without anything else.
• Opaque ids. Stored items are addressed by an HMAC under your key, so the server no longer sees which metric or day an item belongs to.
• Post-quantum from the start. Anything sealed to a person uses HPKE (RFC 9180) with X-Wing, which combines ML-KEM-768 and X25519, so health data stored or shared now stays protected against a future quantum computer. Every symmetric key is 256-bit. Signatures add ML-DSA-65 next to today’s algorithms as iOS 26 becomes the minimum.
• The KMS layer stays as an outer layer, so deleting an account still makes its backups unreadable within 7 days.

The phone does the work

Your iPhone works out scores, summaries, alerts and views from a local encrypted copy of your data, and uploads only sealed results. Google Health data is fetched by the phone too; until that ships, the server seals each page of Google data to your account public key the moment it arrives and keeps nothing readable. Background refresh means circle alerts are as fresh as your phone’s last background update.

Circles

• Your phone works out what each sharing level shows, seals it under a share key for that category, level and month, and wraps the share key to the account public key of each member allowed to see it. The server routes ciphertext and can’t widen anyone’s access.
• Sharing with someone who’s offline. Each account publishes a signed post-quantum public key, which works like the last-resort prekey in Signal’s PQXDH protocol: anyone can seal to it without the owner being online.
• Invites bind keys. The invite link carries a 256-bit secret after the #, which browsers never send to a server. The joiner’s app authenticates its keys with it, so a server can’t substitute its own key.
• An inviter snapshot. When you invite someone, your phone seals a snapshot for them: the circle’s members, their verified public keys and your own share keys at the level you chose. The joiner sees your data as soon as they accept. Other members’ data reaches them from those members’ own phones, because only a person’s own phone can grant access to their data.
• Removing someone starts a new month-key epoch for everything they could see, wrapped only to the remaining members.
• Notifications are sealed to each recipient and opened on their phone, so Apple’s push service carries only ciphertext.

AI with read leases

AI models need readable data, so AI is the stated exception, handled narrowly. For each Ask Voke request, your phone sends a read lease: the content keys for just the categories and date range that request may read. The server opens those items in memory for that request only, calls the model with the same zero-retention and no-training settings as today, and keeps nothing readable afterwards. Chat history is sealed to your account public key, so the server can write it but not read it back.

MCP connections

Each connected AI app gets its own key pair. Its private half is wrapped under secrets carried inside the OAuth tokens the app holds, never in a URL. Voke stores only hashes of those tokens, so at rest it can’t unwrap anything. A request from the app brings the token, the server opens just the data that connection may read, and disconnecting destroys the keys.

What stays visible

To route data and run the service, some information stays visible to the server by design: your account’s name and email, your region, device public keys and push tokens, when your devices sync and roughly how much they write, circle membership and sharing levels, which sources you’ve linked, Google’s notices that new data exists, and AI consent records. Sync times and Google’s notices hint at when you sleep and exercise; the design keeps them as coarse as it can.

Recovery

• Every Apple device you own gets the root key through iCloud Keychain, including a new iPhone restored from iCloud.
• A recovery key (256-bit, 52 characters) is shown at setup and can be saved to Passwords. Voke stores only your root key wrapped under it.
• Linking a new device from one you already have works like Signal’s linked devices: compare a code, approve, done.
• If you lose every device, your iCloud Keychain and your recovery key, your data can’t be recovered by anyone, including Voke. That is the cost of a design in which Voke can’t read your data, and the app says so at setup.

How it ships

The work is planned in phases: the storage rules (already live, sections 6 and 12), then keys, the phone as the compute node, Google Health on the phone, circles, AI leases and MCP keys, and a per-account migration in which each existing account moves over on its own phone. Before Voke describes itself as end-to-end encrypted anywhere, the design and its implementation will go through an external cryptography review. This paper will be updated as each part ships.

Appendix A: cryptographic primitives

• Account data keysPrimitive: 256-bit, generated and wrapped by AWS KMS (AES-256-GCM inside KMS)
• Per-purpose keysPrimitive: HKDF-SHA-256
• Stored dataPrimitive: AES-256-GCM, 96-bit random nonce, 128-bit tag, address bound as associated data
• Opaque record locators, invite hashes, webhook checksPrimitive: HMAC-SHA-256
• Apple tokensPrimitive: XChaCha20-Poly1305, 256-bit server key
• Device keys and request signaturesPrimitive: ECDSA P-256 with SHA-256, in the Secure Enclave
• Google notification signaturesPrimitive: ECDSA P-256 with SHA-256 (Google Tink)
• TLS key exchangePrimitive: X25519MLKEM768 (ML-KEM-768 + X25519), with X25519 for older clients
• Off-site backupsPrimitive: age 1.3, ML-KEM-768 + X25519 recipient (HPKE), ChaCha20-Poly1305 payload
• End-to-end designPrimitive: HPKE with X-Wing (ML-KEM-768 + X25519), AES-256-GCM, HKDF-SHA-256, Ed25519 and ML-DSA-65 signatures

Appendix B: internal decision records

Voke records its design decisions as numbered architecture decision records (ADRs) in its code repository. These are the ones behind each section.

• Architecture: ADR 0011, 0198
• Where your data lives: ADR 0198, 0202 to 0208
• Identity and devices: ADR 0008, 0020, 0021, 0080, 0081
• Keys and encryption at rest: ADR 0006, 0029, 0116
• Encryption in transit and post-quantum readiness: ADR 0087, 0158, 0198, 0251
• Backups: ADR 0006, 0061, 0198, 0252
• Sharing and circles: ADR 0026, 0083, 0145, 0188
• AI features: ADR 0112, 0146, 0160, 0164, 0178, 0210
• MCP connections: ADR 0098, 0099, 0109, 0164
• Operations: ADR 0011, 0200, 0212, 0221
• Deletion: ADR 0006, 0071, 0084, 0085, 0091
• End-to-end encryption design: ADR 0215 to 0222 and 0253, all proposed