End-to-End Encryption: Design and Status

The planned private E2EE model would work as follows:

1. Authorized endpoints establish content keys
2. An endpoint encrypts selected private sync data before upload
3. The service relays ciphertext between authorized endpoints
4. The receiving endpoint authenticates and decrypts the content

Planned endpoint A     Relay service     Planned endpoint B
 content encryption ->  ciphertext  -> endpoint decryption
 Target design; not a current release guarantee

• Local by default — Local workloads keep their data on your device unless you choose a connected feature
• Explicit connections — Sync and cloud workflows require an explicit user action
• Encrypted transport — Supported network connections protect data while it travels between your device and the service
• Clear service boundary — Current relay-assisted deployment workflows are server-assisted; private E2EE remains planned

Why your AI data should stay local →

Recovery depends on the kind of data and the features available in your build. Local apps, models, and outputs require ordinary backups. A recovery phrase may restore supported identity or key material, but it is not a universal backup and does not establish private E2EE.

Use the backup, export, and recovery controls that the product explicitly provides for the data you need to restore.

BeeKEM and Continuous Group Key Agreement (CGKA) inform the planned group-key design. Automatic membership rotation, forward secrecy, and post-compromise security are not current product guarantees.

• Planned membership changes advance group key state
• Planned device removal changes future content access
• Planned releases will state their verified key-lifecycle guarantees explicitly

Forward Secrecy

Forward secrecy is the goal that compromise of a current key does not expose earlier content. Thumper-Run does not currently claim this property for released sync or deployment workflows.

Post-Compromise Security

Post-compromise security is the goal of restoring future confidentiality after an attacker loses access. It remains part of the planned E2EE work.

Use these current boundaries when deciding what data to connect to a service:

Do

• Store any recovery phrase in a physically secure location
• Store a second copy in a password manager’s secure notes
• Verify local backups before relying on them
• Review what each recovery control actually restores

Don't

• Never store in an unencrypted file, screenshot, or note on your device
• Never send via email, chat, SMS, or any messaging app
• Never share with anyone, including Thumper-Run support staff
• Never store in a cloud-synced folder (Google Drive, iCloud, Dropbox)

Pairing authorizes another device to participate in supported multi-device workflows. Current relay-assisted paths remain server-assisted; pairing alone is not evidence of private E2EE.

1. Start pairing from a device you control
2. Verify the device and account details before approving
3. Review connected devices after pairing

The planned private E2EE design adds endpoint-held content keys and verified membership-change behavior. Those properties are not current release guarantees.

For the broader security architecture, current boundaries, and planned key-management design, see the Platform Architecture → Security & Encryption section.