E2EE Architecture & Cryptography

Abolitus is engineered around an uncompromising privacy rule: the server should not need to see your readable workspace.

That rule shapes the entire sync model.

Instead of treating cloud sync as a normal application database full of readable user content, Abolitus treats sync as a transport and storage boundary where data is supposed to cross in encrypted form.

If you only remember one idea from this page, remember this one:

Readable creative state belongs on your device. Sync exists to move protected state, not to turn the cloud into your permanent plaintext archive.

The Trust Boundary

The easiest way to understand the system is to separate two zones.

Local zone

Your browser database acts as the active working environment.

This is where you:

• read chats,
• edit characters,
• manage lore,
• configure your session,
• and interact with model routes.

This zone is readable because it has to be. A writing tool cannot function if it never reconstructs your data locally.

Sync boundary

When information crosses from the local workspace into remote storage, the goal is for it to cross as encrypted payload rather than ordinary application data.

That means the cloud side is meant to retain the continuity benefit of backup and multi-device sync without becoming a place where your roleplay history sits in routine plaintext.

The Cryptographic Pipeline

When you enable Cloud Sync, your local data goes through a strict cryptographic pipeline before it is uploaded.

1. Key Derivation (Argon2)

Your encryption keys are derived from a Master Key generated in your browser. Abolitus uses Argon2 as a key-derivation step because it is intentionally expensive for attackers to brute-force at scale.

That matters most in the scenario privacy systems must take seriously: someone obtains encrypted sync material and tries to attack it offline.

Argon2 is designed to make that class of attack slower, more memory-intensive, and more expensive.

2. Encryption Mechanism (AES-256-GCM)

All syncable user data is encrypted locally using AES-256-GCM through the browser's Web Crypto stack.

This matters for two reasons:

• Confidentiality: the payload is not supposed to be readable without the right local key material.
• Integrity: tampering with the encrypted payload should fail authentication instead of silently producing believable but corrupted plaintext.

That second property is easy to overlook. Encryption is not only about hiding data. It is also about making sure modified ciphertext does not quietly turn into trusted garbage during restore.

3. Traffic Analysis Prevention (1KB Chunk Padding)

Simply encrypting content is not always enough. Raw encrypted payload size can still leak patterns.

For example, if an observer repeatedly sees tiny encrypted objects followed by much larger ones, they may infer something about message cadence, scene growth, or application behavior even without reading the contents.

To reduce that kind of metadata leakage, Abolitus pads data toward fixed boundaries before encryption.

The practical effect is that small differences in plaintext size become less informative to anyone watching storage or transport patterns.

The Vault Concept

Your local browser database acts as the readable workspace. The encryption boundary sits at the moment data is prepared for remote continuity.

• When an automatic cloud sync is triggered, the data is compacted, encrypted with your runtime key, padded, and then pushed to the cloud.
• When you link a new device, the encrypted bundle is downloaded, and your local runtime key decrypts it directly into the new device's local storage.

This is one of the most important distinctions in the app. The cloud is not the place where your ordinary working state becomes conveniently readable and then maybe encrypted later. The protection is supposed to happen before the sync boundary is crossed.

What Does Not Sync Like Ordinary Content

Some information is intentionally kept out of ordinary cross-device sync flows.

Most importantly:

• your raw provider API keys,
• your TTS credentials,
• and the most sensitive key material used to protect your sync state

should not be treated like normal app preferences that casually replicate everywhere.

That separation exists because convenience syncing and credential exposure are different problems.

What the Server Can Still Know

Zero-knowledge does not mean the service learns literally nothing.

Depending on the feature and deployment path, remote infrastructure may still observe limited metadata such as:

• that an account exists,
• that encrypted blobs exist,
• when sync happened,
• and approximate storage volume after padding rules are applied.

What the design is trying to remove is routine access to the readable body of your chats, characters, and lore.

Recovery Tradeoffs

Users often discover the real meaning of zero-knowledge when they ask a support question like: "If I lose everything, can the service just restore my secret for me?"

Usually, the honest answer is no.

That is not a customer-service failure. It is the consequence of the privacy model.

If a service can always recover your encryption secret on demand, then the service or someone who compromises it probably had too much power all along.

What This Means for You Day to Day

If you use cloud continuity features, the safest mindset is:

• keep your recovery material organized,
• treat exported backups carefully,
• do not assume provider keys roam automatically,
• and remember that local device security still matters.

The system is designed to reduce trust in the backend, not to eliminate the need for careful endpoint hygiene.