Privacy-first does not mean hand-wavy.
EmberChamber limits unnecessary centralized visibility while using a hosted relay for reliable delivery. This policy explains what stays on your devices, what the relay handles, and which protections are still evolving.
Core commitments
- Email is used for auth and recovery, not public discovery.
- Email is not the social identity inside the product; pseudonymous names and handles are.
- The current beta is age-gated and uses a self-attested 18+ confirmation step.
- The relay stores operational metadata, mailbox ciphertext, and attachment blobs needed for the hosted beta.
- Private keys, DM history, and local private-content search stay primarily on user devices.
- EmberChamber does not market itself as perfect anonymity, law-proof infrastructure, or zero-visibility hosting.
Current boundary
The right privacy question is not whether the relay exists. It does. The real question is what it stores today, what stays local, and which compatibility paths are still being retired. That includes DMs, group history, device-encrypted versus relay-hosted attachments, search, recovery, and passkeys.
Direct messages
Stays local: Private keys, DM history, and the private-content search index stay on the device.
Relay role: The relay stores account and conversation metadata plus ciphertext mailbox envelopes until they are acknowledged.
Current note: The relay does not serve plaintext DM history back to the browser.
Group history
Stays local: New groups are created with device-encrypted history and local client history.
Relay role: The relay coordinates membership, epochs, and mailbox delivery for new groups while legacy compatibility history still exists for older group and room paths.
Current note: Legacy relay-hosted group and room history still exists in compatibility paths and older data.
Device-encrypted conversation attachments
Stays local: Current web, mobile, and desktop source encrypts attachment bytes before upload and carries file keys inside encrypted conversation payloads.
Relay role: R2 stores ciphertext. The relay currently also receives attachment metadata, including exact plaintext length and a deterministic plaintext hash.
Current note: Current first-party source implements this boundary; production and published-installer parity require separate verification.
Relay-hosted conversation attachments
Stays local: Current clients encrypt bytes before upload, but file keys do not remain exclusively on participant devices.
Relay role: Relay-hosted rooms and legacy groups give the relay recoverable file-key material so their hosted history can serve attachments.
Current note: This is encrypted storage, not end-to-end protection from the relay.
Search
Stays local: Search over private message content stays local to the device.
Relay role: The relay exposes joined-space metadata search, not server-side search over private message bodies.
Current note: Search is local-first today, not a server archive feature.
Recovery
Stays local: Private keys, local history, and trusted-device state remain tied to the devices you control.
Relay role: Email bootstrap plus device and session metadata let the hosted beta restore access to an existing account.
Current note: Total-device-loss recovery remains intentionally limited, and the fuller trusted-device recovery flow is not finished.
Passkeys
Stays local: Passkey private keys stay on user devices or platform authenticators rather than on the relay.
Relay role: The relay issues and verifies WebAuthn challenges, stores public credential material and counters, and creates a device-bound session after successful authentication.
Current note: Enrollment and sign-in are implemented in current web source; native-client UX and trusted-device recovery are not.
Metadata that still exists
A practical relay still needs account, device, session, invitation, and delivery metadata to function. We keep that set narrow, document it honestly, and avoid expanding it into unnecessary behavioral analytics.
Search and storage
Search for private content is a local device capability. The relay is not a searchable archive of private message bodies. Joined-space metadata search and hosted attachment delivery still exist.
Beta caveat
EmberChamber is still a beta product, not a final audited security product. Current production hardening focuses on the relay-first runtime, invite-only onboarding, device review, and honest privacy boundaries while the remaining encrypted-group and recovery work continues.