Architecture
Which machines make up LOOKLOCK and what each one does. Three pieces: a central server acting as a directory, one or more nodes holding encrypted mailboxes, and the user devices, the only ones that see the plaintext.
Central server
The network directory
It is a Windows Server VPS with IIS, PHP 8.4 and MySQL 8.0. It hosts the looklock.chat website and the app API, and acts as a DIRECTORY: it manages accounts, public keys, which node hosts each user, and the public deposit tokens. Today it can also relay encrypted messages, but the project is moving that function to the nodes (federation). It never sees plaintext.
Node servers
Encrypted mailboxes (bring your own node)
One or more Linux VPS with Python 3 running llnode.py: a single file, with no external dependencies, with its own SQLite. Their role is to be MAILBOXES: they store ENCRYPTED messages and files separated per user. Anyone can set one up, hence the motto "bring your own node". The operator can never read what it stores.
User devices
Where the secret lives
The Android app (Flutter) is the only piece that stores the private key (SK) and the plaintext. It encrypts and decrypts LOCALLY, inside the phone itself. This is the zero-knowledge model: the servers never see the content, only sealed blobs they cannot open.
Machine summary
| Machine | OS / Software | Role |
|---|---|---|
| Central | Windows Server, IIS, PHP 8.4, MySQL 8.0 | Web, API and directory (accounts, public keys, deposit tokens) |
| Node | Linux, Python 3, llnode.py, SQLite | Mailbox: stores encrypted messages and files per user |
| Device | Android (Flutter) | Stores the private key; encrypts and decrypts locally |
Flow diagram
Device A encrypts the message, asks the central server (directory) which node hosts the recipient, and deposits the encrypted envelope in that node. Device B picks it up from its mailbox and decrypts it locally. The central server never sees the content.