VRS Native Compact Memory (Lossless Copy)

VRS Native Compact Memory (Lossless Copy) is the least glamorous node in a pack that is already niche. To reach it you have to have built a personal reference memory first - a VRS-INT store of your own images and tags, encoded into vectors so you can pull "stuff like this" back out later. This node then makes a smaller, verified copy of that store.

That's the whole job. If you haven't built a VRS memory, it has nothing to do and no input that will accept anything.

Why you'd reach for it

A VRS store grows the way all personal datasets grow: images go in, nothing ever comes out. The pack's own numbers on a 118,787-vector store: source snapshot 494.0 MiB, compact copy 458.9 MiB. 7.1%. That's the honest headline, on the author's own hardware, with their data.

Which puts the useful framing here: the search cache is where the real savings live (815.1 MiB → 518.8 MiB in the same test, a 36% cut), and you get that automatically - no node - the next time search prepares after the upgrade. This one is for when you specifically want the source data smaller: syncing a memory between machines, or being genuinely out of disk.

What it actually does

The store keeps entries in bucket objects. The node decodes each bucket, re-packs it with XZ (Python's standard library lzma, not a downloaded binary), writes the result, then reads the file back and compares the canonical form of every field before publishing anything: vectors, tags, captions, typed names, audit records, tombstones. Not sample-checked. The counts are checked against the source manifest too.

Deliberately, the vectors are not touched - no FP16, no INT8, no re-encoding. The encoder contract survives, which is what would otherwise silently invalidate your whole memory against a new vision tower.

The result is a new store in the vrs-int/3 format, source lineage recorded in provenance as repacked_from. It's not a continuation of the old history, and the CURRENT pointer isn't copied: the copy has no "latest", only the snapshot it just published.

Inputs and outputs

Two inputs, and only one needs thinking about:

• memory - the VRS_MEMORY wire, off VRS Native Memory Loader or VRS Folder Memory. To pick a specific snapshot, use the Memory Loader and type the exact 64-character hash; its tooltip is blunt that CURRENT is never followed implicitly.
• output_store - a plain path string. Per the author's tooltip: a new local folder outside the source, a verified lossless copy, every source file retained, at the cost of CPU time.

Outputs: memory (the compacted store, ready to feed Recall if you want to chain it in the same run), snapshot (the new hash - write it down, it's how you get back in), and report (JSON: verification result, counts, byte sizes, source snapshot, "lossless": true). It's an output node, so it fires with the graph and shows the report in its text UI.

Installing

Same pack as everything else in RS-Seasonal-Prompt-Generator. ComfyUI Manager → search RS-Seasonal-Prompt-Generator, or:

cd ComfyUI/custom_nodes
git clone https://github.com/raspie10032/RS-Seasonal-Prompt-Generator.git

Restart, then look under the prompt category for VRS Native Compact Memory (Lossless Copy).

For this node specifically: no dependencies, no models, no downloads, no network. The pack's requirements.txt adds only gguf for the built-in Q4 Gemma path, which you don't need here.

Where people get burned

The failures are structural, not mysterious:

• The folder must not already exist, and it can't live inside the source store (nested either direction is refused). So a re-run with the same output_store fails - version each copy (memory-compact-2).
• It wants headroom. A 20% free-disk reserve is checked per bucket as it writes, and the run aborts if the copy would cross it. The source isn't deleted, so this is a disk-growth event first and a disk-saving event later.
• Cancelling doesn't stop mid-object. Interrupt checks happen between buckets, so one in-flight compress and write finishes first. An interrupted run publishes no snapshot but can leave unused objects behind.
• Don't hand the copy to older code. vrs-int/3 needs this version or newer.
• Folder collection won't follow the copy. Daily ingestion still writes to the source; there's no "resume collecting into the compacted copy", though explicit Build/Update against it works. Plan for the source to stay the live one.

This is a one-time maintenance step, so run it in its own throwaway workflow rather than leaving it wired into the graph you generate with. Unlike the builder node beside it, there's no always-dirty guard in the code - if it does fire again with the same folder, you hit the existing-target refusal instead of a second copy.

Also, XZ decompresses slower than the store's default zlib, and the author measured no improvement in build or query time. You're trading read time for megabytes.

Verdict

Small, careful, and honest about its own modest payoff. Got a VRS memory and some free disk? It's a five-minute detour that produces something you can verify. Have neither? Close the tab - the automatic search-cache compaction already did the part that mattered.

Compression is not anonymization, by the way. The tags and source metadata come back out byte-for-byte, which is the point, and also the reason to keep personal memories out of git.