What it is
A drop-in audit and undo module that records every tracked database write inside the same transaction that made it, capturing who changed what, the row state before and after, and when. It sits inside your SpacetimeDB server module and exposes per-user undo and redo, a point-in-time read API, and a configurable retention policy that prunes old records automatically.
Where it fits
- Collaborative editing tools: Multiple users editing shared content simultaneously need undo that only reverses their own actions without clobbering others' work.
- Stream overlay software: Live production tools where an operator needs to roll back a mistaken batch of element moves as a single atomic action.
- Audit-required applications: Any app where a compliance or moderation team needs a complete, tamper-evident log of who changed which records and when.
- Time-slider UIs: Creative or review tools that let users scrub backward through the state of a table to see how it looked at any past moment.
- Conflict-safe multi-user workflows: Apps where silent merges are unacceptable and it is preferable to refuse an undo and surface the conflict explicitly.
How it works
Because SpacetimeDB does not expose database triggers, this module cannot watch your tables passively. Instead, you route writes through tracked wrappers provided by the module. Each wrapper records the before and after state of the affected row in the same transaction as the write itself, so the history entry and the data change either both commit or both roll back together.
Related changes are grouped by wrapping them in a named action with an optional scope. A scope is a logical boundary such as a shared board or a specific overlay, and undo stacks are maintained per user per scope. When a user undoes an action, the module checks whether every affected row still matches the recorded after-state. If another user has since changed any of those rows, the undo is refused entirely and the conflicting rows are reported. If no conflicts exist, the before-values are written back through the same tracked wrappers, so the undo itself appears in the audit log as its own entry.
Point-in-time reads work by taking the current rows and rolling back every recorded change that happened after the requested timestamp. History tables are private by default, so clients can only see their own action groups through a dedicated view. Broader access for auditors or open audit modes can be enabled explicitly. A configurable retention policy periodically removes old change records, which also sets the earliest timestamp available for point-in-time queries.
