End-to-end encryption (E2EE) is now the default in the most widely used messengers, and people expect the content of their conversations to be hidden from eavesdroppers.

Content is only part of the picture. The servers around it still see metadata, they can be blocked, and the apps themselves can be pulled from app stores. Below we go through each of these problems and what VeilMesh does about them.

Figure 1: A messenger built around one central server can be blocked at that point and collects metadata in one place; a mesh has neither weak spot.

1. Servers still see who, when and from where

Even if a messaging company cannot read the text of your message, its servers know who you are talking to, when you sent the message and what IP address you used. Together this shows who you talk to, and for an investigator that is often more useful than the text.

If a government agency can see that a journalist contacted an anonymous source at 2:00 AM and called their editor at 2:05 AM, it can work out where the story came from without reading a word. Most secure apps also still require a phone number to register, which ties your keys to a state-registered SIM card.

VeilMesh has no SIM card registration. Your identity is derived from cryptographic keys created on the device and protected by the iOS Keychain or Android Keystore. Over Bluetooth, Protocol V2 encrypts packet headers with ChaCha20-CTR, and Ghost Mode turns off discoverable broadcasts. Over internet relays, group names are never sent to the server, typing indicators are sealed inside encrypted payloads, push notifications carry only blinded tags, and Locked Chats keep file names and file types off the server. Hiding the sending account from the relay itself is the next step.

2. One blocked server stops the app

Secure messengers depend on central servers. If a platform's servers in Amazon Web Services or Google Cloud go offline, or a national firewall blocks its domain and IP ranges, the app stops working. During internet shutdowns, disasters or power cuts, these messengers are unavailable.

If cellular networks or the internet are down, VeilMesh sends packets directly between devices over Bluetooth Low Energy (BLE) and local Wi-Fi (a shared network, a hotspot, or AWDL between Apple devices), or through an onboard VeilMesh Box. Messages pass from device to device, up to 7 hops, until they reach the recipient. When online, VeilMesh carries signaling and media over TLS on TCP port 443 (wss:// and turns://), which gets through strict corporate and maritime firewalls.

3. App store accounts can be linked to chat keys

Most secure messengers are distributed through the Apple and Google app stores. A download is linked to a personal Apple ID or Google Account, which is tied to a billing address and a payment card. In many messaging apps this store profile is then linked to the in-app account through the phone number or telemetry, so there is a record connecting your real identity to your chat keys. Distribution through a store also means the store operator can be forced to push a modified update or remove the app in a country.

In VeilMesh the store account and the chat keys are separate. There are no phone numbers, e-mail addresses or telemetry logs on our backend, so downloading VeilMesh from an official store does not link your Apple ID or Google Account to your Veil ID, which is generated on the device and stored in the iOS Keychain or Android Keystore after installation. In case a store removes the app, we support installing signed APK files directly, checking release SHA-256 checksums, and sharing the app from device to device.

4. Group encryption cost: pairwise vs. MLS trees

Group chats are expensive in many secure messengers. If you send a message to a group of 100 people, your phone encrypts it 100 times and uploads 100 copies. This costs battery and bandwidth, which matters on slow connections.

VeilMesh uses the Messaging Layer Security (MLS, RFC 9420) protocol. MLS uses tree-structured group keys, so the cost of group operations (adding or removing members, rotating keys) grows logarithmically with group size instead of linearly. This keeps large groups usable over slow Bluetooth links in an offline mesh.

5. Channels without a central server

In most messengers, channels (broadcast feeds) are stored on the company's database servers. A post lives on the server, and subscribers download it from there. If the government blocks the server or forces the platform to delete the channel, subscribers lose access to the content. On some platforms even "private" channels are stored unencrypted on the company's servers.

VeilMesh channels use epidemic gossip routing. When a channel administrator publishes an update, the post is signed with their identity key, so relays cannot change it. The signed post then spreads through the mesh: devices store the channels they subscribe to and pass others along. A user who was offline can fetch the latest channel history from any nearby device that already has it, without a central server.

Channel protections:

Signatures: every post is signed with the creator's Ed25519 identity key. Changing any byte breaks the signature, so relays cannot forge or alter posts.
Private channels: posts in restricted channels are encrypted with a symmetric channel key shared only with authorised subscribers. Devices that relay the data carry only ciphertext.
Subscribers: a central server keeps a full list of each channel's subscribers. VeilMesh uses blinded topic hashes, so devices pick channel updates out of the gossip stream without telling the peers that relay them which channels they follow.

6. UX shortcuts that weaken perfect forward secrecy (PFS)

Some commercial E2EE messengers weaken their cryptographic guarantees to support interface features such as editing messages, history sync or reactions. In several popular apps, editing a sent message changes the cryptographic context, and the message details then show "Perfect Forward Secrecy: No".

To avoid complicating server-side rewriting and key ratcheting during edits, such systems fall back to static or long-lived keys. If one of the current keys is later compromised, the attacker gets the edited text and the related conversation history, so forward secrecy no longer holds.

In VeilMesh, sending, editing, deleting, reacting and system messages are all ordinary Double Ratchet or MLS messages. Each edit advances the ratchet and uses a new single-use key, and no interface feature turns forward secrecy off.

Conclusion

Encryption hides content, but the servers around it still see metadata and can be blocked. VeilMesh registers no SIM card, uses relays that hold no keys, falls back to a local mesh, and distributes channels without a central server.