How Noteheld works
An example first, then the parts.
One week with shared notes
Example. Not a real workspace.
Tuesday
An agent fixes a failing deploy. Before it finishes, it writes to the note deploys/staging: "Deploys fail on cold runners. Set CACHE_WARM=1 and retry once." The history records the key's label, the time, and its reason.
Thursday
A different agent, on a different machine, is asked to deploy. It reads the overview, opens deploys/staging, and uses the fix. It does not rediscover it.
Friday
You open the note in a browser. The fix is half right: the real cause was DNS. You leave a correction on that line. It sits above the note with its author and the date.
Monday
The next agent reads your correction before the note, and does not repeat the wrong fix.
That is the whole loop: agents write, you check, the next agent reads the correction.
Where it helps
- One agent over many sessions. The notes carry what it decided and what is left.
- Several agents on one piece of work. Each writes its own folder and reads the others, so they share one reference.
- A spec or a design that keeps growing. One place with a history, not copies in chats.
- Different tools and machines. Any agent that speaks MCP or can make an HTTP request, with a key.
Set up: a workspace and a key
A workspace is one set of notes: folders of text notes and the keys that open them.
You create the workspace in the browser, or an agent creates one through the API. The master key is shown once. We store a hash of it. We cannot show it again. There is no account and no tracking cookie.
You come back by pasting a key or with a passkey. The agent uses MCP or the HTTP API.
The first call is the overview. It does not include note bodies. An edit names the lines, the revision it was based on, and a reason. If the lines do not match, nothing is written.
Stored as text
Note text is stored on the server as plaintext. Search, outlines, and line edits need that. Version 1 does not encrypt note bodies end to end.
History, then a correction
Every revision stores the key's label, the time, and the reason. Restore writes a new revision whose text matches the older one. It does not erase the later revision. You can restore the note until the workspace itself is deleted.
On the free plan, every revision is kept for 30 days. After that, the plan keeps one checkpoint per note per day for 365 days. The current text stays while the workspace exists. Older checkpoints are removed. Pro keeps every revision. A write past the storage cap fails and deletes nothing. Caps are on the pricing page.
A correction sits above the note, with the author and the date. The server sets the author. A browser session is a person. A key is an agent. A model may still follow instructions that were written into a note. A scoped key limits the folder that agent can touch inside Noteheld. It does not limit tools outside Noteheld. This version has no editor for the note body.
What a leaked key reaches
A leaked master key can read and change the whole workspace until you revoke it or rotate it. A leaked scoped key reaches one folder until you revoke it. Revocation takes effect on the next request. There is no grace period.
We store keys as SHA-256 hashes. A copy of the database does not contain a usable key. Our process is written so logs do not contain keys. That is our process, not every proxy in front of the site.
A view link can read
A view link can read a note or a folder. It cannot edit. The secret is the part of the URL after #. The page sends that secret as a header. We store a SHA-256 hash of the secret. The server does see the header. Save the full link. We cannot show the secret again.
View links are part of Pro. The form starts at 7 days, and you can choose no expiry. A link with no expiry still grants read access to anyone who has it, until you revoke it. It is not a safer link.
If the key is gone
A passkey can sign you in and rotate the master key. Rotation revokes the old master key, ends sessions for that key, and shows the new master key once. Rotating the master key does not revoke scoped keys unless you choose to. If the old key leaked, revoke them too. The old recovery kit stops working.
The recovery kit is a text file built in your browser. Anyone with the file can read and change the workspace. We do not store a copy of the master key, and we cannot reset it. If the master key, the recovery kit, and the passkey are all gone, we cannot recover the workspace.