Search, version history, trash and export, all designed around a server that only ever sees ciphertext
For a long time it felt like you had to choose: a good notes app, or a private one. The polished apps could read everything you wrote. The encrypted ones were often built for one person, on a desktop, with an export button that was more of an apology.
Notes are the core of lockORG, a zero-knowledge workspace for individuals and small teams. Everything is encrypted on your device before it reaches the server. That one rule shapes almost every feature, sometimes in ways you would not expect.
Built for the phone first
The notes module starts on the smallest screen and grows:
Phones show one pane at a time: the note list, then the editor with a back button. Folders and tags open in a bottom sheet, and “New note” is a floating button within thumb reach.
Tablets show the list and editor side by side.
Laptops add a library sidebar with pinned notes, folders and tags.
The editor is one scrolling column with a formatting toolbar that stays pinned while you scroll, and a small status pill that shows autosave progress. On tablet and up, you can open a split view with Markdown source on one side and a live preview on the other.
Search happens on your device
A server cannot search what it cannot read. So in lockORG, search is entirely client-side: titles and previews are searched instantly, and note bodies through an in-memory index of decrypted text that is cleared when you lock the app.
The upside is that your queries never leave your device either.
Images get their own keys
Paste, drop or upload an image into a note and it is encrypted under its own random key before upload. That key travels only inside the encrypted note itself. The server stores a sized blob and never sees the key or the picture.
There is a subtle privacy detail here too: any image link in a note that is not an encrypted lockORG image is shown as a placeholder and never fetched. Fetching it would tell whoever planted the link exactly when the note was read.
Trash and version history, the encrypted way
Deleted notes go to a trash for seven days, where you can restore them or delete them for good. Interestingly, the server never purges the trash on its own. A server deleting rows is exactly what lockORG’s integrity check exists to catch, so expiry is handled on your device.
Every note also keeps its last fifty versions. Open one read-only, restore it, or drop it. Versions are encrypted just like the note.
And if a save cannot reach the server, because you are offline for example, the editor keeps a draft and offers it back next time.
The exit door matters
A notes app that traps your writing is not really yours. lockORG can export a whole workspace’s notes as a zip: every note as Markdown (with front matter for title, folder, tags and pin) and as standalone HTML, with images decrypted and the folder tree preserved.
The export page states plainly that the archive is not encrypted. Once it is on your disk, its safety is in your hands.
Import works the other way. Bring a lockORG export, or any zip of Markdown and HTML files, such as an Obsidian vault or an export from Joplin, Notesnook or Bear. Folders become folders, front matter supplies titles and tags, and everything is encrypted on the way in, just like anything you type.
Folders, tags, templates and pins
The rest is what you would expect from a serious notes app, with one twist: it is all encrypted.
Folders nest as deeply as you like.
Tags have colours, and the colours are encrypted.
Templates let you start new notes from a saved structure.
Pins keep important notes at the top, and the pinned flag itself is encrypted, so the server cannot tell which notes you care about most.
What we chose not to build
There is no real-time co-editing, and that is on purpose. Live cursors would mean either a server that sees your content or a far more complex protocol. Notes autosave with a visible save state and keep drafts if a save fails. We chose privacy over cursors.
Beyond notes
Notes sit alongside kanban boards (drag and drop with pointer or keyboard, with notes linked to tasks), a private todo list and a calendar-first journal. The todos and journal are encrypted under your personal key, so not even your workspace admin can read them. Cmd/Ctrl+K searches across every module, and the app comes in twenty-two themes, each in light and dark, and installs to your home screen.
Top comments (2)
Nice touch on refusing to fetch non-lockORG image links; that's the one most E2EE apps miss. One leak that's left: the server still sees each note's ciphertext size and when each of the fifty versions was saved, which says a fair bit about which notes are active and roughly how long they are. Padding note blobs to size buckets (say, the next power of two) hides most of the length signal cheaply. How does the integrity check catch deletions: a signed list of note IDs per workspace?
Thanks for your feedback, glad you noticed the image rule. Fetching a planted URL is a read receipt, so it gets a placeholder instead.
You're right about sizes and timing. It's documented as an accepted risk: the threat model says the server sees each version's author, timestamp and ciphertext size, along with counts, folder/board structure and ordering. Hiding metadata is an explicit non-goal for v1, but the cheapest part is worth doing, and I'm looking at it for after launch. Padding plaintext before encryption hides the length signal, and I'd also encrypt empty optional fields, which currently show as empty. I'd lean towards Padmé over next-power-of-two: it's ≤12% overhead instead of up to 2×, which matters because images count against a storage quota by size. It changes the ciphertext format, so it would ship as a protocol version bump with new test vectors.
Timing and structure I'm leaving alone on purpose. Hiding when versions are saved means batching or cover traffic, which fights autosave and risks lost edits. Hiding which note sits in which folder, or how many rows exist, means the server can no longer filter, paginate or cascade deletes. At that point it's a different architecture, so those stay documented rather than half-solved.
On deletions: it's not a signed list. Each workspace keeps a manifest of row IDs (notes, folders, tasks, tags…), encrypted under the workspace key, so it's AES-GCM-authenticated. Only key holders can write it, and the server can't read or forge it. Members update it on every create and delete, with a plaintext sequence number for compare-and-swap. The integrity check fetches every listing and reports IDs that are listed but not served. Devices pin the highest seq they've seen, so a rolled-back manifest is flagged. I skipped signatures because they'd need every member to be a trust anchor for every other, and AEAD under the shared key already proves a member wrote it. Personal data (todos, journal) gets its own manifest under the user's personal key.
Two honest caveats: it detects rather than prevents, and right now it runs only when a member opens Settings → Security → Integrity and checks. Note versions aren't in the manifest either, so the server could silently drop an old version (never the note itself).