Messaging infrastructure
Encrypted realtime, by default.
We are building the messaging layer we wanted to exist: realtime chat a developer can drop into an application, where end-to-end encryption is the default rather than an option, and where every claim about the system traces to evidence.
Plaintext in your code, ciphertext on the wire. The server only ever sees ciphertext, never plaintext. Encryption is built on the Signal protocol library, libsignal, rather than cryptography of our own invention.
What it does
- Direct messages, group rooms, and a contact graph that gates who can reach whom.
- Link multiple devices to one identity; messages reach all of them.
- SDKs for Web, Apple, Android, .NET, and Rust.
- One API key per tenant; tenants are isolated and configured independently.
- Encrypted file and image transfer alongside messages.
How we know it works
Security claims are easy to make and expensive to check, so we treat ours as a registry: each one is written down, tied to the evidence behind it, and removed or narrowed when the evidence does not reach. A claim that outruns its evidence is a bug.
The evidence itself is runtime evidence, which we call proof bundles: captured runs of the shipped system against a live cluster, showing that a behaviour held when it was exercised. A DM sent from one SDK is byte-for-byte the message another decrypts, captured pair by pair across the web, Apple, .NET, and Rust SDKs. The bundles are re-verified nightly, so a claim that silently stops being true gets caught rather than remembered.
These are observations of real behaviour, not formal proofs. We reserve the words verified and proven for machine-checked proof of a specification, which this is not. We also publish no throughput or latency figures yet, for one reason: no capacity evidence bundle substantiates a number, and a number without evidence is exactly what this discipline exists to prevent. The journal covers how this works in practice.
Where it stands
The product is in active development in a private repository, with the platform running on our own infrastructure and the SDKs exercised by example applications on every platform. We have commissioned external security review, and the confirmed findings from the most recent round have been resolved. We are preparing it for public release under its own name; enquiries are welcome at info@natuvea.com.