Skip to content

fix(media): stream media with ant-core 0.11.0 read-ahead (release 0.1.1) - #2

Merged
mickvandijke merged 5 commits into
mainfrom
fix/media-streaming-read-ahead
Oct 1, 2026
Merged

fix(media): stream media with ant-core 0.11.0 read-ahead (release 0.1.1)#2
mickvandijke merged 5 commits into
mainfrom
fix/media-streaming-read-ahead

Conversation

@mickvandijke

@mickvandijke mickvandijke commented Sep 29, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Linear issue

Closes V2-1355

Summary

Media playback no longer stalls while records are discovered. This PR ships SDK 0.1.1 with ant-core 0.11.0 from ant-client main.

  • createMediaSource opens a streaming reader. With the read-ahead core from fix(browser): keep media playback streaming while records are discovered ant-client#209, playback fetches the next records in parallel from wherever it starts or seeks to. openFile keeps ordinary readers, which read ahead only once a read continues a previous one.
  • WASM synced from ant-client main db85c72 (ant-core 0.11.0) with npm run sync:wasm. Besides read-ahead (#209), the new core queries six peers per browser lookup round (#211) and reads from holders that discovery finds after the early allowance. It also includes pointer bindings, which the SDK does not expose.
  • Call-shape fix. #209 merged with openPublicFile/openPrivateFile taking an options object, { streaming }, but this PR's first commit passed a bare boolean. Against the new core, every openFile() and createMediaSource() would have failed with invalid type: boolean `true`, expected struct BrowserFileReaderOptions. The SDK now passes { streaming: false | true }. A new boundary test runs that against the packaged WASM, because the mocked client tests could not catch it.
  • Version 0.1.1, and an audit record: docs/audits/2026-10-01-ant-core-0.11-sync.md.

Commits, in bisectable order: the call-shape fix works with both the old and new WASM; then the sync, the version bump, and the audit.

Risk tier

  • T0 — docs / tooling / CI / pure UX-output. Repo CI only.
  • T1 — client-only, no network-facing behavior change. CI + prod compat smoke.
  • T2 — node/client logic with behavioral surface, no protocol/format/economics change. Dev testnet + ADR.
  • T3 — protocol / storage format / payments / routing. T2 evidence + adversarial testing.

Client-only: no node, wire, storage or payment change. The core's read-ahead and wider lookup rounds change how many requests a browser sends in parallel; ant-client's ADR-0004 records them. A paid devnet run is included anyway.

Compatibility

  • Wire: none
  • Storage: none
  • API: none. Public SDK APIs are unchanged. The internal raw openPublicFile/openPrivateFile calls pass an optional third argument, { streaming }.

Semver impact

  • breaking
  • feature
  • fix

Test evidence

Full details, probes, logs and checksums are in docs/audits/2026-10-01-ant-core-0.11-sync.md.

  • npm run check: build, typecheck and 188/188 tests, including the new reader-options boundary test. npm run verify:wasm passed for ant-client db85c72 on main (WASM sha256 8fa35e58…). npm run build:examples: 5/5 built. npm pack --dry-run: 89 files, 2.2 MB. ADR governance passed. CI is green.

  • Paid devnet, real Chromium: seven nodes at ant-node c092f22 (ant-client's browser CI pin) and local Anvil.

    • Core paid recovery: one payment, recovered without repayment, 4 replicas.
    • SDK demo, public: 13,056-byte and 16,789,561-byte files uploaded and downloaded with matching bytes.
    • SDK demo, private: 12,583,689 bytes uploaded, then downloaded through a saved and reloaded DataMap, with matching bytes.
    • openFile and createMediaSource ranges matched for both files. There were no page or console errors.

  • Mainnet, Chromium, on the 612 MB video 134e4537…a889, with the same probe on both builds:

    0.1.0 this PR
    first frame 55.5 s 7.3 s
    first 60 s of playback froze at 8.1 s 57 s played, one 2.8 s stall
    seek to 8:00, then 45 s ~15 s stall no stall

    openFile start, middle and end reads returned correct bytes. On startup timing, both builds connected in about 2 s and reached chunk 3/147 within the same range.

  • Not caused by this change: on the 7-node devnet, a second large upload in the same page fails with "insufficient peers". Published 0.1.0 fails identically (0/4 for both builds). It is recorded in the audit for a separate issue.

New dependency

none

ADR

n/a

Mitigation / rollback

Deprecate 0.1.1 on npm and point users at 0.1.0, or revert this PR and release 0.1.2. Reverting only the media commit returns media sources to ordinary readers, which still read ahead after sequential reads.

🤖 Generated with Claude Code

@mickvandijke @claude
feat(media): open media sources with a streaming reader
f09fdb6 
createMediaSource now opens its reader in the core's streaming mode, which
treats every read as sequential. From wherever playback starts or seeks
to, the core fetches the next records in parallel, instead of stalling
playback on each record's discovery. openFile keeps the conservative
read-ahead of ordinary readers.

The flag needs an ant-core build with read-ahead (ant-client
fix/browser-media-streaming); older builds ignore it. Sync the WASM from
ant-client main once that change merges.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@mickvandijke mickvandijke mentioned this pull request Sep 29, 2026
Merged
2 of 7 tasks
mickvandijke and others added 4 commits October 1, 2026 17:40
@mickvandijke @claude
fix(media): pass reader options as the core's options object
d5315ab 
ant-client#209 merged with openPublicFile and openPrivateFile taking an
options object, `{ streaming }`, which the core deserializes as
BrowserFileReaderOptions. The SDK passed a bare boolean, written against
an earlier draft of that change. The core rejects it before any network
request ("invalid type: boolean `true`, expected struct
BrowserFileReaderOptions"), so with a WASM synced from main every
openFile() and createMediaSource() call would fail.

Type the argument as RawFileReaderOptions, mirroring the core struct, and
pass `{ streaming }`. Builds without read-ahead ignore the argument.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@mickvandijke @claude
build(wasm): sync ant-core 0.11.0 from ant-client main
ed12776 
Rebuild the bundled WASM with `npm run sync:wasm` from a clean checkout of
ant-client main db85c72 (rustc 1.96.1, wasm-pack 0.15.0). It brings:

- read-ahead for sequential and streaming range reads (ant-client#209),
  which the SDK's media sources use, bounded by records and a per-client
  held-record budget;
- six peers per browser lookup round (ant-client#211);
- reads from holders that discovery offers after the early allowance;
- pointer bindings, which the SDK does not expose.

A new boundary test checks that the packaged core accepts the reader
options the SDK passes and rejects a bare boolean. The README states when
openFile() readers read ahead.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@mickvandijke @claude
chore(release): 0.1.1
e724655 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@mickvandijke @claude
docs(audits): record the ant-core 0.11.0 sync validation
f2c2934 
SDK checks, a paid seven-node devnet run in real Chromium, and mainnet
media playback against the published 0.1.0, with probes, logs and
checksums.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@mickvandijke mickvandijke changed the title fix(media): open media sources with a streaming reader fix(media): stream media with ant-core 0.11.0 read-ahead (release 0.1.1) Oct 1, 2026
@mickvandijke
mickvandijke merged commit 117a32f into main Oct 1, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@mickvandijke