解密组件
The decrypt node you never add by hand (and what a serial number actually buys)
- input_anything
- *
Here's the neat part of CryptoCat: you never add DecodeCryptoNode yourself. It's the customer side of the encryption pipeline. When the workflow author runs their SaveCryptoNode, the pack writes out a distributable shell workflow where that opener has already been replaced by this node, pre-wired. You install CryptoCat, load the shell file they sent, paste in the serial they sold you, and the hidden workflow runs as if it were sitting in your graph the whole time.
That's the whole business model in one node: the workflow you paid for is never actually in the JSON on your disk. It lives on the author's server, gets downloaded only when you run the workflow, and is recombined with your visible graph on the fly.
How it works
Under the hood there's real crypto. The node takes your template_id and serial_number, combines them with a hardware fingerprint of your machine (built from CPU info and MAC addresses - check utils.py, it's cross-platform and even adds a random salt on Linux to keep cloud instances from sharing an ID), and asks the CryptoCat backend for the workflow. What comes back is an AES-encrypted zip, decrypted with pyzipper, then handed to ComfyUI's GraphBuilder to reconstruct the hidden nodes dynamically. The node literally expands new nodes into the running graph at execution time.
Because the serial is bound to your machine ID on first use, that's the licensing: a serial is good for one computer. Switch machines and the server won't release the workflow.
The inputs and output that matter
template_id- the same 32-char hex ID from the author's shell workflow. Usually already filled in; you don't touch it.serial_number- the one thing you actually type, and the README's placeholder is honest: "请输入序列号", enter serial number. It's a multiline field; paste the code you were sold.input_anything- this one is real on the decode side, not a vestige. The encrypted workflow can have external inputs, and whatever you wire into this socket gets fed into the hidden graph. It's how a customer plugs in their own prompt, image, or seed while the inner logic stays black-boxed.- Output - a single wildcard
*socket. It carries whatever the hidden workflow produced, so it can feed the bridge and then a SaveImage like any normal result.
Install and gotchas
Same pack, same install as every CryptoCat node: ComfyUI Manager (search "RiceRound" or "ComfyUI Compression and Encryption Node") or
cd ComfyUI/custom_nodes && git clone https://github.com/RiceRound/ComfyUI_CryptoCat
then restart. Dependencies are light (aiohttp, pyzipper, websockets), no models. The failure modes are almost all network or auth: you need to be logged into the CryptoCat service, reachable api.riceround.online, a correct serial, and the same machine the serial was first used on. The error strings are Chinese-first but readable ("需要输入序列号" = "serial number required").
The honest take
As a licensing mechanism it works - but the security is "against casual copying," not "against someone determined." The workflow content is never on the customer's disk, which genuinely beats shipping an unencrypted JSON. But a determined customer can still screenshot the graph as it expands, watch inputs and outputs, and recreate the thing. And as the buyer, remember this is a node that decrypts and executes server-delivered workflow JSON in your environment - that's the trust trade you're making with the author. It's a niche tool for a niche sale: if you're the one selling, this is the node your customers will actually touch, and the serial/hardware binding is the thing to explain to them first.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| template_id | STRING | — | |
| serial_number | STRING | — | |
| input_anythingopt | * | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| * | * | — |