Releases: DeepShareAI/javis-obsidian
Release list
0.3.1 — settings show which account is connected
The settings tab now shows which Javis account this vault is connected to.
Changed
- "Connected as ." When you are connected, the Connection section names the Javis account, for example "Connected as you@example.com. Your wiki pages sync into this vault, one way."
- The email comes from your sign-in token, which is kept in the system keychain. It is never written to the plugin's settings file, so it does not travel with your vault through iCloud, Obsidian Sync or git.
- The server's consent page now also says which account you are signed in to, with a hint for switching accounts. That part is a server change and is already live.
If you connected before this release, the account appears within an hour, when the plugin next refreshes its sign-in. You do not need to reconnect. Until then the tab shows "Connected." as before.
Nothing else changed. minAppVersion stays 1.11.4, and the plugin is still desktop-only.
Upgrading
Replace main.js and manifest.json in <vault>/.obsidian/plugins/javis-wiki-sync/ and reload Obsidian. If you install through BRAT with a frozen version, change the pinned version to 0.3.1.
0.3.0 — the wiki moves into Javis-wiki/
The wiki now lives in one folder, Javis-wiki/, instead of nine folders at the root of your vault.
Changed
- Wiki pages are written under
Javis-wiki/<Type>/, for exampleJavis-wiki/Concepts/Agent-Builder.md. A type folder is created only when it has pages. - Your existing wiki moves on the first sync after upgrading. Every Javis note in the old root folders (
Concepts/,Topics/,Sources/and the rest) is moved intoJavis-wiki/, including pages you edited or adopted (javis_sync: false). You see "Javis: moved N notes into Javis-wiki/." - Your own notes stay where they are. A note without Javis properties in one of those folders is not moved, and neither is a note you upload (one with a
javis_source_id). A root folder is removed only when it is completely empty on disk, hidden files included; later syncs retry if it could not be removed the first time. - Nothing is overwritten. If
Javis-wiki/already has a note with the same name, the root copy is left alone and Sync now tells you, with the paths in the developer console. - Links keep working. Page bodies still contain links like
[[Concepts/Foo]], and Obsidian resolves them toJavis-wiki/Concepts/Foo.md. No link is rewritten. - Upload folders:
Javis-wiki/cannot be chosen. Root folders namedTopics/,Sources/and so on are yours again and can be uploaded.
minAppVersion stays 1.11.4, and the plugin is still desktop-only.
Upgrading
Replace main.js and manifest.json in <vault>/.obsidian/plugins/javis-wiki-sync/ and reload Obsidian. The move runs on the next sync, including the one when the vault opens. Your settings and sign-in are untouched.
If you install through BRAT with the version frozen at 0.2.1, change the pinned version to 0.3.0: BRAT does not update frozen plugins.
Rollback
Reinstalling 0.2.1 does not move notes back. It writes a fresh copy of the wiki at the vault root next to Javis-wiki/.
Tested
668 unit tests pass. The end-to-end run in a real Obsidian 1.13.7 vault passed 16 cases and failed none: the 192-note move, edited and adopted pages, a user note left in place, folder cleanup, link resolution, clash handling, a note with broken properties, and the upload guard. Three were not run: uploading a note from a root type folder (it needs a real upload), and two optional scratch-vault cases.
0.2.1 — upload guard fixes
Fixes two upload bugs found by the end-to-end test run against production.
Fixed
- Emptying or cutting a note is now held for review. The safety check that holds a note which suddenly becomes empty, or shrinks by more than 80%, measured the whole file, properties included. On a short note, the properties alone kept a wiped body above both thresholds, so the wipe was uploaded. The check now measures the note's body. The first edit after upgrading only checks for an empty body; the shrink check starts working again after the next upload.
- Reordering properties no longer re-uploads the note. If you only changed the order of keys in the Properties panel, the note was sent again and re-processed on the server. That no longer happens. Changing a value, or reformatting it (for example quoting a value), still counts as an edit.
Nothing else changed. minAppVersion stays 1.11.4, and the plugin is still desktop-only.
Upgrading
From 0.2.0 or 0.1.1: replace main.js and manifest.json in <vault>/.obsidian/plugins/javis-wiki-sync/ and reload Obsidian. Your notes, settings and sign-in are untouched.
Coming from 0.1.1? This is the first Latest release with upload your own notes (off by default; nothing is uploaded until you pick a folder). See the 0.2.0 notes and the README for what is sent and how removal works.
Tested
The end-to-end runbook was run against the production server in a real Obsidian vault: 43 cases passed, none failed. Two were not run: one needs a staging server (a bad LLM key), the other a second Mac syncing the same vault through iCloud.
0.2.0 — upload your own notes
Adds the other direction: notes you write yourself can now go into your
Javis wiki. The download side works as it did in 0.1.1.
New: upload your own notes (optional, off by default)
Nothing is uploaded until you add a folder under Settings → Javis Wiki
Sync → Upload your notes.
-
What is sent. The full text of every
.mdnote in the folders you select,
including subfolders, plus each note's path and title. Nothing outside those
folders. The nine wiki folders, the vault root and.obsidian/cannot be
selected. -
What happens to it. Your Javis server stores the text and distills it
into wiki pages. Those pages come back into this vault on the next sync. -
Edits follow. Edit a note and the wiki is updated from the new text,
including anything you removed. -
Deleting takes it back out. Delete a note, or move it out of the selected
folders:- its stored text is deleted from the server;
- pages only that note produced are removed;
- pages it shared with other sources are rebuilt from those sources.
Pages created before this feature existed can't be rebuilt, so they are
marked instead and may still mention the note. Nothing in your vault is
ever deleted. -
One line is written into each uploaded note:
javis_source_id: <uuid>.
It's inserted as a single line of text, and the rest of your properties
(comments, quotes, lists, dates) are left byte for byte. -
Safety checks before anything is removed:
- a note must be missing on two syncs at least five minutes apart;
- an unreadable file, such as an iCloud file that is only in the cloud,
counts as present; - a folder that suddenly lists nothing removes nothing;
- a sudden empty or >80%-shrunk note is held;
- a sync that would remove more than min(50, 20%, at least 5) notes holds
everything.
Held changes wait for Review pending changes in the command palette.
The README has the full details: what is sent, where, why, how it's stored,
and how it's removed.
Also changed
- Sign-in now targets the server's
/wikiresource. Allowing uploads asks
you to sign in once more and shows a consent screen that lists the new
permission (wiki:write). If you never select a folder, you keep the
read-only permission you have now. - The plugin refuses a plain
http://server address unless the server runs on
this computer.
minAppVersion stays 1.11.4, and the plugin is still desktop-only.
Requires
The Javis server changes from this release are deployed at mcp.javis.is:
the upload routes, the wiki:write scope and the /wiki resource. The earlier
server-side token handling stays compatible for one release, so 0.1.1 keeps
syncing.
Upgrading from 0.1.1
Replace main.js and manifest.json in
<vault>/.obsidian/plugins/javis-wiki-sync/ and reload Obsidian. Your notes,
settings and sign-in are untouched, and nothing is uploaded until you choose a
folder.
Why this is a pre-release
It has not been run in a real Obsidian vault, and uploads have not been
exercised end to end against the live server.
- What was tested: 602 unit tests (up from 290), a clean typecheck and
build, and a contract check of the plugin's requests against the server's
implementation. - What was not tested: the settings UI and the Obsidian vault adapter have
no automated tests, and nothing was tried alongside Obsidian Sync, iCloud,
git or Remotely Save.
Try it on a scratch vault first, as with 0.1.0. It will be promoted to
Latest after the end-to-end runbook passes against a real vault.
0.1.1 — tombstone banner fix
Fixes a tombstone bug found by the end-to-end runbook against a real
1682-page vault.
Fixed
A restored page kept its "Deleted in Javis" banner forever. The banner was
written above the generated block — in the half of the file the plugin is
forbidden to touch — so restoring the page cleared javis_deleted and refilled
the block, but could never remove the banner. One delete/restore cycle and the
note read as deleted permanently.
The banner is now the generated block's content, so a restore overwrites it
like any other generated text. No exception is carved out of the
never-touch-outside-the-markers rule.
Nothing else changed. minAppVersion stays 1.11.4.
Upgrading from 0.1.0
Replace main.js and manifest.json in
<vault>/.obsidian/plugins/javis-wiki-sync/ and reload Obsidian. Your notes,
settings and sign-in are untouched.
If a note still shows a "Deleted in Javis" banner from 0.1.0, delete those two
lines by hand — the plugin will not remove them, because they sit in your half
of the file and removing them would be exactly the rule this release is
defending.
Verified against production
| Tombstone | banner between the markers |
| Restore | banner gone, javis_deleted cleared, body restored |
| Vault-wide | 1683 files, 0 stray banners, no .trash |
290 unit tests, clean typecheck and build. The runbook now stands at 21 pass,
0 fail, 5 blocked — every critical case passing, including never-unlink,
self-heal after losing plugin state, and hand-written content surviving both an
update and a delete.
Still a pre-release: this has been exercised on one real vault, not many.
0.1.0 — first cut
One-way mirror of your Javis wiki into an Obsidian vault.
Every wiki page becomes a markdown file with working wikilinks, backlinks,
graph view and search. The server never sees your edits, and the plugin never
deletes a file.
Requirements
- Obsidian 1.11.4+ (the plugin keeps OAuth tokens in
app.secretStorage) - Desktop only — the OAuth flow binds a loopback listener on 127.0.0.1
- A Javis account
Install
This repo is private, so BRAT cannot reach it. Install manually:
- Create
<vault>/.obsidian/plugins/javis-wiki-sync/ - Copy
main.jsandmanifest.jsonfrom this release into it - Reload Obsidian, enable Javis Wiki Sync in Community plugins
- Open settings, set your server URL, click Connect
Try it on a scratch vault first. It creates nine folders at your vault root.
What it does
Pages land in Sources/, Entities/, Concepts/, Topics/, Comparisons/,
Questions/, Syntheses/, Decisions/ and Gaps/ at the vault root, because
Obsidian resolves [[Concepts/Foo]] from there and the link text arrives
already correct.
Generated content sits between %% javis:generated:start %% and its matching
end marker. Everything outside those markers is yours permanently — the
plugin replaces the block wholesale and never merges, so there is no merge step
to go wrong.
Set javis_sync: false in a note frontmatter to adopt it. The plugin stops
copying that page down immediately; no write-back needed.
Safety properties
- Never unlinks. The vault adapter exposes no delete or trash method at all.
A deleted page is tombstoned in place with a banner. - Losing plugin state costs a rescan and nothing else. Per-page state lives
in that page frontmatter; the cursor rebuilds frommax(javis_rev)across the
vault. - Tokens never touch
data.json. That file lives in the vault and would
replicate a refresh token to every device you sync to.
Not in this release
Write-back to the server, transcripts, daily notes, stub files for unresolved
links, file deletion, a conflict UI, mobile.
Status
289 unit tests, clean typecheck and build. The end-to-end runbook has not been
run against a real vault yet — hence the pre-release tag. See the Phase 1
design spec in javis-server/docs/superpowers/specs/.