How Lovele protects your conversations

Lovele is a social app: private chat, calls, a feed and stories for your friends. It also has a rewards program, where you collect points for activity and can redeem them. The rewards program is funded by advertising. Advertisers pay Lovele for ad space. They never pay users directly, and they never get access to your conversations. The details are in the Points program terms.

Earning is optional. You can switch it off at any time in Settings. With earning off:

• we never send your advertising ID;
• offerwalls and partner trackers are off;
• ad network banners may still appear, but without any advertising ID.

Your messages and calls are never used for advertising. Their content is end-to-end encrypted, so it is not available to us, or to any partner, in the first place.

Every Lovele chat is end-to-end encrypted with Messaging Layer Security (MLS, RFC 9420), the IETF standard for encrypted group messaging. A one to one chat is an MLS group with two members, so there is a single protocol to analyse, not two. Messages are encrypted on the sender's device and decrypted only on the recipients' devices. The server temporarily queues and forwards ciphertext until delivery. Not even Lovele can read your messages.

Post-quantum hybrid keys

Key exchange uses X-Wing, a hybrid key encapsulation mechanism that combines X25519 with ML-KEM-768 (FIPS 203). An attacker has to break both to recover a key, so a conversation stays protected as long as either one holds. This is aimed at "harvest now, decrypt later": recording encrypted traffic today in the hope of decrypting it with a future quantum computer. Groups use the hybrid suite MLS_128_MLKEM768X25519_AES128GCM_SHA256_Ed25519 from the IETF draft on post-quantum MLS ciphersuites, with Ed25519 signatures. Message encryption itself is symmetric (AES-128-GCM), so a message costs the same with post-quantum keys as without them.

Large groups

Post-quantum keys are large: a hybrid key package is about 2.7 KB, against about 320 bytes for a classical one. In a group with a thousand members, a fully hybrid key tree would make some membership changes several megabytes long. Large groups therefore use the amortized post-quantum combiner (IETF draft-ietf-mls-combiner). An everyday classical MLS group carries messages and frequent membership updates. A companion post-quantum group is rekeyed periodically, and its exporter secret is injected into the everyday group as a pre-shared key (PSK). Message keys keep depending on post-quantum key material, while ordinary updates stay small.

Forward secrecy and post-compromise security

MLS derives a separate key for every message, and each key is deleted after use. Someone who copies a device's current state cannot decrypt earlier messages with it. That is forward secrecy. Devices also send regular, automatic key updates, and every membership change starts a new epoch with new secrets. Once an update goes through, an attacker who copied an earlier state is locked out again. That is post-compromise security. So that messages arriving out of order still open, a device keeps at most 8 unused keys per sender and the secrets of the 2 previous epochs; everything else is erased as soon as it has been used.

Device keys, identity and no downgrade

Each phone and browser is its own member in your conversations, with its own keys generated on that device. Your account has an identity key that signs a certificate for each of your devices, so your contacts' apps can check that a new device really belongs to you. The ciphersuite is fixed when a group is created and is part of the group state that every member checks. Nobody, including our server, can switch an existing group to weaker cryptography: clients reject key material for any other suite.

Photos, videos and files

Every file is encrypted on your device with its own random key before it is uploaded. Our storage holds only the encrypted file. The file's key travels inside the end-to-end encrypted message, so only the people in the chat can open it. Edits, deletions and pins are sent the same way, as encrypted control messages inside the group.

Implementation

The web, Android and iOS apps share one MLS core built on the open-source ts-mls library, with our own cryptography provider: the noble libraries and libsodium on phones, and the noble libraries in the browser, where WebCrypto is used only for random numbers and to encrypt the local store. The core runs against all 785 official RFC 9420 test vectors published by the MLS working group, our provider is cross-checked byte for byte against the library's reference provider, and every change is tested against OpenMLS, an independent MLS implementation: both must create, join and update the same post-quantum group and read each other's messages.

If you use the app, your phone is your primary device. Lovele allows one phone per account: signing in on a new phone signs the old one out, and your contacts stop encrypting to it.

Linking the web with a QR code

To use Lovele in a browser, open it on the web and scan the QR code it shows with your phone. The phone adds the browser to your conversations as a new device and sends it the last 90 days of text, end-to-end encrypted from the phone to the browser. Our server relays the transfer but cannot read it.

Web-only accounts

