Diaryx is currently at version v2.0.0. The mission is archival: making a personal "Papers Project" — gather, transcribe, annotate, publish — accessible to anyone (see PHILOSOPHY).

Direction (planning session, 2026-07-03)

The next phase centers on the gather/import wedge: the person who most wants a personal Papers Project has existing material — a shoebox of letters, old journals, exported blogs, scattered Google Docs — not just new writing. Diaryx should be the best tool for getting that material in, transcribed, and annotated.

The unifying piece is the document record: a specified archival unit (artifact + catalog card + transcription + annotation) that every importer targets, annotation lives in, and identifiers point at. See the Document Record Spec.

Near-term priorities

1. Document record spec

Finalize the Document Record Spec: attachment notes as catalog cards (typed transcription: links, provenance metadata), transcription files with a draft → needs_review → verified lifecycle, annotation via footnotes and sibling commentary files (no standoff/offset anchoring — ever).

The remaining open piece is provenance. transcription_status: verified is currently a bare enum, so it survives an edit to the transcript it describes — a stale assurance sitting in frontmatter. prov's provenance proposal fixes this by binding a verification to the fixity digest it was made against, and the spec's Provenance section records the intended layering: transcription_status stays the workflow position, prov's verified becomes the attributed claim that backs its terminal state. That proposal is an early draft whose Phase 0 is carry-only, so this waits on prov rather than growing a Diaryx-specific duplicate.

2. Gather: photo/scan → OCR → document record

The first new importer and the flagship demo: photograph a physical document, get artifact + draft transcript + catalog card in one gesture. Machine transcripts enter as transcription_status: draft, giving users the archivist workflow (gather → transcribe → verify → annotate) rather than a black-box import.

Then:

• Done. Build import as a first-class workspace crate (crates/diaryx_import). This was written as "promote import from an extism-only plugin", which was no longer the situation: the Extism stack and the old diaryx_import were both removed in archive/tauri-web-1.6.1, and that crate targeted the since-deleted diaryx_core. Its parsers (Day One, email, markdown) are pure bytes -> records and port forward; its writer did not, since it emitted the Markdown catalog card the Document Record Spec no longer describes. There was no plugin to adapt.
• Done. Lead with a directory importer — a folder of scans and documents is the literal shoebox, and it exercises the artifact + card path end to end. It is reachable everywhere it should be: diaryx import <folder> (with --dry-run), and "Bring In What You Have…" in the app's add menu and Browse's empty state. The app asks twice — a scan says what would happen, and only then does anything get written — because an import of several hundred documents has no undo. Still to do: retrofit the ported parsers (Day One, email, markdown) to emit document records, which validates the spec against born-digital inputs
• Write the transcription half: transcribe_page already returns a draft, and diaryx_ffi defers writing it into the vault as "the workspace's job". Nothing does that job yet
• Widen by shoebox-frequency: Google Docs/Drive, blog exports (WordPress/RSS), Apple Notes

3. Identifiers: prov's registry, permanence at publish time

Done, and not the way this section originally planned it. The plan was a Diaryx-owned ID index linked from Meta/Config.md; prov settled identity first, and the vault runs on that instead. Identity is a strictly-additive layer over a path-only workspace, IDs are minted at registration rather than derived, and two config axes govern it — Diaryx sets identity: eager (register on create) and id_storage: both (each document carries its own id, with prov's registry document as a rebuildable cache). Frontmatter storage is what makes a record folder copied out of the vault keep its identity.

What stayed Diaryx's is the meaning of publication:

• Published files get a permalink: <full URL with the ARK inside> in their frontmatter at publish time. Publication is the moment an ID becomes a permanent promise: recorded in the document, in the registry, and in the server-side publish record.
• The ARK's workspace blade is the vault's prov workspace_id; its file blade is the document's prov id. The two minters agree by construction, so publishing mints nothing per file and stores no second identifier.

ARK minting is therefore a publish-time contract layered over prov identity, not a filesystem feature.

4. Trust artifacts

Archival trust for a small project comes from the exit story, not from the software surviving:

• Publish the format specs (frontmatter conventions, document record, ARK scheme) as open documents others could implement — formats outlive apps
• Make "if Diaryx vanishes tomorrow, you lose nothing" a marketing centerpiece
• Design ARK resolution to degrade gracefully: the ID mapping ships inside the workspace itself, and eventual NAAN registration/N2T means resolution can outlive diaryx.org

ARK identifier format

ark:99999/dxXXXXXXC/XXXXXXC[.<FILE>][?<QUERY>][#<CALLOUT>]

Eventually Diaryx as an organization will register for a NAAN, which will replace 99999. dx is the "shoulder" of the ID, which allows for changing the ID format in the future if needed. Each capital X is an extended digit from the 29-character NOID alphabet — digits plus consonants, with no vowels (avoiding accidental words), no l (ambiguous with 1), and no y:

0 1 2 3 4 5 6 7 8 9 b c d f g h j k m n p q r s t v w x z

Each capital C is a NOID check character calculated from the preceding characters, to catch transcription errors. So a workspace blade is 9 characters (dx + 6 + check) and a file blade is 7 (6 + check).

A blade may contain — and begin with — a digit, so anything writing one into metadata has to keep it a string, or YAML/JSON scalar inference turns 0123456 into a number and loses the leading zero.

This alphabet is not a free choice. A file blade is a prov id (see §3), so diaryx_ark must spell ids exactly as prov's minter does or every published permalink fails its own validation. Both previously used betanumeric (bcdfghjkmnpqrstvwxyz23456789); prov moved to the canonical NOID alphabet so its check character would agree with a real NOID minter, and Diaryx followed. That is a hard break in both directions, deliberately not softened: the alphabets differ in membership (y is betanumeric-only, 0 and 1 are xdigit-only), and even where characters are shared the ordinals differ, so the check character differs. Accepting both would leave a blade valid under either check — which is a blade whose check character has stopped detecting typos. ARKs minted and published before the change are invalidated by it.

.<FILE> is a way of accessing different versions of the same file. ?<QUERY> is a way of accessing metadata for a file. #<CALLOUT> is a client-only method of highlighting a specific portion of the content and isn't actually used by the server.

ARKs typically reserve ?info and ?json, as well as ??. These are reserved alongside content for special query functionality rather than mapping literally to frontmatter metadata key names. To access a literal info or other reserved-name frontmatter key, a namespace like ?meta=info or a leading dot like ?.info is under consideration.

6 random characters is enough to identify a workspace for worldwide Diaryx usage (29^6 = 594,823,321), and the same width covers the files within one workspace. Both are minted randomly rather than sequentially — opaque for free, with no sequence to hide — and uniqueness is enforced by rejection at the caller. If usage somehow exceeds this, the dx shoulder can be changed to make a new ID format that allows for more room.

OCFL Provenance

Be able to store version history of a workspace via a OCFL implementation.