The concept of my privacy-first communication platform

Some time ago video calls were pure science fiction. Today they are ordinary. But while technology matured, privacy often did not.

Most people click Join, see the little green camera light, and assume everything is private. That light only tells you your camera is on - not who can see the data, log metadata, or keep records of the interaction.

That gap between perceived privacy and actual privacy is why I decided to build a new communication platform. I am not naming it yet - it is still evolving - but I can describe its core idea: a browser-first, one-to-one video calling system designed from the ground up for confidentiality, ephemerality, and minimal trace.

The privacy goal

The goal is strict and intentionally uncomfortable: the system should make it extremely difficult for anyone to prove that two people communicated.

That means minimizing what can be known about who you are, who you talked to, when you talked, where you were, and what was said - without relying on trust in third-party infrastructure.

No system can protect a compromised device or defeat lawful seizure of an endpoint. The aim here is different: reduce retained data so there is nothing meaningful to compel, leak, analyze, or monetize.

Why browser-first

The browser is the cleanest privacy baseline available today:

• Browsers run in sandboxes; closing the tab destroys in-memory state.
• No installation footprint means fewer device-level metadata trails.
• Modern browsers support WebRTC and strong cryptography without app-store audit logs.

Native apps may come later for convenience and additional device-level protections, but they also introduce new telemetry surfaces (background services, OS APIs, store receipts). For strict ephemerality, the browser remains the cleanest slate.

Core rules for minimizing traces

1) No PII, no accounts

There are no usernames, emails, phone numbers, or identity-based profiles. The system does not need to know who you are.

2) Ephemeral invites only

Calls are initiated through short-lived invite URLs that are:

• Cryptographically random
• Single-use
• Expired within minutes (default: 3)

If an invite expires unused, it becomes meaningless. There is nothing persistent to trace.

3) One-to-one by design

The platform intentionally avoids group calls, recordings, or server-side transcription. Less functionality means fewer opportunities for leakage.

4) Self-hosted STUN/TURN with minimal logging

STUN and TURN infrastructure is self-hosted and operated with a strict policy: no persistent logs. When relaying is required, only encrypted media passes through, and state exists only for the lifetime of the session.

5) True end-to-end encryption (E2EE)

Encryption keys live only in the browsers of the participants. When peer-to-peer succeeds, media flows directly between endpoints. When TURN is required, it forwards ciphertext only.

Technical building blocks include WebRTC (DTLS/SRTP), X25519 key exchange, HKDF-based key derivation, AES-GCM for media protection, and short-lived REST TURN credentials.

6) Ephemeral state only

Sessions and cryptographic material exist in memory only. Refreshing or closing the page destroys the session entirely. No database, no recordings, no analytics.

7) Encrypted real-time chat

Text chat is handled through end-to-end encrypted peer messaging. Socket.IO is used strictly as a signaling relay; message payloads are never stored server-side.

Technology stack (high-level)

• Frontend: Browser WebRTC, ephemeral URL tokens
• Signaling: Node.js + Socket.IO (relay-only)
• Relay: Self-hosted STUN/TURN (minimal, volatile state)
• Crypto: X25519, HKDF, AES-GCM, DTLS/SRTP
• Hosting: From VPS to single-board systems (e.g., Raspberry Pi 5)

Threat model and limitations

• A compromised device can always capture audio/video locally.
• Physical seizure of an endpoint cannot be prevented.
• The system's protection comes from having nothing durable to surrender.

Who benefits from this design

• Therapists and clients requiring non-recorded sessions
• Journalists and sources exchanging sensitive material
• Healthcare conversations involving highly sensitive topics
• Individuals who simply do not want conversations analyzed or archived

Usability tradeoffs

Privacy should not be painful - but it does require tradeoffs. Fewer features mean fewer attack surfaces. What you lose in convenience, you gain in confidence.

A practical checklist for a no-trace call

• Open a private browser window (optional)
• Generate a one-time invite
• Share it through an ephemeral channel you control
• Join the call (media is E2EE)
• Close or refresh the tab to destroy session state

Final thoughts

Encrypted transport is not the same as confidential communication. Many platforms encrypt while still collecting metadata, logs, and behavioral signals.

This platform is built around a different idea: less to store, less to see, and less to compel.

If privacy matters to you the way seat belts matter in cars - not optional, but essential - then this philosophy may resonate.