Security built to be checked, not trusted

Built so the question is not "will they look?" but "can they look?". Wherever we could engineer it, the answer is no.

Identity without identifiers

Your identity is a key made from 12 words on your phone. No number, no email, no name.

End-to-end encryption

X3DH and the Double Ratchet, per device. Every message gets its own key.

Post-quantum messages, checked on your phone

ML-KEM-1024, a post-quantum ratchet and ML-DSA-65 signatures, checked against NIST vectors on your phone at every launch.

Sealed sender, the relay never learns who wrote

Every message between people leaves on an anonymous connection and the relay does not store who wrote it; only messages to and from the official :Spojiti_Beta account name their sender. It still sees the network address.

Sealed at rest

History in SQLCipher. Every photo and voice note under its own key.

A lost device erases itself

Report it on the Support page. From that moment it receives nothing; 48 hours later, the next time it is online, it tries to back up your chats’ text, sealed with your recovery phrase, and erases itself even if the backup fails. The wait lets you cancel from any of your devices a report someone else made.

Notifications that say nothing

Pushes carry no content. Your words are fetched over the encrypted channel.

Safety without surveillance

The abuse guard runs on your phone. Nothing is scanned on our servers.

Abuse handled on your phone

Report and block run on your device, and every message carries a sealed commitment to its exact bytes, checked when it arrives. If you choose, a report sends us the whole chat or the messages you select, words only: theirs with that proof, which we check, and yours marked as unverified. We keep it for 90 days in a reports store on Spojiti.cloud, not on the relay.

Encrypted backup we cannot open

Optional, and sealed with your recovery phrase before it leaves your phone.

Sovereign infrastructure

Servers we run ourselves on rented machines, in two countries. No hyperscaler between you and your words.

Everyone moves forward

A build with a security flaw is refused once the fix is out.

Everything grows from your 12 words

Your account keys are derived on your device from your recovery phrase. Only their public halves are published; a private key leaves your device only sealed, to link a new device or for a recovery method you turn on.

Your 12 recovery words ● ● ● ● ● ● ● ● ● ● ● ● generated on your device known only to you derive (HKDF) same words in → same keys out Identity keys Ed25519 + ML-DSA-65 sign · X25519 public half → published private half → never leaves Post-quantum prekey ML-KEM-1024 · FIPS 203 public half → published, signed Ed25519 + ML-DSA-65 Database key SQLCipher · AES-256 seals your history at rest, on your device only Backup key optional · zero-knowledge seals backups before they leave the device deterministic, so recovery is just re-derivation, and unrecoverable without the words, by design Your 12 recovery words ● ● ● ● ● ● ● ● ● ● ● ● generated on your device, known only to you derive (HKDF) same words in → same keys out Identity keys Ed25519 + ML-DSA-65 sign · X25519 public half → published private half → never leaves Post-quantum prekey ML-KEM-1024 · FIPS 203 public half → published, signed Ed25519 + ML-DSA-65 Database key SQLCipher · AES-256 seals your history at rest, on your device only Backup key optional · zero-knowledge seals backups before they leave the device deterministic, so recovery is just re-derivation, and unrecoverable without the words, by design

How Spojiti actually works

The main boxes we run, labelled with what each can and cannot see.

The real shape of the system: the main boxes we run, labelled with what each can and cannot see The edge · Caddy TLS 1.3 on port 443 · cloud infrastructure we run ourselves, multi-homed Spojiti relay · cells Elixir · your account lives in one cell · sealed envelopes between random ids Holds an envelope only until delivered, then deletes it. Sees: routing ids, ciphertext, when a device connected. Never sees: a name, a number, a contact list, a word. e1 7c 9f 4a b2 … → deleted The BEAM · Erlang/OTP The runtime under the relay and the control plane: millions of light processes, one per connection; supervisors restart what fails; two nodes per cell, clustered; more cells to scale. PostgreSQL prekeys · queued ciphertext A sealed envelope stores no sender, proven by a test. Media store · MinIO sealed blobs, by random id AES-256-GCM per item; one expiry for everyone. Control plane · ctl payments · Ops · cell directory Signs blind tokens; never learns who bought. Push · APNs / FCM a content-free nudge, no content Your words arrive over the encrypted socket after the wake. Calls · device to device WebRTC · DTLS-SRTP · signalled inside the encrypted chat STUN finds a direct path · TURN (TLS on 443) relays sealed media when a network blocks it · a fallback TURN on a second box takes over if the first is down · the relay never sees or stores a call. DR boxes off-box, every cell Live standbys, and encrypted backups every 30 minutes; a monthly drill. You Identity: a key from your 12 words. Post-quantum session, ML-DSA-65 signed. Sealed before anything leaves. seal → send Your contact Their own key, their own device. Opens it on arrival; the relay cannot. Safety number covers both key sets. receive → open Your Mac or PC Linked by QR; its own sessions. No phone needed to be alive. sealed envelope sealed envelope calls never touch the relay The real shape of the system, the main boxes we run, labelled with what each can and cannot see You Identity: a key from your 12 words. Post-quantum session, ML-DSA-65 signed. Sealed before anything leaves. seal → send linked by QR Your Mac or PC Linked by QR; its own sessions. No phone needed to be alive. sealed envelope The edge · Caddy TLS 1.3 on port 443 · infrastructure we run, multi-homed Spojiti relay · cells Elixir · your account lives in one cell · sealed envelopes between random ids Holds an envelope only until delivered, then deletes it. Sees: routing ids, ciphertext, when a device connected. Never sees: a name, a number, a contact list, a word. e1 7c 9f 4a b2 … → deleted sealed envelope Your contact Their own key, their own device. Opens it on arrival; the relay cannot. Safety number covers both key sets. receive → open under the relay The BEAM · Erlang/OTP The runtime under the relay and the control plane: millions of light processes, one per connection; supervisors restart what fails; two nodes per cell, clustered; more cells to scale. PostgreSQL prekeys · queued ciphertext A sealed envelope stores no sender, proven by a test. Media store · MinIO sealed blobs, by random id AES-256-GCM per item; one expiry for everyone. Push · APNs / FCM a content-free nudge, no content Your words arrive over the encrypted socket after the wake. Control plane · ctl payments · Ops · cell directory Signs blind tokens; never learns who bought. DR boxes off-box, every cell Live standbys, and encrypted backups every 30 minutes; a monthly drill. calls never touch the relay Calls · device to device WebRTC · DTLS-SRTP · signalled inside the encrypted chat STUN finds a direct path · TURN (TLS on 443) relays sealed media when a network blocks it · a fallback TURN on a second box takes over if the first is down · the relay never sees or stores a call.

