Ribs Memos Sync

Syncs a folder in your Obsidian vault with a Memos server via its REST API (/api/v1).

Setup

1. In Memos, go to Settings > Access Tokens and create a token.
2. In Obsidian, enable this plugin and open its settings:
   • Memos server URL: e.g. https://memos.example.com
   • Access token: the token from step 1
   • Sync folder: vault folder to mirror (default ., the vault root)
3. Run Ribs Memos Sync: Sync now (command palette or the ribbon icon).

How it works

• Each memo maps to one note in the sync folder, named <memo-uid>.md, tracked via memo_name / memo_updated frontmatter.
• New memos on the server are pulled down as new notes.
• New notes you create in the sync folder (no memo_name yet) are pushed as new memos.
• For notes already tracked, whichever side changed more recently since the last sync wins (remote checked first, so a true simultaneous conflict favors the server).
• Sync is manual by default (command/ribbon icon); set Auto sync interval > 0 to run it periodically.
• Since filenames are opaque uids, use the Memos list side panel (ribbon icon or command Open memos list) to browse notes by <date time> — <first readable line>; click an entry to open the note. The list refreshes after each sync, or via its own Refresh button.

Known limitations (by design, not yet needed)

• No delete propagation: deleting a memo or note does not delete its counterpart.
• No merge/CRDT conflict resolution, just last-write-wins by timestamp.
• Only content is synced (no tags/visibility/attachments round-trip yet).
• The list panel doesn't auto-refresh on note edits, only after sync or manual refresh.

Development

npm install
npm run build   # type-check + production bundle -> dist/main.js, dist/manifest.json
npm run dev      # watch mode

Copy dist/manifest.json, dist/main.js, and dist/styles.css into <vault>/.obsidian/plugins/ribs-memos-sync/ to test in Obsidian.

Releasing

.github/workflows/release.yml builds the plugin and publishes a GitHub Release (with main.js, manifest.json, styles.css attached) whenever a tag is pushed. The Obsidian marketplace and BRAT both read updates from these release assets, so this is the actual "publish" step after the first submission below.

1. Bump the version by hand in both package.json and manifest.json (keep them equal).
2. Commit, then tag with that exact version (no v prefix) and push:

git tag 0.2.0
git push && git push --tags

The workflow double-checks the pushed tag matches manifest.json's version and fails the build if they differ.

One-time step to get listed in the community plugin browser: fork obsidian-releases, add an entry for this plugin to community-plugins.json, and open a PR. After that's merged, every subsequent GitHub Release you publish here shows up as an update automatically.