Security Model

Svoi is built as a secure messenger for everyday conversations: personal, family, work. What follows is a clear and restrained description of what we protect, how, and where the boundaries sit.

End-to-end encryption by default

• All messages are encrypted on the client using the MLS standard (RFC 9420) via the OpenMLS library.
• Groups scale through TreeKEM: a key rotation after membership changes is O(log N) instead of O(N).
• Every user device is a separate leaf in the MLS tree. This makes multi-device support work without weakening forward secrecy.
• A 1-on-1 chat is an MLS group of two. There is no separate "secret chat" encryption path.

What the server sees

The server never sees plaintext message or media content. To deliver messages it does need metadata:

• user and device identifiers,
• chat routing and group membership,
• MLS epochs and message sequence numbers,
• timestamps and sizes,
• security logs without message content.

We document these fields deliberately so you never have to assume "nothing is visible". Privacy is a concrete contract, not a slogan.

Attachments

• Files, photos, and videos are encrypted on the client before upload. Only ciphertext is stored server-side.
• Per-media encryption keys travel inside encrypted MLS messages, not as a separate server object.
• Thumbnails are generated and encrypted on the client.

Calls

• Voice and video calls run through a self-hosted LiveKit SFU, not through a third-party commercial service.
• Call media is additionally E2E-encrypted over WebRTC using insertable transforms; the SFU routes packets but cannot decrypt them.
• Call transport is layered: direct UDP, TURN/UDP, TURN/TCP 443, TURN/TLS 443. This is a response to unreliable networks, not a promise of censorship circumvention.
• Relay capacity sits close to users, so TURN paths stay usable when direct UDP is not available.

Multi-device

• Each device registers independently with its own MLS key material.
• A new device does not gain access to prior-epoch history — this is an intentional property of MLS, not an implementation limit.
• Revoking a device is more than a logout: the device is removed from the MLS tree, so future traffic is unreachable even if old keys later leak.

Invite-only registration

Gating signup behind invites is part of the security model, not a marketing gimmick:

• it controls growth and infrastructure load,
• it reduces spam and raid-style pressure,
• every new account is linked to the issuer for audit purposes.

The inviter-invitee link is used for audit and abuse control, not as a public social graph.

Threats outside our model

We state plainly what Svoi does not protect against:

• compromise of the user's own device (malware, physical access, OS-level privilege),
• social engineering targeted at a specific user,
• traffic analysis by a network provider with the motive and resources to target a specific person,
• leaks via screenshots, forwarding to other messengers, or a camera pointed at the screen.

These are not fine-print disclaimers. They are the boundary you need to know in order to use the product with clear expectations.

On-device storage

• On native clients the local database is encrypted with a key derived from the user's password or biometrics.
• The web client uses an OPFS-backed store; storing secrets in a browser has its own limitations, and we document them separately inside the web app's settings.

Responsible disclosure

If you find a vulnerability, email security@svoi.red. We acknowledge receipt within 72 hours and respond substantively, not with boilerplate.