NullTrace

A private space
to speak freely.

End-to-end encrypted rooms. Invite your people, choose who enters, and talk without a permanent chat archive.

What it does

NullTrace is not a feed with privacy bolted on. It is infrastructure for people who need to speak freely and leave no platform-owned trail behind.

01

Protects free speech

Talk in a room built for the conversation itself, not for distribution, engagement, profiling, or later inspection.

02

Controls who enters

Entry happens through a temporary invite capsule. You approve participants instead of publishing to an audience you do not control.

03

Encrypts before transport

Messages are encrypted in your browser before they move. The server passes encrypted traffic; it is not a place where readable conversations live.

04

Leaves less behind

No permanent chat archive, no ad profile, no account timeline. NullTrace is built for conversations that happen, serve their purpose, and disappear.

Why it works

Free speech needs more than a policy promise. NullTrace makes the room technically hard to abuse: approve entry, encrypt locally, rotate keys, store no readable history.

Encrypt first. End-to-end encryption starts locally, before a message leaves your device.

Hybrid keys. X25519 and ML-KEM-768 establish session secrets; Double Ratchets refresh epoch delivery keys.

Short-lived entry. Signed invite capsules carry an expiration time and require host approval.

Approved members. Participants enter through verified handshakes and fresh room keying.

Traffic shaping. Padding and random cover frames add traffic variation; timing remains observable.

One active session. Access is limited so quiet account sharing and invisible parallel use get harder.

Signal Comparison

Signal and NullTrace serve different workflows. Signal is a persistent messenger; NullTrace focuses on temporary, host-approved browser rooms. Their encryption and retention models differ.

Area Signal NullTrace In practice
Identity Starts from a phone-number account, with usernames added as a contact layer. No phone number or public profile; access uses user and restore keys. Room identities are separate from phone numbers and address books.
Room control Groups live inside a persistent messenger account and contact graph. Rooms are created on demand with signed, temporary invite capsules and explicit approval. Hosts approve membership for each temporary room.
Encryption model PQXDH and the Triple Ratchet, combining the Double Ratchet with post-quantum SPQR. X25519 + ML-KEM-768 setup, vodozemac Double Ratchet for epoch delivery, and per-message sender chains. NullTrace's ongoing DH ratchet is classical; Signal also ratchets post-quantum secrets.
Message isolation Ratchets derive fresh message keys and delete earlier keys. Each sender chain derives a new XChaCha20-Poly1305 key per message; signatures bind sender and packet metadata. Used keys are erased; a bounded, temporary key cache permits reordered messages.
Membership secrecy Group history belongs to the device history and group conversation model. Fresh epoch seeds go to current members after approval, removal, and periodic rotation. New members receive no previous epochs. Removed members receive no subsequent epochs.
Message retention Device message history, app state, and notifications can leave OS-level residue depending on settings. No push notifications, no inbox archive, no platform notification previews, burn timers, deadman, one-tap wipe. Burn timers remove visible messages; browser and OS traces are still possible.
Server breach A messenger service still has account, device, delivery, and abuse-prevention structure around users. Browsers encrypt content; the relay holds short-lived ciphertext. Access records are stored separately. Relay data alone cannot decrypt content; compromised browser code can expose it.
Server visibility A delivery service for known accounts, devices, and contactable identities. The relay sees connection and room metadata but does not receive message plaintext or keys. Encryption protects content; it does not hide connection timing or room membership from the relay.
Intended use Everyday private messaging in a persistent app. Temporary browser rooms with host approval and no permanent chat archive. Choose according to room controls, retention needs, and device security.

FAQ

Do I need an account?

No. NullTrace does not need usernames, phone numbers, email addresses, or a public profile. Access is controlled by your user key and restore key, so the product can stay focused on rooms and encryption instead of identity collection.

Can NullTrace read my messages?

No readable chat history is stored for NullTrace to browse later. Message content is encrypted before transport, sent as protected room traffic, and only the approved participants in that room are meant to decrypt it.

What happens if I lose my keys?

You can lose access. Save both keys somewhere offline before continuing. If it happens, contact us and we can look at what is still possible, but the system is intentionally designed so keys matter.

How many people can be in a group conversation?

A room supports up to 16 participants, including the host. Each participant needs host approval, and membership changes trigger fresh epoch keys.

NullTrace 2026

Choose access

Payment

Plan

Exact SOL amount

Deposit address

Waiting for payment...

Save your access keys

Anyone with these keys can access or reset your NullTrace access. Store them offline. If your restore key is exposed, someone can revoke your current session.

User key
Restore key

Sign In

Your space, your invitation

A private room.
For your people.

Start a room and invite someone, or join with an invitation.

End-to-end encrypted. Entry by invitation.

Pending approvals

Conversation

Messages disappear automatically
    Security, in detail

    Hybrid session setup

    X25519 + ML-KEM-768 bootstrap; ongoing ratchet recovery uses classical X25519.

    Identity-bound pairing

    Signed transcripts bind participants and the initial ratchet key. Compare SAS through a trusted channel.

    Fresh message keys

    Advancing sender chains supply one XChaCha20-Poly1305 key per message, with replay checks and signed metadata.

    Double Ratchet & epochs

    The vodozemac WASM engine protects epoch delivery. Membership changes and periodic rekeys refresh sender chains.

    Access capsules

    NT-C3 invites: signed, time-limited, size-padded. One-time room tokens authorize WebSocket access.

    Traffic shaping

    Randomly padded frames and random cover traffic; larger messages remain larger. The relay discards cover frames.

    Bounded traffic

    Message-size limits, session rate limits, and bounded send queues constrain abusive traffic.

    Temporary chat state

    Chat keys and relay ciphertext live in memory; access and payment records are stored separately.

    Safety UX

    Approvals, SAS verify, burn timer, deadman switch, one-tap wipe.

    How your room works
    1. Host starts a room. Fresh keys; disposable room ID.
    2. Share an invite capsule. Signed NT-C3, time-limited, size-padded, with no access token inside.
    3. Guest pastes & confirms. Check the room and host fingerprint before joining; compare SAS after pairing.
    4. Host approves. A signed X25519 + ML-KEM-768 handshake authenticates the initial ratchet key.
    5. Ratchets deliver epoch keys. Pairwise Double Ratchets protect fresh seeds; encrypted acknowledgements advance the ratchets.
    6. Chat. XChaCha20-Poly1305 uses a fresh message key and random nonce; signatures authenticate packet metadata.
    7. Membership changes refresh keys. The host also rotates epochs periodically; old epoch chains are erased.
    8. Traffic shaping. Frames receive random padding; random cover frames carry no message keys.
    9. Clean exit. Burn timers remove visible messages; leaving wipes in-memory session keys.

    Invite someone

    Make room for them.

    Send this invitation privately. You approve each guest before they enter.

    Expires in 02:00

    You’re invited

    Join their room.

    Paste the invitation your host shared with you.

    One last check

    The right room?

    Compare the host fingerprint through a trusted channel, then request entry.

    Room

    Host fingerprint

    Your fingerprint