PrivateChat
Private beta
Private conversations by design
A temporary place to talk. Browser-side encryption. A guest you choose to admit.
Create with a voucher. Invite by link or code.
No telephone number or email address required for registration.
01 / The idea
Some exchanges need a private place, a chosen participant and a clear end. PrivateChat brings those decisions into the room itself.
Message content is encrypted on the sender’s device and decrypted on the recipient’s device. The relay delivers encrypted material and the operational information needed to make the room work.
The creator chooses a permitted lifetime and can destroy the room earlier. A guest can enter a valid invitation without creating an account. Local room names belong to the browser, rather than a public directory.
This makes PrivateChat useful for a personal conversation or a short-lived project discussion. It also creates responsibilities: protect the invitation, check who you admit and keep the browser’s local state safe.
Read the practical limits02 / Getting in
V2 supports links and invitation codes. Resolving either invitation starts an admission request; the creator still chooses whether to accept it.
The browser reads the private invitation material from the link’s fragment. Fragments are normally handled locally rather than included in the page’s HTTP request. The external channel used to share the full link still matters.
Treat the full invitation as a secret. Possession of the link does not prove a person’s identity.
The public code-entry page accepts six uppercase letters and digits, with at least one of each. A VOPRF-assisted exchange and an encrypted invitation envelope let the browser recover and verify the invitation before requesting admission.
The example above is illustrative. Short codes depend on online guessing controls and are not unlimited-entropy secrets.
Open code entry| Property | Link | Code |
|---|---|---|
| What you share | A full private invitation URL | A six-character invitation code |
| What the browser does | Reads and verifies invitation material | Resolves and verifies an encrypted invitation |
| Creator approval | Required | Required |
| A guest account | Not required; account linking is explicit in supported flows | Anonymous code entry does not require an account |
| The human decision | Verify that the requesting participant is the person you intended. | |
03 / A room, from beginning to end
Follow the room as you scroll. The illustration describes the intended V2 flow; it does not display a real session.
An authenticated, entitled creator opens a temporary room. The browser prepares the private state; the relay records the room and its operational limits.
Share the link or code outside PrivateChat. The invitation channel is part of the threat model: whoever receives the secret may attempt to claim the guest position.
The invited browser prepares its credentials and cryptographic claim. An interrupted code request can recover its saved intent instead of silently creating another guest identity.
The creator approves the pending guest. V2 binds admission to the reviewed claim and MLS material; receiving an invitation alone does not complete admission.
The guest completes admission and activation. Browser-held state protects messages while authenticated transport carries encrypted events and small real-time controls.
The room becomes unavailable after expiry or creator destruction. Application cleanup removes active records through its designed paths; offline devices and copies outside the application need separate consideration.
04 / Follow the information
A useful privacy model separates content, credentials and metadata. Explore the two sides of that boundary.
The browser encrypts and decrypts message content. It holds the active cryptographic state, room credentials and local conversation records needed for recovery.
Local encryption helps protect stored records. A compromised browser origin or unlocked device can still use or expose accessible state.
The service processes encrypted payloads and room state. It also authenticates accounts and room access. A network provider or relay can observe that a device connects to PrivateChat.
No absence-of-logging claim is made here. The actual infrastructure, recipients and retention belong in the final Privacy Policy.
| Information | Participant device | Service side |
|---|---|---|
| Messages | Readable during use; V2 history is sealed locally | Encrypted relay events, with delivery metadata |
| Account credentials | Entered by the user; account session cookie | Username, password verifier and session records; login credentials are processed for authentication over protected transport |
| Room access | Room credentials and invitation material | Credential digests, admission state and access references |
| Registration agreement | Explicit acceptance of the displayed terms | Account reference, document versions and server timestamp |
| Support correspondence | Information the user chooses to send | Email and communication-provider records, under their applicable practices |
05 / Under the surface
The deeper model is V2: MLS-based browser state, explicit access transitions and a relay that validates delivery without needing message plaintext.
Creator registration uses a voucher, username and password. Password storage uses a memory-hard derived verifier. Authentication processes the supplied credentials over protected transport; message end-to-end encryption is a separate boundary.
Voucher redemption, account creation, entitlement, session and versioned terms evidence are committed in one transaction. A failed transaction does not intentionally leave a partially registered account or consume its voucher. A response lost after commit can still leave a completed registration, so uncertain outcomes need checking before retry.
Account sessions use protected cookies and hashed server-side session tokens. Settings provides password change and invalidation of other account sessions. These account controls do not recover a lost browser’s message keys.
The link path carries invitation material in a browser-handled fragment. The code path uses blinded VOPRF evaluation, proof verification, a derived lookup and a context-bound encrypted invitation envelope. The browser verifies the recovered invitation before provisioning a claim.
The evaluated exchange is a component, not a promise of anonymity from the operator. A six-character code has a finite guessing space. Its protection depends on online limits, service-key handling and the sharing channel; compromise of those assumptions changes the threat model.
Input syntax, payload bounds, proof checks and rate controls are enforced at their relevant boundaries. Internal key material and deployment-specific operational settings are not part of this public explanation.
The browser’s native cryptographic implementation is compiled from Rust to WebAssembly. MLS maintains authenticated membership and evolving conversation state. Admission binds the reviewed guest claim to the intended room and the creator’s cryptographic approval material.
Conversation state advances through epochs. Message envelopes bind ciphertext to room context, epoch, sequence and event identity. The client and relay apply their respective tampering, replay, stale-state and ordering checks before accepting progress.
These mechanisms authenticate protocol state and possession of credentials. They do not establish the real-world identity of the person holding an invited device.
Link and code are controlled entry modes. Moving an admitted guest to another method is an explicit transition, with saved intent, a current access reference and creator review where required. It is not equivalent to opening an unrelated second guest slot.
A replacement guest submits a separate request for the creator to approve or reject. Accepted replacement advances the access state and cryptographic membership. Retired access references no longer authorize the new active session.
Readiness and creator-confirmation gates must complete before protected operations resume. This does not erase messages or copies that an earlier participant already received.
V2 seals persistent records in IndexedDB with AES-GCM and browser-held encryption keys. Protected conversation state uses non-exportable keys: this restricts key export through the browser API, but code running with the relevant origin’s privileges may still use accessible keys.
Room credentials, protocol state, local history, delivery cursors and pending outbound events have distinct roles. Related state and delivery changes are committed atomically through the designed storage operations. Web Locks coordinate conflicting local use across tabs.
A local room name is a browser-side label. Clearing site data, using another browser or losing the device can remove access to conversation state. There is no server-held plaintext or lost-key recovery promise.
The V2 relay authenticates bounded HTTP events and their ordering while treating the cryptographic payload as opaque. Native WebSockets authenticate their connection and carry small controls such as event-availability and heartbeat notifications; they are not an extra plaintext-message channel.
Encrypted snapshots, an outbox and recovery journals let the browser reconcile interruptions with already committed work. A lost response does not prove that an action failed. Recovery verifies the retained outcome rather than silently treating a new attempt as the original action.
Origin checks, request markers, input validation, capacity bounds and time limits constrain the public interfaces. Availability still depends on the device, browser, network and service.
V2 pads message plaintext into bounded size classes before encryption. This reduces exact-length disclosure within a class. It does not hide all ciphertext size information, timing, volume or the fact that a connection occurred.
The service needs room identifiers, participant roles, access state, event order and expiry information. IP addresses and security records may exist at network, proxy or infrastructure layers depending on the actual deployment.
PrivateChat is not a replacement for an anonymity network. Avoid equating an account without a required contact field with an untraceable person.
Expiry and explicit destruction end the active room’s availability. Server-side deletion uses the designed database paths, and client cleanup removes active local room records and key material when it can run. An offline browser cannot be remotely guaranteed to erase all local data immediately.
Deletion is a logical application operation. It does not guarantee immediate physical overwrite on flash storage, databases, replicas or infrastructure backups. Retention and backup practices must be described using the verified production arrangements.
Claims of guaranteed forensic invisibility or universal rollback immunity would therefore be inaccurate.
The reviewed architecture separates administrative access from the public application and protects the administrative infrastructure boundary with mutually authenticated transport. Administrative access remains an operational trust responsibility.
Local automated tests exercise protocol, storage, admission, transport, registration and interface behavior. Passing tests is useful evidence about those cases; it is not independent cryptographic certification. No independent security audit is claimed for this implementation.
The release status below distinguishes the deployed service from the V2 implementation under integration. Hosting locations, recipients, log retention, backup policy and operator identity must be verified in the final public notices.
06 / Strengths and trade-offs
A clear boundary is part of the product. Choose it for the model it implements, with the limits that come with it.
Malware with access to the device can read messages while they are displayed. Browser extensions, an unlocked device, screenshots, operating-system artifacts or backups can expose information outside the application’s control.
A legitimate participant can copy, photograph, export or disclose received plaintext. An invitation proves access to an invitation, not a person’s identity. Destroying a room cannot retract copies made by another participant.
If the production server or delivery infrastructure serves malicious client code, that code could target plaintext or cryptographic material. HTTPS protects transit; controlled releases and trustworthy operation remain necessary.
A supported browser, JavaScript, local state and network access are required. A lost key or cleared browser can mean lost conversation access. A beta service does not imply uninterrupted availability.
| Design choice | What it gives you | What remains yours |
|---|---|---|
| No required phone or email | Fewer contact identifiers in registration | Protect credentials; network and support metadata still exist |
| Explicit guest approval | Control over who enters the active room | Check the intended person through a suitable channel |
| Browser-side encryption | Plaintext processing at the endpoints | Trust and protect the device, browser and delivered client |
| Temporary rooms | A defined end to active room access | Understand local, participant-copy and infrastructure deletion limits |
07 / The project
The deployed service is a private beta. This page also explains the reviewed V2 implementation, including code entry, membership transitions and encrypted durable state. V2 remains a development release until production integration, review and deployment checks are completed.
Feature descriptions are not a live service-status monitor. Read the Privacy Policy and Terms of Service for their scope, version and any draft status.
The PrivateChat team is working to strengthen privacy for everyone using the service. We have not obtained an independent security audit. Join the beta community, explore the model and share what should improve.
Design disclosure. Some visual components of this website were developed with the assistance of professional artificial intelligence tools.
A smaller circle
Sign in to manage your rooms, or register with a valid voucher. An invited guest does not need an account.
How to request access