The vault that can't be everywhere it's needed
At some point your knowledge vault stops being a single-audience thing. It started as a place for you — drafts, private reflections, half-finished dossiers, notes about your health and your money that live one keystroke from your reading list. Then reality arrives with more readers. You want your active projects on your phone. You want to share a family calendar and some shared context with your sister, or your partner. Eventually you want to put your articles in front of readers.
And here's where the naive instinct breaks: just sync it. Turn on Obsidian Sync, mirror the whole vault to every device, and share the folder with family. It fails on three fronts at once. Privacy — you do not want your health notes landing on your sister's laptop, and a whole-vault sync gives you no way to hold them back. Performance — a seventy-thousand-file vault that flies on a laptop crawls on a phone; the mobile app chokes on the index. Portability — the moment your notes leave the master device, absolute paths break, and links that worked on the laptop point at nothing on the phone.
Whole-vault sync treats every audience as if it wanted the same thing you do. None of them do. The fix isn't a better sync tool. It's a change in what the master vault is for.
The shift: master is a generator, not a destination
Here's the whole reframe. Your master vault is not a thing you sync. It's a thing you publish from.
The master stays on the laptop — full, fast, and completely private. Nothing syncs it wholesale, ever. Instead, each audience gets its own small, self-contained publish-vault, generated from the master by a little engine that reads a config and emits exactly the view that audience should see. Your phone gets a publish-vault. Your family gets a different one. Your readers, eventually, a third. Each is a real, portable Obsidian vault — but it's an output, not a copy. The master is the source; the publish-vaults are projections of it.
Say it as a slogan and it reorganizes your whole mental model: stop thinking "sync," start thinking "publish." Your phone doesn't need your master vault. It needs a view of it — and a view is something you generate, filter, and rewrite for its destination, not something you mirror byte-for-byte from the source.
This is the same principle that runs underneath a lot of good systems: the master is a generator, and the outputs derive from it. Change the master, re-run the engine, and every view updates. You never edit the phone's vault or the family's vault directly — those are build artifacts. You edit the source and republish.
The engine is small, and the config is where the intelligence lives
The publish-engine itself is not much: a script that walks the source folders, applies a filter, rewrites paths and links so the output is portable, copies the attachments each note needs, and writes out a clean vault. A couple of hours of one-time work.
The intelligence isn't in the script. It's in the per-audience config — one small YAML file per publication that declares what that audience gets: which source folders feed it, which filters apply, which frontmatter rules decide inclusion. That's the real move: scope-as-code. Adding a new audience isn't a re-architecture; it's a new config file. What the family sees, what the phone carries, what readers eventually get — each is a few lines you can read, diff, and reason about, instead of a set of sharing permissions scattered across an app's settings screens.
Frontmatter is the audience-control layer
The engine needs to know, per note, who's allowed to see it — and the honest place for that decision is in the note itself, in frontmatter, declared where you write.
Two fields carry it. visibility: private is a hard block — a note marked private never leaves the master, for any publication, full stop. share: <audience> is the opt-in — a note only reaches the family publication if it says share: family. The default matters enormously and it's asymmetric on purpose: default-deny for anyone who isn't you. Your own phone can default to seeing your active work, because it's still you. But family and external audiences get nothing unless a note explicitly opts in. You don't build a share-everything system and then try to remember what to hold back — you build a share-nothing system and consciously let specific things through.
That's a small, boring discipline — tagging notes with share: as you write them — and it is exactly the discipline that means you never have the 2 a.m. realization that something personal is now on someone else's device. The frontmatter conventions live in the master; the engine simply obeys them.
The hard part: rewriting the links so the view actually works
The genuinely tricky engineering is the path-rewrite. On the laptop, some of your links are absolute paths into the master vault's location. Those are meaningless on a phone, on Android, on your sister's machine — different OS, different root, different everything. A publish-vault full of dead absolute links is worse than no publish-vault.
The engine has to reason about every link at publish time. Wikilinks are the easy case — they resolve by filename, so they travel fine as long as their target is also in the publication. Absolute markdown links are the work: if the target is inside this publication, rewrite it to a relative path that resolves on the destination; if the target is outside this publication — a note the audience isn't allowed to see — you can't rewrite it to anywhere valid, so the engine reports it as a broken link rather than shipping a dead one. That broken-link report is a feature, not a failure: it's the engine telling you where a public note is quietly leaning on a private one, which is exactly the seam you want surfaced before you publish, not after.
Read-only, guaranteed at the protocol — not asked-for at the app
Generating a clean publish-vault is only half the guarantee. The other half is making sure the copy on the phone or the sister's laptop can't drift back and corrupt anything, or get edited into a fork of the truth.
The transport layer earns its keep here. Rather than trusting an app-level "please don't edit this" setting, you enforce direction at the sync protocol: the source side is send-only, the target side is receive-only. That's not a preference the app politely honors — it's a hard property of the sync relationship. Local edits on a receive-only device don't propagate and don't survive; the master is structurally untouchable from downstream. (This is where Syncthing does the gluing, and folder-type becomes the security boundary — a topic in its own right.)
There's a deliberate exception: a capture back-channel. Your phone shouldn't only consume — it should be able to send a voice note or a quick capture back. That's a separate, small, bidirectional folder pointed at your inbox, kept completely apart from the read-only publish-vaults. Consuming and capturing are different flows with different directions, and keeping them in different folders is what stops them from tangling.
What it costs, plainly
None of this is free, and the outline of the cost is short: a couple of hours to build the engine once, a gigabyte or two of extra storage on the laptop per publication, one YAML file per new audience, and the standing discipline of tagging notes with share: as you write. That's the bill.
Against it: your master stays fast and fully private because nothing ever forces it onto a constrained device; each audience gets a view sized and shaped for them; and adding your next reader is a config file, not a project. For a single-user, single-device life, whole-vault sync is genuinely fine and this is overkill — that's the honest boundary. The moment a second audience appears with a different set of things they should see, sync stops being able to answer the question and publish starts.
Publish your knowledge; don't spray it
The reason "just sync everything everywhere" feels right is that it's simple. The reason it fails is that your audiences aren't you, and a single mirror can't tell them apart. The structural answer costs a little discipline and returns a lot of control: one private master, a small engine, a config per audience, frontmatter that decides who sees what, and a transport that guarantees read-only downstream.
This is structure beats magic applied to the oldest tension in personal knowledge management — wanting your notes both private and everywhere. The magic pitch is a sync service that somehow keeps it all straight for you. The structural answer is to stop mirroring and start projecting: keep one source of truth, and generate the exact view each audience deserves. Your phone gets a view. Your family gets a view. Your readers get a view. And your master vault stays what it should always have been — yours.
Part of the Structure Beats Magic series. The transport and folder-type security model is in Syncthing as the Glue; the frontmatter-as-contract layer is its own piece; the generator-not-destination principle runs through A Brain That Publishes Itself.