Version control for documents, spreadsheets and presentations

Dynodoc records edits to paragraph text, cell values and slide text in Word, Docs, Excel, Sheets, PowerPoint and Slides, routes them through review, and keeps the merged result in a hash-chained history that can be checked.

Pre-alpha 0.0.1b: a desktop app for Windows and Linux that keeps your workspace on your own computer, or a sample workspace in your browser. Add-ins ship as test installs; marketplace listings are not live. The engine, API and command-line tools are open source (MIT).

Illustration with sample content, not a screenshot of a real file.

WORKS WITH

  • Word
  • Excel
  • PowerPoint
  • Google Docs
  • Google Sheets
  • Google Slides
  • DOCX
  • XLSX
  • PPTX
  • CSV
  • Markdown

How it works

Dynodoc runs beside the editor. It records changes against stable identities, routes them through review, and keeps the outcome in a log that anyone with access can check.

  1. Step 1

    Capture in your editor

    An add-in in Word, Excel, PowerPoint, Docs, Sheets or Slides records edits to existing paragraphs, cells and slide text against stable identities. Capture runs while its pane is open; there is no background agent.

  2. Step 2

    Review as a change request

    Push the captured changes to a project. Reviewers see what moved, approve or ask for changes, and the project’s rules set how many approvals a merge needs.

  3. Step 3

    Merge and record

    A merge records its parents, resolutions and resulting state in an append-only, hash-chained log. The result can be pulled back into the file.

Writing stays in the editors. The project holds the review and the history shared between the copies.

Supported editors

All six add-ins use the same capture protocol. Each tab shows an illustration of the pane that opens beside the file, with sample content, and what the add-in captures.

OPENS FROM
Home ribbon > Dynodoc
CAPTURES
Existing paragraph text in .docx files.
DETAIL
Content-control tags keep each paragraph’s identity across saves. Needs WordApi 1.3.

Capture runs while the pane is open, and there is no background agent. Structure and formatting changes go through edited-file push. Add-ins ship as test installs today; marketplace listings are not live, and installed-editor acceptance has not been run. Install steps and limits


Change requests and review

A change request shows which paragraphs, cells and slides moved. Reviewers approve or ask for changes, and the merge follows the project’s rules.

  • Word-level diffs

    Changed words are marked inside the paragraph, cell or slide, so a reviewer reads the edit instead of the whole page.

  • Approvals with rules

    A project can require one to five approvals before a merge. Owners and managers can override, and the audit log records that they did.

  • Policy floors

    A project sets the minimum protection for every file inside it. A file can tighten the rules and never weaken them.

Example diffs in Word, Excel and PowerPoint

Board update.docx · Summary, paragraph 1 Maya Chen · 2 min ago
-Revenue grew sharply in Q3.+Revenue rose 12% in Q3.
Q3 budget.xlsx · Sheet1!D4 Sam Okoye · yesterday
-=C4-B4+=C4/B4-1
Launch plan.pptx · Slide 1 title Priya Nair · 3 days ago
-Launch plan+Launch plan: October beta

An append-only, hash-chained history

Who changed what, and when, is recorded as typed events in a log that anyone with access can check.

  • Append-only

    Events are never updated or deleted. Restoring or reverting adds a new commit that points back at its source; history is not reset.

  • Hash-chained

    Each event’s hash covers the one before it, so changing the past breaks every hash after it. Anyone with access can walk the chain and check it.

  • Signed commits

    Project commits in the open-source engine and CLI carry an Ed25519 signature from the author’s device key. Revoked keys stop signing; older signatures still verify.

Illustrative project with synthetic names. The hash chain runs in the hosted workspace today; signed project commits are in the engine and CLI and are not yet the hosted default.


Projects, drafts and named versions

A project groups related files and gives people roles. Each file keeps its own history, drafts and change requests.

  • Projects

    Related Word, Excel, PowerPoint, CSV and Markdown files live together with one set of members and one set of rules.

  • Drafts

    Each person can work in a private draft of a file and share selected changes when they are ready. Project-wide branches exist in the engine, and the workspace lists them read-only under Branches.

  • Named versions

    Name a milestone such as Board pack v3 and return to it. Restoring creates a new change; newer work is not erased.

  • Recovery

    Revert a past change or replay it onto the current version. Either one is a new commit that points back at the change it came from.


