Designed to protect your conversations — and keep the platform healthy.
Invite-only access and end-to-end encrypted direct messages are the current privacy floor, not the excuse for inflated claims. The design still needs clear boundaries, real reporting paths, and accurate language about what is already true versus what is still being migrated.
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
New groups start device-encrypted, while legacy relay-hosted group and room history still exists in compatibility paths.
Mixed by client flow
Attachments
Browser encrypted-conversation uploads can encrypt before upload, but native attachment encryption is still uneven across client paths.
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 adults-only 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 ack and attachment blobs needed for delivery. 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. That does not make every legacy path or attachment flow equally mature yet.
What stays on your device
Private keys, DM history, local search index, and contact trust state. Attachment encryption and legacy relay-hosted compatibility paths still need to be described separately instead of flattened into one claim.
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.
Trust starts with accurate limits, not inflated claims.
The strongest privacy position on this site is honesty. If a boundary is still evolving, say that plainly instead of borrowing the language of 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 anonymity guaranteed.
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.