End-to-end encryption is often treated as the end of the security discussion: use Signal-grade protocols, keep the keys on the device, and you are done.

We build VeilMesh, a messenger that works over Bluetooth and Wi-Fi when there is no internet and over relays you can own when there is. Encryption decides whether anyone can read a message. Two other questions remain:

Who can see that you talked, when, and to whom?
Who can be ordered to switch the service off, or change it?

The answers depend on how the system is built and which country's law applies to the operator. Below is how we approach them in VeilMesh and what a relay can still see today.

Nearby devices talk directly. Over the internet, relays carry ciphertext they cannot open. An organisation can run its own relay.

1. Encryption protects content, not metadata

A modern messenger can make message content unreadable to its own servers. A server that delivers messages still learns some things in the course of its work: which accounts are online and when, who a message is addressed to, and how large an attachment is.

For investigators and data brokers this metadata is often the most useful part: a contact graph with timestamps reveals a lot without decrypting anything.

Signal's sealed sender, for example, hides the sender from Signal's own server. Still, whoever runs the delivery infrastructure belongs in your threat model, and encryption alone does not change that.

2. The law that applies is the company's, not the datacenter's

Hosting in a European region does not by itself keep data under European law.

US CLOUD Act (2018). A provider subject to US jurisdiction can be ordered to produce data in its possession, custody or control, including data stored in its European datacenters. For European organisations this conflicts with GDPR; the Schrems II ruling dealt with the same tension.
Client-side scanning. The EU's proposed CSAM Regulation ("Chat Control") has repeatedly included scanning on the device before encryption. Whatever the final text, a design in which one vendor's app on one vendor's infrastructure is the only trusted component gives regulators a single place to apply pressure.
One operator, one country. A single operator can be ordered to hand over its domain, shut down or ship a modified update.

This applies to us as well. VeilMesh's hosted relays run on commercial cloud providers, including US-incorporated ones with European regions, so we assume any host can be compelled and design for it.

3. Designing for a host you don't trust

If the relay operator, the cloud provider or the network may be hostile or unavailable, three requirements follow:

Messages must still be delivered when there is no internet.
A seized relay must not hold anything useful.
Organisations that need it must be able to run the infrastructure themselves.

A. Nearby, without internet

VeilMesh devices connect to each other directly in two ways, neither of which needs the internet:

Bluetooth Low Energy, between any iOS and Android devices. It carries text, receipts and key exchanges, and tells a neighbour where to reach the device over Wi-Fi.
Wi-Fi for files, calls, history and other larger data. This works on a shared network or a phone's hotspot (a ship's or office network is enough, with no internet connection behind it) and, between Apple devices, over AWDL, Apple's peer-to-peer Wi-Fi, which needs no access point.

In addition:

Bluetooth mesh packets are flooded to nearby devices, and the radio header does not name the recipient, so a phone relaying a message cannot tell who it is for.
Every packet is signed with the sender's Ed25519 key and carries a small proof-of-work, which is checked before the signature so that forged or junk traffic is dropped cheaply.
Ghost Mode keeps a conversation off the internet: it uses no relay, cloud sync or push notifications.

Offline messaging is not new; Briar and others have shown that it works. We wanted the same account and chats to work over a Bluetooth mesh, over the internet and over a relay you run yourself.

B. Over the internet: relays that hold no keys

When the internet is available, messages travel over TLS WebSockets through a relay. We use established protocols:

One-to-one chats: X3DH and the Double Ratchet, with XChaCha20-Poly1305.
Groups: MLS (RFC 9420). Group keys move to a new epoch whenever members join or leave, and are also refreshed regularly.
Calls: end-to-end encrypted WebRTC. Group media keys are derived from the MLS group, so the call server forwards media it cannot decrypt.
Identity: an account is a key pair created on the device. No phone number, SIM or e-mail address is used.

A relay keeps encrypted messages only until delivery, for a limited time, and holds no end-to-end keys. A seized relay contains ciphertext addressed to public keys, without message history or phone numbers.

Push notifications raise their own jurisdiction question, since Apple and Google are US companies. VeilMesh notifications contain no message content and no sender or chat identifiers, only a blinded tag that the phone recognises. The notification wakes the app with a generic "Encrypted message" text, and the app then fetches the message from the relay.

C. Running your own relay

Organisations that do not want to depend on our infrastructure can run their own:

Private relays run on a dedicated machine per customer, with its own network, database, call server and backups; nothing is shared with other customers. Membership is by invitation, and the owner holds a key that only they see.
Vendor access is granted by the customer. After setup, our engineers can log in only through an access window that the owner opens, and the customer sees every login and every refused attempt.
VeilMesh Box is the same relay packaged for the customer's own hardware, in a data centre, offshore or on board a vessel, and it works without an internet connection.

For example, on a ship at sea the crew communicates over the Bluetooth and Wi-Fi mesh and through a VeilMesh Box on the vessel's network. When the ship is back in coverage, messages to shore go through the company's own relay, so no outside cloud holds the keys or the history.

We are also rolling out several relays in one app: a person can belong to the public relay and to private relays at the same time, and each relay sees only its own conversations. Private relays are described in more detail in Your Own Relay.

4. What a relay still sees

Some of this is not solved yet.

Like any messaging server, a VeilMesh relay can see which accounts are connected, when, which account a message is for, and the size of attachments. Because the connection to the relay is authenticated, it can currently also see which account (a cryptographic key, not a phone number) sent a message, even though one-to-one messages are already wrapped in a sealed-sender envelope between the apps. Removing that link is on our roadmap, as is post-quantum key agreement between phones (already used between phone and computer).

Already in place: no phone numbers or e-mail addresses; group names, read receipts and typing indicators never reach the relay in readable form; relay logs use salted pseudonyms instead of account identifiers.

Our security reviews so far have been internal; an independent audit is planned. The details are in our Whitepaper, which was rewritten against the current source code.

5. Comparison

Centralised E2EE messengers (Signal, WhatsApp): strong cryptography, a single operator, internet required.
Federated (Matrix): you can run your own server, but delivery still needs the internet.
Offline-first (Briar and similar): works without infrastructure, designed mainly for nearby communication.
VeilMesh: a Bluetooth and Wi-Fi mesh without a network, a public relay without keys when the internet is available, and your own relay or Box where needed, in one app with one identity and no phone number.

Conclusion

You should not have to take our word for it, or any host's. VeilMesh is built on the assumption that a relay, its cloud provider or the network can be hostile, and section 4 lists what they can still see.

The same applies to this website: every page is listed in a signed manifest that your browser verifies with our open-source veil-guard, so a compromised server cannot silently change what you read.

More details are in our Whitepaper and on the Security page.

Get your own relay →