This app is built to reduce how much you must trust servers, platforms, and global identity systems. It does not use accounts, usernames, email addresses, or a central profile that ties your conversations together. Trust exists only inside each connection you create, and each connection is cryptographically isolated from the others.
For a code-accurate description of the protocol, threat model, and receiver rules, see the technical overview.
Most modern secure services still rely on central accounts, stable identifiers, and trusted infrastructure to authenticate users, enforce permissions, and recover access. This design removes those assumptions entirely. There is no central authority that can validate identity, no global account that can be correlated across relationships, and no server that can intervene, revoke, or impersonate a participant. Trust is never delegated upward to the platform.
Messages pass through a transient cloud relay whose job is to move encrypted payloads from sender to recipient. The relay cannot authenticate you, cannot validate messages, and cannot “recover” access. It is intentionally blind: it sees only opaque mailbox identifiers and network metadata that any HTTPS service necessarily observes (such as timing and volume). It does not store your contact list, your group membership, or your message history.
Messages are removed from the relay by the recipient after successful receipt. Cover messages (dummy messages), which are used to obscure message patterns, are also removed. If a recipient’s vault is locked, delivery cannot complete until they unlock and come back online. If local session data is erased, delivery becomes impossible as the recipient identity no longer exists. Undeliverable messages are periodically purged to reduce metadata retention.
Because the relay does not possess per-relationship secrets or continuity state, relay storage alone does not allow an attacker to decrypt message content or forge messages that recipients would accept. Relay storage does, however, expose per-relationship mailbox artifacts (distinct channel identifiers) and message volumes per mailbox. The design aims to prevent cross-relationship linkage into a stable user graph because there is no global account identifier, directory entry, or reusable identity credential tying multiple relationships together at the protocol layer.
Traditional systems authenticate you by proving possession of a stable identity credential. This app takes a different approach: identity is proven by continuity. Each message must be the next valid step in a shared cryptographic history. If a message is replayed, reordered, spliced, or forged, it fails automatically because it does not advance that history correctly. There are no long‑term identity keypairs, signing keys, escrow keys, or recovery secrets that a server can validate or that can be reused across relationships.
This is not simply encryption layered on top of a conventional messaging system. It is a different security primitive. Identity is not declared or registered; it emerges from an unbroken sequence of valid actions between two parties. A message is accepted not because it is signed by a known key, but because it correctly advances a shared cryptographic state. If that continuity breaks, identity fails automatically. There is nothing for a server to verify, approve, or override.
Systems built around accounts, public keys, or recoverable credentials cannot adopt this model without abandoning core assumptions. Centralized identity, auditability, and account recovery all require a party that can recognize and reassert identity. This system deliberately forbids that. There is no back door, no master key, and no mechanism for correlation across conversations, even by the operator of the service.
Conversations use pairwise, direction‑specific encryption. Every message is encrypted using secrets shared only between you and the intended recipient for that direction. Keys are derived per message and advanced forward with continuity. Protocol state and message content live on participating devices, and they are encrypted at rest whenever the vault is locked. Secrets are destroyed on wipe.
Groups are a local convenience feature, not a shared cryptographic object. Group names and membership are stored only on your device and are never transmitted, synchronized, or disclosed to any other party. When you send a message “to a group,” the app actually delivers independent one‑to‑one encrypted messages to each selected contact. Each delivery preserves the same guarantees as a direct conversation, and recipients cannot see who else received the message.
Messages may include a shared, user‑defined group tag (for example, #neighborhood_watch) so recipients can organize related
messages locally. A tag does not imply shared membership, shared state, or visibility into who else participated. The system avoids global
group identities, shared group keys, and centralized coordination.
Your device stores your encrypted vault, your locally chosen contact labels, optional local message history, and the continuity state needed to authenticate the next step in each relationship. You can delete local transcripts at any time; continuity state is independent from message storage, which means you can keep strong authentication even if you choose to clear local history.
No messaging system can protect you if an attacker gains access to your device while your vault is unlocked. In that situation, they may be able to read any locally stored messages and send messages as you until you lock the vault. For best security, lock your vault when you step away and use device-level protections (screen lock, full‑disk encryption, and secure backups).
Like all software, this app cannot protect against malware or hostile environments at the operating system or browser level. If your device is compromised by keyloggers, screen capture malware, malicious browser extensions, or similar tools, an attacker may observe what you type or see what appears on your screen. The same is true in physical settings: someone looking over your shoulder in a public place can observe on‑screen content.
While no application can fully defend against real‑time observation or a compromised operating system, this design emphasizes fast, practical defenses in worst‑case situations. Keeping your vault locked encrypts all locally stored secrets and message data at rest, even if the device itself remains powered on and unlocked. An emergency erase option allows you to quickly remove local vault data, contacts, and transcripts if you need to render a device inert without delay.
These measures do not prevent an attacker from observing what is visible on screen in the moment, but they sharply limit what can be recovered afterward. A locked vault on an unlocked device still protects all cryptographic material and stored conversation history. Once erased, there is no residual account, identifier, or server‑side record that can be recovered later.
In this worst‑case scenario, there is also no central service provider, platform operator, or account database that can be subpoenaed, hacked, or coerced to reconstruct your relationships. The only other copy of any conversation exists on the trusted recipient’s device. There is no archival copy on the internet at large, no central log of participants, and no authoritative record that can be queried after the fact.
This system does, however, limit the damage such observation can cause. Even if message text or keystrokes are exposed, there is no global identity, account name, phone number, or addressable identifier attached to the conversation. An observer cannot determine who you are speaking with, correlate that conversation to others, or link it to activity elsewhere, except for the local label you have chosen to display on your own device. That label is not transmitted, stored, or shared. While no application can defend against a fully compromised environment, this design minimizes how much meaning an observer can extract from what they see.
The relay and hosting provider can still observe network‑level metadata such as the existence of traffic, its timing, and its approximate volume. The app reduces linkability by using per‑relationship mailbox identifiers and by sending periodic cover traffic that is indistinguishable from real traffic at the relay. If you want additional protection against network linkability, you may choose to use anonymizing networks such as Tor.
As the service provider, we do not maintain user accounts, device identifiers, analytics identifiers, or registration records. There is no persistent user identity in the protocol that allows us to reliably distinguish one person from another or to link multiple relationships into a single user profile. The relay necessarily observes network-level metadata (timing and approximate volume) as any HTTPS service does, but it is not given protocol-level identity claims that would allow it to map mailboxes to real-world identities.
At the infrastructure level, the relay cannot distinguish between real messages and cover (dummy) messages because both are encrypted and structured to be handled identically. As a result, we cannot reliably measure user-level engagement (such as unique users or relationship graphs) without introducing account linkage or other identity surfaces that would change the system’s security model.
This is not a policy choice or a logging configuration; it is a structural limitation. Implementing user analytics, engagement metrics, behavioral profiling, or message classification would require the relay to authenticate users, correlate mailbox activity, or interpret message flow. Any such capability would undermine the cryptographic blindness that the system relies on and would weaken the guarantees described above.
In practical terms, this means we operate the service without insight into how it is used beyond coarse operational signals necessary to keep the infrastructure running (such as aggregate server load or error rates). We cannot determine how many people are using the service, how many conversations exist, or how frequently messages are exchanged. There is no hidden telemetry layer and no feasible way to add one without fundamentally changing how the system works.
To form a connection, the recipient must consume the connection code you generate and then send you an initial message. Until both steps happen, the connection remains pending. Anyone who obtains a connection code can consume it, so share codes securely. Once a connection is established, confirm you are communicating with the intended person. If you are unsure, or if messages are not being received reliably, generate a new connection code and try again.
Connection labels are created and stored locally in your browser and are never shared with other parties. Neither your device nor your contact’s device stores personally identifying information about the other beyond the custom labels each of you chooses locally. No connection lists, labels, or identities are stored on the server.
For more details on the continuity rules, replay handling, AAD binding, cover/checkpoint behavior, and recovery triggers, see the technical overview.