generated from coulomb/repo-seed
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>
50 lines
2.6 KiB
Markdown
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>
|