Version history

Version history shows how a note got to its current state. It opens as a full-screen tab with a timeline of changes on the left and a comparison of any two of them on the right. Every entry can be read and compared. Most can be restored, and the conditions are listed under Restoring a version.

History is built from two separate sources. Knowing which one you are looking at explains most of the behavior on this page.

Source	Where it comes from	Where it is stored	Needs sync
Autosave snapshots	The app copies a note’s previous content just before it writes a new version	<vault>/.jotura/history/ on the current machine	No
Synced versions	One entry per push of that note to the server, decrypted from your own sync data	The sync database for the unit that owns the note	Yes

Synced versions are the ones that carry an author, survive a reinstall, and appear on every machine signed into the same account. Autosave snapshots are local to one computer and are thinned aggressively. Synced versions require cloud sync, which is a paid feature, so see pricing for what that costs.

What is kept

Synced versions

Every time the desktop app pushes a note to the server, that push becomes a version in the note’s history. Each one records the time, the size, the author, and whether it was an ordinary edit, a delete, or a restore.

Version numbers are vault-wide, not per note. The number shown as v12 is the vault’s manifest version at the moment of the push, and a single push commits every note that changed at once. Two notes saved together therefore share a number. A note left alone for a while jumps from v3 to v12. Gaps in a note’s timeline are normal and do not mean anything is missing.

A synced version’s timestamp is the time the server accepted the push, not the time you typed. An edit made offline is stamped when it eventually synced. Autosave snapshots are different: they are stamped locally at the moment of the write.

Reading an older version needs the network

Only the index of synced versions lives on your machine. The content of each past version stays on the server as an encrypted blob, and selecting a version downloads it on the spot. That means the timeline is readable offline but its contents are not. While you are offline, or when your sign-in cannot be refreshed, selecting an older synced version shows a network error in the comparison pane instead of a diff.

Retention

Superseded content is reclaimed after three years. The current content of a note is never reclaimed, however old it is, for as long as the note exists.

The sweep that does this is deliberately quiet. Five minutes after you open a vault, an owner device asks the server to reclaim the encrypted blobs behind superseded versions older than the cutoff. It then removes those rows from the local index, so the timeline stops listing content that is no longer stored. Three conditions gate it, and all three must hold:

Condition	Why it matters
The device is the owner of the vault or share	Members and viewers never sweep. The server refuses them anyway.
You are signed in and the vault is registered with the server	Without an account there is nothing to ask.
Someone opened the vault	The sweep is scheduled once per vault open. A vault nobody opens keeps every superseded version indefinitely.

A version that has already been reclaimed still fails gracefully. Selecting one shows This version is past the retention window and can no longer be viewed. in the comparison pane rather than an error.

Because the index is rebuilt from your encrypted sync data, it follows you. Sign in on a new machine, restore the vault, and the full timeline comes with it. See Sync and sharing for how that works, and the security page for the underlying design.

Autosave snapshots

Before any write the app makes to a Markdown note, Jotura copies the content that was on disk into <vault>/.jotura/history/. The layout mirrors your vault, so a note at notes/foo.md keeps its snapshots in .jotura/history/notes/foo.md/. A snapshot is skipped when the content is identical to the newest one already recorded, so repeated saves of unchanged text do not pile up.

Snapshots are thinned every time a new one is recorded. The rule depends on how old each snapshot is.

Age of the snapshot	What survives
Under 24 hours	Everything.
24 hours to 7 days	The newest snapshot in each hour.
Older than 7 days	The newest snapshot in each day.

Two rules sit on top of that. The newest snapshot is always kept regardless of its bucket. Thinning walks the list newest first and stops once 50 snapshots have been kept, so a note never holds more than 50.

Renaming a note moves its snapshot folder along with it, so history is not lost to a rename. Deleting a note leaves its snapshots in place, so restoring the note from the trash picks its history back up.

Snapshots are recorded only for edits made in this app’s editor and for the other writes the app performs directly. Three cases produce no snapshot:

• An edit made by another editor, by a script, or by the jotura command-line tool changes the file on disk without routing through the app’s write path.
• A change pulled in from another device is applied by the sync pipeline, which does not take a snapshot of what it replaced. The incoming change is itself a synced version, so nothing is lost, but there is no local snapshot of the content it overwrote.
• Anything that is not a .md file. Documents, plain text, and HTML are never snapshotted.

Opening version history

There are three ways in, and none of them has a keyboard shortcut.

Entry point	How
File tree	Right-click a .md file and choose History. The item only appears for Markdown files.
Command palette	Open it with Cmd/Ctrl+Shift+P and run History for Current Note. It does nothing when the active tab is a search or history tab, or is not a .md note.
Right sidebar	The history icon in the right sidebar rail, with the tooltip Open history. It is disabled unless the active tab is a Markdown note. The right sidebar is collapsed by default, so you may need to open it first.

