Privacy & security
Server security
The useful question about a messaging server is not how well it is defended, but how little it is worth attacking. This page describes what the Keylane relay holds, and what an attacker who took it over completely would actually get.
What the relay is for
The Keylane server is a router, not a repository. Its job is to accept a sealed envelope from one device and hold it until the destination device collects it. It has no role in encrypting, decrypting, or interpreting anything it carries.
This is a deliberately unambitious design. A server that cannot do much is a server that cannot be made to do much on someone else’s behalf.
What the relay stores
| Data | Held? | Retention |
|---|---|---|
| Message ciphertext | Yes, sealed | Until acknowledged, max 14 days |
| Destination device ID | Yes | Until acknowledged, max 14 days |
| Sender identity | Not recorded | — |
| Message content | Not readable | — |
| Contact lists / social graph | No | — |
| Phone numbers, emails, names | Never collected | — |
| Public prekey bundles | Yes | Until consumed or replaced |
| Encrypted attachment blobs | Yes, sealed | Until TTL expiry |
| Message history archive | No | — |
Why there is no sender record
Most secure messengers encrypt content well and still write a row saying user A sent something to user B at 21:14. Aggregated over months, those rows are the social graph — often more revealing than the messages themselves.
The Keylane spooling database does not record who sent a message. An envelope carries a destination and a payload. The consequence is concrete: a database dump, whether obtained by a court order or by an intruder, does not reconstruct who talks to whom.
Spam prevention normally requires knowing the sender, so Keylane uses hashed capability tokens instead. The server enforces strict global rate limits on unknown senders; presenting a valid capability token lifts that limit without revealing who is presenting it.
Retention
An envelope is deleted the moment the recipient device acknowledges receipt with a cryptographic watermark. If a device never comes back — uninstalled, lost, switched off — the envelope is purged when its 14-day time-to-live expires.
There is no archive tier behind this and no backup that outlives the TTL. Once the envelope is gone, delivery has permanently failed, and neither we nor anyone compelling us can produce it.
Attachments
Files are encrypted on the sending device with a freshly generated symmetric key before upload. The relay returns an unguessable 32-byte identifier and stores an opaque blob — it does not learn the file type, the contents, or who uploaded it.
The identifier and the decryption key travel to the recipient inside the end-to-end encrypted message payload, never alongside the blob. The relay holds a locked box and no key, and purges it at TTL expiry.
What a full compromise yields
Assume an attacker gains complete control of a Keylane relay — root access, database, and live traffic. They obtain:
- Sealed envelopes currently in flight, which they cannot decrypt.
- Destination device identifiers for those envelopes, and the times they were collected.
- Public prekey bundles, which are public by design.
- The IP addresses of devices connecting while they hold the server.
They do not obtain message content, past conversations, sender identities, or the historical social graph, because the relay never held any of them.
An attacker who controls the relay and observes it over time can perform traffic analysis: correlating connection timing and volume to infer which devices are likely communicating. Zero-knowledge routing raises the cost of this substantially, but it does not eliminate it. See the threat model.
Operational security
- RAM-first handling. Envelopes are held in memory wherever practical and written to disk only when spooling requires it, shortening the window in which data exists at rest.
- Transport. All connections are TLS-encrypted, in addition to the end-to-end encryption of the payload.
- No access logs tying users to content. Operational logs exist for availability and abuse rate limiting; they are not a message archive and are not retained as one.
- Jurisdiction. The public relay is operated by Livotov Labs Ltd., a Bulgarian company subject to EU law. Requests from authorities are handled as described in the transparency report.
Federation and trust between servers
Keylane instances exchange messages with each other, which raises a reasonable question: does using Keylane mean trusting every server in the network?
No. Encryption is end-to-end between devices, not between servers. A relay forwarding an envelope to another instance forwards a sealed envelope; the receiving instance is no more able to open it than the sending one. Federating with an instance means agreeing to carry its traffic, not extending it any ability to read yours.
Each instance publishes its capabilities at /.well-known/keylane. The public network’s descriptor is at keylane.app/.well-known/keylane.
Running your own relay
If the trust model above is still more trust than your situation allows, the answer is to operate the relay yourself. Self-hosting is in development; see server setup for scope and status.