[Scope] Real-time multi-researcher co-editing #133

Open
opened 2026-07-15 20:35:40 +00:00 by claude-bot · 0 comments
Contributor

Scope-expanding idea - PARKED, needs a product decision (Fable ideation) · Category: architecture/scope

Pitch
Live, simultaneous multi-user editing of entries/motifs within a project (shared cursors, real-time merge), beyond today's invite-based collaboration.

What it would add
project_collaborators (migration 028) already models shared access, and v7 added signed cross-instance editing - but both are asynchronous. Live co-editing would need CRDT/OT conflict resolution and a persistent websocket layer, a runtime shape the app deliberately avoids (short BullMQ jobs, request/response).

Why it redefines scope
The spec's first identity statement is "a personal research tool" for one researcher. Real-time co-editing inverts that into a collaborative multiplayer app, with the attendant presence/permissions/merge infrastructure and a fundamentally different operational profile (long-lived stateful connections - see also the v9 streaming prerequisite, #117).

The honest case for
If the "help others start building their own research" thread (spec v2 collaborative access) grows into genuine joint projects, live editing is the natural endpoint.

The honest case against (recommended default)
The existing async collaboration (share links, editor invites, v7 signed remote edits with a conflict-review queue) already supports multiple contributors without the CRDT/websocket burden. Last-write-wins + conflict review is a reasonable ceiling for a research tool; real-time is a large investment against the single-researcher identity.

Decision needed

  • Is genuine simultaneous multi-user editing a real need, or does async collaboration suffice?
  • Is the identity shift (personal instrument → collaborative app) intended?

From the 2026-07-15 codebase audit - Fable feature-ideation pass. Companion report: docs/.internal/report-2026-07-15.md (gitignored).

**Scope-expanding idea - PARKED, needs a product decision** (Fable ideation) · Category: architecture/scope **Pitch** Live, simultaneous multi-user editing of entries/motifs within a project (shared cursors, real-time merge), beyond today's invite-based collaboration. **What it would add** `project_collaborators` (migration 028) already models shared access, and v7 added signed cross-instance editing - but both are asynchronous. Live co-editing would need CRDT/OT conflict resolution and a persistent websocket layer, a runtime shape the app deliberately avoids (short BullMQ jobs, request/response). **Why it redefines scope** The spec's first identity statement is "a personal research tool" for **one** researcher. Real-time co-editing inverts that into a collaborative multiplayer app, with the attendant presence/permissions/merge infrastructure and a fundamentally different operational profile (long-lived stateful connections - see also the v9 streaming prerequisite, #117). **The honest case for** If the "help others start building their own research" thread (spec v2 collaborative access) grows into genuine joint projects, live editing is the natural endpoint. **The honest case against (recommended default)** The existing async collaboration (share links, editor invites, v7 signed remote edits with a conflict-review queue) already supports multiple contributors without the CRDT/websocket burden. Last-write-wins + conflict review is a reasonable ceiling for a research tool; real-time is a large investment against the single-researcher identity. **Decision needed** - [ ] Is genuine simultaneous multi-user editing a real need, or does async collaboration suffice? - [ ] Is the identity shift (personal instrument → collaborative app) intended? --- _From the 2026-07-15 codebase audit - Fable feature-ideation pass. Companion report: `docs/.internal/report-2026-07-15.md` (gitignored)._
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rbrooks/TeaLeaves#133
No description provided.