Henrique Manduca35 downloadsEnable a local and private history for your notes.
MyHistory is an Obsidian plugin that keeps a local, private version history for your Markdown notes.
Every time a note's content changes, MyHistory stores the full text as an immutable version in a local database inside your vault. You can then open a note's timeline in the sidebar, read any stored version, and restore it.
Nothing leaves your machine. There is no server, no account, and no network request.
[!WARNING] Back up your vault before using it with important notes. Restoring a version overwrites the note's current content, and resetting the local database permanently deletes every stored version.
1.12.7 or newer.22.22.0 or newer for development builds.MyHistory has no external dependencies to configure. The local database is created automatically the first time the plugin loads.
Download the release files and place them in your vault plugin folder:
VaultFolder/.obsidian/plugins/myhistory/
The folder must contain:
main.js
manifest.json
styles.css
Reload Obsidian, open Settings -> Community plugins, and enable MyHistory.
Open Settings -> MyHistory in Obsidian.
50.
Use 0 to keep every version. Pinned versions never expire.15. A note edited without pause is captured anyway once four
times this delay has passed, so a long writing session still produces
versions.myhistory.log inside the plugin
folder.The ribbon icon and the status bar both open the history panel.
MyHistory adds these command palette commands:
The panel lists the active note's versions, newest first. Each row shows when the version was captured, what caused it, and its size. Selecting a row opens a preview modal with the version's content rendered as Markdown, and the modal is where you confirm a restore.
The pin next to a version protects it from retention.
A version is created when a note's content hash changes. Touching a note without changing its text — a metadata change, a save with identical content — never creates one.
Events shown in the timeline:
Renaming or moving a note does not create a version. The note keeps its identity and the panel reports the rename above the timeline.
Restoring writes the selected version's content to the note's current path. The content being replaced is captured as a version first, so a restore never destroys the current state. Restoring a deleted note recreates the file, and its folder if needed.
Before writing, MyHistory re-hashes the stored content and refuses the restore if it does not match the hash recorded with the version.
.md files are tracked. Other file types get no history.Clone this repository into your vault plugin folder:
VaultFolder/.obsidian/plugins/myhistory
Install dependencies:
npm install
Run the development watcher:
npm run dev
Create a production build:
npm run build
npm run build runs TypeScript checks and produces the bundled plugin files in
dist/.
Run the unit tests:
npm test
Use npm run test:watch while developing, npm run test:coverage to generate
the coverage report, or npm run check to run the production build, test type
checks, and unit tests together. See TESTING.md for the mock
boundaries and the testing roadmap.
For local Obsidian testing, reload Obsidian after starting the development build, then enable the plugin from community plugin settings.
To bump the plugin version, use:
npm version patch
You can also use minor or major. The version hook updates manifest.json
and versions.json. Release tags are generated without a v prefix so they
match the manifest version.
MyHistory stores three kinds of document in one local PouchDB database named
myhistory-<vault-id>:
note:<file-id> — the mutable record for a tracked note: its current path,
content hash, latest version, and rename history. The file-id is generated
once and never changes, which is what keeps a timeline continuous across
renames.version:<file-id>:<timestamp>:<suffix> — an immutable version holding the
full content, its hash, the path at the time, and the event that created it.
The id sorts chronologically, so reading a timeline is a single ranged query
rather than a scan of the database.path:<vault-path> — maps a vault path to the file-id that owns its
history.A capture writes the version and the note record in one batch. If Obsidian stops between those writes, the next capture or vault scan detects the mismatch and repairs the note record instead of storing the same content twice.
MIT. See LICENSE.