What the relay sees

Sealed envelopes addressed to random account IDs, with no sender: every envelope between people arrives over an anonymous connection, wrapped to the recipient’s keys, so the relay never holds a sender, recipient pair. Only envelopes to and from the official :Spojiti_Beta account name their sender. Plus a coarse wake class (call vs message), and an opaque call id on a ring, so a sleeping phone can still ring. That trade is universal in VoIP push; we're just the ones who tell you.

What it never sees

Your name, your contact book, your message content, your call audio or video, and your phone number: if you choose to be findable, only a blinded fingerprint of it.

What it keeps

No message it can read. An envelope waits until your contact's devices collect it, five days at most, and is then deleted. It also keeps what routing needs (your random account id, public keys, devices and push tokens) and anything you opt into, such as passkey recovery or being findable; its encrypted snapshots hold the same for a few hours. It keeps no backups: those are on Spojiti.cloud, apart from the relays, or wherever you chose. Your history lives encrypted on your devices.

How a conversation gets its keys

A classical and a post-quantum secret, both needed, in every chat except the one with the official :Spojiti_Beta account, wherever both phones pass the on-device NIST self-test. Then a fresh key for every message, thrown away after use.

Classical secret · X25519 (X3DH) the exchange trusted for a decade Post-quantum secret · ML-KEM-1024 used only after passing NIST vectors on your device HKDF combine break one, learn nothing Signed · Ed25519 + ML-DSA-65 both signatures must verify root key key · msg 1 key · msg 2 key · msg 3 … a fresh key per message, deleted after use, and a fresh ML-KEM secret folded in as you talk Double Ratchet + post-quantum ratchet, keys churn as you talk a stolen key opens one message, never a history, and the ratchet heals the session afterwards Classical secret · X25519 (X3DH) the exchange trusted for a decade Post-quantum secret · ML-KEM-1024 used only after passing NIST vectors on your device HKDF combine break one, learn nothing Signed · Ed25519 + ML-DSA-65 both signatures must verify root key key · msg 1 key · msg 2 key · msg 3 … a fresh key per message, deleted after use, and a fresh ML-KEM secret folded in as you talk Double Ratchet + post-quantum ratchet, keys churn as you talk a stolen key opens one message, never a history, and the ratchet heals the session afterwards

Honest limits, what we can and cannot see

What the relay handles: ciphertext until delivered, random account ids and public keys, your devices and their push tokens, when a device last connected, your plan while you are connected, the IP address any server sees while you are connected, and anything you opt into (passkey recovery, being findable).

What it cannot see: your messages, media, call audio and video, name or number, or any group's name or member list. What it can see: which contacts' online status you ask for, that call signalling is in flight, and, because a group message goes out as one batch of sealed copies, which accounts receive copies together. It keeps no record of groups.

What no messenger can stop: the person you talk to, or a compromised phone. Where a promise cannot be absolute, we say so.

The promises we can keep one line each

Properties of how Spojiti is built. If one ever stops being true, it comes off this page first.

We never ask who you are.

No phone number, no email, no name, your recovery phrase IS your account.

We run the relay and still cannot read a word you send another person, unless they report it to us.

Even a subpoena finds only ciphertext, random account ids and the limited metadata listed in our privacy policy, plus the words of any report sent to us in the last 90 days.

