research: local-first workspaces cohort deep dive (Anytype/AFFiNE/AppFlowy) — CRDT substrate; UC-64/65

Combined cohort memo for the three open-source local-first all-in-one
workspaces, studied together because they share the trait none of the
prior eleven systems had: the store is a CRDT (Anytype any-sync, AFFiNE
Yjs/y-octo, AppFlowy Yrs). The cohort thesis: CRDT changes the adapter
math — the backend performs conflict-free merge itself (shard-wiki must
not impose git/text merge; speak the CRDT via a replica or stay
projection/overlay), history is a CRDT update log (supplement not git),
and the attach surface is a replica or self-host sync endpoint, with
Anytype adding P2P (no single endpoint) + E2EE (opaque). Added UC-64
(CRDT-synced shard with native merge), UC-65 (P2P/decentralized shard,
no single canonical endpoint); enriched UC-36/47/48/51/55/57/58/61.
Catalog now 65 UCs. Architecture for SHARD-WP-0002 T11/T14: merge-model
capability (proposed 13th spectrum: none/git/native-CRDT), CRDT-replica
substrate + P2P/no-central-endpoint attach mode, endpoint-model
capability, MCP as an integration surface. Boundary: CRDT local-first
candidate shards — attach a replica/projection as pages, respect native
merge, never re-drive their sync; not substrates and not the federation
layer.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

spec/UseCaseCatalog.md

@@ -8,8 +8,9 @@ Promoted from `research/260608-c2-wiki-origins/`,
 `research/260613-twiki-deep-dive/`, `research/260613-foswiki-deep-dive/`,
 `research/260614-xanadu-deep-dive/`, `research/260614-zigzag-deep-dive/`,
 `research/260614-roam-deep-dive/`, `research/260614-obsidian-deep-dive/`,
-`research/260614-notion-deep-dive/`, `research/260614-joplin-deep-dive/`, and
-`research/260614-logseq-deep-dive/`.
+`research/260614-notion-deep-dive/`, `research/260614-joplin-deep-dive/`,
+`research/260614-logseq-deep-dive/`, and
+`research/260614-localfirst-workspaces-deep-dive/`.
 See InfoTechPrimers on coulomb.social for use-case catalog conventions.
 
 ## Conventions
@@ -283,7 +284,9 @@ closed-SaaS instance: internal page history bounded by plan, **not portable** an
 exported as git (`research/260614-notion-deep-dive/findings.md` §4) — a supplementation
 case like Confluence/MediaWiki, not an import case. **Joplin** keeps internal note
 revisions locally, likewise not portable (`research/260614-joplin-deep-dive/findings.md`
-§1) — supplement.  
+§1) — supplement. **CRDT** shards (Anytype/AFFiNE/AppFlowy) keep a CRDT update log, not
+git — also supplement, or snapshot the replica
+(`research/260614-localfirst-workspaces-deep-dive/findings.md` §4).  
 **Priority:** Later
 
 ### UC-37 — Attach a static engine export as a read-only backup shard
@@ -472,7 +475,9 @@ a page is a cell at the intersection of many independent ranks
 (`research/260614-zigzag-deep-dive/findings.md` §2, §5). Reframes the existing derived
 views (UC-05, UC-17–UC-20) as *dimensions + rasters* under one vocabulary. Embodies
 union-without-erasure: every relationship co-equal, none privileged. Open: public
-navigation API vs. internal model (findings §10 Q1).  
+navigation API vs. internal model (findings §10 Q1). **AFFiNE** ships the commercial
+proof: docs, whiteboards, and databases are *views of the same block set*
+(`research/260614-localfirst-workspaces-deep-dive/findings.md` §2).  
 **Priority:** Later
 
 ### UC-48 — Pivot two relationships into a cross-tab view (H-view)
@@ -484,7 +489,9 @@ or page × versions-across-shards — and pivot to re-cross by a different pair.
 **Notes:** ZigZag **H-view** shows two dimensions through a cursor, one horizontal one
 vertical, with only existing cells present (`research/260614-zigzag-deep-dive/findings.md`
 §3). A differentiated exploration primitive for federation/provenance. Open: reference-UI
