dynodoc

Features

Paragraphs, cells and slide shapes keep a stable identity, and changes to them go through review into a recoverable history. This page says what exists, where it runs and what its limits are.

Open Projects Compare with Track changes

Status labels

  • Live In the hosted pilot today (application 3fa06fd, database schema 47).
  • In source Implemented and tested in source, not yet deployed.
  • Test build A downloadable test package, not a marketplace listing.

Identity and history

The rest of the product depends on two things: each part of a document keeps a permanent identity, and each change is appended to a log that can be checked.

  • Live

Stable identity for paragraphs, cells and shapes

Dynodoc reads a file as logical nodes: paragraphs, table cells, worksheet rows and cells, slides and shapes. Each gets a permanent ID the first time it is seen. Moving, rewording or reformatting changes the node’s content but not its ID, so its history stays attached to it when it moves.

  • Text inside a node is kept as formatting runs. Bolding a word splits runs and joins them again; the node and its history stay put.
  • Equal-looking text in unrelated places never becomes one node.
  • A matching file name or similar content can suggest a binding. It never grants access or authorship.

LimitsStable IDs for structures nested inside tables, and the rules for splitting, joining and moving them, are still in the engine plan (part 4).

Illustrative mockup with synthetic names. Run boundaries are drawn dashed.
  • Live:hash-chained events
  • In source:signed commits and receipts

Hash-chained history and signed commits

Each content change is a typed event linked to the one before it by a SHA-256 hash chain, so editing an old event breaks every link after it. Current state is folded from the log; snapshots are derived and verified, never authoritative. In the project repository, commits are signed with device keys and branch updates carry signed receipts.

  • Anyone with access to a document can verify the chain’s internal consistency.
  • Device keys are bound to an account and can be revoked permanently. Earlier signatures stay verifiable.
  • A client can pin a branch head in its own journal and detect rollback, forks and missing updates.

LimitsA hash chain shows the record is consistent, not who typed a sentence. Catching a complete rewrite by whoever runs the database needs an independently kept anchor; external witnesses are not built yet.

Illustrative mockup. Event names and values are synthetic.

Review

Edits are proposed as change requests. Project rules decide who must approve, and each outcome is recorded with the account that made it.

  • Live

Change requests, review and merge

A change request carries selected block changes against a base. Reviewers see what changed in content, formatting and structure, approve or ask for changes, and a merge records its parents, resolutions and result without discarding either contributor.

  • Independent edits combine after validation. Overlapping edits and shared constraints stop for an explicit resolution instead of a silent guess.
  • Project rules are a floor: a file rule can raise the approvals required, never lower them. Owning a file does not bypass review.
  • An approval names the version of the request the reviewer saw. If the request changes afterwards, that approval stops counting and a new one is needed.
  • Approvals, merges and overrides are written to the audit trail with the acting account.

LimitsReview is deliberate. There is no live co-editing and there are no collaborator cursors.

Illustrative mockup with synthetic names.
  • Live:per-file drafts
  • In source:project-wide branches

Private drafts and branches

Try different wording in a private draft without touching the team’s version. Compare it with main, submit it for review, or throw it away. In the project repository, branches and commits span several files at once, with the same review rules at a protected main.

  • Hosted Projects: a private draft per file, with a main-and-draft comparison and pull requests.
  • Local repository: signed multi-file commits, parents, branches moved by compare-and-swap, and every best merge base.
  • Shared history (schema 36): candidates are published explicitly, reviews bind the exact candidate and base, and main is protected.

LimitsThe Projects interface lists project-wide branches and reviews read-only. Creating and merging them there, and adoption by the add-ins, are in progress.

Diagram: a private draft branches from main, main moves on, and the merge commit has two parents.

Recovery and sync

Earlier states can be read and recovered. Recovery adds a new change that names its source; it does not rewind the log.

  • Live:per-file recovery
  • In source:commit-addressed recovery

Named versions, restore, revert and cherry-pick

Any retained revision can be inspected, not only the ones you named. Download the state before an edit, restore selected blocks, revert the net effect of a range of changes, or replay a chosen change onto another base. Each is a new, reviewable change with its source recorded.

  • Name a stage and publish a frozen read-only copy; revoke the link later.
  • Review shows deletions and structural dependencies, not only the recovered text.
  • In the project repository, commit-addressed revert and cherry-pick are signed, and are tested fifty commits back with later work preserved.

LimitsNative downloads of old revisions use the supported exporters, so complex formatting can still be lost. See the compatibility guide.

Illustrative mockup. Revision numbers and hashes are synthetic.
  • In source:shared writers off

Local project history and selected-history sync

The project repository lives on your device in SQLite, so commits survive a restart and offline work. A command-line client plans what would become shared, pushes only the selected history and the objects the server is missing, then fetches and fast-forwards a branch while checking every signature and receipt.

  • The plan lists every commit and dependency that would become shared, including private ancestry. A push cannot add anything the plan did not show.
  • A retry reuses objects and commits the server already accepted. Stale refs and corrupted objects fail closed.
  • Pull fast-forwards one chosen local branch with compare-and-swap. It never writes to an open document.

LimitsSchema 36 is deployed, but shared writers are off and no receipt-signing key is installed, so a push is refused on the hosted pilot. The example commands use an account token; the client can also sign in with a device key limited to one project.

  1. Step 1: plan 
    engine-cli sync work.sqlite PROJECT --remote remote.json --token-file account-token.txt --journal pins.sqlite --branch main plan COMMIT --out push-plan.json
  2. Step 2: push 
    engine-cli sync work.sqlite PROJECT --remote remote.json --token-file account-token.txt --journal pins.sqlite --branch main push push-plan.json
  3. Step 3: pull 
    engine-cli sync other.sqlite PROJECT --remote remote.json --token-file account-token.txt --journal other-pins.sqlite --branch main pull local-main
