id: design: Knowledge layer feature program — competitor feature matrix, import/export, read-authority #5678

Extends #2048 (Zettelkasten layer — multiplayer docs/wiki on ID). This is an EXPANSION design and explicitly a design to go make designs: a feature-matrix investigation program whose output is a family of follow-on designs, not one monolithic spec.

Problem

#2048 establishes the zettelkasten/knowledge layer on ID. Before building further, we need to know — systematically, not anecdotally — what the mature knowledge tools actually do, which of those features cluster into coherent ID designs, and how existing users' content gets in and out. Skipping this risks reinventing a worse Notion while missing the one feature (e.g. the graph, or daily notes) that makes a knowledge tool sticky.

Method (the program itself)

1. Enumerate: for each product below, produce a feature inventory from primary sources (docs, hands-on use): features named consistently so they can be compared across products.
2. Matrix: build a product × feature matrix (products as columns, features as rows, with notes on quality/implementation differences, not just yes/no).
3. Cluster: group features into coherent clusters; each cluster becomes one follow-on design ticket against id: design: Zettelkasten layer — multiplayer docs/wiki on ID #2048.
4. Decide per cluster: adopt / adapt to ID's multiplayer object model / explicitly reject with reasons. No feature is adopted by default just because a competitor has it.
5. Import/export designs (below) proceed in parallel — they depend on the object model in id: design: Zettelkasten layer — multiplayer docs/wiki on ID #2048, not on every cluster decision.

Products in scope

Obsidian, Evernote, Notion, OneNote, NotebookLM, Logseq, Joplin, Anytype, Open Knowledge.
(For each: capture its data model, sync story, sharing/permissions model, pricing/lock-in shape where it affects import/export difficulty, and its distinctive features — e.g. NotebookLM's source-grounded AI, Anytype's object/type model, Logseq's outliner + daily-journal model, Obsidian's local-first vault + plugin ecosystem.)

Feature clusters (expected; the matrix may redraw them)

Each of these is a planned follow-on design:

• Graph view cluster — the Obsidian-style graph view as its own cluster/design: local vs. global graph, edge types (links, backlinks, tags, typed relations), filtering, performance on large vaults, multiplayer/live graph behaviour on ID objects.
• Multi-device sync cluster — local-first vs. cloud-first sync, conflict resolution, offline editing, end-to-end encryption expectations, sync of attachments/media. (Must reconcile with ID's own sync/relay designs — link, don't duplicate.)
• Content model cluster — blocks vs. pages vs. daily notes: block-based editing (Notion/Logseq), page/document model (Evernote/OneNote/Obsidian), daily notes/journals as an organising primitive, outlines vs. freeform, databases/tables-as-content (Notion databases, Anytype sets/collections).
• Sharing & permissions cluster — see the ruled read-authority default below; also write/edit sharing, link sharing, workspace/team models, guest access, per-object vs. inherited permissions.
• Capture & organisation cluster — web clipping, quick capture/inbox, tags vs. folders vs. links, search (full-text, semantic), templates.
• AI-over-notes cluster (à la NotebookLM) — source-grounded Q&A over a user's corpus, summarisation, citation-back-to-source requirements, audio/overview generation if in scope, privacy model (whose AI sees whose notes), and how AI features respect the read-authority model below.
• Extensibility cluster — plugins/APIs (Obsidian plugins, Notion API), embeds/transclusion, scripting/automation.
• Attachments & media cluster — file handling, OCR/handwriting (OneNote/Evernote), PDF annotation.

Read-authority default (ALREADY RULED — fold in, do not re-litigate)

Drew has ruled the read-authority default for the knowledge layer (and it is recorded here so every cluster design inherits it):

• Default: public read.
• The owner may grant read to any number of groups and/or users (grants refine/augment the default per the resolution order).
• Resolution order: object → user default → server config → public. I.e. an object's own read setting wins; else the owner's user-level default; else server configuration; else public.
  Every cluster design (especially sharing/permissions and AI-over-notes) must state how it complies with this ruling; AI indexing/search must never expose content to a reader the resolution order would deny.

Import designs (one design per tool, minimum set)

Design importers for at least: Obsidian (vault of Markdown + attachments, wikilinks/backlinks, frontmatter, canvas?), Evernote (ENEX export, notebooks/tags, attachments), Notion (export/API, blocks → ID objects, databases, relations), OneNote (notebooks/sections/pages via export/API — expected to be the hardest; state fidelity limits honestly), Logseq (Markdown/org outliner graphs, daily journals, block refs), Joplin (Markdown + resources, notebooks/tags, JEX export).
Each import design covers: source format and how to obtain it, mapping into the #2048 object model (what maps cleanly, what degrades, what is dropped — with a user-visible fidelity report), link/backlink preservation, attachment handling, incremental/repeat import and deduplication, and a test corpus.

Export design

• Export into the most standard interchange format that works for as many tools as possible (expected candidate: a vault/folder of Markdown files with frontmatter + attachments folder — the Obsidian/Logseq/Joplin-common denominator — to be confirmed by the investigation, not assumed).
• Export must be lossless-enough to round-trip: ID → export → import into at least Obsidian, Logseq, and Joplin with links, tags, and attachments intact.
• Also specify a full-fidelity ID-native export (complete object data) alongside the interchange export, and how the two are presented to users.

Deliverables of this program issue

• The feature matrix document (linked from this issue).
• One follow-on design issue per cluster and per importer, filed and linked here.
• The export-format recommendation with evidence from the matrix.

Decomposition sketch

Follow-on design tickets to be filed from this issue:

1. Feature matrix investigation — enumeration method, product inventories, matrix document.
2. Graph view design (Obsidian-style graph as its own cluster).
3. Multi-device sync & conflict model for the knowledge layer.
4. Content model design: blocks, pages, daily notes, databases/collections.
5. Sharing & permissions design — implementing the ruled read-authority resolution order.
6. AI-over-notes design (NotebookLM cluster) — source-grounded Q&A, citations, privacy vs. read-authority.
7. Import designs batch: Obsidian, Logseq, Joplin (Markdown-native tools).
8. Import designs batch: Notion, Evernote, OneNote (hosted/proprietary tools) + interchange export design (most-standard format + round-trip tests).

Open questions

• Which product versions/editions are inventoried (free vs. paid tiers change the feature set materially)?
• Hands-on evaluation vs. documentation-only — how much time is budgeted per product?
• Is Open Knowledge a product, a standard, or a project in this context — confirm its identity before enumerating it.
• Does the graph view need to span all ID objects (boards, chat, files) or only knowledge objects in v1?
• AI-over-notes: local models, hosted models, or user's choice — and does AI processing change the read-authority analysis?
• OneNote import fidelity: what is realistically achievable, and do we ship a "best effort + fidelity report" importer or defer OneNote?
• Export: is plain Markdown + frontmatter actually the best common denominator, or does a standard like OPML / HTML / a documented JSON schema serve more tools?

Program note: expansion-style design — "a design to go make designs." A later pass breaks this into the follow-on design tickets above, then implementation tickets. Relatives: #2048.