Whitepaper

Local intelligence. Encrypted continuity.

Tilde is a local-first AI workspace. Its defining choice is not a privacy setting but an architectural boundary: the model and the canonical working copy of a conversation live on the user’s device. The cloud is used for authentication, encrypted continuity, and deliberately requested network tools—not as the default home of the user’s intelligence.

This paper describes Tilde’s implemented local and cloud continuity architecture. It explains what Tilde protects, which metadata remains visible, how a new device earns access, how recovery works when every trusted device is unavailable, and where the system’s trust boundaries sit.

Abstract

Tilde encrypts durable conversation content with a randomly generated 256-bit personal vault key using libsodium’s XSalsa20-Poly1305 authenticated encryption. Each trusted device has an independent Curve25519 keypair and receives the vault key inside a sealed, device-bound envelope. A separate 160-bit Recovery Key can open a recovery envelope after Email OTP authentication when no trusted device is available. Supabase coordinates accounts, devices, opaque key envelopes, and an ordered change ledger, but it does not receive the plaintext vault key or synchronized content.

The Room database, with durable content encrypted at the field level, remains the source of truth. Local writes commit immediately and add a mutation to a durable outbox in the same transaction. Small, idempotent REST batches synchronize those ciphertext records through a narrowly granted RPC surface. No WebSocket, polling loop, or generalized replication service is required for correctness.

Table of Contents

1. The Product Boundary
2. Design Principles
3. Threat Model
4. Encrypted Local Foundation
5. The Personal Vault
6. Trusted Device Enrollment
7. The Recovery Kit
8. Local-first Sync
9. Cloud Security Boundaries
10. Conflicts, Deletion, and Failure
11. Data Classification
12. Account and Device Lifecycle
13. Scope Boundaries
14. Conclusion

• Appendix A: Wire Formats
• Appendix B: Cloud Information Model
• Appendix C: Cloud API Boundaries
• Appendix D: Glossary and References

1. The Product Boundary

Most AI products begin with a remote model endpoint. The client sends a prompt, a provider performs inference, and the provider returns a response. Tilde begins one boundary closer to the user: inference runs inside the native app, using a model stored on the device. The conversation can continue without a network connection, and the full transcript is not sent to a model provider as a condition of getting a response.

Local does not mean isolated. People replace phones, move between a phone and a computer, and expect their durable history to follow them. Tilde therefore separates two jobs that cloud AI products commonly combine:

• Computation and comprehension happen locally, where plaintext is required.
• Continuity and coordination happen through the cloud, where plaintext is not required.

The distinction is important: end-to-end encryption cannot hide text from a remote model that must read that text to perform inference. Tilde removes that routine disclosure by moving inference to the device. Encryption then protects durable content when it is stored or synchronized.

1.1 What is durable

A conversation contains ordered messages. A message contains ordered, self-describing events: user text, model output, reasoning state, tool calls, tool results, and other renderable content. Replaying those events reconstructs the message. Tilde also stores encrypted conversation titles and encrypted memories that help the local model provide continuity.

Model binaries, model installation state, drafts, transient generation state, hardware tuning, and ephemeral UI state remain device-local. Tilde synchronizes durable user state, not a live mirror of every process.

2. Design Principles

3. Threat Model

Tilde’s cryptography is intended to keep durable content confidential when a database, backup, network trace, or cloud store is obtained without control of a trusted device. It is not intended to make a fully compromised device safe from itself.

3.1 Trusted components

• The native Tilde app process while it is running.
• Platform secure storage: Apple Keychain and Android Keystore-backed Tink storage.
• The operating system sandbox and cryptographic random-number generator.
• libsodium’s authenticated-encryption and sealed-box implementations.

3.2 Explicit non-goals

• Protection after complete operating-system or app-process compromise.
• Concealing that an account, device, conversation record, or synchronization event exists.
• Remotely erasing an offline device or retroactively hiding content it already decrypted.
• Cryptographic forward revocation in v1.
• Hiding a deliberately submitted network-tool query from Tilde’s proxy or the selected provider.

4. Encrypted Local Foundation

