Documentation / @etherfold/core / streamSeedContentHash

Function: streamSeedContentHash()

streamSeedContentHash(payload): string

Defined in: packages/core/src/stream/seed.ts:270

The CONTENT HASH of a seed: sha256:<64 lowercase hex> over the DECOMPRESSED payload octets.

The byte domain, which is decided and not negotiable (ADR-0066)

The octets as they exist AFTER any transfer decoding and BEFORE JSON.parse -- never the gzipped file, and never a re-stringified parse. Over the compressed file the domain is not even well-defined at the client: a host that sets Content-Encoding: gzip makes fetch decompress transparently, so a client could not reproduce a hash of the compressed bytes from anything it holds, and a rule forbidding that header is one a publisher on Pages, CloudFront or a gateway frequently cannot enforce. Hashing the decompressed octets is transport-INVARIANT, so opaque and transparently-decoded delivery land on the same value and no hosting constraint is implied.

It takes BYTES and not a string, deliberately. A caller handing over text would have had to encode it, and a caller handing over a PARSED seed would be hashing a re-serialisation -- integrity resting on a round trip JSON does not guarantee is the failure this domain was chosen to avoid.

Why it is rendered with its algorithm in front

A build PASTES this value into its source, where it long outlives the session that produced it. A bare hex string cannot say which function produced it, so the day a second one exists every pinned literal is ambiguous. sha256: is the prefix an OCI image digest uses and it splits on one character.

Why SHA-256

The one hash this project already has (streamDigestOf uses viem's, for a reason its own docstring gives: already a dependency, and SYNCHRONOUS, which crypto.subtle is not). A second primitive would be a second thing two ends must agree on.

Parameters

payload

Uint8Array

Returns

string