Skip to content
Trust & safety

Designed to protect your conversations — and keep the platform healthy.

Invite-only access and end-to-end encrypted direct messages form the current privacy baseline. Clear boundaries, real reporting paths, and accurate status details show what is protected today and what is still being migrated.

Clear privacy boundaries
Specific security claims
Transparent operational limits
Current Encryption Status

Three lines tell the truth faster than a page of caveats.

Live

Direct messages

DM delivery is encrypted end to end, and the relay does not expose plaintext DM history back to the browser.

Live with migration caveats

New groups

Groups created with the device-encrypted option keep message bodies on member devices rather than on the relay. Older relay-hosted groups and rooms still leave readable history in compatibility paths until that history is retired.

Protection depends on conversation type

Attachments

Current web, mobile, and desktop source encrypts conversation attachment bytes before upload. Device-encrypted conversations keep file keys inside encrypted message payloads; relay-hosted rooms and legacy groups give the relay recoverable key material. Encrypted-upload metadata currently includes exact plaintext length and a deterministic plaintext hash.

Private By Default

Your conversations stay private.

EmberChamber is built around end-to-end encrypted DMs, new device-encrypted groups, and invite-gated trusted circles. The relay routes mailbox traffic without exposing DM plaintext history, while legacy relay-hosted group and room history still exists in compatibility paths during the migration.

The product is also age-gated by design. Invite gating, self-attested 18+ onboarding, and organizer-controlled spaces mean the people in a circle chose each other deliberately.

What the relay can see

Account, device, session, invite, and membership metadata, plus ciphertext envelopes until acknowledgement and attachment blobs needed for delivery. Encrypted-attachment metadata currently includes exact plaintext length and a deterministic plaintext hash. The relay is narrow, but it is not empty.

What the relay cannot read

Direct-message content and new device-encrypted group history are not exposed through relay-hosted history endpoints. Device-encrypted conversation file keys remain inside encrypted message payloads; relay-hosted rooms and legacy groups use a different boundary.

What stays on your device

Private keys, DM history, local search index, contact trust state, and file keys for device-encrypted conversations stay on participant devices. Relay-hosted rooms and legacy groups can give the relay recoverable attachment-key material.

When Something Needs Attention

Private spaces still need defensible response paths.

The safety model is built around narrow disclosure, deliberate access, and operator action only when something serious is surfaced.

Reports are disclosure-based

If something crosses the line, you choose the evidence you share. The system is not built around harvesting full private histories by default.

Invite gating matters

The product starts with deliberate circles, not open-network growth. That social boundary reduces a large class of abuse before it starts.

Serious abuse still has consequences

Severe abuse can lead to session termination, invite revocation, and account bans. Private by design does not mean consequence-free.

What We Are Honest About

Trust starts with accurate limits, not inflated claims.

Honesty is part of EmberChamber's privacy model. We explain evolving boundaries plainly and avoid claims that belong to systems with very different threat models.

Privacy by design does not mean pretending moderation, abuse handling, or platform policy disappear. It means keeping those powers narrow, documented, and tied to real problems instead of broad surveillance.

We do not promise “uncensorable forever.”

We do not promise zero server visibility in an absolute sense.

We do not position EmberChamber as law-enforcement proof or promise guaranteed anonymity.

Keeping The Platform Healthy

Healthy does not mean intrusive.

Invite controls, rate limiting, block rules, and operator response paths exist to keep the experience usable for legitimate participants. They are not there to turn private conversations into a monitoring product.

  • Invite controls reduce spam and bot abuse before they enter the circle.
  • Block rules and revocation paths keep participants in control when trust breaks.
  • Operators act on surfaced abuse, not on blanket inspection of private conversations.