Tilde’s implemented local store uses a single random 32-byte vault key and a versioned content format:

content_v1 =
  version(0x01)
  || nonce(24 bytes)
  || crypto_secretbox(plaintext, vault_key, nonce)

crypto_secretbox combines XSalsa20 encryption with a Poly1305 authenticator. A wrong key, modified ciphertext, or modified nonce produces an explicit authentication failure rather than plausible-looking garbage. The 24-byte random nonce makes accidental reuse negligible at Tilde’s write volume.

4.1 Key provisioning

On first use, the device generates a random Curve25519 key seed, derives a device keypair, generates the vault key, and seals a recoverable copy of the vault key to the device public key. The seed, cached vault key, public key, and sealed copy live in platform secure storage. The private key is derived only when needed and wiped from working memory afterward.

The current local implementation can recover a missing cached vault key from the sealed copy on the same device. The sync design strengthens this device identity by placing Tilde vault secrets in non-migrating, device-only secure storage so a backup restore does not silently clone a trusted device.

4.2 Encryption boundary

The repository layer encrypts content before persistence and decrypts it after reading. The sync layer handles the exact same bytes without opening them. At rest, opaque values use ByteArray/SQLite BLOB in Room and Postgres bytea in the cloud. Base64 is used only when binary data crosses a JSON RPC boundary.

5. The Personal Vault

A vault is the cryptographic and synchronization home for one account. V1 permits one active personal vault per account. Its 32-byte vault key encrypts all durable content, while an unrelated UUID identifies the vault in local and cloud data.

Devices do not share a private key or an account-wide seed. Each device creates its own independent 32-byte seed and Curve25519 keypair. The server stores the public key and a sealed envelope containing the vault key; it never receives the device seed, private key, or plaintext vault key.

6. Trusted Device Enrollment

Email OTP answers “which account is requesting access?” It does not answer “may this device decrypt the vault?” Device enrollment is a separate ceremony:

The approving and requesting devices need no direct connection. Supabase is the mailbox for the sealed envelope and records which authenticated trusted device authorized it. The ceremony relies on authenticated backend integrity and does not use QR binding, number matching, key transparency, or biometric step-up.

Device enrollment does not rely on push notifications. A pending request appears when the trusted device next refreshes its enrollment state. A request cancelled from another device remains as a terminal revoked row long enough for the waiting client to show a clear cancellation state instead of becoming silently orphaned.

7. The Recovery Kit

A Recovery Kit is the fallback authority when no trusted device is available. It combines a uniformly random 160-bit Recovery Key with a recovery envelope stored by Supabase. Recovery requires both:

1. a valid Email OTP session for the account; and
2. the Recovery Key that opens the current recovery envelope.

Neither factor is sufficient alone. The server can return the opaque envelope to an authenticated pending device, but only the Recovery Key can reveal the vault key and a random proof token inside it. The client returns that proof over authenticated TLS to demonstrate that it opened the envelope before the server trusts the device.

7.1 Human format

TILDE-RK1-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-CCCC

The eight secret groups encode 20 random bytes using Crockford Base32. The final group is a 20-bit checksum that catches common copy and transcription errors; it does not add authorization. Tilde deliberately uses a random string rather than a mnemonic phrase or user-selected PIN.

Setup creates a one-page PDF with the account email at creation, creation date, QR code, grouped Recovery Key, and short instructions. It also offers a recovery URL:

https://tildeapp.ai/recover#<grouped-recovery-key>

The secret is placed after the URL fragment marker, so a conforming browser does not send it to the web server. The URL contains no email, account ID, vault ID, or device ID. Tilde never emails or uploads the PDF automatically; the user deliberately exports it or stores the URL.

A mandatory checkbox acknowledges that the kit was saved before initial vault creation completes. Tilde does not pretend it can verify the destination. The plaintext key is shown only during creation and is not retained for a later “view kit” action.

7.2 Recovery does not mean incident response

Routine recovery on a replacement phone adds that phone as a trusted device without revoking a Mac or older phone. After recovery, Tilde offers to keep the current kit or create a replacement. The Trusted Devices screen also provides an explicit Replace Recovery Kit action and a separate Sign Out All Other Devices action.

