an effort to gather together all extant Joseph Smith documents and to publish complete and accurate transcripts of those documents with both textual and contextual annotation1
Diaryx enables anyone to have their own “Papers Project.” It is designed to make archival, annotation, and publication accessible to anyone.
However, this description is incomplete: why is it important for a person to have their own Papers Project? In short, it is because a society undergoing significant social and technological shifts needs strong, new social infrastructure that caters to those who may be more prone to self-criticism, rejection-senstivity, and avoidance.
Around 20% of people consider themselves neurodivergent. Around 20% of people live with mental illness. Both of those numbers are increasing over time. War and strife fill the world, and debate and discourse grows more heated. It has never been more difficult to connect with people.
"Alarming numbers of Americans are lonely. According to our recent national survey of approximately 950 Americans, 36% of respondents reported feeling lonely “frequently” or “almost all the time or all the time” in the prior four weeks. A startling 61% of young people aged 18-25 and 51% of mothers with young children reported these miserable degrees of loneliness."
The cost of disconnection is great. "Loneliness is linked to early mortality and a wide array of serious physical and emotional problems, including depression, anxiety, heart disease, substance abuse, and domestic abuse."
Ultimately, as long as people respect each others' rights, there isn't any one specific way that a human ought to behave or function. As the world grows more connected, more people encounter other people who have differing cultures, behaviors, and sensitivities. These need to be met with greater kindness and understanding.
Social media is a cesspool of misinformation and contention. "When we asked respondents who or what they think contributes to loneliness in America, technology (73%) topped the list". This result isn't surprising to anyone. But it is a shame that the technology designed to improve lives has instead darkened them with loneliness. We need to develop new social technology that respects the boundaries and honors the differences between people instead of blurring them.
[not finished]
historica is an experiment in readable, convergent version control. It follows one non-negotiable rule: a person must be able to inspect the history, understand its relationships, and recover stored content without decoding an opaque database or binary operation log.
shasum -a 256 already prints for its file.+ down the margin.historica keeps a journal's history beside its entries — convergent, inspectable, and durable on plain files — which is the same bet everything else at Diaryx makes. In the app it does more than remember: what you publish to a circle is a derived historica store, and what your readers write back travels home the same way.
Two siblings extend it rather than living inside it:
The core model, strict revision and operation formats, and replay all exist and are corpus-tested, and the app runs its publishing and remark layers on them. It isn't a general-purpose VCS today.
Lossless parsing and editing of config files — down to every comment, key order, and blank line.
Editing config files programmatically shouldn't mean reformatting them. fig parses JSON, JSON5, YAML, TOML, ZON, and its own dialect into a lossless AST, then splices your change in: a one-line diff, everything else byte-for-byte identical.
fig set config.yaml service.replicas 5 touches one line.fig comment --inline config.yaml service.replicas "bumped" — and they survive every edit and conversion.fig is the metadata layer of Diaryx — frontmatter in every entry goes through it, and flower is a structural editor built on its tree. Standalone, it's a library (crates.io, npm) and a CLI for anyone who scripts against config files.
Actively maintained and published: the Rust crate wraps the Zig core, an npm package ships it for JavaScript, and Homebrew carries the CLI.
A structural editor for config files — it edits the tree, not the characters.
Where a text editor edits characters, flower edits the tree. You navigate the parsed config structurally — into mappings, along sequences, down to scalars — and edit one value at a time. Every change is a path-addressed, lossless splice through fig's editor: the bytes you didn't touch stay byte-for-byte identical, and the document is only ever committed in a valid state.
flower is the config sibling of leaf: leaf's caret model is right for permissive document formats; a strict config grammar wants a structural one. It edits through fig's tree, and in Diaryx it's a natural front end for vault configuration and frontmatter.
Early prototype. Navigation, both views, typed edits, deletes, and save all work today; the roadmap in the repo says what isn't here yet.
leaf gives you an ordinary text caret — mouse, selection, a formatting toolbar — and turns every keystroke into an offset-addressed edit on twig's tree. The document stays a live, round-trippable AST the whole time you type into it, so a Markdown file and a Djot file are edited through exactly the same operations.
**bold** painted bold, delimiters hidden) — every rendered glyph maps back to its source byte, so carets and clicks ride the visible text in either.leaf is the editor underneath Diaryx's writing surface — the same core that renders an entry on Mac renders it on iPhone. It edits documents through twig's tree. Standalone, it's embeddable anywhere a rich-text view over plain files belongs.
Work in progress, and open about it: caret editing, mouse, selection, and both views work today; soft-wrap edge cases, inline images, and undo/redo are the known next steps.
Plaintext Records, Organized and Verifiable — a self-describing workspace of plain documents.
A prov workspace is a set of documents whose structure lives in the documents' own embedded metadata (frontmatter) — not in the filesystem layout, and not in an app-private sidecar folder. The files describe themselves, so anything that can read text can read the whole organization.
prov binary for working with workspaces without any app at all.prov is the vault engine underneath Diaryx — the part that makes a folder of Markdown behave like an archive. It stands on fig for the frontmatter and twig for the documents. Standalone, it's a Rust library anyone can build on.
Works for simple workspaces; active development is incorporating it into Diaryx. Released to crates.io as eleven crates via one tagged commit.
Where fig parses configuration files, twig parses documents. It's comparable to Pandoc, but with different goals: not conversion for its own sake, but exposing the abstract syntax tree so precise operations can be performed on it — then writing the document back, faithfully.
twig is the document model everything at Diaryx is written
against — every entry in a vault is a twig document, and
leaf is a rich-text editor over its tree.
Standalone, it's a library (crates.io as twig-doc)
for anyone who needs to treat markup as data.
Copyright © 2025–2026 Adam Harris. All rights reserved.
The Diaryx software, source code, documentation, and all associated materials in this repository (the "Software") are the exclusive property of Adam Harris (the "Licensor") and are protected by copyright and other intellectual property laws.
The Licensor publishes the source code of the Software so that it may be read, audited, and referenced. Making the source publicly viewable does not grant any license to use, copy, modify, merge, publish, distribute, sublicense, sell, or create derivative works from the Software, in whole or in part, except as expressly permitted in a separate written agreement signed by the Licensor.
All rights not expressly granted are reserved by the Licensor. No rights are granted by implication, estoppel, or otherwise. Nothing in this license shall be construed as a waiver of any of the Licensor's rights.
You may use the Diaryx application only through the official channels the Licensor provides (for example, app.diaryx.org and official app-store distributions), subject to the applicable Terms of Service and Privacy Policy. This license does not grant any right to run, host, or redistribute the Software yourself.
Unless a separate written agreement states otherwise, any contribution you submit to this repository is provided under, and you assign to the Licensor all right, title, and interest in, such contribution, so that the Licensor may license the combined work under these proprietary terms. See Contributing to Diaryx.
The Software may include or depend on third-party components that are licensed under their own terms. Those components remain governed by their respective licenses. This license applies only to the original work of the Licensor.
As far as the law allows, the Software is provided "as is", without warranty or condition of any kind, and the Licensor will not be liable for any damages arising out of these terms or the use or nature of the Software, under any kind of legal claim.
Any use of the Software not expressly authorized by this license or a separate written agreement is a violation of the Licensor's rights and automatically terminates any permissions you may otherwise have.
For prior public releases: versions of this Software distributed under a previous license remain governed by the terms under which they were received. This license governs the current and future versions of the Software.
]]>You can also email the founder directly at adam@diaryx.org. He is very friendly!
]]>A document record is the archival unit of a Diaryx workspace: everything the workspace knows about one gathered document. It is the target shape that every importer emits, the structure that annotation lives in, and the referent that identifiers point at.
The design follows the PHILOSOPHY: gather, transcribe, annotate, publish — the same structure the Joseph Smith Papers Project uses for each document (artifact, transcript layers, source note, editorial annotation). Everything is plain text — Markdown with frontmatter for prose, YAML for the card that stands in for a file that is not prose — and a document record is fully legible in any text editor.
A document record consists of:
<payload>.<ext>.yaml, minted beside the artifact by attach. It carries the artifact's title, its content: pointer, typed links, and provenance metadata. This is the record: there is exactly one document per artifact, and it is the sidecar.Only the artifact and its sidecar are required. A born-digital Markdown import needs no transcription; a photo of a letter usually wants one.
An earlier draft of this spec gave the artifact a Markdown catalog card of its own. That card was a second document about the same file, since attach had already minted the sidecar — two nodes in the tree, two rows in a lens, and no answer to which of them the record is. A transcription link would have had two places to hang off.
So the card is the sidecar, and there is no Markdown card. The cost is real and is accepted: a whole-file YAML document has no prose body, so the free-form source note is a frontmatter string (source_note:) rather than paragraphs under a fence. Anything longer than a note belongs in a sibling commentary file (see Annotation), which is where document-level prose was always meant to live.
An artifact and its sidecar are siblings in an attachments/ directory beside the index that contains them — the placement import_attachment writes and prov's reverse index requires (photo.jpg ⇄ photo.jpg.yaml is found by name alone, so the pair cannot be split). The containing index is resolved by the same rules a story written that day would use, so an artifact is filed under the period index the vault already files writing into, rather than into a folder of its own:
Daily/2026/
index.md (the containing index; contents: links the sidecar by id)
attachments/
letter-from-may-1943.eml (artifact, byte-for-byte)
letter-from-may-1943.eml.yaml (catalog card: content:, attachment: true, transcription:, provenance)
letter-from-may-1943.transcript.md (transcription)
There is no record folder and no date prefix. A record is a link neighbourhood, not a directory: the sidecar names its payload through content:, its transcriptions through transcription:, and its container through the index's spanning field. Tools must follow those links rather than assume any path — including attachments/, which is where writes land, not a location anything may rely on when reading.
Records are not confined to Documents/. That directory was this spec's earlier convention; placement now follows the vault's declared date view, and a user may move a record anywhere.
Born-digital text imports (a Day One journal, a folder of Markdown) have no artifact, and so no card and no attachments/ directory: they import as plain entries, filed into the same date structure by the same placement rules. A record is what an artifact gets; an entry is what text that was never anything else gets.
Extends prov's sidecar — which attach mints carrying title, content: and attachment: true — with transcription links and provenance metadata. The whole file is the metadata; there are no fences:
title: Letter from Ruth Harris, May 1943
content: letter-1943.jpg
attachment: true
created: 2026-08-16
transcription:
- '[Letter from Ruth Harris, May 1943 (transcript)](letter-1943.transcript.md)'
source: Grandma's shoebox, box 2
source_note: >-
Water-stained but legible. Ruth describes the week Dad was born.
This is the only surviving letter from this period.
date_of_document: 1943-05-12
people:
- Ruth Harris
places:
- Ogden, Utah
Two keys are prov's and are not this spec's to redefine: content: is the pointer to the payload, resolved relative to the sidecar's own folder, and attachment: true is what stops prov reading the payload as prose. Containment is not a key here at all — the index gains the spanning link, in id-form, so the relationship survives the sidecar being moved.
The two dates answer different questions and must not be conflated. created is when Diaryx/prov made the document — an act of the software, stamped like any other document's. date_of_document is when the original was made, which is a fact about the world that often only its owner knows. A scan made today of a letter from 1943 has created: 2026-08-16 and date_of_document: 1943-05-12.
This matters most to importers, which are the tempting place to blur it: an EXIF origin date, an email Date: header, and a Day One entry's timestamp are all statements about the original, so they belong in date_of_document. created is never inferred from the source — it is when the record entered this archive, and nothing else.
| Key | Type | Meaning |
|---|---|---|
content |
path | The artifact this card represents, relative to the card (prov's, not this spec's) |
attachment |
bool | true — marks the card a sidecar rather than prose (prov's) |
transcription |
link list | Transcription files for this artifact |
source_note |
string | Free-form note: condition, context, why it matters. The body a whole-file card cannot have |
source |
string | Provenance: where the artifact came from (see Provenance below) |
date_of_document |
date, or unknown |
When the original was made (distinct from created, which is when Diaryx made the document). See below |
people, places |
string lists | Entities appearing in or associated with the document |
All provenance keys are optional. Unknown keys remain permitted, as everywhere in Diaryx frontmatter.
date_of_document: unknownA date lens groups by a chain — [date_of_document, created, updated], declared per-vault as a view's group: — and the chain is first key present wins, not first key parseable. A grain then cuts the winning value, and validates rather than slices: banana at year grain is not the group bana, it is no group at all.
Those two rules compose into the marker. Writing
date_of_document: unknown
stops the chain at the first link and yields a value no grain can cut, so the document files as undated instead of inheriting the day it was scanned. Verified against prov: a document carrying date_of_document: unknown alongside created: 2026-01-01 lands in (ungrouped), while the same document without the marker lands in 2026.
This is what a shoebox needs. A folder of 200 undated scans imported on one afternoon would otherwise all inherit that afternoon through created, burying a year of the reader's real archive under a day that means nothing about any of the documents. Undated is the honest answer, and the marker is how a record gives it.
Two consequences worth stating plainly:
unknown — any uncuttable value stops the chain identically, so a typo'd May 1943 silently files as undated too. unknown earns its place by saying deliberately unknown to the next human, not by doing anything special to the engine. (Nor does anything catch the typo: prov's check does not validate type: date values, which is a real gap and not this spec's to close.)date_of_document is already load-bearing for placement. Period indexes are resolved by the date they carry rather than by title — real ones are titled 2025-03 index, December 2025, March 2026 and 07, and no title rule matches all four — so the index-creating path stamps date_of_document on each index it makes. The key is structural, not merely descriptive, and a tool writing it is participating in filing.A transcription is an ordinary Markdown file — fenced frontmatter and a prose body, unlike the card — with a back-link to that card:
---
title: Letter from Ruth Harris, May 1943 (transcript)
transcription_of: '[Letter from Ruth Harris, May 1943](letter-1943.jpg.yaml)'
transcription_status: needs_review
audience:
- family
---
Dear Mother,
We are all well here, though the rain has not let up since Tuesday...[^1]
[^1]: Spring 1943 was unusually wet in northern Utah.
| Key | Type | Meaning |
|---|---|---|
transcription_of |
link | Back-link to the attachment sidecar (pairs with transcription, following the link/link_of convention). It names the card, not the payload — the card is the record, and a payload prov cannot read as text has nothing to link back from |
transcription_status |
enum | draft → needs_review → verified |
Machine-produced text (OCR, speech-to-text) is a draft pending human review, never silently treated as truth:
draft — machine-generated or in-progress, not yet human-reviewedneeds_review — complete but awaiting verification against the artifactverified — a human has checked it against the artifactThis gives users the archivist workflow: gather → transcribe → verify → annotate → publish. verified is a position in that workflow, not an attributed claim about particular bytes — see Provenance below for what it does not yet say, and what prov will eventually let it say.
transcription is a list. A record may carry multiple layers — e.g. a verbatim transcript (original spelling, strikethroughs preserved) and a normalized reading copy — as separate files. No layer-type key is defined yet; distinguish layers by title until real usage motivates one.
Two forms, both plain Markdown:
links or contents), for essays, research notes, or historical introductions about the document.Explicitly out of scope: standoff annotation. No character-offset or range anchors into transcripts — offsets break on every edit. If in-text anchoring beyond footnotes is ever needed, anchor to quoted text snippets (fuzzy-matched), not positions.
This spec's source key and transcription_status lifecycle predate prov's provenance proposal, which reaches for the same goals with more mechanism behind it. That proposal is an early draft — eight open questions, three of which change the shape of the rest, and a Phase 0 that is carry only — so nothing here changes today. What this section fixes is the layering, so that neither side grows a duplicate of the other.
transcription_status is not prov's verified, and should not become itprov proposes verified: [{by, at, of}] — an append-only list of dated, attributed confirmations, each bound to the fixity digest it was made against — with trust tiers derived from the entries rather than stored. Diaryx's transcription_status looks like a smaller version of that, but the two answer different questions and both are worth keeping:
transcription_status is a position in the transcription workflow. needs_review has no prov equivalent and will not get one: prov's proposal lists workflow as a non-goal ("no review queues, no assignment, no approval states").verified is an attributed, dated, digest-bound claim. It says who checked, when, and against which bytes.The intended relationship is that the second backs the first, rather than replacing it: transcription_status: verified is legitimate only when a verified entry exists whose of matches the transcription's current digest.
Diaryx's verified is a bare enum, so it survives an edit to the transcription it describes. Someone checks a transcript against the artifact, someone else fixes a line, and the frontmatter still claims the transcript is verified — prov's proposal names this exact failure and calls it worse than having no vocabulary at all, "because it launders staleness as assurance."
Diaryx stamps fixity over attachments by default, and a vault can widen it to fixity: all in config.yaml, which is what puts a content_hash on a transcript's own body — so the ingredient is available, but a vault that wants checkable transcription claims has to ask for it. When prov's Phase 2 lands, the demotion rule comes with it: a transcript whose bytes no longer match the digest its verification was made against falls back to needs_review, and prov reports a VerificationStale finding. Until then this is a known, unenforced gap, not a solved problem — and transcription_status: verified should be read as "a human said so at some point," not as a checkable claim.
Two rules from the proposal apply to Diaryx as written, and are worth stating here because importers are the tempting place to break them:
verified. A clean OCR run, a confident speech-to-text score, and a passing prov check are all attestations about state; verification is a claim about meaning, and only a person or a named process makes one.source and prov's sourcessource stays a free-form human string — Grandma's shoebox, box 2 is not a path and never will be. It is the narrow case of prov's proposed sources list.
The part worth tracking is §6 of the proposal: extending prov's fields mechanism from term-valued to path-valued fields, so that a frontmatter string prov knows is a path gets rewrite-on-move, locator handling, and dangling-reference reporting for free. It is Phase 1, independently valuable, and fixes a live bug rather than adding a capability. When a document record's provenance needs to name another document in the workspace — a finding aid, an accession record, a parent collection — that belongs in a path-valued sources field, not in source, and not in a new Diaryx-specific key.
Identity is prov's, not Diaryx's. This spec earlier described a hand-rolled ID index (Meta/Ids.md, reached through a Config indirection); prov settled the question first and differently, and that design was never built. What follows is the layer Diaryx actually runs on.
prov treats identity as a strictly-additive layer over a workspace that already works on paths alone: the graph, traversal, and mutation layers never dereference an ID, and turning identity off changes nothing about how a record is stored or linked. IDs are minted at registration rather than derived — an unregistered document has no opaque ID at all and is addressed by path. Two config axes govern it, both set in the vault's config.yaml:
identity: none | lazy | eager — when an ID is minted. lazy (prov's default) registers on link-by-id or publish, keeping the registry to the minimal set something external depends on. Diaryx runs eager, which also registers on create: stable identity from birth, at the cost of a registry entry per document.id_storage: registry | frontmatter | both — where a registered ID lives. Diaryx runs both: each document carries its own id field and the registry document is a rebuildable cache. Frontmatter storage is what makes identity move- and copy-robust — the ID travels with the file, which is exactly what an artifact and its card copied out of the workspace need.The registry is a first-class member of the workspace, discovered through prov's registry pointer relation off the root. It is not a Meta/ convention, and nothing in this spec should assume its path.
What remains Diaryx's is what publication means. Publication turns a registered ID into a permanent promise: at publish time the file receives a permalink frontmatter key holding the full URL with the ARK inside, in the canonical bare-ark form served by the site proxy (e.g. permalink: https://diaryx.org/ark/dxg6h4ncm/4k2ph9t, blades illustrative; the ark:99999 prefix form is accepted as an alias). The ARK's workspace blade is the vault's prov workspace_id, and its file blade is the document's prov id — prov and diaryx_ark mint the same 6-random-plus-check shape over the same alphabet, so publication mints nothing per file and stores no second identifier. The ID is thereby recorded redundantly — in the document, in the registry, and in the server-side publish record — and must never be reused or reassigned.
The ARK envelope itself (NAAN, dx shoulder, check character, .<FILE>/?<QUERY>/#<CALLOUT> suffixes) is specified in the ROADMAP; the alphabet and blade lengths are diaryx_ark's, which follows prov's minter.
Every importer emits document records. Import is a first-class workspace crate (crates/diaryx_import), not a plugin — the Extism stack that once held it was removed in archive/tauri-web-1.6.1, and the crate archived alongside it targeted the since-deleted diaryx_core. Its parsers are pure (bytes -> records) and port forward; its writer does not, because it emits the Markdown card this spec no longer describes.
The contract:
ImportedEntry → an entry file (title, date, body, extra frontmatter), for born-digital text with no artifactImportedAttachment → an artifact written through Workspace::import_attachment, which places the payload and lets prov mint the sidecar; the importer then stamps provenance onto that sidecartranscription_status: draft, linked from the sidecar's transcription:people, EXIF origin date → date_of_document, etc.), and write date_of_document: unknown when the source offers no date for the original — never today's date, and never a date inferred from createdNothing an importer writes may claim more than it knows. Deterministic decodes of born-digital originals (e.g. the text part of an email) may enter as transcription_status: verified; OCR and speech-to-text must enter as draft, per the lifecycle above.
people/places should eventually be links to entity pages rather than bare strings. Bare strings are forward-compatible with this (a string can be upgraded to a link), so start simple.This Privacy Policy describes how Diaryx ("we", "us") collects, uses, and protects your information when you use our applications and services (the "Service").
Diaryx is local-first, and there is no cloud sync. Your notes are files in a folder on your own device. We never receive them.
The only content that reaches our servers is content you explicitly publish. Everything below is mostly about that, and about the small amount of account data needed to run it.
Of that, the part you publish privately — a site behind a share link or a password — is encrypted on your device before it is uploaded. We store it, serve it, and cannot read it.
Payment is processed entirely by Stripe (web) or Apple (iOS/macOS). We never see or store your card details. We store only the identifiers those providers give us to recognize your subscription: a Stripe customer and subscription ID, or an Apple original transaction ID.
We never use your content to train AI models. Diaryx does not send your notes to any AI provider on its own initiative. Where the Service offers an optional AI-assisted feature, content is sent to the model provider only for the specific request you invoke, and only when you invoke it. (As of July 30, 2026, no AI-assisted content is available in the Service, optional or otherwise.)
app.diaryx.org/api.We use the following third-party services:
| Service | Purpose | Data Shared |
|---|---|---|
| Cloudflare | All hosting: compute (Workers), database (D1), object storage (R2), domain routing (KV), CDN, and TLS | Everything the Service stores or serves, plus request metadata. A private site's pages reach Cloudflare already encrypted, so what is shared there is ciphertext |
| Resend | Sending sign-in emails | Email address |
| Stripe | Payment processing (web) | Email address, payment details you enter with Stripe |
| Apple | Payment processing (iOS/macOS) | Apple ID, payment details you hold with Apple |
We do not sell your data to third parties.
You may:
diaryx export command can additionally produce an audience-filtered copy of a vault.If you are in the EU/EEA or the UK, you also have rights under the GDPR including rectification, erasure, data portability, restriction of processing, and the right to lodge a complaint with your supervisory authority. To exercise any of them, contact us at the address below.
The Service is not directed at children under the age of 13. We do not knowingly collect personal information from children under 13. If you believe we have collected such information, please contact us so we can delete it.
We may update this Privacy Policy from time to time. If we make material changes, we will notify you via the Service or by email. The "Effective Date" at the top indicates when the policy was last updated.
If you have questions about this Privacy Policy, contact us at contact@diaryx.org.
]]>These Terms of Service ("Terms") govern your use of Diaryx, including the Diaryx apps for macOS and iOS, and the diaryx command-line tool (collectively, the "Service"). By using the Service, you agree to these Terms.
Diaryx is a local-first note-taking and journaling application. Your notes are plain files in a folder you choose on your own device; the app reads and writes that folder directly.
An account is optional. It exists to enable the online features:
*.diaryx.org subdomain or on a custom domain you ownThe Diaryx server is also available to self-host under the license in Section 7.
Diaryx does not currently offer cloud sync. Nothing leaves your device except what you explicitly publish. Keeping a vault available across your own devices is something you arrange yourself — for example by putting the folder in iCloud Drive or another file-syncing service of your choosing — and any such service is governed by its own terms, not these.
If we add a sync feature later, we will describe it here before it applies to you.
To use the online features you must create an account with a valid email address. Sign-in is by emailed link or code. You are responsible for maintaining the security of your account and of the devices signed in to it.
Each account may have a limited number of registered devices signed in at once. This ceiling is a security backstop against a leaked or shared credential, not a plan feature, and is set well above what any individual would reach. You can review and remove your registered devices in the app's account settings.
Storage figures below are decimal: 1 GB means 1,000,000,000 bytes.
Writing is never counted. The storage figures below apply to published photos and files only. The text you publish — your pages, and the rendered site made from them — does not count against any plan's storage, on any plan, however much of it there is.
The Free plan includes:
*.diaryx.org subdomain for your siteDiaryx Plus costs $4.99/month (USD) and includes:
The custom-domain and circle allowances belong to your account as a whole, not to each workspace. Free *.diaryx.org subdomains are not counted against the domain allowance.
Accounts created before the Free plan's photo-and-file allowance was reduced from 200 MB keep the allowance they signed up under.
If your Plus subscription ends, nothing you have published is taken down. Your sites stay online and readable, your workspaces stay connected, and you can keep publishing what you write. What the Free plan does not include — additional workspaces, sites and domains, and photos and files beyond its allowance — you can no longer add until you subscribe again.
The price shown at the point of purchase is the price that applies. Plus subscriptions renew monthly until cancelled. You may cancel at any time:
Cancelling stops future renewals; your Plus features remain active until the end of the current billing period. Refunds for purchases made through Apple are handled by Apple under its own policies.
We may change plan limits and pricing. If a change reduces what your existing plan includes, or raises its price, we will tell you before it takes effect.
You retain all rights to the content you create with Diaryx. We do not claim ownership of your notes, entries, or attachments.
Content stored only on your own device is never transmitted to us. When you publish, the content you selected is uploaded to our servers and served at the audience level you chose. Removing it from your site removes it from our servers; it may persist briefly in caches and backups.
You are the publisher of anything you publish through the Service, and you are responsible for having the rights to publish it.
You agree not to:
We may remove published content, or suspend publishing for an account, in response to a valid legal complaint or a clear violation of this section, with notice when practicable.
If you point a domain you own at the Service, you are responsible for that domain's registration and DNS. We provision and renew a TLS certificate for it while it is registered with us and pointed at us. Removing the domain from your account stops that.
The Diaryx software is closed source. All rights are reserved by Adam Harris as of 2026. Your use of the software is subject to that license, which means you may not copy, modify, reverse-engineer, or otherwise tamper with the Diaryx binary or its source code, though you retain all rights to the content you provide and interact with through the Service. Diaryx workspaces are based on the open-source software Prov, and users may alternatively interact with their workspaces through the Prov command-line interface. For more details, see LICENSE.
You may delete your account at any time. We may suspend or terminate your access to the Service if you violate these Terms, with notice when practicable.
Upon termination, your published sites are taken down and your uploaded data may be deleted from our servers. The files on your own devices are not affected — deleting your account does not delete your notes.
The Service is provided "as is" without warranties of any kind, express or implied. We do not guarantee that the Service will be uninterrupted or error-free.
You are responsible for backing up your own data. Diaryx has no copy of anything you have not published.
To the maximum extent permitted by law, Diaryx and its operators shall not be liable for any indirect, incidental, special, consequential, or punitive damages, or any loss of data, profits, or goodwill, arising from your use of the Service.
Our total liability for any claim arising from the Service is limited to the amount you paid us in the 12 months preceding the claim.
For apps obtained through the App Store: Apple is not a party to these Terms and has no obligation to provide support or maintenance for the Service. Apple is not responsible for addressing any claim relating to the app, and Apple's maximum liability to you in the event of a defect is the purchase price, if any. You represent that you are not located in a country subject to a U.S. Government embargo and are not on any U.S. Government restricted-parties list.
Apple and its subsidiaries are third-party beneficiaries of these Terms, and upon your acceptance of these Terms Apple will have the right (and will be deemed to have accepted the right) to enforce these Terms against you as a third-party beneficiary. We, not Apple, are solely responsible for the app, its content, and any maintenance or support for it, and for addressing any claims relating to it.
We may update these Terms from time to time. If we make material changes, we will notify you via the Service or by email. Continued use of the Service after changes take effect constitutes acceptance of the updated Terms.
These Terms are governed by the laws of the State of Utah, United States, without regard to conflict of law principles.
If you have questions about these Terms, contact us at contact@diaryx.org.
]]>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.
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.
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:
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.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 inputstranscribe_page already returns a draft, and diaryx_ffi defers writing it into the vault as "the workspace's job". Nothing does that job yetDone, 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:
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.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.
Archival trust for a small project comes from the exit story, not from the software surviving:
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.
Be able to store version history of a workspace via a OCFL implementation.
]]>