What Held protects, and where the limits are

Encrypted content, visible connection metadata

The intended application exchanges encrypted messages, chat posts, files, filenames, room names, and peer signing identities over browser-to-browser connections. An optional relay, chosen when a message or group is created, can forward the encrypted traffic when a direct path fails. Its coordination server handles admission, live-session leases, and connection setup; it does not receive message or file payloads.

The server still sees room identifiers, room status, session control information, and signaling. Hosting, connection-discovery, and optional relay providers can observe addresses and timing, and peers may learn network addresses. The relay also observes traffic volume but cannot read the encrypted content. Held provides no IP anonymity or promise that provider logs are deleted. Ended rooms retain server records that prevent their IDs from being reused.

Secret links grant access; IDs identify keys

The secret fragment of a room link supplies the reading capability. Anyone who obtains the complete link may be able to join while a holder keeps the room available. Avoid publishing it or submitting it to a URL shortener.

Automatic signing identities differ by room. A saved identity deliberately reuses the same public key across future sessions, allowing peers to recognize it. Fingerprints authenticate signing keys, not real-world identities. A local identity seed persists in the browser; exporting a backup creates a saved copy under your control. Optional verified contact details are also included in new encrypted identity backups; restoring checks their current status with Held before sharing them again.

Contact details are optional

A saved identity can include a website, a bio of up to 250 characters, and an email address. Website and bio are self-provided and stored by Held with your public identity until changed or removed. They work without an email. An email is shared only after its owner enters a verification code. Held processes the address and stores the verified email linked to that public identity until it is removed or successfully replaced. Resend processes the address to deliver verification codes. A pending replacement stays private while the existing verified address remains available.

Email verification does not expire or require periodic email checks. The signed confirmation sent to connected peers lasts ten minutes and refreshes automatically; this short lifetime lets old confirmations stop working after a removal or replacement. Verification shows access to the mailbox when it was checked, not a verified real-world identity or a guarantee of trustworthiness.

These details are shared only with authenticated, connected peers over the encrypted connection. Website links open only when clicked, without a preview fetch. It is not advertised in nearby discovery, embedded in the saved message, or added to chat history. Peers can retain a copy, which removal cannot erase. Email is contact information and cannot recover an identity; recovery still requires an encrypted identity backup and its matching code.

Temporary access is not remote erasure

Message text and chat history are held in memory rather than a server mailbox. Received file pieces use a temporary encrypted device cache with a separate key kept in memory. Leaving or losing session access invalidates that key and starts cleanup; crashes can leave encrypted pieces until a later cleanup or clearing site data.

Creator-held messages require the original creator session. Carried messages and group chats require at least one admitted holder. Connection loss and expiry end access under those rules; there is no read-once destruction guarantee.

Recipients can save text, screenshots, files, or ciphertext together with its key. Held cannot erase those copies, browser history, clipboard history, operating-system copies, or provider backups. Original file metadata is not scrubbed.

Trust your endpoint and distinguish the tools

A compromised browser, extension, device, dependency, or delivered frontend can access content available to that endpoint. Direct WebRTC connections can fail on restrictive networks, and the registry remains necessary for availability. Held offers no guaranteed delivery or complete chat history.

Short links offer two choices. Traditional is the default: the shortest link, with a destination Held can read until expiry. Encrypted makes a slightly longer link, encrypts the destination in your browser, and keeps its secret in the complete link. The app sends Held only the encrypted address and a lookup identifier. Anyone with either complete link can open it while available. The latest 100 created destinations and complete links stay in this browser’s local history until removed, cleared, or replaced by newer entries, including expired entries.

Short-link encryption depends on trusted browser code. Hosting can still observe request metadata, and browser history or recipient copies can retain destinations and keys. Feedback is separate: its text and optional email are stored for Held’s team to read. A disguised voice recording changes the sound, but cannot guarantee anonymity.

Review the public security guide when evaluating Held. Automated checks support development; they do not replace an independent security assessment.