Real-time messaging

End-to-end encrypted chat your customers can actually trust.

1:1 and group messaging with multi-device sync, offline delivery, edit & delete, and read receipts — encrypted on device, never readable by us.

X25519 + AES-256-GCM·Per-device keys·Blind relay

E2EEon every encrypted message
Multi-deviceseamless sync, per-device keys
Offline-firstmessages queue and deliver
JS · iOS · Androidone protocol, one wire format

Use cases

What customers build with it

Chat drops into your product surface, your auth model, your branding. We carry the bytes, never read them.

Customer support chat

Stream/Intercom-style chat inside your app — your support agents, your queue logic, your data.

SaaS · Support

Patient-doctor secure chat

HIPAA-friendly two-party messaging. E2EE always, attachments to your own bucket, audit-friendly retention.

Healthcare · Regulated

Community & team chat

Slack-style channels with member counts in the thousands. Cleartext or E2EE per channel — your choice.

Community · SaaS

Why DropOnAir for messaging

Trust is the feature. Everything else is built around it.

E2EE on every encrypted message

Per-device X25519 keys, AES-256-GCM payloads with AAD binding sender, recipient, timestamp. We forward sealed envelopes.

Multi-device, no key sharing

Each device generates its own keypair. Sender encrypts once per recipient device. Lost a phone? Revoke one device, others keep working.

Offline delivery

Messages queue while the recipient is offline and deliver on reconnect — including across multiple devices in any order.

One SDK across platforms

JavaScript, Android, iOS — same wire format, same message IDs, identical edit / delete semantics. No per-platform divergence.

Under the hood

How it works

Your client encrypts the message locally for each recipient device. We see a sealed envelope, route it, persist it for offline delivery, and never have the keys to open it.

  • Sender derives a shared key with each recipient device (X25519), encrypts the payload (AES-256-GCM), and submits an Envelope frame to the relay.
  • Relay validates the JWT, persists the sealed payload for the recipient, and fans out to any of their devices that are online.
  • Recipient devices open the envelope with their private key. The original plaintext never lived on our infrastructure.
  • Edit / delete are re-encrypted edits or tombstones — same path, same E2EE rules.

3 lines to send

The SDK does the crypto. You handle the UI.

Your backend mints the token, the SDK encrypts per recipient device, and your UI surfaces a delivered envelope. That's the loop.

Sending messages →

// 1) Initialise
const client = await initialize({ appId, getUserJwt });

// 2) Send encrypted
const messageId = await client.sendMessage(toUserId, "Hello");

// 3) Receive
client.onMessage(msg => render(msg));

What you ship in a week

A messaging product, not a starting point.

  • 1:1 E2EE messages
  • Group messages with sender-side fan-out
  • Cleartext mode for public communities
  • Edit & delete (for-everyone or for-me)
  • Read receipts & typing indicators
  • Multi-device sync with per-device keys
  • Offline delivery + push notification
  • Attachments stored in your bucket

Ready to build

Add chat your customers can trust.

Start with the technical quick-start. The crypto is in the SDK.