Privacy-first does not mean hand-wavy.
This beta policy is a product-facing summary of how EmberChamber is intended to reduce unnecessary centralized visibility while still operating a usable hosted relay.
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 adults-only 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, browser versus native 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.
Browser attachments
Stays local: Browser encrypted-conversation flows can encrypt attachment bytes and keep file keys with the client before upload.
Relay role: R2 stores attachment blobs and signed access metadata so downloads can be delivered to authorized members.
Current note: This browser DM path is ahead of the native attachment path today.
Native attachments
Stays local: File selection, local cache, and local trust state remain with the client.
Relay role: Current mobile and desktop flows can still upload raw bytes to R2 through signed upload and download tickets.
Current note: Native attachment encryption is still being migrated and should not be flattened into the browser DM story.
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: When shipped, passkey private keys will live on user devices or platform authenticators rather than on the relay.
Relay role: The relay schema and endpoints exist only as scaffolding today so the beta can add passkeys later without changing the product boundary.
Current note: Passkey sign-in is not live in the current beta.
Metadata that still exists
A practical relay still needs account, device, session, invitation, and delivery metadata to function. The product direction is to 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 should not become a searchable archive of private message bodies, even while 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.