-investment vs. research-only (findings §10 Q4).  
+investment vs. research-only (findings §10 Q4). **AFFiNE**'s page/edgeless/DB modes over
+one block set are this idea shipped (`research/260614-localfirst-workspaces-deep-dive/findings.md`
+§2).  
 **Priority:** Later
 
 ### UC-49 — Navigate created-from / fork genealogy as a first-class dimension
@@ -544,7 +551,10 @@ rename/move (`research/260614-joplin-deep-dive/findings.md` §1) — coarser tha
 UUID, more stable than a path. **Logseq** is the **sweet spot**: a block-level `id:: uuid`
 stored **in the Markdown text** — fine-grained *and* git-diffable/portable at once,
 resolving the Roam(DB-minted) vs Obsidian(page-level) tension
-(`research/260614-logseq-deep-dive/findings.md` §2).  
+(`research/260614-logseq-deep-dive/findings.md` §2). **CRDT** shards
+(Anytype/AFFiNE/AppFlowy) mint object/block IDs as part of the CRDT structure — fine-
+grained, store-assigned (`research/260614-localfirst-workspaces-deep-dive/findings.md`
+§6).  
 **Priority:** Later
 
 ### UC-52 — Delegate derived views to a shard's native query engine
@@ -615,7 +625,9 @@ decision, not just adapter config (findings §10). JSON Canvas is an open format
 first-class support. **Joplin** resources (attachments, each with an ID, linked `:/<id>`)
 are the same demand in a sync-mirror shard (`research/260614-joplin-deep-dive/findings.md`
 §5). **Logseq whiteboards** (tldraw JSON) are the same in a file-store block shard
-(`research/260614-logseq-deep-dive/findings.md` §6).  
+(`research/260614-logseq-deep-dive/findings.md` §6). **AFFiNE** edgeless canvas, **AppFlowy**
+boards/calendars, and **Anytype** objects/files are the same demand in CRDT shards
+(`research/260614-localfirst-workspaces-deep-dive/findings.md` §5).  
 **Priority:** Later
 
 ### UC-56 — Publish a curated projection to an external read-only target
@@ -649,7 +661,10 @@ profile must encode this **operational envelope** and **scoped/revocable grant**
 projection is cache/poll/webhook, not a live read model. Best as projection/mirror/
 overlay/backup; write-through possible but bounded. Links the authz-in-core decision and
 "no silent remote mutation". Third attachment mode alongside file-store (UC-40) and
-in-engine host (UC-38/50).  
+in-engine host (UC-38/50). Self-hostable variants: **AFFiNE Cloud** / **AppFlowy Cloud**
+(self-host sync servers) and **Anytype**'s open API + MCP are endpoint forms within a
+user's trust boundary (`research/260614-localfirst-workspaces-deep-dive/findings.md` §4,
+§9) — see also UC-65 (P2P, no single endpoint).  
 **Priority:** Later
 
 ### UC-58 — Attach a typed database with schema, relations, and views
@@ -665,7 +680,10 @@ relations**, shown through many views (table/board/calendar/gallery)
 (`research/260614-notion-deep-dive/findings.md` §2). Presses the page model: collection +
 schema + relations, not just a page (findings §9). Relations map to the union link graph
 and/or a relation index (cf. ZigZag many-to-many, UC-47/48); views relate to UC-54.
-Deferred to `SHARD-WP-0002`.  
+Deferred to `SHARD-WP-0002`. **Local-first** variants exist: **Anytype**'s user-editable
+typed object graph (types + relations = an ontology) and **AppFlowy**'s Notion-style DBs,
+both CRDT-backed (`research/260614-localfirst-workspaces-deep-dive/findings.md` §1, §3) —
+the typed-collection demand is not exclusive to hosted SaaS.  
 **Priority:** Later
 
 ### UC-59 — Translate a proprietary content model with an explicit fidelity report
