Mememage Fetch Record

Mememage Load Record reads local disk. Mememage Fetch Record is its network twin: it GETs the record a surface serves for an identifier - the Internet Archive, a self-hosted souls host, or any plain URL - and hands you the JSON to verify against. The README calls it the "By Word" path, and the mental image is right: you say the identifier, the record answers from wherever it lives.

How it finds the record - two strategies

Inputs: identifier (wire Decode's - the tooltip suggests a second Decode to avoid a loop), source (the base URL), optional content_hash, search_host (on by default), and timeout (per-request seconds, default 8).

1. Straight to it, by ID (fast). The identifier is the address. It probes <source>/<id>.soul, <id>.json, and - when you wire content_hash - the hashed <id>.<hash>.* forms the Internet Archive writes, returning the first that answers. Instant, no server smarts. The source base can template per-item layouts with {id}:

• Internet Archive: https://archive.org/download/{id}/
• A souls host: just https://souls.example.com/ (the default is https://souls.mememage.art/)

2. Search the host (search_host, on by default). If the by-ID lookup misses - the host names its files anything - it lists every record the host serves and returns the one whose identity matches your identifier. Filenames stop mattering. It only runs after the fast path misses, so on a convention-named host it never fires and costs nothing - which is why it's safe to leave on. Turn it off for a strict, fast, ID-only fetch. Search needs a listable host: an S3-style bucket, a GitHub folder, or a web server with directory listing (nginx/Apache autoindex). A host that can't be listed cleanly reports "nothing to search" → found = False.

The outputs, and the honesty built into them

• record - the fetched JSON.
• identifier - echoed through.
• found - boolean. This is the star output. A 404, a CORS block, a timeout, an offline network, or an unlistable host all give found = False and an empty record - never a crashed graph. It's genuinely best-effort.
• url - the URL that actually answered, so you can see where the record came from.

And the important division of labor: Fetch retrieves, it doesn't verify. Integrity is Mememage Verify's job - wire record and the image into Verify, whose hash check understands every record version and is the authority. Retrieval staying dumb about integrity is a feature: a foreign hash version that core can't judge shouldn't be rejected at the fetch stage, it should get the honest UNSUPPORTED verdict from Verify.

Installing it

Same pack, one install. ComfyUI Manager → search "Mememage" → Install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/sememtac/mememage-comfy
<ComfyUI-python> -m pip install mememage

Restart; it's under Mememage/Records. The pack's requirements.txt also pins certifi specifically so HTTPS validates against current Mozilla roots instead of a possibly-stale Windows cert store - that's the fix for bogus "certificate expired" failures on Windows boxes, and it's exactly why this node's HTTPS path is reliable.

Common issues

• found = False with no explanation. Check the backend log for the node's print line - it distinguishes "404/no answer" from "nothing to search at that host." If the host can't be listed, that's the cause; either name records by ID (fast path, no search needed) or pick a listable host.
• CORS is blocking you. The fetch runs server-side, so browser CORS is usually a non-issue on a local ComfyUI - but if your host rejects the request anyway, the node reports found = False rather than crashing. Point at a host that serves the file, or serve from a surface that allows it.
• Slow host? Bump timeout (1–60s) and remember search_host does a listing plus N fetches - on a big, messy bucket, search can be slow by nature. If you know records are named by ID, turn it off for the fast path only.