Security should be explained,
not just claimed.
NyChat clearly explains what is encrypted, what the server handles, and where the boundaries are — every claim on this page matches the shipped implementation.
Eight sections, no slogans: the encrypted-text path, per-content-type boundaries, invite anatomy, the server's exact role, operational defenses, moderation, and an honest list of what NyChat does not promise.
How encrypted text travels.
Six steps from creation to decryption. Hover or tap a step on desktop; the path is a vertical rail on smaller screens.
Each message is encrypted in the browser with AES-256-GCM via the native Web Crypto API — a fresh 12-byte IV per message, with additional authenticated data binding every ciphertext to its room and crypto version.
The entire encrypted-text path — plaintext exists only at the two ends. Tap any step to inspect it.
Every content type, its own security model.
Text, media, calls, and reports are protected differently — and pretending otherwise is how trust gets broken. Filter by protection model.
| Content type | Protection | Server role | |
|---|---|---|---|
| End-to-end encrypted | Relays ciphertext | ||
Encrypted in your browser with AES-256-GCM before it leaves your device; decrypted locally by recipients holding the room key. The server stores and forwards ciphertext, an IV, and a crypto version label. | |||
| Access-controlled capability access | Storage + temporary access capability | ||
| WebRTC peer-to-peer transport | Signaling | ||
| WebRTC peer-to-peer transport | Signaling | ||
| Bounded moderation evidence | Moderation processing | ||
Encrypted in your browser with AES-256-GCM before it leaves your device; decrypted locally by recipients holding the room key. The server stores and forwards ciphertext, an IV, and a crypto version label.
Different content types are protected by different mechanisms — stated exactly as implemented.
One locates the room. The other unlocks it.
A Room Code identifies a room. A Complete Secure Invite contains the information required to unlock encrypted text. Dissect an invite below.
The key fragment is client-side key material. Browsers do not send URL fragments in HTTP requests, so this part never reaches any server. This is what turns a located room into an openable one.
Redacted illustration — a real invite carries the actual room secret in its fragment. Share it only with people who belong in the room.
- A short identifier that locates the room
- Contains no key material — cannot open a secure room alone
- Handy for reference; never sufficient for access
- The full room URL, including the fragment key material
- Fragment handling is client-side — the server never sees the key
- Invalid or missing key material fails closed; no fallback derivation
Fail-closed by design. Joining with a code alone, or with missing or invalid key material, stops immediately. NyChat never guesses, never derives a replacement key, and never falls back to an unprotected session.
Lost invite, lost session. The room key exists only in the complete invite link. Lose it and the encrypted session cannot be re-established — no reset, no recovery, no fallback.
What the server handles — and what it cannot read.
Coordination requires seeing a lot. Reading encrypted room text requires the key, and the key never arrives.
- Room coordination — creating, joining, expiring, and removing temporary rooms
- Ciphertext delivery — relaying encrypted text payloads between participants
- Media access — storing uploads and issuing short-lived capability tokens
- Call signaling — relaying WebRTC offers, answers, and ICE candidates
- Moderation workflows — reports with bounded server-side evidence capture
- Operational systems — validation, rate limiting, presence, audit logging
- Encrypted text messages — it receives and stores ciphertext only, and the room key never transits the server.
- The room encryption key — it lives in the invite URL fragment, which browsers never send in HTTP requests.
- Call audio or video — those flow directly between participants' browsers over WebRTC.
Precisely worded: media files are stored on the server and access-controlled — they are not end-to-end encrypted, and reported content is processed through the moderation workflow.
All transport between your browser and NyChat runs over HTTPS and secure WebSockets (WSS), encrypted in transit with TLS. Transport security protects traffic from network observers; content protection for text comes from the client-side encryption layered on top of it.
Plaintext exists on participant devices. The server coordinates, relays, and stores ciphertext — for room text, it never receives the key that would turn it back into plaintext.
The unglamorous layers that keep rooms safe.
Cryptography gets the attention; these six layers do the daily work on every request.
Rate limiting
- Room creation is rate-limited (2 per 5 minutes, 5 per hour) to blunt spam at scale.
- Message limits (20 per 10 seconds, 40 per minute, 500 per hour) plus dedicated GIF and upload budgets.
- Invalid room-join attempts are throttled with an escalating cooldown.
Defense in depth is a stack, not a slogan — select a layer to see what actually runs there.
Reporting, stated plainly.
Moderation is the documented exception to the temporary-room expectation. It is bounded, hashed, and audited — and it is not hidden.
Reporting opens a second, documented boundary.
- messages of bounded context per report
- 20 + 20
- messages of bounded context per report
- configured evidence retention, then purge
- ≤ 90 days
- configured evidence retention, then purge
- session & IP references stored hashed
- HMAC
- session & IP references stored hashed
- capability URLs stripped from evidence
- 0 tokens
- capability URLs stripped from evidence
- Anyone can report a message, media item, file, poll, participant, call activity, or room from its action menu.
- A report captures a server-side evidence snapshot — bounded context around the reported item, when available.
- Reported message text remains end-to-end encrypted: evidence preserves ciphertext, not plaintext.
- Network references in moderation records are cryptographically hashed rather than stored in plain form.
- Moderation tools can apply time-boxed restrictions — blocking room entry, uploads, or calls.
- Moderation actions are recorded in audit logs with sensitive fields redacted.
This is the exception to “temporary”. NyChat does not hide it: report evidence is retained for up to 90 days to give moderation something to work with, then purged. It is described in the Privacy Policy too.
Bounded in scope, hashed in storage, audited in action — precision over promises.
What NyChat does not promise.
This section exists because transparency is a feature. Nothing here is fine print.
What NyChat does not promise.
Trust is earned by what a product admits. These are the things NyChat explicitly does not claim — stated up front, not in fine print.
- Perfect anonymityLimited operational metadata is processed to run the service. NyChat is not an anonymity network.
- Protection from screenshotsParticipants can screenshot, photograph, or record a conversation. No service can prevent that — NyChat included.
- Protection from forwarded invitesAnyone you share a valid secure invite with can join the room. NyChat cannot protect an invite shared with the wrong person.
- End-to-end encryption for mediaUploaded media and files are access-controlled and temporary — they are not end-to-end encrypted.
- Zero operational recordsThe service keeps operational metadata and logs it needs to run and secure the platform. Reporting keeps bounded evidence.
- Guaranteed availability foreverAvailability depends on hosting, networks, and browsers. NyChat is provided as-is.
- Recovery of lost secure invitesThe room key exists only in the complete invite link. Lose it and the encrypted session is unrecoverable.
- A compromised deviceYour browser and device security still matter. NyChat cannot protect a device that is already compromised.
Security questions, answered directly.
Short answers first — each one matches how NyChat actually works.
Text messages are encrypted in your browser, before they are sent. The browser uses the native Web Cryptography API with AES-256-GCM and a 256-bit room key, and only participants holding the key from the complete secure invite can decrypt them.
Explore NyChat architecture & topics
Temporary & Ephemeral Chat
Pillar: About NyChat PhilosophyInstant disposable rooms without accounts, permanent logs, or profile trails.
Client-Side Cryptography & Boundaries
Pillar: Security Trust CenterAES-256-GCM browser text encryption, URL fragment key isolation, and capability tokens.
Live Calling & Capability Media
Pillar: Knowledge Base & LimitsWebRTC mesh voice and video calls, audio notes, and temporary file exchanges.
Room Lifecycle & Privacy Truthfulness
Pillar: Privacy PolicyAutomatic purge upon room close, zero ad profiles, and bounded moderation evidence.
A room that treats your conversation like a conversation — not a database record.
Create a room