Replacing a kit is atomic: the old kit remains valid until the user acknowledges saving the new PDF or URL and the replacement transaction commits. Tilde does not attempt to verify where the kit was saved. A crash before commit leaves the old kit usable.

7.3 When recovery is impossible

If every trusted device and the Recovery Kit are lost, the vault key is unavailable by design. The user may still authenticate by email and choose Reset Encrypted History & Start Fresh. This atomically purges the old encrypted vault, revokes its devices and recovery material, and creates a new unrelated vault, vault key, and Recovery Kit. Account identity and non-secret account state survive; encrypted history does not.

8. Local-first Sync

Sync extends the encrypted local store rather than replacing it. Room remains the UI source of truth on iOS, Android, and macOS. A local edit updates the domain row and its outbox entry in one database transaction, so a crash cannot preserve one without the other.

8.1 Three operations

8.2 Bootstrap without a moving target

The first bootstrap page captures the current vault ledger revision as a baseline. Every subsequent page uses a signed, opaque token bound to that baseline and the authenticated device. The server does not hold a database snapshot open across requests. Writes committed after the baseline receive later revisions; once the final page is applied, an ordinary pull catches up from the baseline and closes the race.

8.3 Incremental pull

Pull accepts only after_revision. The server derives the account, trusted device, and vault from the authenticated session and controls the page size. Changes arrive in ascending revision order. Room applies the page and advances its cursor to the final revision in the same transaction.

8.4 Atomic, idempotent push

Every mutation has a UUID. The server locks the vault revision counter, recognizes already committed UUIDs as successful retries, validates new records and relationships, applies them, allocates consecutive revisions, and inserts matching ledger entries in one transaction. Any invalid mutation rolls back the whole chunk. The client then removes only the exact outbox generations acknowledged by the response.

Large backlogs drain through bounded, dependency-safe chunks. A conversation may span chunks as long as parents are already committed or precede their children. Server configuration controls decoded byte and mutation-count limits.

8.5 When sync runs

Sync runs opportunistically as the app and local data change, and users can request it explicitly. Transient errors use bounded retry with backoff and leave the durable outbox intact for a later attempt. There is no endless foreground polling.

Completed messages synchronize; token-by-token generation does not. Realtime, silent push, and specialized replication engines sit outside the authoritative sync path; REST batches provide correctness.

9. Cloud Security Boundaries

Tilde uses Supabase Auth for Email OTP sessions and Postgres for coordination and encrypted storage. Native clients contain only a publishable credential. They receive no service-role key and no direct CRUD privileges on application tables.

9.1 Four Postgres schemas

9.2 Defense in depth

Direct SELECT, INSERT, UPDATE, and DELETE privileges are revoked from anonymous and authenticated clients. Every application table enables and forces row-level security as a second isolation layer. Each RPC still performs explicit account, live-session, trusted-device, and vault checks; RLS is not treated as a substitute for ceremony-specific authorization.

Privileged database functions use an empty search path, fully qualified objects, and narrowly granted ownership roles without BYPASSRLS. The service-role credential is confined to service_api: it has no direct internal_data privileges or table grants. Each allowlisted RPC runs through a no-login, no-BYPASSRLS executor with only the internal table privileges that operation requires.

9.3 Edge Functions

Edge Function source lives under supabase/functions, not inside a Postgres schema. Tilde’s web-tool handlers validate the caller’s Supabase session inside the function, verify App Attest, rate-limit the request, and validate its input. They do not forward the caller’s JWT to app_api. For attestation keys, one-time challenges, replay counters, and rate-limit windows, the handlers use a module-private service-role client to call an allowlisted service_api RPCs. Those RPCs have no path to vault, conversation, message, event, memory, or sync-ledger tables.

Optional web search, current-information, and places tools are a separate privacy boundary. When enabled and invoked, the selected plaintext query and provider response pass transiently through Tilde’s attested Edge Function. The function makes the provider request with Tilde’s credentials and does not forward the user’s email, account ID, device ID, JWT, conversation ID, unrelated conversation history, or vault key. The external provider receives the query text needed to answer the request, but receives it as an anonymous query from Tilde’s proxy.