History opens as a pinned tab at the far left of the tab bar, titled History: <note name>. Like the search tab, it cannot be dragged and cannot be a drop target. See Keyboard shortcuts for the palette and tab bindings.

There is only ever one history tab. Opening history for a second note reuses the tab you already have and replaces what it shows, rather than giving you two timelines side by side. Closing the history tab returns you to the tab you opened it from.

While the tab is open it stays current on its own. It refreshes when the window regains focus, when the app reports that the note’s history changed, and every two seconds while an older vault is still building its index.

These are the states the view can show apart from a normal timeline.

State	What it means
Loading history…	The first read of the timeline is in flight.
No history yet for this note.	Neither a snapshot nor a synced version exists yet.
Building history… with a progress bar and a done/total count	An older vault is replaying its manifest into the version index. The rail and comparison pane still render from whatever is already indexed, so this strip sits above a working timeline. It clears itself when the count completes.
An error with a Retry button	The timeline could not be read.
Open history from a note to see its timeline.	The history tab is focused but no note has been chosen.
Loading diff…	A comparison has been selected and its content is being fetched.

Backfilling is decode-only. It downloads nothing, and it resumes where it stopped if you quit.

Reading the timeline

The left rail lists changes newest first, grouped twice. Consecutive changes are collapsed into a session, and sessions are then grouped under a day heading reading Today, Yesterday, or a short date.

A session is a run of changes from the same source and, for synced versions, the same author, with no gap longer than four hours between them. Deletes and restores are never merged into a session. They always stand alone so they stay visible.

Each session row shows the author, the time or time range it covers, and its version span as v7 for a single version or v3…v7 for several. A session with more than one change adds a count reading 4 saves, and a chevron that expands it into the individual versions underneath. Restores are marked with a rotate icon and deletes with a trash icon.

Autosave sessions look different on purpose. They carry a clock glyph instead of an author chip and read Autosave or 3 autosaves.

The Autosaves filter

When a note has synced versions, a toggle chip labeled Autosaves appears at the top of the rail. It is off by default, which means the timeline shows only the synced versions and hides the local snapshots between them. Turn it on to interleave both.

The chip is only shown when synced versions exist. In a vault with no cloud sync there is nothing to filter against, so autosaves are always visible. Your choice is remembered per machine in browser storage under jotura:historyShowAutosaves.

Comparing two versions

The timeline opens with a selection: a base version on the left of the comparison and a head version on the right. Clicking a session selects that whole session as the head and the change immediately before it as the base, so you see what the session as a whole did.

Action	Result
Click a session	Selects the session as head, with the preceding change as base.
Click a version inside an expanded session	Selects that single version as head, with the preceding change as base.
Shift-click a version	Sets that version as the base and leaves the head alone.

The comparison header gives you the same control with dropdowns. Base version lists every visible entry plus a leading Start option, which means the note’s creation and compares against empty content. Compare version lists the same entries for the head. Each option reads v12 · 14:07 for a synced version or Autosave · 14:07 for a snapshot. When the base is Start, the left side of the header reads Note created instead of an author.

A swap button, labeled Swap versions, exchanges base and head. It is disabled when the base is Start, since there is nothing to swap in.

Above the diff, the header shows the added and removed line counts as +18 and −4. When a whole session is selected and it holds more than one change, it also shows framing text reading 4 saves by adam or 3 autosaves.

Unified and split

Two layout buttons, Unified and Split, switch how the diff renders. Unified interleaves old and new lines in one column with a + or - marker. Split puts the old text on the left and the new text on the right.

Both show hunk headers in the usual @@ -12,7 +12,9 @@ form and line numbers for each side. Inside a changed line, word-level emphasis shows exactly which words moved.

Your layout choice persists per machine under jotura:historyDiffView, and unified is the default.

Very large diffs are capped at 5000 lines. When a comparison exceeds that, the first hunk always renders in full, then as many further whole hunks as fit under the cap. A Show full diff button renders the rest.

Restoring a version

Select the version you want back, then click Restore. The button swaps into an inline confirmation reading Overwrite current note? with Restore and Cancel. Confirming writes that version’s content over the note and reloads any open tab on it.

Restoring is not destructive, whichever kind of entry you restore. The write goes through the app’s normal write path, so the content that was on disk is snapshotted first. Nothing earlier in the timeline is removed.

What differs is how the restore is recorded:

• Restoring a synced version pushes a new version marked as a restore. It carries the rotate icon in the timeline and is attributed to you. Once it lands, the view reselects the comparison to show what the restore changed.
• Restoring an autosave snapshot is not marked. It pushes as an ordinary edit with no restore icon, and the comparison is not reselected.

The Restore button is hidden or refuses in three cases.

