Ship a browser-safe build — UUID.TB can't run in the renderer (static node crypto import)

[Shinrai]

@cldmv/uuid can't run in a browser, which blocks using it as the fleet PK primitive on the client side.

dist/uuid.mjs does a static import crypto from "crypto" (node builtin) at module top and calls crypto.randomBytes(16) for entropy — including on the UUID.TB() path. The package has no browser export condition and no browser build. So esbuild-bundling it for the browser (platform: "browser") fails to resolve crypto (and fs/url/path from the dynamically-imported issuer-registry), and any renderer import of @cldmv/uuid 404s / throws.

This came up wiring rummage's offline-first data facade (CLDMV/rummage#25): a client-minted create id BECOMES the server PK, so it must be a UUID.TB — but the renderer can't mint one today. As an interim, rummage's facade minter is injectable and falls back to a native UUID; that's a stopgap, not the PK format the fleet rule (D36) wants.

What would fix it: an isomorphic randomness source — use globalThis.crypto.getRandomValues in the browser and node crypto in node (the standard pattern) — and a browser export condition (or a pre-bundled browser entry) so platform: "browser" bundlers resolve cleanly. The issuer-registry node bits (fs/url/path) are already behind a dynamic import(), so they only need to stay off the UUID.TB static path (they appear to be). Ideally UUID.TB() / UUID.TA() work in the browser with zero node builtins.

Once this lands, rummage vendors @cldmv/uuid into the client-storage browser bundle and injects the UUID.TB minter into the facade (the seam is already in place), so every client-minted PK across the fleet is a real UUID.TB.

[Shinrai]

Triaged — confirmed as described, and the actual surface area is a bit bigger than the UUID.TB()/crypto.randomBytes call sites alone:

• The static import crypto from "crypto" isn't unique to uuid.mjs — it's duplicated identically in every RFC/timestamp/issuer version module (v1, v3/v5, v4, v6, v7, v8, timestamp/v1, timestamp/v2, issuer/v1), all reached eagerly via uuid.mjs's top-level import * as rfcUuids from "./lib/versions/rfc/index.mjs". None of them do anything Node-specific beyond crypto.randomBytes(n) (v1's MAC "node" field just falls back to random bytes), so an isomorphic swap is mechanically uniform everywhere — but it touches ~10 files, not one.
• index.mjs itself isn't browser-bundlable today either, independent of the crypto issue: it does await import("./devcheck.mjs"), and devcheck.mjs statically imports node:fs/node:url/node:path. A browser build would need to enter through ./main (or an equivalent) rather than the package root, or devcheck.mjs needs its own browser-safe path.
• issuer-registry.mjs's fs/url/path usage is confirmed already isolated behind the dynamic getRegistry() import, as the issue notes — no change needed there.

Labeled as a feature request (area: core, Effort: High) rather than a bug, since nothing misbehaves in Node — this is new capability. Holding off on implementation pending a scope/mechanism decision (asking separately) rather than guessing at a multi-file architecture change.

[cldmv-bot]

Closed in v1.2.0 — resolved by #23.