Files
shard-wiki/research/260614-joplin-deep-dive/README.md
tegwick e00c160a43 research: Joplin deep dive (SQLite-local/Markdown-on-sync, interchange-format attach, E2EE content opacity); UC-60/61
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>
2026-06-14 14:21:31 +02:00

50 lines
2.6 KiB
Markdown

# 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 on `localhost: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).
</content>