Situation	Behavior
The selected head is already the newest synced version	The button is not shown. There is nothing to restore to.
You are a viewer on a shared note	The button is not shown, and a restore request is refused. Viewers cannot write.
The note has unsaved changes	The restore is refused with Save the note before restoring.

The first case needs a synced version to compare against. In a vault with no cloud sync, there is no newest synced version, so Restore is offered for every entry including the newest snapshot.

Saving is automatic in Jotura, so the third case usually clears itself within a second. See The editor for how autosave works.

How attribution appears

Attribution is available only on synced versions, because the author is written into the encrypted sync operation when a device pushes. The account signed in on the pushing device is stamped as the author. Autosave snapshots have no author at all, which is why they render as Autosave.

Each authored entry gets a small round chip holding the initials from the author’s email address. The chip is colored from that address, so the same person keeps the same color throughout the timeline, and the full email is its tooltip. Next to the chip is a label resolved this way.

Label	When it is used
You	The version was pushed by your own account, or by this device when no account id is recorded.
The email local part, for example adam	Someone else’s version, where the email is known.
Former member	Someone else’s version where no email can be resolved. The chip shows ? instead of initials.

In a shared note, an author recorded only as a user id is resolved against the share’s member list, including the owner, so names appear for everyone currently in the share. Someone who has since left the share falls back to Former member, because their address is no longer in the list to look up. When a version carries no author at all, the app asks the server which account owns the pushing device and uses that. A failed lookup is not cached, so a transient network problem does not pin an unknown author for the rest of the session.

What the server can see

The author stamp travels inside the encrypted operation, so the server cannot read who edited a note. Two things about each push are stored in plain text: the id of the device that sent it, and the time it arrived. The server also maps device ids to the accounts that own them, which is how the app attributes older operations, and it requires a caller-owned device id on every push to a shared vault.

The honest summary is that the server can tell which account pushed, and when. It cannot tell which note, which path, or what changed. See Sync and sharing for the sharing model, and security for the encryption design.

Sharing moves a note’s timeline

Version history is read from whichever sync unit currently owns the note, and sharing changes that unit. This is the most surprising behavior on this page, so it is worth stating plainly.

A note inside an active share has its versions read from that share’s own database at .jotura/shares/<id>/sync.db, never from your personal one. Synced versions written before the note was shared stay in your personal database and are not listed while the note is shared. They are not deleted, and they come back if the note leaves the share.

When a share is not currently mounted, its database cannot be read at all. The timeline quietly falls back to autosaves alone with no message on screen. If a shared note shows only autosaves, check that the share is mounted in the Shared pane.

What version history does not cover

• Local-only vaults get autosave snapshots and nothing else. Synced versions need a vault with cloud sync configured and a signed-in account, or an active share. Without that, the timeline shows only the local snapshots on that machine: no version numbers, no authors, no retention window, and nothing that survives moving to another computer.
• Being signed out hides synced versions. When the app is signed out, it does not ask for the version list at all and the timeline is autosave-only. Sign in again to bring it back.
• A paused sync key hides them too. If sync is configured and you are signed in but the key is not cached, the version list cannot be decrypted and the timeline falls back to autosaves. Entering your sync password brings the full timeline back. See Troubleshooting.
• Markdown only. History is available for .md files. Imported documents, plain text files, HTML files, and images have no timeline. See Documents.
• Deleted notes keep server history you cannot reach. The backend deliberately allows a version lookup for a path that no longer exists on disk. All three entry points need a live target, though: the tree item needs a row in the tree, and the palette command and sidebar button need an open note. Once a note is deleted and gone from the tree, there is no way to open its timeline.
• External edits leave no snapshot. Changes made outside the app, including edits from the jotura command-line tool, do not produce a local snapshot.
• The command-line tool cannot push. The CLI enqueues a change, but the desktop app runs the sync loops. On a machine where both are installed, a CLI edit becomes a synced version the next time the desktop app pushes. On a machine with only the CLI, it never becomes a synced version at all. See Sync and shares.
• The command-line tool has no history commands. There is no CLI equivalent of the timeline, the diff, or restore. See Reading and searching for what the CLI does cover.
• The Android app has no history view. Edits made on the phone become synced versions like any other push, and you can see them on the desktop, but the phone itself does not show a timeline.
• Autosave snapshots are not synced. They live in .jotura/ on one machine, which also keeps them out of search, the file tree, and sync. Another computer signed into the same account will not see them.
• Folder deletes are not listed. A deleted folder produces no per-note timeline entry. Only file changes appear.

Related pages

• Sync and sharing for enabling sync, roles, and what the server can and cannot see.
• The editor for autosave and how external changes are merged.
• Settings reference for the sync and account settings that gate synced versions.
• Getting started if you have not opened a vault yet.