Commands from the selected-history sync guide. PROJECT and COMMIT are IDs; the file names are yours.

Access, editors and file formats

Dynodoc handles review and history. Microsoft and Google remain the editors, and access follows each person’s role in the project.

  • Live

Roles, audit and erasure

Access follows the team. Owners and managers control sharing; editors, reviewers and viewers get what their role allows. Reads, downloads, proposals and merges recheck current access every time, and permission and metadata changes keep their own operational audit.

  • Project profiles are visible only to shared members and never include an email address.
  • Revoked access ends history access. Public links and content hashes never grant it.
  • Erasure is explicit and audited. Content is removed, and opaque commitments keep the remaining record verifiable.

LimitsThese are product controls. They are not a compliance certification or a third-party audit.

Illustrative mockup with synthetic names.
  • Test build:no marketplace listing

Editor add-ins

Add-ins for Word, Excel and PowerPoint and add-ons for Google Docs, Sheets and Slides record edits to existing text and cell values while the pane is open. Send them for review, then preview approved team changes and apply them in one step. Sign-in happens in the browser; each connection reaches one file, expires after seven days and can be revoked.

  • Word and Docs: the text of existing paragraphs. Excel and Sheets: cell values, formula text and date-only values. PowerPoint and Slides: text in existing shapes. Up to 2,000 items per file.
  • Nothing is written to your file until you choose Apply, and the add-in stops if the file changed after the preview.
  • Not a background recorder or a keystroke log. Capture runs only while the pane is open.

LimitsDownloadable test builds only. No marketplace listing exists, and installed-editor acceptance has not been run.

  • Word
  • Excel
  • PowerPoint
  • Google Docs
  • Google Sheets
  • Google Slides
Illustrative mockup of the Word task pane. The other five hosts use the same flow.
  • Live

File adapters

Adapters read each format into the same logical nodes and runs, so review and history work the same across files. Add Word, Excel and PowerPoint files, plain text, Markdown and LaTeX to a project. Original uploads are kept, and supported content exports back.

  • .docx and .doc, .xlsx and .csv, .pptx, .txt, .md and .tex can be added to a project.
  • During testing, original files are limited to 3,000,000 bytes.
  • Layout-heavy features, macros, charts and embedded objects may not carry across. Check the compatibility guide before relying on a round trip.

LimitsRTF is the next planned adapter and is not certified. Preserving a formula is not a promise that two calculation engines agree.

  • Word DOCX · DOC
  • Excel XLSX · CSV
  • PowerPoint PPTX
  • Text and code TXT · MD · TEX
Formats accepted by the Projects upload today.

Compared with Track changes and version history

The built-in tools are good at what they do, and Dynodoc does not replace live co-authoring. The table shows where a recorded, reviewed history adds something and where it gives something up.

Comparison of Track changes, built-in version history and Dynodoc
QuestionTrack changesVersion historyDynodoc
Who changed whatYes. The author name is stored in the file and anyone with the file can change it.Per saved version, by the hosting service’s account. Coarse.Every event carries an authenticated account. Commits in the project repository are signed.
Review before it landsAccept or reject inside the file. No required approvals and no record of who agreed.No.Change requests with required approvals, policy floors and a recorded merge.
Try something privatelyNo.No. Copy the file.Private draft per file. Project-wide branches are listed read-only under Branches (in source).
Recover part of an old stateReject your own pending changes.Restore or copy a whole version.Restore selected blocks, revert or cherry-pick a range. Each is a reviewed new change.
Detect a rewritten recordNo.Controlled by the host. You cannot verify it yourself.Hash-chained events anyone with access can verify, with the limits stated above.
History across files and editorsOne file, one editor.One file, one service.One project history across files, through six connectors (test builds).
Live co-authoringYes, in Word and Docs.Handled by the host editor, not by version history.No. Changes are deliberate and reviewed. There are no live cursors.
Formatting changesTracks many formatting edits.Whole-file fidelity.Add-ins capture text and cell values only today. Web editors keep supported formatting.
SetupBuilt in.Built in.An account, a project and an add-in or an upload.

Track changes and version history describe the behavior of Word and Google Docs, Sheets and Slides in general; individual products and plans differ. Dynodoc figures describe the hosted pilot or, where marked, source.

Common questions

Longer answers are in the compatibility guide and on the roadmap.

Do we have to switch editors?

No. Dynodoc sits beside Word, Excel, PowerPoint, Google Docs, Google Sheets and Google Slides through add-ins, or takes an uploaded file. The basic web editors are optional. The add-ins are test builds today.

Is this Git for documents?

It borrows the useful parts of Git: commits, parents, branches and review. The unit is a paragraph, cell or shape instead of a line of text, and you work through actions in a web workspace. No Git commands are needed.

What runs today, and what exists only in source?

The hosted pilot runs application 3fa06fd on database schema 47, as of 23 October 2026. Shared project history is deployed with its writers off and no receipt-signing key installed, so publishing to shared branches is refused. The local repository and the sync client are implemented and tested in source. The roadmap lists each item with its status.

How large can a file be?

During testing, original uploads are limited to 3,000,000 bytes. Acceptance with 100, 250 and 500 MB files is future work, and no capacity figure is claimed.

Compatibility guide Roadmap Help

Open Projects

Create an invite-only project, add a document and open a change request.

Open Projects Why provenance matters