Version history, snapshots and recovery — how much “time travel” should a writing project expose?

[qnbs]

Why this exists

Writing projects need recovery that is understandable under experimentation, interruption, and collaboration. This Discussion explores how much time travel a project should expose without creating a second silent authority.

Product decision space

Please compare autosave history with explicit named snapshots and automatic checkpoints. Consider restore versus open-as-copy, version comparison, deleted-content recovery, scene-level versus whole-project history, retention and storage pressure, external backups, and the differences between PWA and native environments.

Local-first and CRDT work may affect how history is represented, but history must remain legible to authors. Future encrypted snapshots are a design constraint to account for, not a claim that every current snapshot is already protected. Any restore, backup, or snapshot path must preserve one canonical authority and make generation, conflict, and recovery outcomes visible.

Context only

• pwa(storage): engineer a durable IDB+OPFS storage tier with persistence, quota & recovery UX #482: storage durability, quota, persistence, and recovery context.
• security(core/R-15): renderer-neutral encrypted desktop storage, durable migration & identity binding #445: future renderer-neutral encrypted native storage context.
• local-first: migrate manuscript text to Y.Text and gate the source-of-truth flip #555: manuscript/Y.Text authority and local-first context.

These references do not change those Issues' scope or imply that future storage/encryption work is complete.

Role perspectives

Role-perspective note: The viewpoints below are maintainer-curated, AI-assisted design lenses. They are not separate community members, votes, user testimony, or evidence of consensus.

• ✍️ Author who experiments heavily: try alternatives safely, name meaningful milestones, compare versions, and recover deleted work.
• 🧪 Data-integrity/recovery: acknowledged edits, restore fencing, no-loss behavior, durable backups, and explicit failure paths.
• ⚡ Large-project/storage: retention cost, indexing, latency, quotas, and bounded storage pressure.
• 🤝 Collaborative/local-first: reconcile history with local-first and collaboration semantics without hiding conflicts.
• 🧭 Product simplicity: expose useful recovery without turning ordinary writing into a version-control administration task.

Questions for real author workflows

• Do you rely more on continuous autosave history, named snapshots, or both?
• When would you restore in place versus open a version as a copy?
• Do you need scene-level recovery, whole-project recovery, or a searchable deleted-content history?
• Which comparisons are useful: text, structure, metadata, assets, or rendered output?
• How long should checkpoints remain available when storage is limited?
• Which external backup behavior feels safe rather than confusing?
• What should differ between browser/PWA and native environments?
• When would local-first history or CRDT-aware recovery provide value even without collaboration?

Relationship to implementation

This Discussion is product and recovery UX exploration only. It does not create a second authority, change #482/#445/#555, or alter their priority, roadmap admission, acceptance criteria, or execution sequencing.