Durable, strictly ordered
Persisted before delivery, monotonic per-room sequence, idempotent send. Replies, edits, reactions, delivery/read receipts, unread cursors, full-text search, stories.
✦ REALTIME COMMUNICATIONS BACKEND
Chat, calls and E2EE —
the server half, already built.
Ollacore is a production backend for messaging, multi-party audio/video and end-to-end encryption. One Rust service on one Linux VM. You build the apps; the durable ordering, media forwarding, key distribution, push and multi-tenancy are done.
Verified spec
API Surface & Verification
114 ops A+
Durable message ordering (PostgreSQL) 100%
SFU media forwarding (WebRTC RTP) 100%
E2EE key transport (Megolm/Olm) 100%
ARCHITECTURE // WIRE TOPOLOGY
Web iOS Android Desktop
➔
OLLACORE
MESSAGING · SFU · E2EE ➔
Durable Ordering Media Forwarding Key Distribution Push & Tenancy
TOP SPECIFICATION: You build the apps; the durable ordering, media forwarding, key distribution, push and multi-tenancy are done.
Everything below is implemented and verified against a live deployment.
Not a roadmap. Each of these has integration tests running against a real stack on every release, and a production smoke suite on every deploy.
MESSAGING
REALTIME
Gap-free reconnection
Clients resume from their last sequence with deliberate overlap — nothing missed, nothing duplicated. Typing indicators, presence with crash detection.
CALLING
SFU audio, video, screen share
Multi-party with per-subscriber forwarding, multi-device, trickle ICE, TURN relay. Simulcast with a layer per subscriber chosen by an adaptive policy or pinned by your server. Verified with real WebRTC clients and across four browser engines.
ENCRYPTION
E2EE transport, blind relay
Megolm/Olm key distribution with atomic one-time-key issuance and forward-secrecy signalling. The server never holds a key or a plaintext.
IDENTITY
Turnkey phone-OTP directory
Optional: phone signup, contact discovery, profiles with photos, direct and group conversations with invite links, per-chat mute and block, a chat-list inbox and token vending — so you can ship a messenger without building an auth layer.
NOTIFICATIONS
Web Push, FCM and APNs
Presence-aware so only genuinely offline members are notified, with storm cooldown and content-free mode. Incoming calls ring offline devices.
Bring your own users — or don't.
The difference is only who owns identity. Everything downstream — chat, calls, push — is identical.
PATH A · YOU OWN IDENTITY
Server-to-server
Your app-server authenticates the user however you already do, then calls Ollacore with a tenant-pinned API key to provision a room and mint a room-scoped token for the client.
The backend stores no names, emails or phone numbers. Best for embedding chat/calls into an existing product.
PATH B · TURNKEY
Phone-OTP directory
The client talks to Ollacore directly: phone + one-time code, contacts, conversations, and a token per conversation. No app-server of your own required.
You supply your own SMS route and push credentials — we hold no telecom or push account. Best for a standalone consumer messenger.
See both paths, step by step, in the integration checklist →
How it is verified
| Check | What it proves |
|---|---|
| Integration suites vs a live stack | Every plane exercised against real Postgres, Valkey and object storage — not mocks. |
| Real WebRTC media through the SFU | Headless peers exchange genuine audio, video and screen-share RTP, in order. |
| Browser interoperability | Chromium, Firefox, Chrome and WebKit driven against a live stack, media proven by received-byte counters. |
| Push through Google's real service | Web Push verified end-to-end to a service worker, not a local sink. |
| Production smoke on every deploy | 13 checks including restart durability; the release is refused if they fail. |
| Licence compliance, mechanically | The whole dependency tree is checked at every release — MIT/Apache/BSD/ISC/Zlib only. |
| Restore drill from off-site backup | Measured RTO of 64 seconds, with the smoke suite run against the restored data. |
The limits, stated plainly
You will find these in the docs too. It is cheaper for both of us if you know them now.
No high availability
Single SFU, single VM by design. Host loss is an outage until the machine is rebuilt (~20 minutes). There is no SLA or status page yet.
One client library, pre-release
A TypeScript client — typed REST plus a room connection that handles tokens, reconnects and catch-up — exists but is not yet published to npm, and calls are not in it yet. Every other language generates a client from the OpenAPI and AsyncAPI documents.
You bring SMS and push accounts
OTP delivery and native push use your vendor credentials. We hold no telecom or push account, and DLT/sender registration stays yours.
Capacity is a measured envelope
About 150 concurrent chat sessions and 50+ concurrent uploads per node, with calls bounded structurally. Beyond that is unproven, not promised.
Start with the checklist
Exact endpoints, exact frames, in the order you need them: stand up chat, place a call, and ring an offline phone.