tegwick
e00c160a43
Architecturally distinct from the Obsidian/Roam/Notion trio: content is Markdown, the local store is SQLite, and the sync representation is a folder of per-item Markdown+metadata files on a backend of choice (filesystem, WebDAV, Nextcloud, Dropbox, OneDrive, S3, Joplin Server/Cloud). Two new findings: (1) attach the sync/interchange mirror, not the app or the SQLite store, offline and app-independent, landing on INTENT's WebDAV/Nextcloud/S3 backends (UC-60, distinct from native on-disk store UC-40 and app-files UC-53); (2) E2EE => content opacity, a proposed twelfth capability spectrum for encrypted-at-rest shards (UC-61). Also: Joplin is the file-sync-daemon boundary case (attach the mirror as pages, never re-sync); store-minted page-level :/id links (addressing spectrum middle); dual surface (plugin host + local Data API on localhost:41184). Enriched UC-31/36/38/40/51/55. Catalog now 61 UCs. Architecture for SHARD-WP-0002 T11/T14: interchange-format attach, content-opacity field, local-REST sub-mode, format-aware file-store profiles. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
260614 — Joplin deep dive (SQLite-local, Markdown-on-sync, interchange-format attach)
Date: 2026-06-14
What this is
A focused study of Joplin — the open-source Markdown note app — read through shard-wiki's lens. Joplin looks like "open-source Obsidian" but is a genuinely different point in the space: content is Markdown, the local store is SQLite, and the sync representation is a folder of per-item Markdown+metadata files on a backend you choose (filesystem, WebDAV, Nextcloud, Dropbox, OneDrive, S3, Joplin Server/Cloud). It also ships end-to-end encryption and is itself a sync layer over heterogeneous storage.
Distinctive material:
- Architecture — SQLite local store (documented schema); Markdown content;
notebooks → notes → resources + tags + to-dos; 32-char item IDs;
:/<id>note links (rename-stable, page-level) - Sync — serialized to plain-text items on a chosen target; tombstones; conflict notes (keep-both) → enables the "attach the sync mirror, not the app" pattern on WebDAV/Nextcloud/S3
- E2EE — items encrypted before leaving the device → content opacity (ciphertext at rest)
- Extension surfaces — a plugin API (
joplin.data/workspace/contentScripts/ views) and a local Data API (REST onlocalhost:41184, token) used by the Web Clipper; plus JEX/Markdown/RAW export
Contents
| Path | Role |
|---|---|
findings.md |
Architecture, sync/interchange attach, E2EE/content-opacity, plugin + Data API surfaces, capability profile, INTENT mapping, UC seeds, architecture notes, sources |
Status
Initial deep dive complete. Two new use cases promoted to spec/UseCaseCatalog.md
(UC-60 attach a tool's documented sync/interchange representation on third-party storage
without the app; UC-61 attach an encrypted-at-rest shard with content opacity);
UC-31/36/38/40/51/55 enriched. Logged for SHARD-WP-0002 (T11, T14): the
interchange/sync-representation attach surface, content opacity as a proposed twelfth
capability spectrum, a local-REST attach sub-mode, and format-aware file-store profiles.
Key takeaways recorded: the best attach surface is often a tool's interchange/sync representation (offline, app-independent — Joplin items on Nextcloud/WebDAV/S3, the INTENT-named backends), not its live store or API; encryption-at-rest demands a content-opacity capability so encrypted shards degrade to backup/structure-shell; and Joplin is the file-sync-daemon boundary case — shard-wiki attaches its mirror as pages and never re-syncs (not-a-sync-daemon).