Frequently Asked Questions

Yes. All direct messages and small server conversations on Renwer are protected with end-to-end encryption (E2EE) using the Messaging Layer Security (MLS) protocol.

MLS is an open standard designed for secure group messaging. It provides:

• End-to-end encryption — messages are encrypted on your device before they leave it. Renwer's servers only ever see ciphertext and cannot read your messages.
• Forward secrecy — encryption keys are regularly rotated, so even if a key is compromised in the future, past messages remain protected.
• Post-compromise security — if a device is compromised, the protocol automatically heals over time as keys rotate, limiting the window of exposure.

This means your conversations are private by design — not by policy, but by mathematics. We couldn't read your encrypted messages even if we wanted to.

When an encrypted message is sent on Renwer, the sender's client takes a cryptographic hash of the plaintext content and includes it alongside the ciphertext. When recipients decrypt the message, their client compares the hash of the decrypted text against the hash provided by the sender.

If the hashes match, the message is verified — what you're reading is exactly what the sender wrote. If they don't match, you'll see a hash mismatch warning.

What causes a mismatch?

A hash mismatch means the plaintext hash the sender provided doesn't correspond to the actual message content. This could indicate the sender is using a modified client or that something has been tampered with between encryption and delivery.

How does this affect reports?

Because Renwer uses E2EE with forward secrecy, we cannot retrieve the content of encrypted messages ourselves. When a user reports a message, we rely on the reporter to provide the plaintext. We then verify this plaintext against the sender's original hash.

If the hash doesn't match, there are two possibilities:

• The sender is faking their hashes to conceal what they actually wrote
• The reporter is providing fabricated plaintext to file a false report

Since we have no way to determine which case is true, reports with mismatched hashes cannot be accepted. We err on the side of caution to prevent both abuse and false accusations.

What should I do?

If you see hash mismatch warnings on messages from another user, exercise caution. That user may be running a modified client that doesn't produce accurate hashes. You engage with users who mismatch their hashes at your own risk, and we strongly recommend avoiding sharing sensitive information with them.

Not yet, but we're actively working on it. We plan to support secure device-to-device transfers of your decrypted message history, so a new device can access the full history of your DMs and servers from before it was added to your account.

The transfer will require access to an existing device that already holds the message history — it acts as the source for the secure handoff to the new one.

In the meantime, all devices need to be signed in before new conversations begin in order to be included in the encryption group from the start. Messages sent before a device joins a conversation won't be available on that device until history transfer is supported.