@@ -718,7 +736,10 @@ proposed as a twelfth spectrum for the adapter contract (findings §8; extends
 `research/260614-shard-spectrum-synthesis/findings.md` §2). Graceful degradation extreme:
 IDs/counts/timestamps may be visible while bodies are opaque; never silently surface
 undecryptable content. Open: does shard-wiki ever hold keys, or only treat such shards as
-opaque backups (findings §9 Q1)? Ties [[shard-wiki-auth-in-core-decision]].  
+opaque backups (findings §9 Q1)? Ties [[shard-wiki-auth-in-core-decision]]. **Anytype**
+reinforces this: any-sync is **E2EE by default** — backup nodes hold ciphertext they
+cannot read (`research/260614-localfirst-workspaces-deep-dive/findings.md` §1), and it is
+**P2P** (UC-65).  
 **Priority:** Later
 
 ### UC-62 — Attach a block-graph-on-plain-files shard
@@ -755,6 +776,41 @@ Open: built by adapter (per-shard) or core (over the union); persisted vs rebuil
 (findings §10 Q2). Belongs to the T16 navigation layer + T11 capabilities.  
 **Priority:** Later
 
+### UC-64 — Attach a CRDT-synced local-first shard with native merge
+
+**Actor:** Maintainer  
+**Goal:** Attach a CRDT-based local-first store (Anytype any-sync, AFFiNE Yjs, AppFlowy
+Yrs) whose backend performs **conflict-free merge itself** — consuming a replica or
+sync endpoint, respecting CRDT semantics rather than imposing git/text merge.  
+**Source:** localfirst-workspaces, intent  
+**Notes:** The cohort's defining trait: the store is a CRDT, so concurrent edits merge
+mathematically (`research/260614-localfirst-workspaces-deep-dive/findings.md` §4). Adds a
+**merge-model** capability (`none → git/text → native-CRDT`) — a proposed **thirteenth
+spectrum** for the adapter contract (with Joplin's content-opacity twelfth). shard-wiki
+must **not** git-merge a CRDT shard: speak the CRDT (hold a replica) for live/writable, or
+stay **projection/overlay** that respects CRDT merge. History is the **CRDT update log**,
+not git → supplement (UC-36). Attach a **local replica** (offline, full state) or a
+self-host sync endpoint (UC-57). Like Joplin, do **not** re-drive the backend's sync
+(not-a-file-sync-daemon). Open: embed a CRDT client vs consume snapshots; overlays as CRDT
+ops vs out-of-band patches (findings §10 Q1–Q2).  
+**Priority:** Later
+
+### UC-65 — Attach a peer-to-peer / decentralized shard with no single endpoint
+
+**Actor:** Maintainer  
+**Goal:** Attach a decentralized shard (Anytype any-sync: P2P, E2EE) that has **no single
+canonical URL** — binding via a local replica or a named peer/backup node, with content
+that may be encrypted.  
+**Source:** localfirst-workspaces, intent  
+**Notes:** any-sync is P2P with sync/file/consensus/coordinator nodes; **backup nodes hold
+ciphertext they cannot read**; changes signed/encrypted with the user's key
+(`research/260614-localfirst-workspaces-deep-dive/findings.md` §1, §4). The shard's
+"address" is a space ID + replica/peer/invite, **not a URL** — a new binding mode beside
+file-store / in-engine-host / external-API (UC-40/38/57). Combines with **content opacity**
+(UC-61): E2EE shards are replica-only / opaque without keys. Open: shard address form;
+whether shard-wiki holds keys (findings §10 Q3–Q4). Ties [[shard-wiki-auth-in-core-decision]].  
+**Priority:** Later
+
 ---
 
 ## B. Knowledge work and collaboration
@@ -1006,6 +1062,8 @@ CamelCase and `[[free links]]`. Markdown-first link semantics TBD.
 | UC-61 | | | | ‖ | ✓ |
 | UC-62 | | | | ※ | ✓ |
 | UC-63 | | | | ※ | ✓ |
+| UC-64 | | | | ⌘ | ✓ |
+| UC-65 | | | | ⌘ | ✓ |
 | UC-08 | ✓ | | |
 | UC-09 | ✓ | | |
 | UC-10 | ✓ | | |
@@ -1317,6 +1375,39 @@ substrate migrating file→SQLite (UC-43). Architecture logged for `SHARD-WP-000
 (T11/T14/T16): Logseq format profile, derived-query-index capability, substrate-migration
 tolerance, in-file block addressing as the concrete T16 span-address target.
 
+### localfirst-workspaces mapping (Anytype · AFFiNE · AppFlowy)
+
+(⌘ UC-64–UC-65 are placed in the **wikiengines** matrix column as the nearest existing
+source — these are shipped tools — but their true lineage is the **local-first workspaces
+cohort dive**, `research/260614-localfirst-workspaces-deep-dive/findings.md`.)
+
+| Cohort mechanism (findings §) | Catalog UC |
+|-------------------------------|------------|
+| CRDT store with native conflict-free merge (any-sync / Yjs / Yrs) (§4) | UC-64 (new) |
+| P2P, no single canonical endpoint; E2EE (Anytype any-sync) (§1, §4) | UC-65 (new) |
+| CRDT update log ≠ portable git history → supplement (§4) | UC-36 (enriched) |
+| One block set as page / canvas / DB views (AFFiNE) (§2) | UC-47, UC-48 (enriched) |
+| Edgeless canvas / boards / objects = non-Markdown content (§5) | UC-55 (enriched) |
+| Self-host sync server (AFFiNE/AppFlowy Cloud) + Anytype open API/MCP (§4, §9) | UC-57 (enriched) |
+| Typed object graph / user-editable ontology + Notion-style DBs, local-first (§1, §3) | UC-58 (enriched) |
+| E2EE by default; backup nodes hold ciphertext (Anytype) (§1) | UC-61 (enriched) |
+| Object/block IDs CRDT-assigned (fine-grained) (§6) | UC-51 (enriched) |
+| Lossy Markdown export (§5) | links UC-59 |
+
+Note: Anytype, AFFiNE, and AppFlowy form the **CRDT local-first workspace** family — the
+first studied shards whose **store is a CRDT** (the backend merges concurrent edits
+itself). This changes the adapter math: shard-wiki must **not impose git/text merge**
+(speak the CRDT via a replica, or stay projection/overlay), history is a **CRDT update
+log** (supplement), and the attach surface is a **replica or self-host sync endpoint** —
+Anytype adding **P2P + E2EE** (no single endpoint, opaque without keys). **Boundary
+recorded:** CRDT local-first candidate shards — attach a replica/projection as pages,
+respect native merge, never re-drive their sync; not substrates and not the federation
+layer (`research/260614-localfirst-workspaces-deep-dive/findings.md` §7). Architecture
+logged for `SHARD-WP-0002` (T11/T14): a **merge-model** capability (proposed thirteenth
+spectrum: `none / git / native-CRDT`), a **CRDT-replica** substrate + **P2P/no-central-
+endpoint** attach mode, an **endpoint-model** capability, and MCP as an integration
+surface.
+
 ---
 
 ## Open questions
@@ -1355,4 +1446,10 @@ tolerance, in-file block addressing as the concrete T16 span-address target.
     orchestrator (over the union), and is it persisted or rebuilt? (Logseq dive §10.)
 17. When a tool offers **both file and DB substrates** (Logseq), does shard-wiki prefer
     the git-diffable file graph or the richer DB graph, and can one binding follow the
-    migration? (UC-43, UC-62.)
+    migration? (UC-43, UC-62.)
+18. For a **CRDT shard** (UC-64), does shard-wiki embed a CRDT client (Yjs/Yrs) to hold a
+    live replica, or consume periodic snapshots — and are overlays CRDT ops or out-of-band
+    patches? (Local-first workspaces dive §10.)
+19. For a **P2P shard** (UC-65), what is the shard's address (space ID + peer / replica
+    path / invite-key), and does shard-wiki ever hold E2EE keys or only treat it as an
+    opaque replica? (UC-61.)