Bidirectional knowledge sync patterns
Definitie
Bidirectional sync tussen twee kennis-systemen (bijvoorbeeld een lokale Obsidian vault en een Notion workspace) betekent dat edits aan weerskanten automatisch doorwerken naar de andere. Afhankelijk van het niveau varieert de implementatie van simpele metadata-sync tot volledige entity-level sync inclusief relations. Elk niveau koopt andere complexity en andere faalmodi.
Context
Bij het kiezen van een tweede kennisbackend (Notion naast Obsidian, Confluence naast git) verleidt de gedachte tot “het gewoon synchroniseren”. In de praktijk is bidirectional sync tussen twee systemen met verschillende data-modellen een klassiek moeilijk probleem: conflict resolution, data-mapping, race conditions, edge cases. Dropbox, Google Drive en Notion zelf hebben teams fulltime op dit soort problemen. Voor een persoonlijk kennissysteem is het zaak expliciet het juiste complexity-niveau te kiezen, niet automatisch naar de zwaarste oplossing te grijpen.
Kernpunten
Niveau 1: metadata-bidirectional
Properties zoals status, tags, deadline en owner in het remote systeem syncen met YAML frontmatter in de lokale bestanden. Content blijft onaangeraakt.
- Gereedschap:
oss-notion-markdown-syncof vergelijkbare push/pull tools - Mechanisme: YAML frontmatter velden mappen op Notion properties, polling op beide kanten detecteert wijzigingen
- Effort: 4-8 uur om op te zetten
- Faalmodi: property-rename remote breekt frontmatter
- Wat je niet krijgt: inline databases, rollups, collaborative cursors
Niveau 2: content-bidirectional
Niveau 1 plus de page body zelf. Als iemand in Notion een alinea toevoegt, komt die terug in de lokale markdown. Three-way merge nodig voor simultane edits.
- Gereedschap:
interkastenimplementeert dit metnode-diff3voor three-way merge, WAL protocol voor crash recovery, circuit breaker tegen cascading API-failures, 30-dagen soft-delete retention - Mechanisme: polling op
last_edited_time, sync-events naar beide kanten, conflict-detectie via gedeelde ancestor - Effort: 8-16 uur om te installeren en configureren
- Faalmodi: auto-merge faalt bij overlap dezelfde regels, handmatige review nodig; rich blocks mappen niet schoon naar markdown (callouts, toggles, inline databases)
Niveau 3: entity-level met relations
Vault-assets en database-rows zijn one-to-one, inclusief relaties tussen entities. Een project met reference-rollups werkt automatisch omdat de relation-edges gemirrord zijn in beide systemen.
- Gereedschap:
interkastenzwaar configureren met custom mapping rules, of zelf een StorageBackend abstraction bouwen in de eigen MCP server - Mechanisme: asset-model dat Notion’s property + blocks + IDs kan representeren, mapping-laag tussen local paths en remote IDs
- Effort: 60-80 uur refactor als je het zelf schrijft vanaf een filesystem-gebaseerde MCP
- Faalmodi: distributed systems problemen (race conditions op create-events, stale reads, cascade-deletes)
Circulaire schrijflus: detectie en preventie
Bij bidirectionele sync waarbij een proces zowel leest als schrijft (File A → DB → File A), ontstaat een circulaire lus als de eigen schrijfoperatie een nieuwe sync triggert. Oplossing: gebruik een in-memory write guard als Set<string>.
Patroon (TypeScript):
private writingAssets = new Set<string>();
async syncToExternal(assetId: string): Promise<void> {
this.writingAssets.add(assetId);
try {
// schrijf naar extern systeem
} finally {
this.writingAssets.delete(assetId);
}
}
async syncFromExternal(externalPath: string): Promise<void> {
const assetId = this.findAsset(externalPath);
if (this.writingAssets.has(assetId)) return; // eigen write, overslaan
// verwerk inkomende update
}Conflict policy: bij externe edit (file gewijzigd door derde applicatie) en gelijktijdige vault-edit is het handig een expliciete policy te kiezen:
- Last-write wins: eenvoudigst, acceptabel bij persoonlijk gebruik
- XMP wint: extern systeem (bijv. Lightroom) is source of truth voor metadata
- Vault wint: vault is source of truth; extern lezen, nooit overschrijven
Dit patroon is geimplementeerd in vault/src/providers/xmp-sync.ts voor de Lightroom XMP-bridge (TASK-065, 2026-04-16).
Faalmodi die op elk niveau blijven
- Dubbele pages na race conditions tussen create-events aan beide kanten
- Frontmatter corruptie door property-rename aan de remote kant
- Merge-conflicten die niet auto-resolven
- Polling-latency: sync cycles zijn minutes, niet seconds
- Rich blocks (callouts, toggles, inline databases) mappen niet 1:1 naar markdown
- Permission-model van het remote systeem moet expliciet gedeeld worden met de integratie
Alternatief: rolverdeling zonder sync
Als de twee systemen verschillende rollen krijgen (bijvoorbeeld lokale vault als denk- en captureruimte, Notion als plan- en deelruimte), is geen bidirectional sync nodig. Alles landt eerst in de source of truth, publicatie is een expliciete actie, geen automatische flow. Dit voorkomt de hele class van sync-problemen ten koste van wat extra handmatige stappen.
Beslisboom in een paragraaf
Start met niveau 0 (rolverdeling zonder sync). Upgrade naar niveau 1 alleen als je merkt dat properties aan beide kanten worden aangeraakt en je metadata synchroon wil houden. Upgrade naar niveau 2 alleen als je echte collaboration nodig hebt waar anderen in het remote systeem content schrijven die terug moet in de lokale vault. Niveau 3 is alleen zinnig als het lokale systeem een active query-rol heeft over relations en die structuur aan beide kanten nodig is. Spring niveaus niet over.
Verbanden
- Zie ook: wiki-notion-sync-markdown-api
- Zie ook: wiki-vault-mcp-architectuur
- Zie ook: wiki-karpathy-llm-wiki
Bronnen
- mistakeknot. (2026). interkasten [GitHub repository]. https://github.com/mistakeknot/interkasten
- VegaStack. (2026). oss-notion-markdown-sync [GitHub repository]. https://github.com/VegaStack/oss-notion-markdown-sync
- Wikipedia contributors. (2024). Merge (version control): Three-way merge. https://en.wikipedia.org/wiki/Merge_(version_control)#Three-way_merge