FNP Delete Operations & Visibility Control

ELI5

When you delete text in FNP, the text doesn’t actually disappear — it’s marked as “deleted” but stays in the document. This is like redacting a line in a legal document with a marker instead of tearing it out. It keeps the document intact for offline users who might insert at that position and ensures everyone sees the same result.

Technical Deep Dive

Soft Delete vs Hard Delete

FNP uses soft deletes (tombstones) instead of hard deletion:

Why soft delete?

• CRDT requires operation history for convergence
• Offline users may still insert at deleted positions
• Audit trail: deletion is traceable and reversible
• Concurrent deletes + inserts handled deterministically

Tombstone marking:

[Position]    [Content]    [Deleted Flag]
LSEQ(2,1,5)   "h"         false
LSEQ(2,2,3)   "e"         false
LSEQ(3,1,1)   "l"         true  ← marked deleted
LSEQ(3,1,2)   "l"         true  ← marked deleted
LSEQ(4,1,2)   "o"         false

Deletion Protocol

1. Client issues delete operation — marks position + provides Halo2 proof of authorization
2. Server verifies Dilithium signature — only original poster can delete their own content
3. Server marks tombstone — UPDATE characters SET deleted = true WHERE position = X
4. Visibility recalculation — CRDT merge computes visible = [characters WHERE deleted = false]
5. Broadcast tombstone — all replicas apply soft delete

Offline Delete Handling

Scenario: Alice deletes positions [L3, L4]. Bob (offline) inserts at L3.5.

Resolution via CRDT:

• Bob’s insert: position L3.5 is unique (site, counter)
• Merge order: both operations remain in history
• Visible text: honors deletion of L3, L4 but includes L3.5 in between
• Result is deterministic, no user resolution needed

Proof-Based Authorization

Only the original poster can delete their edits:

# Server verification (simplified)
delete_proof = client.delete_operation.halo2_proof
authorize = verify_proof(delete_proof):
  - creator_agent == current_user
  - content_signature matches
  - no modification timestamp

if not authorize:
  reject("Unauthorized deletion")

Key Terms

• Tombstone → Deletion marker; content remains in history with deleted=true flag
• Soft delete → Logical deletion; physical record retained for CRDT convergence
• Visibility function → computed as [c for c in characters if not c.deleted]
• Deletion authorization → Only original poster can tombstone their own content

Q&A

Q: Can deleted content be recovered? A: Yes, from the audit trail in the git commit history. Tombstones are permanent markers, but the delete operation itself is reversible via a new “undelete” operation (if permission checks pass).

Q: What if two clients delete the same position offline? A: Both delete operations are recorded in history. The CRDT merge sees position marked deleted twice — idempotent operation, no conflict.

Q: Does deletion affect the LSEQ position numbering? A: No. Deleted positions retain their identifiers. The position space remains stable for future inserts, ensuring no cascading renumbering.

Examples

Soft deletes are like redaction in legal documents: the original text is marked redacted with [REDACTED] but the document structure remains intact. Other editors can still reference “the part after the redaction” without ambiguity, and auditors can trace what was deleted and by whom.