Shima System Buffer

On paper, Shima System Buffer is a "dormant buffer" for latent tensors and images. In the source code it's described as a camouflaged security node, and that's the more honest label. It passes your latent through untouched and hands you a status string - but its actual job is checking whether a purchased Shima "island" is legitimately owned before it lets the workflow feel at peace. If you're not buying islands from the shima.wf marketplace, it's just a passthrough with extra steps. If you are, it's a DRM watermark node wearing a utility's clothes.

What it actually does

The execution is dead simple. execute() copies your latent, runs a workflow "security audit," and returns the latent, the image, and a status string. That audit (ShimaSecurity.verify_workflow) scans your entire prompt for two kinds of forensic tracers: a "signature sentinel" node and a set of hidden property keys with names like f_offset, w_bias, k_sharp - deliberately bland enough to look like sampler settings. The logic table is straight out of a trust-but-verify playbook:

• No keys, no sentinel → CLEAN (fresh workflow, nobody's business)
• Keys present but sentinel deleted → INDEX_SHIFT (the author's code literally labels this the "pirate deleted the node" case)
• Sentinel present → it HMAC-checks your auth key against the island's buyer_id. If you're the buyer, BUFFER_STABLE. If the signature doesn't match, it fires a silent background request to a local endpoint that forwards to shima.wf's server. "Forensic data," in the author's words.

For the record, the phone-home only happens on a signature mismatch, and it fails silently if the network's down. Your generation doesn't get blocked or sabotaged - it just gets reported.

The inputs that matter

Here's the part worth knowing before you trust the widgets: buffer_mode (Accurate / Compatible / Fast) and v_depth are camouflage. The execute code never reads them. They exist to make the node look like a real buffer control, and they change nothing about the output. The inputs that do something:

• latent (required) - passed straight through to the latent output
• image (optional) - passed through to the image output
• signature, island_id, buyer_id - injected by the marketplace sync ("Injected by Enigma server" in the code); you don't set these by hand
• status (output, STRING) - BUFFER_STABLE normally, or BUFFER_INDEX_SHIFT / BUFFER_PLANK when the audit flags something

If you want to react to the status, wire the status string into a text display or one of Shima's string/switch utilities. Otherwise you can safely ignore it.

Installing it

This node ships in the Shima pack (KDB-USJP/shima_wf). In ComfyUI Manager, search "Shima" and install; or clone it manually:

cd ComfyUI/custom_nodes
git clone https://github.com/KDB-USJP/shima_wf

Then restart ComfyUI. The pack's own install.py auto-clones two dependencies if they're missing - cg-use-everywhere and ComfyUI-Impact-Pack - which the wider Shima island system leans on. requirements.txt is just aiohttp and requests, both usually already present.

Where people get burned

Two things. First: if you buy an island and see the status flip to something other than BUFFER_STABLE, re-sync it from the marketplace - the signature sentinel is missing from the workflow or your auth key doesn't match. Second, and more of an opinion: this node phones home when it suspects a mismatch, and a surprising number of people don't expect a "buffer" to do that. If the silent reporting bothers you - it's a fair thing to bother you - don't use the node. It adds nothing to image quality. The pack works fine without it.

The honest bottom line: treat Shima System Buffer as a passthrough with a DRM conscience. For plain workflows, delete it and save yourself the mystery.