10. Conflicts, Deletion, and Failure

10.1 Conversation divergence

Every message records the previous message known when it was created. If two offline devices add different children to the same predecessor, the server rejects the later atomic batch rather than interleaving branches. The client pulls the committed branch and moves only its unsynchronized tail into a new conversation whose title carries a localized Split marker. Both pieces of work survive without introducing a full branching-history model.

10.2 Metadata conflicts

Renames, pinning, and other ordinary metadata use deterministic server-commit-order, whole-record last-write-wins behavior. Device clocks are not authoritative. last_activity_at is updated in the same local transaction as a message commit. Like other whole-record conversation metadata, conflicting cloud writes resolve in server commit order.

10.3 Deletion wins

A conversation deletion first enters a short local pending state and presents an Undo toast. Only after that window expires does the client synchronize a tombstone. Postgres and Room cascade messages and events; memory provenance becomes null; encrypted payloads are purged. A stale offline upsert cannot resurrect the deleted record.

10.4 Permanent rejection

A structurally invalid mutation is treated as an application or schema defect, not a routine user conflict. The client follows dependencies from the bad record to its conversation, excludes that conversation’s complete pending tail for the rest of the process session, and continues syncing unrelated data. A cold launch gives it one fresh attempt.

V1 records a privacy-safe PostHog event with operational categories and batch-shape metadata. It sends no IDs, titles, content, ciphertext, keys, envelopes, tokens, or payloads. Persistent quarantine UI and diagnostic submission are outside this architecture.

11. Data Classification

Tilde does not claim metadata invisibility. Supabase can infer approximate activity timing, device population, record counts, and encrypted payload sizes. V1 does not use padding, cover traffic, or private-information-retrieval techniques.

12. Account and Device Lifecycle

12.1 Sign in when local data already exists

A device may contain unaffiliated local conversations before the user signs into an account whose vault already has history. Tilde waits until the device has cryptographically opened an approval or recovery envelope, then asks the user to Merge & Continue, Discard Local Data & Continue, or Back Out of Sign In.

It does not download the account history before this decision. The pending choice is stored globally and bound to the target vault so a crash or interrupted login cannot mix data between accounts. A merge bootstraps the account store before importing and re-encrypting local content; a discard verifies the account bootstrap before deleting the local source.

12.2 Sign out

Sign out revokes only the current Tilde device registration, clears its local Supabase session, and deletes its account database, device key, and vault key. It does not revoke other trusted devices. If it is the last trusted device, Tilde warns that returning will require the Recovery Kit or a destructive start fresh.

12.3 Remove a device

A trusted device may revoke another trusted or pending device. Every protected RPC checks the live Tilde device registration in addition to the Supabase JWT, so revocation takes effect even while an old access token remains cryptographically valid. The removed app signs out with an explanation on its next server contact.

13. Scope Boundaries

• Single-owner vault. Every trusted device has the same owner authority. The vault does not support shared conversations, participant key distribution, or member-level access.
• Remote-agent access. Tilde does not disclose the personal vault key or continuous conversation context to remote agents. External tool providers receive only deliberately selected, anonymous queries through Tilde’s proxy.
• Authentication and recovery. Email OTP authenticates the account, and the Recovery Key provides last-resort vault access. Passkeys do not participate in this protocol.
• Revocation. Device removal denies future Tilde server access but does not rotate content keys or remotely erase content already downloaded by that device.
• Device approval. Approval uses the authenticated backend mailbox and device-bound sealed envelopes. It does not include number matching, QR binding, key transparency, or system-authentication step-up.
• Sync delivery. REST is authoritative. Push and realtime delivery are not part of the correctness model.
• Client trust. The protocol covers installed trusted-device clients. Browser and temporary-computer access are outside its trust model.
• Metadata exposure. Records do not use padding, cover traffic, or access-pattern defenses.
• Ledger retention. The server retains ledger metadata indefinitely and does not compact the ordered history.

14. Conclusion

