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).

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:

  • Promote import from an extism-only plugin to a first-class workspace crate (crates/diaryx_import), with the extism plugin as a thin adapter over it
  • Retrofit existing importers (Day One, email, directory) to emit document records — validates the spec against born-digital inputs
  • Widen by shoebox-frequency: Google Docs/Drive, blog exports (WordPress/RSS), Apple Notes

3. Identifiers: index-based, permanence at publish time

File IDs move out of frontmatter into a workspace ID index linked from Meta/Config.md (e.g. Meta/Ids.md, unsharded until scale demands it).

  • Private files rely on the index alone. Their IDs are workspace-internal and disposable; they exist for local-first benefits — rename-proof internal links and stable sync identity.
  • Published files get a permalink: <full URL with ARK ID inside> in their frontmatter at publish time. Publication is the moment an ID becomes a permanent promise: recorded in the index, in the file, and in the server-side publish record.

ARK minting is therefore a publish-time contract, 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/dxBBBBBBC/BBBBC[.<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 B is a betanumeric character from this alphabet to reduce ambiguity:

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

Each capital C is a checksum character calculated from the previous ID sequence, to capture transcription errors.

.<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 characters to identify a workspace is enough for worldwide Diaryx usage (28^6 = 481,890,304), and 4 characters should be plenty of files allowed for a workspace (28^4 = 614,656). 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.