GameCult/CultLib
Watch
9
0
Fork
You've already forked CultLib
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

cultmesh-browser: document the verified content reader; name it in the portability job

Browse source 
README section for fetchVerifiedContent / fetchVerifiedChunk; the CI comment
records that the content reader is proved to release only verified bytes.

Builds unaffected (docs and a comment).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Meta Vens 2026-10-19 15:28:46 +02:00
commit 55530a941f
2 changed files with 27 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

3
.github/workflows/cultmesh-portability.yml vendored
View file

@ -103,7 +103,8 @@ jobs:
# Linux at all, and the browser client's never ran in CI on any OS.
# packages/cultnet-ts verifies both vector files (content.test.ts judges both
# C# content files, the Rust one and its own); cultmesh-browser proves
# the browser client reads the shared rules rather than its own.
# the browser client reads the shared rules rather than its own, and that its content reader releases only verified
# bytes, requesting the same URLs as the C# HTTPS connector.
# No workflow ran cultcache-ts's tests, and its test script listed two files by hand while a third sat compiled
# and unrun. The wiring check fails when any TypeScript test file is run by no script, and the cache's own suite
# runs here beside the packages built on it.

25
packages/cultmesh-browser/README.md
View file

@ -69,3 +69,28 @@ Run `scripts/verify-eve-browser-network.mjs --eve-root <path-to-Eve>` for the
real Chromium + C# headless chronology. The witness publishes a lower-priority
decoy endpoint owned by another runtime and proves that neither client connects
to it before and after route rotation.
## Verified content
`fetchVerifiedContent(endpoint, manifest)` and
`fetchVerifiedChunk(endpoint, hash, size)` read CultMesh CDN content over HTTP.
The endpoint comes from CultMesh and never from content: a manifest carries no
URL. No byte is released that failed its chunk or whole-body SHA-256 (WebCrypto,
so a secure context in browsers). Only https is accepted, and http only on
loopback. Options: `maxConcurrentChunkRequests` (1 to 32, default 4), `maxBytes`
(default 256 MiB, checked before any request), `signal` (an abort rejects with
the signal's own reason). Failures are `CultMeshContentError` with a `code`
(`manifest-invalid`, `too-large`, `insecure-endpoint`, `webcrypto-unavailable`,
`network`, `http-status`, `length-mismatch`, `chunk-hash-mismatch`,
`content-hash-mismatch`); messages never carry the endpoint or body bytes. The
byte count actually received is judged, never a length header, because Fetch
decodes content codings.
```ts
import { fetchVerifiedContent } from "cultmesh-browser";
const bytes = await fetchVerifiedContent(endpoint, manifest, {
signal: AbortSignal.timeout(30_000),
maxConcurrentChunkRequests: 8,
});
```