Where the project stands

Dynodoc is early software. The test count is from one run of the public engine repository’s CI on 20 October 2026 (UTC), and the schema is the one the hosted workspace has run since 23 October 2026. None of it counts customers, users or uptime.

1,285

Rust tests passing in the public engine’s CI on Linux, macOS and Windows (1,284 on Intel Macs, where one timing test is excluded).

6

editor add-ins, as test installs. No marketplace listing exists, and installed-editor acceptance has not been run.

47

PostgreSQL schema version, deployed on the hosted workspace.


Running the open-source engine

The engine, API and command-line tools are open source under the MIT licence. Run the API on your own machine against PostgreSQL 16. The workspace and website are not published as open source.

  1. Step 1

    Start PostgreSQL 16 on loopback port 5548

    task up
  2. Step 2

    Apply migrations with the operator login

    task migrate
  3. Step 3

    Grant the restricted runtime login its allowlist

    task db:grant-runtime
  4. Step 4

    Run the HTTP API on loopback port 8080

    task run

First copy the two example env files, set the keys and create the restricted runtime login, as the engine README describes. The API listens on loopback only and never applies migrations itself. The commands need Docker, Rust and Task.


Common questions

Including what Dynodoc does not do.

What is Dynodoc?

Dynodoc is version control for documents written in Word, Google Docs, Excel, Google Sheets, PowerPoint and Google Slides. It records changes against stable paragraph, cell and slide identities, routes them through change requests and review, and keeps an append-only, hash-chained history that can be verified. Editing stays in those editors.

How is it different from track changes or version history?

Track changes and built-in version history live inside one file in one editor. Dynodoc keeps one history across files and editors: a project with private drafts, change requests with approval rules, named versions and a hash-chained log of who changed what and when. A change made in Excel and a change made in Word are reviewed in the same place.

Which editors and file types does it work with?

Word, Excel and PowerPoint through task-pane add-ins, and Google Docs, Sheets and Slides through Apps Script add-ons. You can add DOCX, XLSX, PPTX, CSV and Markdown files to a project. Dynodoc also has basic web editors for documents and spreadsheets, which are not the main product.

How does capture work?

An add-in watches the open file while its pane is open and records edits to existing paragraph text, cell values and formulas, and slide text. There is no background agent, so edits made while the pane is closed are picked up by pushing the edited file instead. A reviewer sees what was captured before anything merges.

Is the history tamper-evident?

Every event is appended and hashed together with the one before it, so altering an earlier event breaks every later hash, and anyone with access can verify the chain. That is tamper-evident, not tamper-proof: spotting a wholesale rewrite by a database administrator also needs a hash or backup you kept independently. External witnesses are planned, not shipped.

Can I self-host it?

Partly. The engine, HTTP API and command-line tools are open source under the MIT licence. The engine repository explains how to run them against PostgreSQL 16 with Docker, Rust and Task: task up, task migrate, task db:grant-runtime and task run. The workspace and website are not published as open source, so the full hosted application cannot be self-hosted from public source. Private document content you put in the hosted app does not become open source.

What does it not do?

There is no character-by-character co-editing and no live collaborator cursors; collaboration works through drafts, change requests and deliberate merges. The add-ins do not run in the background and do not capture every keystroke, layout change or embedded object. Dynodoc is not a replacement editor for Office or Google, and it makes no compliance claims.

What does it cost, and who can use it?

There is no paid plan and no payment flow yet. The hosted workspace at app.dynodoc.online is a test deployment with email and Google sign-in, and projects are invite-only: only their members can see them. You can start a sample workspace without an account (removed after 24 hours), or download the unsigned desktop workflow manager: Windows 0.1 alpha 1 and Linux 0.0.1c pre-alpha. It manages repositories, reviews, history and sync while you edit in Office or Google editors through the add-ins and extensions. The add-ins are test installs, not marketplace listings. The engine, API and command-line tools are open source, so you can run those yourself today. The terms and privacy policy are drafts and are not yet effective.

Try the pre-alpha

Start a sample workspace of your own (no account, removed after 24 hours), sign in to create your own projects, or install the desktop app for Windows or Linux. The hosted workspace is a test deployment with no paid plan.