If you don't use the app, your browser can be your primary device. You then get a 24-word recovery key. Write it down and keep it somewhere safe: it is how you restore your account's keys, and Lovele does not have a copy. Clearing the browser's data deletes the history stored in that browser, so Lovele asks the browser for persistent storage and reminds web-only users about it.

Up to 5 devices, and you see every new one

An account can have up to 5 devices: the primary one and up to 4 linked ones. A linked device that is not used for 30 days is unlinked automatically. Every device on your account is notified when a new one is linked, so a QR code scanned by someone else does not go unnoticed. A new device sees only messages sent after it joined, plus the history transfer described above.

Your app gets your contacts' keys from our server. Verification lets you check that the server delivered the right ones, without having to trust us.

Security code and QR

Every contact has a 60-digit security code, shown as 12 groups of 5 digits, and a matching QR code. Your device computes it from both people's identity keys, and it is the same on both sides. Compare it in person or over another channel you trust, or scan your contact's QR code with your camera. On the web you can also paste a code to compare it. If it matches, mark the contact as verified and a verified mark appears in the chat. In groups, every member has their own code in the group settings.

Key-change warnings that don't depend on the server

The first time your device sees a contact's identity key, it remembers it. If the key later changes, your device itself shows "security code changed" in the chat, whatever the server says. For a contact you verified, a notice also appears above the message box, so you can compare codes again. A key change never blocks sending: the decision stays with you.

Voice and video calls, one to one and in groups, are end-to-end encrypted. Media goes through LiveKit media servers, which forward encrypted frames: LiveKit end-to-end encryption, built on WebRTC insertable streams (RTCRtpScriptTransform in Safari). The media servers route the call but cannot decode its audio or video.

A new call key on every join and leave

Each call uses a random 32-byte media key. It is rotated every time someone joins or leaves, so a person who left cannot follow the rest of the call. The key is distributed over the same end-to-end encrypted channel as your messages, and signed by the device that created it. Our server never sees it.

Per-device call keys

Every device also has its own call key: in the Android Keystore, in the iOS Keychain, or as a non-extractable WebCrypto key in the browser. It is certified by your account identity key, and call keys are sealed to it with HPKE (RFC 9180). It can open a call's media key and nothing else, never your messages. That is what lets you answer a call quickly from the lock screen.

No unencrypted fallback

If a browser cannot encrypt call media, Lovele does not start the call. Firefox is not supported for calls for this reason. Lovele and its media servers do not record calls and cannot decrypt call media. Like any end-to-end encryption, it cannot stop a participant, or a compromised device, from recording what is played or shown on that device.

End-to-end encryption protects what you say. It does not hide everything about how you use Lovele. This is what our servers see, and what they don't.

What the server needs to know

• Which account and device is connected, and which conversation each encrypted message goes to. Without that, nothing can be delivered.
• Who belongs to which group, so that only members can add or remove people.
• When a message is sent, and the size of the encrypted message.
• Delivery and read markers, kept only to the hour, your read receipt and typing settings, mute and archive state, the media timer of a chat, and when a contact's security key changes.
• For calls: who takes part, when they join and leave, and how long the call lasts. This also appears as a call entry in the chat.
• For rewards on chat activity: how many messages you send per day in a conversation. Never what they say.

What the server does not see

• Message content, photos, videos, files, reactions and edits.
• The sender inside a group message: it is encrypted together with the content. The server still knows which account was connected when a message was uploaded.
• Call audio, video and call keys.

Deleted after delivery

Encrypted messages are deleted from our servers once they have been delivered. Your history lives on your devices.

IP addresses

We keep IP addresses for 7 days, for security and fraud prevention, and then delete or truncate them. IP addresses are not logged with messages or calls.

Push notifications

Push notifications never carry message content. By default they show who wrote to you, and Settings has an option to hide the sender's name as well. They are delivered through Google Firebase Cloud Messaging, Apple Push Notification service or Web Push, which see that a notification reached your device.

Cloudflare

Lovele is served through Cloudflare, which protects the site against attacks. Cloudflare sees your IP address and the requests your device makes to Lovele, with their timing and size. It does not see message content, which is encrypted before it leaves your device.

Call media servers

The LiveKit media servers that relay calls see the IP addresses of the participants, their Lovele user IDs (not their names), and the timing and volume of the encrypted media. They cannot decode the call.

End-to-end encryption is legal in the European Union and in Romania, where Lovele is based. No law requires us to hold a copy of your keys, and we don't: there is no key escrow and no back door.

