I noticed that whenever a plugin updates user_data (even a single char), the next revision collected for that note stores the entire new user_data blob, not a delta. Plugins that write often accumulate full-size snapshots in revision history, especially with the default 90-day retention.
in this thread the recommended approach for plugin-managed data is user_data. I agree, but current revision behaviour can be improved to avoid bloat.
quick code review
RevisionService.noteMetadata_() (packages/lib/services/RevisionService.ts:67) builds the metadata snapshot from every note field except an explicit exclusion list. user_data is included.
Revision.createObjectPatch() (packages/lib/models/Revision.ts:87) then diffs at the field level with ===. since user_data is a single TEXT column holding a stringified JSON blob, any internal change replaces the whole field in the patch (no JSON-aware sub-diffing). so each plugin write to user_data (e.g. recomputing a summary after the note changes) produces a revision whose metadata_diff carries the entire new user_data blob.
proposal
add user_data to the existing exclusion list in noteMetadata_().
-
user_datais plugin storage, not user-authored content -
reverting it from history has no clear meaning, plugins write to it programmatically
-
the existing list already covers similar non-content fields (encryption state, conflict flag, etc.)
backward compatible: existing revisions still decode and apply normally. new revisions stop carrying the field. an edit that only changes user_data won't create a revision at all (metadata_diff ends up empty and Revision.isEmptyRevision filters it out).
I'm happy to work on this if this seems reasonable.