Security model

Privacy & Security

Hestia is designed as a privacy-first messenger focused on reducing server-side data exposure. In the current architecture, messages and files are intended to be encrypted on the client before they touch the server.

This page describes the intended security properties and known limitations. It is not a promise of anonymity or perfect protection.

What is protected

Text messages

Messages are intended to be encrypted on the client before sending. The server should not see message plaintext.

Files

Files are intended to be encrypted before upload. The server should store encrypted blobs, not plaintext files.

Calls

Calls use WebRTC media transport. WebRTC uses DTLS-SRTP for media encryption in transit.

Local history

Message history is stored on the user's device instead of being centrally stored as plaintext on the server.

What the server can see

Hestia reduces plaintext exposure, but it does not make metadata disappear. In the current architecture, a server operator may be able to observe operational metadata.

Which accounts communicate with each other
Connection times and rough activity patterns
Message frequency and delivery state
Encrypted file sizes
Call signaling events
IP addresses and user agent level connection metadata

If metadata privacy is critical, treat the server operator and hosting provider as part of your trust boundary.

Trust model and fingerprint verification

Each user is intended to have a public key. First contact follows a trust-on-first-use model: the first observed key is trusted until it changes or the user verifies it out of band.

Fingerprint or QR verification helps confirm a contact's key.
If a contact key changes, communication should be blocked until re-verification.
Without fingerprint verification, a man-in-the-middle risk remains possible.

What is not protected by design

Hestia cannot protect everything. Some risks are outside the messenger protocol and depend on the user's device, behavior, and environment.

Compromised devices
Malware on a user device
Screen recording or local device access
Weak device passwords or unlocked screens
Social engineering
Users manually copying or forwarding sensitive content

Local data

Messages and files are stored locally for usability. Decrypted data exists on the device while the user reads messages, opens files, or participates in calls.

Losing control of a device can mean losing control of local conversation data. Device security still matters.

Push notifications

Push notifications are intended to act as a wake-up mechanism. By default, push payloads should avoid plaintext message content and carry only minimal metadata required to notify the client.

Server model

The server relays encrypted traffic, coordinates delivery, and may temporarily store encrypted payloads for offline delivery. It is not intended to be the plaintext source of conversation history.

The server is controlled by its operator. In a self-hosted model, that operator may be you, your organization, or a community admin.

Self-hosted implications

Running your own server increases infrastructure control. It can reduce reliance on a third-party service operator, but it does not hide metadata from the server you operate.

You control server updates, hosting, logs, and backups.
You are responsible for TLS, access control, and operational security.
Your server can still observe metadata needed to route and deliver traffic.

Security recommendations

Verify fingerprints for important contacts.
Use strong passwords or passphrases.
Keep devices locked and updated.
Update the Hestia app regularly.
Trust the server operator, or consider self-hosting.
Use HTTPS/WSS for self-hosted deployments.
Be careful with backups and exported files.
Do not ignore unexpected key-change warnings.

Limitations

No anonymous routing is provided by default; Hestia is not Tor or I2P.
Metadata is minimized where practical, but not fully hidden.
The current trust model includes TOFU and benefits from manual verification.
No formal external security audit is claimed on this page.
Endpoint compromise can expose local plaintext regardless of transport encryption.

Future improvements

Possible future work includes stronger key verification UX, optional at-rest encryption controls, additional metadata minimization, and more transport privacy options.