Skip to content

Navigation Menu

Sign in
Sign up

Local-first manuscript editing and CRDTs — what user experience should Yjs authority actually enable? #636

qnbs started this conversation in General
Discussion options

Why this exists

Issue #555 explores manuscript and Y.Text authority; #548 is a current compatibility defect; and #349 is the collaboration invite-link UX. This Discussion asks what user experience local-first manuscript editing and CRDT authority should actually enable.

Current state

Local-first behavior can provide offline editing, fast local response, recovery, and multi-view continuity for solo authors. Collaboration adds conflict semantics and shared state, but the product should explain what CRDT authority improves even when a user is not collaborating.

The scopes are intentionally distinct:

Product decision space

Explore solo-author value, offline behavior, undo/redo, multiple views, conflict semantics, collaboration handoff, history/versioning, recovery, and whether CRDT authority earns its complexity without active collaboration. A good model should make acknowledged edits durable and understandable rather than exposing implementation details as new uncertainty.

Role perspectives

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

  • ✍️ Solo author: immediate editing, offline continuity, undo/redo, and trustworthy recovery.
  • 🤝 Co-author: understandable presence, conflict outcomes, handoff, and collaboration continuity.
  • 🧪 Data integrity: durable acknowledged edits, deterministic history, no-loss merges, and explicit recovery.
  • Large-manuscript performance: bounded memory, responsive views, indexing, and predictable synchronization costs.
  • 🧭 Product: use CRDT authority where it improves the writing experience, not merely because collaboration exists.

Questions for the community

Relationship to implementation

This Discussion links product exploration to #555 while explicitly preserving #548 as a technical defect tracker and #349 as the invite UX tracker. Those Issues remain authoritative for implementation, acceptance, priority, and sequencing; the Discussion changes none of them.

You must be logged in to vote

Replies: 0 comments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
1 participant

AltStyle によって変換されたページ (->オリジナル) /