Encrypted messaging, as an API call.
Identities, sessions, one-time prekeys and AES-256-GCM message encryption behind a small REST API, so you don't build a messaging crypto stack yourself. Keys are generated and held server-side — this is managed encryption, not end-to-end.
What this is — and what it isn't
What it is
A REST API that manages messaging identities, establishes sessions between them, hands out one-time prekeys, and encrypts each message with AES-256-GCM under a per-session key. Session keys are agreed with X25519. Identities are ECDSA (P-256) signed and expose a verifiable fingerprint.
What it isn't
Not end-to-end encrypted. You POST plaintext to the API and the service encrypts it; it generates your keypairs and holds the key that unwraps them. Anyone with the server and its encryption key can read message contents. Not post-quantum — key agreement is X25519, a classical algorithm.
If your threat model includes us, this is the wrong tool — you need encryption performed on the client, where we never hold the key. If you just need messages encrypted at rest and in transit without writing the key management yourself, this is the shortcut.
Storage: identities, sessions and messages are held in Postgres and survive restarts and redeploys. We do not yet publish a backup, restore or uptime commitment. The client libraries are also not published to any package registry yet — see the quickstart.
Quickstart — four calls
Note step 3: the plaintext goes to the server. That is the trade — you skip the key management, we can read the message. Python, JavaScript and Swift client sources live in the repo; none is published to a package registry yet.
What's under the hood
X25519 session keys
Each session agrees a shared secret with X25519, then derives the message key through HKDF-SHA256. Standard, classical elliptic-curve key agreement.
AES-256-GCM messages
Every message is encrypted and authenticated with AES-256-GCM, so tampering with stored ciphertext is detectable rather than silent.
One-time prekeys
Ten single-use prekeys per identity, marked spent as they're consumed — the Signal-style shape for asynchronous session setup.
Fingerprint verification
ECDSA P-256 signed identities, each exposing a fingerprint your users can compare out of band to confirm who they're talking to.
The Signal-style shape, without the protocol work
The primitives you'd expect — identities, sessions, one-time prekeys, signed fingerprints — arranged the way you already know, with the key handling done for you rather than by your client. Client sources for Python, JavaScript and Swift are in the repo.
Pricing
- Up to 10,000 identities
- 100,000 messages / day
- Session key rotation
- WebSocket delivery
- Unlimited identities
- Unlimited message volume
- Session key rotation
- Priority support
- Unlimited identities + volume
- SSO & advanced security
- Dedicated support
- SLA
Every tier uses the same cryptography — AES-256-GCM messages over X25519 session keys. Paid tiers raise the identity and volume limits and add session key rotation; they do not change the algorithms.