Why didn't we reuse an existing federated protocol?
The federated protocols that already exist are well built. Even so, we chose to build our own, simpler and lighter. Here is why.
We evaluated the most mature federated messaging protocols and chose our own implementation instead. Not out of arrogance: because of weight, pace and metadata.
A mature federated protocol vs LOOKLOCK
| Aspect | Federated protocol | 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 server for those protocols needs a full database and plenty of RAM and CPU. Our node is a single dependency-free Python file: it fits on a Raspberry Pi.
2. Simpler encryption
They use stateful group cryptography (device keys, cross-signing): powerful, but a lot of surface to maintain and audit for what we need.
3. Less metadata
Federation replicates events across servers and exposes metadata (who talks to whom, memberships, room state). In LOOKLOCK the hub is only a directory, and the node holds sealed envelopes it cannot open.
4. Control and independence
Our own implementation lets us evolve at our own pace (invite-only registration, your own node, ephemeral messages) without waiting for someone else's standard.
Honestly: what we give up
To be fair: those protocols do three things very well that we do not match yet: forward secrecy, device verification and a huge client ecosystem. We say it here because we would rather you heard it from us.