Your phone never fetches a link because a message arrived.

Other messengers hand the link's owner your IP and exact read-time for a thumbnail. We don't. If you see a link card, the sender's own phone built it and sealed it into the message.

Ask the app itself, the :Spojiti_Beta assistant answers on YOUR device.

Your question is answered on your device from a fixed guide, so it works in airplane mode. The question also travels, end-to-end encrypted, to the :Spojiti_Beta account like any chat, where nothing reads or answers it today.

Nobody can impersonate the official Spojiti channel, not even someone who controls the network.

Our key ships inside your app, and nobody else gets to wear our name.

Already post-quantum.

ML-KEM-1024 key agreement, an ML-KEM-768 ratchet and ML-DSA-65 signatures, the NIST standards, live in every chat except the one with the official :Spojiti_Beta account, wherever both phones pass the on-device NIST self-test. Recorded messages stay sealed and keys stay unforgeable, even against a future quantum computer.

Notifications that wake your phone carry no message and no name, only whether it is a message or a call.

The words only ever exist decrypted on your device.

Read receipts that only say READ when you actually read.

An unfocused window never speaks for you.

Our relay cannot hear a call.

It can tell call signalling is in flight, never what is said. Media flows peer to peer where possible, otherwise through our own TURN relay, encrypted end to end either way.

Groups we keep no record of.

The relay stores no group, no name and no member list: a group message travels as a batch of separately sealed one-to-one copies. Carrying that batch, it can see which accounts receive copies together, and nothing more about the group.

Your access code is blind-signed when you redeem it, so the token your account uses cannot be matched to the purchase by our records.

The payment provider or app store sees the purchase; nothing we keep ties it to your account.

No false promises.

Where a platform cannot truly block screenshots, we say so, and give you detection instead of theatre.

A shared contact card carries the name they chose for themselves, or a short account id if they chose none.

Your private nickname for someone is not yours to forward.

Live location that lives inside the encryption.

No map service is contacted unless you tap a location to open it in a maps app.

Diagnostics stay on YOUR device.

Diagnostics stay on your device until you share them. They record actions, not messages, and every entry is scrubbed of e-mail addresses, phone numbers, keys and tokens.

Strangers arrive as quarantined requests.

Content-free, never marked read, and ignoring them tells them nothing.

Everything at rest is sealed too, apart from short-lived copies made to record, play or share a file.

Messages in SQLCipher, media, files, even profile pictures, ciphertext on disk.

Finding people never hands us your number.

If you turn on “people who have my number can find me”, we hold a blinded fingerprint of it, never the number, that only someone who already has your number (or holds our signing key) can use. Your address book is matched on your phone; we never learn who you looked for. A hello reaches you only if the sender's number is in your address book too. Off is one tap, for everyone.

Found something?

Security reports are welcome and taken seriously, and you never have to tell us who you are. How to report, what we promise back, and what counts as in scope is written down in Reporting a vulnerability below; the machine-readable version is at /.well-known/security.txt.

No ads. No brokers. No exceptions.

Our only revenue is subscriptions. There is no advertising SDK, no analytics broker, and no data-sharing "partner" in the app, the business model is the privacy policy.

Reporting a vulnerability

Coordinated disclosure, written for a messenger that does not know who its users are, so it does not need to know who its researchers are either.

How to reach us

Email spojiti@spojiti.world with SECURITY in the subject, or open a ticket on the support board, the board takes no name and no email, only a code sent to your Spojiti account, whose random id only our staff can see. Tell us what you found, how to reproduce it, and which build (Settings → About Spojiti). A diagnostics export (Settings → About Spojiti → Diagnostics) helps and contains no message content.

What we promise back

An acknowledgment within 3 business days. A fix or a written plan within 90 days for anything confirmed, faster for anything that touches message confidentiality, which ships as soon as it is built and tested. Public credit on this page if you want it, under any name you choose, or none. Every confirmed report is noted in the app's release history.

In scope

The apps (Android, iOS, macOS, Windows), the relay and TURN servers, the ops console, and this website. Anything that lets a third party read a message, learn who is talking to whom, unmask an account, or take an identity is the top of the list. Cryptographic protocol findings are especially welcome, the session design is on this page on purpose.

Out of scope

Volumetric denial of service, rate-limit “bypasses” that only prove you can send a lot of traffic, social engineering of people, physical access to an unlocked device, findings in third-party services we do not run (push providers, app stores, payment processors), and reports that require a rooted or jailbroken device with our app's own protections disabled.

Good-faith research

Research done in good faith, testing against your own accounts and devices, stopping at proof, not accessing or altering anyone else's data, and giving us the time above before publishing, is authorized use of Spojiti, and we will not pursue legal action against it. If you are unsure whether something is covered, ask first; the answer is usually yes.

Thanks

Researchers who help make Spojiti safer are credited here, by the name they choose. A paid bounty programme opens with the audit report, and this page will say so. An independent security audit of the full product is in progress, expected by end of 2026 and on track; the report will be published in full.