What a host can see

Veiled Contact locks what a member sends before it leaves the device. That protects what was said. It does not hide that something was said, to whom, or when.

Visible to the person running the server

Addresses and connection times
Display names and public keys
Channel names, order and membership
Who spoke, and for how long
Roughly how much was said, worked out from the size of the traffic
When each message arrived, and from which member

Message bodies, voice and screen share stay locked. Run the server on a machine you control if you want to choose who can inspect its metadata.

The full split, in two tables

Locked on the sending device. The server holds a locked bundle or nothing at all.
What	Who can read it	Why the server cannot
Message bodies, replies, reactions, edits	Members holding the channel key	Each body is locked with XChaCha20-Poly1305, a standard modern encryption method, under a key the server is never given. The server stores a bundle it cannot open, along with the sender, the channel and the time.
Voice audio	Members of the voice channel	Every 10 ms block of sound is locked with the voice key for that channel. The server reads the 28-byte envelope to know which channel to pass it to, and never touches the sound itself.
Screen share video	The people in the call	Video runs directly between the people in the call, with the channel key protecting the pictures where the browser allows it. The server only carries the introductions.
Channel keys	Only the members they were made for	Each member's copy of the key is placed in a locked packet addressed to that member's public key, which only that member can open. The server stores the packets and hands them out without being able to open one.
Join and admin passwords	Nobody, including the host	The password is never sent. The client proves it knows the password. The server keeps a derived value it can check, and cannot turn back into the password.
Private keys	The device that made them	They are made on the device and stay there. A browser keeps them in its own storage, a desktop app in the operating system's key store, and they are never sent anywhere.

The details the server holds, by design
Addresses and connection times	Which address connected, when it arrived, when it left. This cannot be avoided: every packet has to have a source and a destination.
Display names and public keys	The name a member chose and the public half of their identity, kept against a user number so people are recognised when they come back.
Channel names, order and membership	The shape of the server: what exists, who is in which voice channel, and which role each member holds.
Who spoke, and for how long	Every block of voice is stamped with the sender, the channel and a sequence number. The server can see when someone spoke and for how long. It cannot hear what was said.
Roughly how much was said	The size and number of blocks over time. Voice blocks of ten milliseconds are close to fixed in size, so little is given away by size alone. The rhythm and the volume of traffic are still visible.
When each message arrived	The time each locked message arrived and from which member. The message itself is unreadable. The pattern of arrivals is not.

That is the trade for running the server close to the people talking. Defences against traffic analysis, cover traffic and deniability are not in this version, and the crypto specification says so in the same words.

What Veiled Contact does not do

No telemetry: The client sends nothing back to the project. There is no analytics script, no crash reporter and no update check against a project server. The only two pieces of software that talk to each other are a client and the server it joined.
No accounts: No signup, no email address, no phone number, no password reset. A client makes its own keys and is recognised by them. The join password is set by the host.
No outside requests: This site and the client load their fonts, styles, scripts and images from the server in front of them. There is no content network, no font service, no embedded video, and no advertising or tracking pixel anywhere in the product or on this site.
No search or previews on the server: There is nothing for the server to search, because it cannot read a message. Search runs over the copy kept on the member's own device. Notifications that would need the message text on a server are not offered.
On this site: Nothing is collected and no cookies are set. The colour scheme choice is remembered in the browser's own storage and never sent anywhere. The server logs on veiled.contact are ordinary web server access logs, kept short, and are the only thing this site has.

More questions are answered on the questions page.

The limits worth stating

Read these before trusting a server.

A dishonest host controls the software a browser loads: The host serves the web client to browsers. Someone who edits that client could try to read a message before it is locked. Building the client locally avoids that risk, and the client files are small enough to read. There is no reproducible build verification yet, so this is a choice about who to trust.
Compare the server's fingerprint: A client records the server's key the first time it connects. An invite link carries that key by another route instead. The fingerprint the host published can be compared with the one the client shows. Skipping that comparison means trusting the first connection on faith.
Losing the keys means losing the history: Channel keys live on the devices that hold them, and the server cannot restore them. Losing every device means losing access to channels, and there is no support desk that can hand the keys back.
A removed member keeps what they already had: Removing someone changes the channel key so that new messages are unreadable to them. It cannot take back anything they already read, and no design can change that.
Version 1: Attachments, sharing keys between a member's own devices, and phone apps are not in this release. The crypto specification lists what is out of scope in the project's own words.