Frequently Asked Questions

Syphr utilizes the native browser WebRTC (Web Real-Time Communication) standard, specifically RTCDataChannel and RTCPeerConnection.

Here is how the connection is formed:

• Signaling Handshake: When you generate a room link or QR code, your browser creates a temporary cryptographic Session Description (SDP offer) and registers a random peer identity via transient signaling.
• Peer Exchange: When your peer opens your link or scans the QR code, their browser exchanges network candidates (ICE candidates) and sends an SDP answer.
• Direct Socket Link: Once the handshake completes, the signaling server drops out entirely. A direct, encrypted peer-to-peer data socket is established between your device and your peer's device. All subsequent text messages, photos, code snippets, and voice notes travel exclusively across this direct pipe.

No. Unlike traditional messaging platforms (such as Telegram, WhatsApp, or Slack), Syphr operates without any centralized message database, backend message broker, or cloud media repository.

Messages, binary file chunks, and audio recordings flow point-to-point directly between participating browsers over DTLS (Datagram Transport Layer Security). At no stage are payloads transmitted to, processed by, or saved on any server.

Because WebRTC establishes a direct, socket-to-socket peer connection, browsers must exchange public routing endpoints (ICE candidates) so their devices can locate each other over the Internet.

As with all peer-to-peer architectures (e.g., BitTorrent or direct VoIP), your peer's browser can technically inspect the remote network candidate IP to route UDP packets directly. If you require complete network-level IP anonymity from your peer, we strongly recommend running a reputable Virtual Private Network (VPN) or Tor-compatible proxy before opening Syphr.

When software stores data on a hard drive or SSD (persistent disk storage), that data persists even after your computer restarts and leaves digital forensics traces.

In contrast, RAM (Random Access Memory) is volatile storage: it exists only as momentary electrical state inside your computer's high-speed memory modules. Syphr holds conversation messages, decrypted image bitmaps, and audio buffers exclusively in JavaScript heap memory inside your browser process.

• No message history is ever written to localStorage, sessionStorage, or IndexedDB.
• No media or voice notes are cached to disk.
• The instant you close the browser tab, refresh the page, or click NUKE, the memory pointers are discarded and zeroed out by the browser engine.

No, recovery is technically impossible. This is an intentional security design choice, not a missing feature.

Because Syphr maintains zero server logs, zero database backups, and zero local disk storage, refreshing the page or closing the tab destroys the volatile memory state. Neither you, your peer, nor the creators of Syphr can retrieve past messages.

Syphr strictly isolates non-sensitive client preferences from private communications:

• Zero Chat Data: Chat logs, images, voice clips, peer IDs, and cryptographic tokens are strictly excluded from local storage.
• Local UI Preferences Only: Only cosmetic display settings (your chosen dark/light visual theme, audio haptic mute toggle, and customized local nickname) are remembered in your personal browser storage so you don't have to re-select your preferred theme every visit. This data stays entirely on your device and is never sent to any server.

When you attach a file or photo, your browser reads the file locally into an ArrayBuffer using the HTML5 File API.

• The file is segmented into 16KB binary chunks.
• Each chunk is transmitted directly through the WebRTC RTCDataChannel using binary transport.
• The recipient's browser reassembles the chunks in RAM into a temporary Blob and renders a volatile URL.createObjectURL().
• No intermediate file upload server, Amazon S3 bucket, or temporary file host is ever involved.

Syphr provides a dedicated View-Once mode for sensitive images:

• When sent with View-Once enabled, the photo arrives in an obscured, locked state.
• When the recipient clicks to view the photo in the full-screen ephemeral lightbox, an immediate countdown begins.
• Once dismissed or when the view period finishes, the underlying in-memory Blob URL is revoked via URL.revokeObjectURL(), and the DOM container is replaced with a "Viewed & Vaporized" indicator. It cannot be reopened or downloaded.

Syphr supports a wide array of formats including JPEG, PNG, WEBP, GIF, PDF, plain text, ZIP, JSON, Python, JavaScript, TypeScript, Markdown, and CSV files.

Because transfers occur over in-memory WebRTC DataChannels, files under 25MB transfer almost instantaneously. Very large files are limited primarily by browser heap memory to preserve UI responsiveness.

The NUKE button is Syphr's instant panic wipe protocol. When triggered, the client executes a synchronous multi-stage memory purge:

• Connection Severance: The active WebRTC RTCDataChannel and RTCPeerConnection sockets are forcefully closed.
• Signaling Disconnect: The peer signaling instance is permanently destroyed.
• DOM Incineration: The entire chat stream container, message nodes, media elements, and message queues are removed from the browser DOM.
• Object URL Revocation: All temporary Blob URLs representing audio notes and images are invalidated using URL.revokeObjectURL().
• Heap De-allocation: Internal JavaScript arrays and state objects are set to null, triggering browser garbage collection.
• Visual Flash & Reload: A white emergency flash overlay displays for 200ms before clearing the URL hash and resetting the app to a clean slate.

When you click NUKE, a final instantaneous nuke protocol payload is transmitted across the data channel before your connection terminates, notifying your peer's client that the session has been incinerated.

Their connection drops to Disconnected immediately. If you have auto-burn timers configured, any unburned messages on either side will also vaporize according to their burn intervals.

When you tap the microphone button, your browser requests permission to access your audio hardware via navigator.mediaDevices.getUserMedia.

• Audio data is recorded using the standard browser MediaRecorder API into temporary memory chunks.
• As soon as you release or stop recording, audio capture hardware is stopped, and all audio tracks are closed immediately.
• The audio is encoded into an in-memory WebM audio blob, transmitted directly to your peer over the WebRTC data channel, and never submitted to any speech-to-text API or third-party server.

None. Syphr contains zero tracking pixels, zero analytics scripts (no Google Analytics, no Mixpanel, no Meta Pixel), and zero advertising cookies.

We do not collect telemetry, track browsing behavior, or build user profiles. We believe private communication should be truly private.

All WebRTC peer-to-peer data channels mandate DTLS (Datagram Transport Layer Security) encryption with ephemeral cryptographic keys generated independently by the two connecting browsers during the ICE handshake.

This ensures that intermediate network operators, Wi-Fi routers, and internet service providers cannot inspect, alter, or inject traffic into your communication stream.