Viewer routes.

Code notes

There is no separate viewer product and no share-link generator. The viewer family is three distinct routes served from the nukez.xyz Firebase site, each driven entirely by query parameters: /view renders one stored file, /verify renders the proof chain behind one receipt, and /viewer is the generic container an agent fills with an inline payload. The agent portal at portal.nukez.xyz/agent-portal is a fourth, unrelated surface that lists files through a session-gated endpoint and never links to these routes.

1. 1Single file viewThe /view route renders one stored file and reads exactly four query parameters: locker_id, filename, receipt_id and download_url. This is the link to hand to someone who needs to look at a single object rather than an entire locker.
2. 2Receipt proof viewThe /verify route renders the payment, content, Merkle and on-chain anchor layers behind one receipt. It is the only route in this family that also accepts a path segment, /verify/<receipt_id>: the client matches it with a regex and runs the lookup, but leaves the address bar alone, so the path form stays in the URL.
3. 3Agent return windowThe /viewer route is a generic container an agent renders into, not a shared locker view. It reads request_type, locker_id, receipt_id, filename and payload, decodes the payload out of the URL with four successive fallbacks, and draws whichever typed blocks the payload declares.
4. 4Where these routes liveAll three routes are Firebase rewrites on the nukez.xyz site, only /view and /viewer are hidden from crawlers, and portal.nukez.xyz forwards every path to the agent portal shell, so a viewer URL built against the portal host can never resolve.

Code notes

A /view link is a plain query string. filename is always required, and at least one of receipt_id or locker_id must be present; every other parameter is an optimisation. When only a receipt is supplied, the client derives the locker id locally and resolves the file URL against the public API bases before rendering, which is why a two-parameter link is enough to open a file.

1. 1Every supported parameterThis is the complete parameter set /view reads. Query-string order is irrelevant, but download_url is the one value the client takes verbatim instead of decoding it a second time, so percent-encode it exactly once.
2. 2Required parametersThe client refuses to load without a filename, and refuses again unless at least one of receipt_id or locker_id is present; each case renders its own error string rather than an empty page.
3. 3Optional parameterslocker_id may be omitted because the client recomputes it from the receipt with the same rule the gateway uses, and download_url may be omitted whenever a receipt is present.
4. 4Receipt-only linkA link carrying just filename and receipt_id resolves the receipt against the production API base first and the staging base second, then builds the receipt-scoped file URL and passes it directly to a native browser element with no intermediate fetch or blob.

Code notes

Two functions in lib/navigation.ts are the only link builders in the codebase, and each has exactly one caller: the MCP chat modal. The chat path has nothing but a receipt and refuses to build a link without one; the owner path bypasses the helpers entirely, resolving a download URL first and assembling the query string itself. Both hand the result to openViewerPage, which navigates the current tab.

1. 1The /view builderbuildFileViewUrl always writes filename and receipt_id, and writes locker_id or download_url only when they are supplied, which is what produces the short receipt-only links seen in the previous step.
2. 2The /verify builderbuildVerifyUrl emits the query form and encodes the receipt id, which is the only URL shape any Nukez code generates for the verification page.
3. 3Chat callerThe MCP chat modal returns early when no receipt id is present, so a user who has not stored anything can never be handed a link that would fail on arrival.
4. 4Owner callerThe owner path resolves a download URL before navigating and assembles the query string itself, so the recipient loads the file through that URL instead of re-resolving the receipt.

Code notes

Opening a /view, /verify or /viewer link never prompts for anything. None of the three clients imports a session, passkey or auth module, and the receipt-scoped file endpoint on the gateway serves requests with no Authorization header. Access control is possession of the receipt id, or of an owner-minted download URL, which makes any such link a bearer credential.

1. 1No session code exists hereThe three viewer clients import only next/link, next/navigation, React, the shared marketing components and lib/api, so there is no code path in which a recipient could be asked to register or present a passkey.
2. 2Unauthenticated probeRequesting a nonexistent receipt with no credentials returns a 404 carrying LOCKER_NOT_FOUND, which is the gateway reporting that the object does not exist rather than refusing an anonymous caller.
3. 3The link is the credentialBecause a valid receipt id is sufficient to read, anyone who receives the URL inherits the same read access, and nothing in these routes can withdraw it afterwards.
4. 4The only auth messageThe single authentication string in this family appears when a link arrives with neither a download URL nor a receipt, and it directs the owner back to the owner portal rather than gating the recipient.

Code notes

A recipient does not have to trust the rendered page. The verification page is backed by two unauthenticated endpoints that anyone can call directly: POST /v1/storage/verify returns the receipt and its attestation, and GET /v1/storage/verification-bundle returns a self-contained bundle carrying the payment proof, the content proof, the on-chain anchor, the Merkle algorithm specification and a written verify-yourself procedure.

1. 1Receipt and API basesThe receipt used here is one of the three samples the verification page offers, and the two bases are the same production and staging hosts the browser client tries in order.
2. 2Resolve across basesA receipt that is absent from the first base is not an error, so the loop moves on to the next one and only fails after both have declined; the base that answered is kept because the bundle must be fetched from the same host.
3. 3Verification responseThe verify call returns a verified flag, the locker id, the raw receipt and an attestation object carrying attestation_status, merkle_root and file_count, and the attestation may legitimately be null for a locker that has never been attested.
4. 4Verification bundleThe bundle adds the payment transaction signature, the content proof with its Merkle root and per-file hashes, the algorithm specification with pseudocode, and an explicit list of steps for reproducing the result offline. content_proof and on_chain_anchor are null until the locker has been attested, which is why the content proof is read through a guard while payment_proof, merkle_algorithm and verify_yourself are always present.