Defensive deletion with materialized state

[Antonov548]

Inconsistent Deletion Behavior Across Packages

Problem

Deletion behavior differs across packages:

• treecrdt-core: Defensive deletion with version vector awareness
• treecrdt-wasm-js: Simple boolean tombstone
• treecrdt-sqlite-ext: Simple boolean tombstone

This causes inconsistent visibility behavior and potential data loss.

Current Issues

• No view abstraction - visibility logic embedded per implementation
• Materialized state handles deletion differently
• No consistent is_tombstoned() behavior

Proposal

Standardize on materialized state for deletion across all packages:

• Use materialized state consistently for node deletion status
• Provide consistent visibility API for all packages

[marcus-pousette]

Disclaimer: I am an AI assistant (bot) generating this comment for discussion. Please sanity-check details.

Thanks for filing this. I agree the current deletion story diverges across packages:

• treecrdt-core: defensive deletion via deleted_at: VersionVector plus OperationMetadata.known_state.
• treecrdt-wasm-js and treecrdt-sqlite-ext: boolean tombstone.
• The shared TS interface and sync protobuf currently do not include known_state, and the sqlite storage drops it, so awareness cannot round-trip across sync and restarts.

I think we should pick one canonical semantic and push it down into every adapter and view. Two possible directions:

Direction A (minimal change)

Keep a dedicated delete op (drop Tombstone, keep Delete), and make every adapter compute is_tombstoned(node) like core does (awareness check with dynamic restoration). This requires serializing known_state: VersionVector on the wire and persisting it.

Direction B (move-only plus future GC)

Model soft delete as a real move to TRASH, and apply defensive semantics to that move:

• A Move(node -> TRASH) carries known_state (captured subtree VV).
• A trash move is considered effective only if it remains aware of the node's current subtree VV.
• If later subtree ops arrive that are not in known_state, the trash move becomes ineffective and the node pops back out to the last non-trash location determined by the op log.

Then hard delete becomes a separate future feature, GC and compaction after some acknowledgement protocol, or a server-side policy.

This gives OS-like trash (materialized move) while still preventing hiding data when trash was made on a stale view. It is also more aggressive than classic OS UX because an unseen concurrent edit can auto-untrash, but that seems aligned with the defensive goal.

Concrete work items

• Add known_state to the public operation metadata types (@treecrdt/interface), protobuf (sync/v0/types.proto), wasm bridge, and sqlite storage schemas.
• Define a stable wire format for VersionVector (frontier plus ranges).
• Implement a single visibility and status function across implementations (core, wasm-js, sqlite-ext) and add cross-implementation test vectors.
• Decide whether to keep Delete or deprecate it in favor of move-to-trash plus future GC. Either way, one behavior needs to be the source of truth.

Happy to refine the semantics for Direction B (how to compute last non-trash location deterministically) if maintainers think move-only is the long-term goal.