Why don't we use Matrix?
Matrix is a great protocol. Still, we chose to build our own, simpler and lighter. Here's why.
We evaluated Matrix (federated messaging with Olm/Megolm encryption) and chose our own implementation instead. Its strengths —mature federation, forward secrecy, device verification— come with a complexity and weight that don't fit our three goals: easy to self-host, easy to audit, and strictly zero-knowledge on the node.
Matrix vs LOOKLOCK
| Aspect | Matrix | LOOKLOCK |
|---|---|---|
| Server | Heavy homeserver (Synapse/Dendrite) + PostgreSQL | A single Python file (~11 KB), no dependencies |
| Group encryption | Olm/Megolm: powerful but stateful and 'unable to decrypt' | ECIES fan-out: one copy per member, no room state |
| Metadata | Federation replicates events and exposes memberships/relations | Central = directory; the node only stores sealed envelopes |
| Self-hosting | Requires resources and maintenance | Anyone spins up their node on a cheap VPS in minutes |
The reasons, one by one
1. Server weight
A Matrix homeserver needs PostgreSQL and plenty of RAM/CPU. Our node is a single dependency-free Python file that runs on the cheapest VPS. It's the key to 'bring your own node'.
2. Simpler encryption
Matrix uses Olm/Megolm (Double Ratchet + stateful group keys, device keys, cross-signing): powerful but complex, with the usual 'unable to decrypt' failures. We encrypt each message once per member's public key. No session state, no room-key rotation. Easier to audit.
3. Less metadata
Matrix federation replicates events across servers and exposes metadata (who talks to whom, memberships, room state). In LOOKLOCK the central server is just a directory and the node stores sealed envelopes it cannot open.
4. Control and independence
Our own implementation lets us evolve at our own pace (invite-only registration, per-conversation node, rooms, business accounts) without being tied to the Matrix spec or roadmap.
Honestly: what we give up
Matrix does three things very well: forward secrecy (Megolm ratchet), device verification, and mature federation. With our model, today we do NOT have forward secrecy: a key leak could expose history. We're implementing the Double Ratchet to close that gap. Key verification between users (a safety number) is already available. We explain it in detail on the security page.