Under the European Electronic Communications Code, transposed in Romania by Law 198/2022, Lovele's chat and calls are a number-independent interpersonal communications service, the same category as other messaging apps. Romania has no general data retention law for these services: the earlier retention laws were struck down by the Constitutional Court (decisions 1258/2009 and 440/2014). EU and Romanian law (the ePrivacy Directive, art. 6, Law 506/2004, art. 5, and the GDPR) require traffic data to be deleted or anonymised once it is no longer needed.

Requests from authorities

We answer lawful judicial requests, and only with the data we hold. That never includes the content of messages or calls, because we don't have it. When an authority orders specific data to be preserved, we keep that data as the order requires. European Production Orders (e-Evidence), which apply from 18 August 2026, work the same way: we can hand over only what we hold.

What we keep, and for how long

Message and call content

Never held. It is end-to-end encrypted on your devices.

Encrypted messages

Text messages until they are delivered, then deleted. Encrypted photos, videos and voice messages until they expire, never longer than 24 hours.

Message and call keys

Never held. They stay on your devices.

IP addresses

7 days, for security and fraud prevention (legitimate interest, GDPR art. 6(1)(f)), then deleted or truncated.

Chat and call metadata

Only what delivery, your chat list and rewards need. Call records: 90 days. Daily message counts: 60 days. Message times are cut to the day 35 days after a message expires.

Redemption and accounting records

For the period Romanian accounting law requires, with your identifying details removed if you delete your account.

Identity verification

The result: while your account exists, deleted with it. The ID images and videos: kept by Didit for 6 months, never copied to us.

Account data

Until you delete your account.

The full list is in our Privacy Policy.

What Lovele protects you against

• Anyone reading traffic between your device and our servers, such as a network operator or the owner of a Wi-Fi network.
• A breach of our servers: an attacker would find metadata and encrypted messages waiting for delivery, not message content or keys.
• Recording traffic today to decrypt it later with a quantum computer.
• Keys copied from a device being used to read earlier messages, or later ones after the next key update.
• A server that swaps a contact's keys: your device notices the change on its own, and the security code shows it.
• A server that tries to move a group to weaker cryptography.

What it does not protect against

• A compromised device. Malware, or someone holding your unlocked phone, can read what is on the screen and what is stored on the device.
• Screenshots and forwarding. Encryption ends on the recipient's device. A recipient can photograph the screen, take a screenshot or pass your words on.
• Metadata visible to the network. That you use Lovele, when, from which IP address, and the size and timing of your traffic are visible to your network, to Cloudflare and to us, as described above. A VPN can hide your IP address from us and from Cloudflare.
• A contact you never verified. If keys were substituted before your device first saw them, only comparing security codes reveals it.
• A lost recovery key. On a web-only account we cannot restore your keys for you.

Independent review

The ts-mls library has not had a formal security audit, and our implementation has not yet been reviewed by an external auditor. Audit reports will be linked here when they exist.

Reporting a vulnerability

If you find a security problem, write to contact@lovele.app. Please give us a reasonable time to fix it before you publish it.

End-to-end encryption (E2EE)

Content is encrypted on the sender's device and decrypted only on the recipients' devices. Servers in between see ciphertext.

MLS

Messaging Layer Security, RFC 9420. The IETF standard for end-to-end encrypted group messaging, built on a tree of keys (TreeKEM).

Epoch

A period of an MLS group with one set of secrets. Every key update or membership change starts a new epoch.

Forward secrecy

Keys stolen today cannot decrypt messages from the past, because the keys that protected them are already deleted.

Post-compromise security

After a key update, an attacker who copied an earlier state can no longer read new messages.

X25519

A widely used elliptic-curve key exchange.

ML-KEM-768

A post-quantum key encapsulation mechanism standardised by NIST as FIPS 203.

X-Wing

A hybrid key encapsulation mechanism that combines X25519 and ML-KEM-768. A key stays secret while either one holds.

PSK

Pre-shared key. A secret injected into an MLS group from outside, here from a companion post-quantum group.

HPKE

Hybrid Public Key Encryption, RFC 9180. A standard way to encrypt a small secret to a public key.

Security code

A 60-digit number derived from two people's identity keys. If both sides see the same code, nobody has swapped the keys in between.

Frame encryption

Encryption of each audio and video frame on the device before it is sent, so media servers relay it without decoding it.

Metadata

Data about a communication rather than its content: who, when, how much, from where.

Key escrow

A copy of users' keys held by a provider or a third party so content can be decrypted on request. Lovele has none.