End-to-end encryption with OMEMO + a policy / MDM layer that lets admins lock cameras, GPS, and Google services; peer-authorized remote wipe; auto-expiring messages; and a small set of in-app mini-utilities. All on infrastructure you can self-host under your own brand.
The chat surface treats encryption as a precondition rather than an option. The protocol is open (XEP-0384), peer-reviewed, and has been deployed in production for years — Conversations is the reference Android client and the codebase we fork.
Multi-end multi-message encryption with the Signal-derived double-ratchet. Forward secrecy + future secrecy on every key rotation. The server (ours, yours, or anyone you federate with) only ever sees ciphertext.
Optional policy: refuse to send any message in plaintext. Even when a recipient hasn't published an OMEMO bundle, the message is held until they do, instead of falling back to legacy XMPP plaintext.
Each device publishes its own OMEMO bundle. Adding a new phone doesn't compromise old conversations; revoking a lost device doesn't invalidate the others.
Users are username@chat.yourdomain — not a phone number. SIM-swap attacks are irrelevant; the contact graph isn't tied to a phone-number database that gets leaked or subpoenaed.
Admins define named Policy templates (kiosk users, full-staff users, contractors, etc.) and assign one to each user. Devices poll /api/v1/policy on every foreground; runtime toggles take effect immediately, no app re-install.
Users can't change the XMPP hostname / port. Stops a confused or malicious user from re-pointing the app at a non-org server.
Single-account install. Users can't add personal XMPP accounts alongside the org account, removing a data-leakage path.
Limit chat to JIDs in the same customer org. Useful for closed deployments where federation is a liability rather than a feature.
Sets FLAG_SECURE on every chat surface so the OS blocks both manual screenshots and screen-recording apps. Surfaces a black thumbnail in the recents tray.
Set a per-policy retention window: messages older than N days are wiped from the device automatically. Catches the case where a user forgot to clean up sensitive history before losing a phone.
Push a custom presence note to every device — useful for compliance disclaimers, on-call rotations, or just brand-tone messaging.
When the app holds Device Owner (the strongest Android admin tier), it dispatches policy keys directly to DevicePolicyManager. Best-effort on Device Admin (the lighter tier; some keys silently skip), mandatory on Device Owner. Useful for hardware vendors who provision devices before shipping.
OS-level: the camera hardware is disabled while the policy is in force, app-wide. Even other apps can't access it.
OS-level mic block. Pairs naturally with the camera disable to lock down passive surveillance vectors on shared / loaner devices.
Block all location services system-wide. App-level location requests fail; passive geofencing stops working. Removes a major behavioral-tracking surface.
Kills the BLE scanner / pairing surface. Useful where BT trackers, beacons, or sneaky-pairing attacks are part of the threat model.
Mandatory PIN/biometric on every wake. The device can't sit unattended without going to lockscreen — useful policy for shared offices and field crews.
On Device-Owner-provisioned devices, strip Play Services, Play Store, and the Google account framework. The phone runs without any Google dependency — pairs with sideloaded APK delivery for a fully de-Googled stack.
Three independent layers: peer-authorized wipe (you designate contacts who can nuke your device from theirs), admin-driven wipe via the portal, and subscription-expiry lockout that triggers automatically when payment lapses.
From the app, the user authorizes specific JIDs (a spouse, a security officer, a duress contact) to remote-wipe their device. The grantee taps a button in their app and the target device factory-resets — without going through the admin portal at all.
From the admin portal, the customer's IT can force-wipe any enrolled device. Standard MDM behavior; falls back to a forced sign-out + key revocation if the device is offline at the moment of issue.
When a subscription expires, the XMPP password is rotated server-side. The device drops connection on next sync and falls into a lockout screen — even if it was offline when the expiry fired.
Lost device, replaced phone, or post-wipe re-onboarding: admin re-issues a single-use activation token from the portal. Old device tokens are invalidated; the new device gets a fresh OMEMO bundle.
An Apps tab in the bottom nav surfaces small in-app utilities — currency converter, shared bookkeeping, crypto-balance helper, peer-device view. Each tile is policy-gated; deployments can hide any subset (or the entire Apps tab) via the customer's policy.
Built-in mini-app: convert between fiat + crypto with up-to-date rates. Useful for travel, remittance discussions, and treasury chats happening in-thread.
Lightweight ledger for personal or small-team accounting. Each book can be shared with one or more contacts — entries sync over OMEMO, end-to-end encrypted, with no third-party SaaS in the middle.
Hold-only multi-chain balances tile inside the app — handy for OPSEC use cases where you want to check holdings without opening a separate wallet app and exposing it to the recents tray.
Customers and resellers (whose `peerManagementScope` permits) get a tile listing devices they manage — handy for households and ops teams that want one-tap visibility into who's enrolled.
Every mini-app can be hidden via policy. The Apps bottom-nav entry itself disappears when all mini-apps are off — clean install for customers who only want the chat surface.
The infrastructure is yours: managed ejabberd on your subdomain, signed APKs delivered through the portal's updater, federation with the rest of the XMPP universe when you want it. Voice/video calls and group chats over the same encrypted transport.
Managed ejabberd on the customer's own subdomain (e.g. chat.yourbrand.com). User JIDs, OMEMO bundles, MAM history, and the federation surface all live on infrastructure you control.
Admins upload signed APKs to the portal; the app's in-app updater polls for the latest version, downloads, verifies SHA-256, and installs (silent on Device-Owner devices). Targets de-Googled phones, GrapheneOS, kiosk fleets — wherever Play Store isn't an option.
Standard XMPP federation — your users can talk to anyone running an XMPP server, encrypted by OMEMO when both sides support it. Or restrict via the cross-org-messaging policy if federation isn't part of your threat model.
1:1 calls over XMPP Jingle with end-to-end encryption (DTLS-SRTP). No third-party calling provider in the path; signaling stays on the same XMPP server as your text chat.
Multi-user chatrooms with admin / moderator roles, message archive, and OMEMO group encryption. Per-room retention policy if you want short-lived deal rooms vs. long-lived team channels.
Message Archive Management (XEP-0313): when a device comes back online after being off, it pulls the messages it missed from the server's encrypted archive. Encryption is end-to-end; the server only stores ciphertext.
The runtime app respects branding policy keys (app name, primary color) so a deployment can ship under a custom name without rebuilding. Past that — package ID, app store listing, custom JID domain — sits in the white-label tier.
Set via policy — the running app respects the override on next foreground. Colors propagate across the chat surface, splash, and notification icon. Useful even before a full white-label rebrand.
Beyond runtime branding: package ID, app store listing, custom JID domain, branded admin portal, dedicated XMPP server. Same codebase, fully your product. Detailed on the white-label page.
Try it standalone with a trial, deploy at scale via the white-label tier, or skim the use cases for fits adjacent to yours.
Questions about plans, payments, or installation? Send us an end-to-end encrypted message and we will reply within an hour.