In plain English
When your child sends a message on Orbit, their phone scrambles it before it leaves. The only phones that can unscramble it are the ones belonging to the people in the conversation. Our servers move the scrambled message between phones — like a post office that can see the envelope but not read the letter inside.
This is called end-to-end encryption. It's the same idea behind apps like Signal and iMessage. The difference with Orbit is the rest of the product: the contact list is closed, parents have to approve new connections, and the people chatting are usually kids you already know.
When we say "we can't read your messages," we mean it structurally — not as a promise. The keys that unscramble messages never leave your family's phones. If someone broke into our servers, or served us a subpoena, or if we wanted to (we don't), the thing we'd be looking at is still scrambled.
Messages get locked on the sender's phone and only unlocked on the receiver's phone. We carry the locked package. We don't hold the key.
The technical bits
For curious or technical readers. Skip this section if you don't want to go into the weeds.
The protocol: X3DH + Double Ratchet
Orbit uses the Signal Protocol — the same end-to-end encryption protocol behind Signal, WhatsApp, and Facebook Messenger's secret conversations. It's open, well-audited, and widely peer-reviewed. We didn't invent our own crypto.
X3DH (Extended Triple Diffie-Hellman) is how two phones that have never met establish a shared secret the very first time they talk — even if one of them is offline. Double Ratchet is how they keep rotating keys forward as they chat, so that if any one key is ever compromised, it doesn't unlock earlier or later messages. This property is called forward secrecy and post-compromise security.
The keys: Curve25519
Every device has three kinds of keys, all generated on the device itself:
- Identity key — a long-lived Curve25519 key pair that identifies the device. The private half never leaves the phone.
- Signed prekey — a medium-lived key, signed by the identity key, that starts new conversations.
- One-time prekeys — a batch of single-use keys that get consumed as new conversations begin, giving extra forward secrecy for the opening handshake.
Our server stores the public halves of these so your friends' phones can look them up to start a conversation. The private halves never leave the device where they were generated.
Per-device sessions
If a user has multiple devices (an iPhone and an iPad, say), each device has its own independent identity key and its own encryption session with every peer. A message sent to Emma isn't encrypted "to Emma" — it's encrypted separately for each of Emma's devices. If one device gets compromised, the others aren't.
What our server handles
The server is responsible for routing, not reading. It:
- Holds public key bundles so phones can find each other and start conversations.
- Stores encrypted message blobs until the recipient's phone is online to fetch them.
- Manages accounts, the family graph (who's in which family, who's approved to talk to whom), and content-filter rules that run on the sending device.
- Broadcasts delivery notifications (metadata only — "a message arrived for you") so phones know when to sync.
It does not — and structurally cannot — decrypt the message contents.
Sign-out wipes local state
When someone signs out of Orbit, every piece of crypto state on that device is wiped: identity key, session state, message cache. A re-login generates a fresh identity and starts new sessions. If a phone is lost, a remote sign-out via the parent account achieves the same thing.
What we store (and what we don't)
On our servers
- Account basics (parent email, child display name, family graph)
- Public keys (so phones can find each other)
- Encrypted message blobs awaiting delivery
- Metadata needed for routing: who sent to whom, when, and to which device
- Your content-filter rules (word lists, approval settings)
Never on our servers
- Plaintext of any message your family sends
- Private encryption keys — they live on the device that made them
- Contacts from your phonebook or social graphs outside Orbit
- Ad identifiers, tracking pixels, third-party analytics
- Any data sold or shared with marketers
What parents can actually see
Because we can't read the messages, we can't show them to you. That cuts both ways — it's the same property that keeps anyone else from reading them. What parents can see and control:
- Who their child is talking to. The list of active conversations and the other parent on the other end.
- Approval for new contacts. A child can't add a new friend without both parents agreeing.
- Content filters. Word lists that block or flag messages before they send. Filters run on the device, before encryption, so they catch things without anyone else reading the message.
- Approval requests. Optional "ask me first" mode where messages flagged by your filter show up for your sign-off before they send.
- Metadata. When conversations happen, how often, with whom. Useful for spotting unusual patterns without reading content.
What parents cannot see: the verbatim text of every message. That boundary is by design. It's what lets Orbit promise real privacy.
Transparency & current state
We believe you should be able to check what we claim. Honest status as of today:
- Orbit is currently in pre-launch / early beta. The security design described here is in place; polish and audits are ongoing.
- We plan to commission a third-party security review before a broad public launch and publish the report.
- If you find a security issue, please email us (a proper contact form will land with launch). We take responsible disclosure seriously and will credit researchers who report issues privately first.
Technical FAQ
Why not just tell families to use Signal or iMessage?
Those apps nail the encryption but not the rest of the problem for kids: anyone with a phone number can message them, there's no parental approval for new contacts, and no per-child content filtering. Orbit reuses the same battle-tested protocol and wraps a family-specific product around it.
What if the Orbit server is compromised?
An attacker with full server access would get: encrypted message blobs (unreadable without device keys), public key material, account metadata, and the family graph. They would not get message plaintext, private keys, or any way to decrypt past or future conversations. This is the whole point of end-to-end encryption: the server is untrusted by design.
Do you support perfect forward secrecy?
Yes — the Double Ratchet construction provides forward secrecy and post-compromise security. Each message uses a fresh symmetric key derived from a rotating ratchet, so compromising one key does not expose earlier or later messages.
Can I see the source code?
Parts of Orbit will be open-sourced over time; others will remain closed for now. We'll publish a clear list at launch. The cryptographic core uses open, audited libraries rather than anything proprietary.
How are keys verified between devices?
Each device publishes a signed prekey tied to its long-lived identity key. A recipient device verifies the signature before starting a session. Out-of-band identity verification (safety numbers, QR scan) is on the roadmap for parents who want belt-and-suspenders confirmation.
What happens to messages when a device is added or removed?
New devices generate their own identity and prekeys and register them with the server; future messages are encrypted for the new device as well as the old ones. Removed devices stop being included in new sessions; their local state is wiped on sign-out.