TRUST & BOUNDARIES
Know what you share.
And with whom.
One keyring connects the conversation to the services in a room. Trust is your decision, not a badge supplied by someone else.
Your keyring is the decision
A node is an identity with its own keys, rooms, and keyring. A room brings nodes together; joining the room does not grant every sender’s keys. There is no contact directory, automatic trust, or trust inherited from someone else.
Your keyring names the nodes you trust. Your node releases your sender keys to those nodes in shared rooms and accepts sender keys only from nodes in your own keyring. The other side makes its own decision. A two-way conversation requires both sides’ trust.
Trust is not per room. It applies across the rooms you share now and later, including access to the services you share there. Trusting Ann does not make Ann trusted by anyone else.
Names are local aliases for fingerprints. Compare the full fingerprint through a channel you trust before adding it. A sender’s claim about their name is not identity evidence.
By default, granting access starts with messages from that point onward. The model also permits an explicit full-history grant for your own retained messages. “Forward-only” must not be mistaken for an unconditional prohibition on sharing history.
Removing trust rotates your sender keys and stops accepting that node’s keys. It protects subsequent access, but it cannot take back content already read or copied.
A room gives context. Trust gives access.
A node shares a named service with a room. The host checks both its keyring and current room membership when a member connects. An invitation alone is not permission to reach the service.
The address is service.node.room.vox. The service name comes from its sharer; the node and room aliases are yours. The address identifies a service, not an SSH endpoint implied by a room or a node alone.
Removing a share or withdrawing trust cuts its live sessions. There is no extra per-service permission matrix. File sharing uses a room-bound service and a pull model; file data does not become a server-hosted chat attachment.
Classical and post-quantum, together
Vox’s hybrid design combines two families of algorithms. That describes a construction, not a guarantee that either family is infallible.
| Purpose | Classical | Post-quantum |
|---|---|---|
| Key agreement | X25519 | ML-KEM-768 |
| Signatures | Ed25519 | ML-DSA-65 |
Keys protect content. Comparing fingerprints and choosing the right nodes to trust remain human responsibilities. A compromised endpoint can expose plaintext regardless of the algorithms used in transit.
No central messaging operator
Rooms live on member nodes. Reachable, user-run anchors help peers find one another, coordinate connections, and relay encrypted traffic when needed.
An anchor acting only as an intermediary holds no room keys or room log. A node can also be a room member; in that role it reads only according to the same keyring rules as other members. Being an anchor does not confer special read access.
Members that are never online together can exchange retained messages through another member that overlaps with both. An anchor that is not a member is not a store-and-forward mailbox.
Anchor storage boundary · Offline members · Reachability design
What encryption cannot promise
- No read-receipt inference. A connection or a received sender key does not prove someone read a message.
- No protection from a trusted recipient’s copy. Retention removes content from cooperating nodes. It cannot erase screenshots or copies elsewhere.
- No anonymity guarantee. Traffic timing, volume, and connection information can remain observable.
- No endpoint-compromise guarantee. Malware, a keylogger, or access to a running node can expose content and secrets.
- No guaranteed reachability. Offline nodes, blocked paths, and unavailable intermediaries can delay or prevent delivery.
The daemon can run several attached nodes independently. Detaching one is not the same as locking the machine or stopping every other node. The keyring’s passphrase window concerns trust changes, not whether an attached node continues running.
Direction is not a release claim
This page explains the v0.3.0 model and links to its decisions and work items. A closed issue marked “awaiting-release” is not proof that a downloadable release contains the change.
The installation guide targets the published v0.2.10 terminal client. Its commands can differ from v0.3.0. The homepage’s native-style app study is proposed UX, not a shipped macOS client.
The v0.3.0 work includes UDP transport and family-LAN mode, not just TCP. Deniable mode is removed from this release’s design, not advertised as a privacy guarantee.
Source inspection is not an independent security audit. Check the release milestone, published release notes, and implementation before relying on a capability.