Rootr Sync — share one folder of your vault with your team (and with Claude/ChatGPT)

Disclaimer

Is this project open source? Yes — the plugin is MIT licensed, source linked below. The service it syncs to is a hosted product and is not.

Is this project completely free? The plugin is free and always will be. The service it syncs to is not fully free: it has a free tier that covers this use, and paid plans above it.

Is this project vibe-coded beyond the author’s ability to comprehend how it works? No. It is a single ~600-line TypeScript file, and it passed the plugin directory’s automated review. Ask me about any part of it.

Community Directory: https://community.obsidian.md/plugins/rootr-sync


Most of my vault is mine alone. But a few folders — specs, meeting notes, runbooks — other people on my team need to read, and some of them don’t use Obsidian at all.

So I built a plugin that syncs only what I pick out to a shared workspace, and leaves the rest of the vault alone.

What it does

  • You choose a folder (or a tag). Only that gets synced.

  • Folder structure is preserved 1:1 on the other side.

  • Teammates read and edit it in a browser — they don’t need Obsidian.

  • Claude and ChatGPT can connect to that workspace over MCP and actually read and write those notes. So “turn last week’s meeting notes into a spec” runs against the real files instead of a paste.

What it does not do (yet)

  • No reverse sync. The vault is the source of truth; edits made on the web don’t come back.

  • Wikilinks are not converted.

  • Images and attachments are not uploaded.

About your data — the part I’d want to read first, since this talks to a server:

  • Only files inside the folder or tag you pick ever leave your machine. Nothing else is read.

  • Nothing is sent in the background. Sync runs when you run it.

  • No telemetry, no analytics, no crash reporting of any kind.

  • Privacy policy: https://rootr.io/legal/privacy

Install: Community plugins → search “Rootr Sync”.
Source: https://github.com/gwmage/obsidian-rootr-sync

If it breaks on your setup I’d like to hear about it. Reverse sync is the next thing I’d build if people actually want it.

By reverse sync do you mean something like this:

  • A shares folder with B.
  • Folder appears in B’s Obsidian.
  • Any edit made by B is invisible to A and overwritten by future syncs
  • B shares folder with A
  • The same rules apply.
  • Both see the two folders under the same root (eg Team)
  • Each may link to the other folder from their own
  • Back links work as expected.
    ?

Not quite. I meant something narrower, and yours is the more interesting version.

What I meant: right now the vault is the only writer. Notes go out to the web workspace, and anything edited there is stranded. “Reverse sync” was just pulling those edits back down into the same files.

What you’re describing is the plugin writing someone else’s folder into your vault, which it never does today. B doesn’t see A’s folder in Obsidian at all — B reads it in a browser. So your version is a bigger step, and honestly a cleaner one.

Two things I’d want to get right before building it:

Ownership has to be visible. A mirror that silently eats B’s edits on the next sync is a trap. If B’s edits are going to be overwritten, Obsidian should make that folder look not-yours before B starts typing in it.

Links pointing out of a pulled folder. Links from your own notes into the mirror are fine — those are real files, so backlinks work for free. Links inside the mirror pointing at notes you don’t have are the part that breaks.

Is B meant to edit, or is reading enough? Read-only mirroring is much safer to ship, and it covers most of what I’ve actually needed.

Two things I’d want to get right before building it:

Ownership has to be visible. A mirror that silently eats B’s edits on the next sync is a trap. If B’s edits are going to be overwritten, Obsidian should make that folder look not-yours before B starts typing in it.

I was thinking that there might be some reason B would do that, but can’t think of one. Only the author can edit. The receiver can only write a back linked comment. I’m thinking of such notes as peer-to-peer messages, in which case Syncthing almost works, but the Android version is defunct. I don’t see any case for multiple editors of one note.

Question: Should the author be able to edit the note once synched, or should they, like everyone else, like a comment or update?

I’m leaning towards the latter. Everything older than a certain date (say a week or a month) is read-only, and you have a limited number of inboxes for things you might work on that are automatically emptied of anything older.

Links pointing out of a pulled folder. Links from your own notes into the mirror are fine — those are real files, so backlinks work for free.

I think so. You can link into the mirror from your private notes and see the back link, but no one else will.

Links inside the mirror pointing at notes you don’t have are the part that breaks.

Yes. Obsidian will try to resolve all such references to the receiver’s vault. That seems easy to check on the sending side.

But should each participant be required to archive everything? Perhaps they should be able to ignore some notes, in which case a pulled note might refer to one they had not saved. It’s obviously not meant to be one of theirs, so maybe there might be a way to fetch it again..

Such considerations as as much social as technical. You might have a look at ActivityPub to see how it manages such things.

But what do I know? I haven’t programmed anything for the last 25 years.

That question — author edits vs author comments — is the one that decides what
you’re building, so I’d answer it before anything else.

If a note is a message, you’re right: it should freeze. Messages that change
after you’ve read them are a betrayal of the format, and your read-only-after-a-week
rule falls straight out of that. If a note is a document, freezing it is the bug.
A runbook that can’t be corrected is worse than no runbook.

I’d keep the author editable, because everything I use this for is the second kind.
The note is the current state of something, and it’s supposed to drift. Comments
from readers hang off it; they don’t replace it.

Which is also where our two designs part company, and I should be straight with you:
what you’re sketching is a peer-to-peer protocol between two people who both live in
Obsidian, with identity and federation underneath — hence ActivityPub, and hence
Syncthing being nearly right. That’s a real thing to want, but it isn’t what I’m
building, and I’m not going to pretend it’s on my list. The reason this plugin exists
is narrower and duller: the people I have to share a folder with aren’t in Obsidian
at all and never will be, so there’s no second vault to sync to.

On the broken-link question you raised — checking on the sending side is the right
instinct, and it’s cheap. Resolve the links in the outgoing folder, and anything
pointing outside it either travels along or gets flagged before it leaves. That much
I should probably do regardless of the rest.

And for what it’s worth, 25 years away from code hasn’t hurt your instincts here.

Unrelated to the above, but worth saying here since this thread is where people
find the plugin: setup used to dead-end if you didn’t already have a Rootr
account. There’s now a page that walks through the two values the settings
screen asks for — https://rootr.io/obsidian

Well, that was interesting, and thank you for taking the time.

Your use cases are very different from mine. I have no interest in AI, and no idea even what a runbook is.

I’ll possibly never communicate with anyone in the way I outlined, but I am interested in the idea of a mainly read-only vault where revisions do not overwrite previous versions.

1 Like