Tilde’s privacy model is a division of responsibility. The device is trusted with understanding: it runs the model, holds the keys, and renders plaintext. The cloud is trusted with continuity: it authenticates accounts, coordinates devices, and stores opaque records in commit order. The Recovery Kit is trusted with last-resort access, but only alongside the account email.

No single mechanism carries the whole claim. On-device inference removes the routine model provider. Authenticated encryption protects durable content. Independent device keys make access explicit. A narrow REST/RPC layer and forced RLS reduce the cloud attack surface. Honest recovery language acknowledges the unavoidable trade: if no trusted device and no Recovery Kit can reveal the vault key, Tilde cannot reveal the history either.

Local where intelligence happens. Encrypted where continuity happens.

Appendix A: Wire Formats

All multibyte identifiers use their canonical 16-byte UUID representation. Opaque binary values are stored as BLOB/bytea and Base64 encoded only inside JSON transport.

A.1 ContentCiphertextV1

format_version     1 byte   0x01
nonce             24 bytes random
auth_tag          16 bytes Poly1305
encrypted_message  n bytes XSalsa20 output

The encoded value is version || nonce || auth_tag || encrypted_message, matching libsodium’s combined crypto_secretbox_easy output.

A.2 DeviceVaultKeyEnvelopeV1

outer:
  format_version             1 byte   0x01
  sealed_box               113 bytes  crypto_box_seal(authenticated_plaintext)

authenticated_plaintext:
  purpose                    1 byte   DEVICE_VAULT_KEY (0x01)
  vault_id                  16 bytes
  recipient_device_id       16 bytes
  vault_key                 32 bytes

total                      114 bytes

The server validates only the outer version and fixed length. The recipient opens the envelope and verifies its sealed purpose, vault ID, and device ID.

A.3 Recovery Key

secret         20 random bytes (160 bits)
encoding       Crockford Base32, 32 characters
checksum       first 20 bits of BLAKE2b-256(
                 "TILDE-RK1-CHECKSUM" || secret
               )
display        TILDE-RK1-[8 x 4 secret chars]-[4 checksum chars]

Input parsing is case-insensitive, ignores whitespace and hyphens, and maps commonly confused characters O→0 and I/L→1. Output always uses canonical uppercase grouping.

A.4 RecoveryVaultKeyEnvelopeV1

recovery_wrapping_key =
  BLAKE2b(
    output_length = 32,
    key = raw_recovery_secret,
    message = "TILDE-RK-WRAP-V1" || vault_id
  )

outer:
  format_version             1 byte   0x01
  nonce                     24 bytes
  secretbox                 97 bytes

authenticated_plaintext:
  purpose                    1 byte   RECOVERY_VAULT_KEY (0x02)
  vault_id                  16 bytes
  vault_key                 32 bytes
  proof_token               32 bytes random

total                      122 bytes

Supabase stores SHA-256(proof_token) alongside the envelope. The proof token itself remains encrypted until a correct Recovery Key opens the envelope.

Appendix B: Cloud Information Model

Cloud records contain opaque identifiers, encrypted payloads and key envelopes, ordering metadata, and timestamps. Room remains the canonical working copy and separately tracks unsynchronized local changes and the last applied cloud revision.

Appendix C: Cloud API Boundaries

Requests omit account, vault, caller-device, and auth-session identifiers whenever the server can derive them. Client-provided UUIDs identify target records; they are never treated as authorization capabilities.

Appendix D: Glossary and References

D.1 Glossary

Envelope

An opaque encrypted artifact that delivers the vault key to one device or Recovery Key.

Ledger revision

A monotonically increasing, per-vault commit position used for incremental synchronization.

Personal vault

The encrypted content and key-distribution domain owned by one Tilde account.

Recovery proof

A random token encrypted inside the recovery envelope and hashed by the server, proving that a client opened the current envelope.

Trusted device

A device whose registration is active and that can open its own envelope to obtain the vault key.

D.2 References

1. libsodium: Authenticated encryption with secret-key cryptography
2. libsodium: Sealed boxes
3. libsodium: Generic hashing
4. PostgreSQL: Row security policies
5. Supabase: Row Level Security