From ecec6548fba22f5fad4aca4f2129df13c08dbc9d Mon Sep 17 00:00:00 2001 From: Jim Collinson <13061030+JimCollinson@users.noreply.github.com> Date: Tue, 27 Oct 2026 16:43:37 +0000 Subject: [PATCH 1/8] docs(releases-browser): promote Browser SDK 0.1.3 - Advance the manual release pin and all six scoped verification blocks - Document released streaming limits and record fresh browser evidence --- docs/sdk/build-in-browser.md | 14 ++--- docs/sdk/how-to-guides/README.md | 6 +-- .../how-to-guides/retrieve-data-in-browser.md | 12 ++--- docs/sdk/install.md | 6 +-- docs/sdk/reference/README.md | 6 +-- docs/sdk/reference/overview.md | 6 +-- planning/sweeps/2026-10-27.md | 54 +++++++++++++++++++ target-manifest.yml | 18 +++---- 8 files changed, 89 insertions(+), 33 deletions(-) create mode 100644 planning/sweeps/2026-10-27.md diff --git a/docs/sdk/build-in-browser.md b/docs/sdk/build-in-browser.md index 3d85d87..258d4a2 100644 --- a/docs/sdk/build-in-browser.md +++ b/docs/sdk/build-in-browser.md @@ -2,9 +2,9 @@ @@ -67,15 +67,17 @@ You do not have to load every file into memory before using it. The SDK provides For seekable audio and video, the SDK provides a service worker: a browser-managed script that connects a media element's requests to the SDK's file reader. This setup requires HTTPS or localhost and the application's page to remain open. Applications with an existing service worker must integrate the media handling with it. -Browser SDK 0.1.2 accepts files from 3 bytes up to 1 GB (1,000,000,000 bytes) for uploads, downloads, range reads, and media. +Browser SDK 0.1.3 accepts uploads from 3 bytes up to 1 GB (1,000,000,000 bytes). -Whole-file downloads and uploads from byte arrays may run out of browser memory well before that limit. Choose range reads or the media integration when loading the whole file would be unsuitable. The [browser SDK API documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.2#random-access-reads) covers range reads, media setup and file-size limits. +`download()` and `downloadAndSave()` buffer the whole file and use a default 1 GB `maxMemoryBytes` budget. You can pass a different budget, but the returned bytes and `Blob`, the resolved DataMap, caches and transport buffers need additional memory. + +Streaming downloads and media do not have a fixed 1 GB cap. For bounded-memory downloads, use `client.streamAndSave(source, options)` or `client.openFile(file, options)` followed by `reader.pipeTo(destination, options)`. Use `reader.stream(options)` to consume a bounded stream in your application. Browser memory, storage and safe-integer limits remain practical constraints. Uploads from byte arrays may run out of memory before reaching the upload cap. The [browser SDK API documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.3#stream-directly-to-disk) covers streaming saves, range reads, media setup and file-size limits. ## Uploading from a browser The SDK also accepts browser files and byte arrays for public or private uploads. Your application supplies a payment provider to authorize storage payments; supported integrations include Ethers and Wagmi/Viem. A read-only application does not need these wallet integrations. -File uploads have additional browser requirements, including a worker for file processing and IndexedDB for temporary storage. Use the [browser SDK's upload documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.2#upload-files) when adding uploads and payment handling. +File uploads have additional browser requirements, including a worker for file processing and IndexedDB for temporary storage. Use the [browser SDK's upload documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.3#upload-files) when adding uploads and payment handling. ## Network compatibility diff --git a/docs/sdk/how-to-guides/README.md b/docs/sdk/how-to-guides/README.md index 2987adc..a0a1b62 100644 --- a/docs/sdk/how-to-guides/README.md +++ b/docs/sdk/how-to-guides/README.md @@ -10,9 +10,9 @@ diff --git a/docs/sdk/how-to-guides/retrieve-data-in-browser.md b/docs/sdk/how-to-guides/retrieve-data-in-browser.md index bfd2637..4f099c4 100644 --- a/docs/sdk/how-to-guides/retrieve-data-in-browser.md +++ b/docs/sdk/how-to-guides/retrieve-data-in-browser.md @@ -2,9 +2,9 @@ @@ -30,7 +30,7 @@ This example only reads existing public data. It does not configure a wallet or Vite serves the JavaScript and WASM assets during development and bundles them for deployment. -This tutorial uses browser SDK 0.1.2 and Vite 8.2.0. The commands save these exact versions so reinstalling the project does not select a different version of either package. +This tutorial uses browser SDK 0.1.3 and Vite 8.2.0. The commands save these exact versions so reinstalling the project does not select a different version of either package. In a terminal, run: @@ -38,7 +38,7 @@ In a terminal, run: mkdir autonomi-browser-demo cd autonomi-browser-demo npm init -y -npm install --save-exact @withautonomi/ant-browser-sdk@0.1.2 +npm install --save-exact @withautonomi/ant-browser-sdk@0.1.3 npm install --save-dev --save-exact vite@8.2.0 ``` @@ -174,7 +174,7 @@ The browser retrieves the data directly from Autonomi nodes. Vite serves your ap ## Next steps -- [Browser SDK documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.2): upload, wallet, private-file and media APIs for the same experimental release. +- [Browser SDK documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.3): upload, wallet, private-file and media APIs for the same experimental release. - [Browser SDK](../build-in-browser.md): capabilities, application ideas and how browser connections work. - [Build with the SDKs](../install.md): compare application connection options. - [Keys, Addresses, and DataMaps](../../core-concepts/keys-addresses-and-datamaps.md): understand public addresses and private-file access. diff --git a/docs/sdk/install.md b/docs/sdk/install.md index b6c5c69..1eff607 100644 --- a/docs/sdk/install.md +++ b/docs/sdk/install.md @@ -10,9 +10,9 @@ diff --git a/docs/sdk/reference/README.md b/docs/sdk/reference/README.md index 6f4a9a8..10eebb1 100644 --- a/docs/sdk/reference/README.md +++ b/docs/sdk/reference/README.md @@ -10,9 +10,9 @@ diff --git a/docs/sdk/reference/overview.md b/docs/sdk/reference/overview.md index 4e2202a..5b30c88 100644 --- a/docs/sdk/reference/overview.md +++ b/docs/sdk/reference/overview.md @@ -10,9 +10,9 @@ diff --git a/planning/sweeps/2026-10-27.md b/planning/sweeps/2026-10-27.md new file mode 100644 index 0000000..96615b5 --- /dev/null +++ b/planning/sweeps/2026-10-27.md @@ -0,0 +1,54 @@ +# Browser SDK 0.1.3 promotion — 2026-10-27 + +## Release evidence + +- GitHub tag `v0.1.3` resolves to source commit `813aa1817274551e3596038ffc8d2706672eba3b`. The [public release](https://github.com/WithAutonomi/ant-browser-sdk/releases/tag/v0.1.3) is neither a draft nor a prerelease. This was checked through `git ls-remote`, the GitHub release API and a detached checkout of the exact commit. +- The exact [npm metadata](https://registry.npmjs.org/@withautonomi/ant-browser-sdk/0.1.3) identifies `@withautonomi/ant-browser-sdk` version `0.1.3` with integrity `sha512-eAqVQLWNMZzaJGcuYFHT97zacz89u6qhM9lum3X8s8AY/6eIF+t2tj4WnIHxufaLchXfi6o80kmKqwrm4Jc9QQ==`. A fresh tarball download reproduced that SHA-512 value and its SHA-1 metadata value. The npm tarball and GitHub release asset both had SHA-256 `cd6db9f2d4d72e3e966663b89bc2d8465b9b7fe197ec227fa2e094d379719984`. +- The release's immutable [`src/wasm/source.json`](https://github.com/WithAutonomi/ant-browser-sdk/blob/813aa1817274551e3596038ffc8d2706672eba3b/src/wasm/source.json) records ant-client commit `ccd4106dd8fd60545bbd31c40d46cc041f85fb8d` and WASM SHA-256 `08ae5d0cc7b96458ba9899d68be0455b276848644237f42704419a2e4311fec4`. Hashing `dist/wasm/ant_core_bg.wasm` from the independently downloaded npm package reproduced that value. +- The released source and packaged README still call the SDK and direct-browser protocol experimental. This promotion does not change that status. + +## Documentation changes + +All six mapped pages advance only their Browser SDK verification block to `v0.1.3`, the exact release commit and `2026-10-27`: + +- `docs/sdk/build-in-browser.md` +- `docs/sdk/how-to-guides/retrieve-data-in-browser.md` +- `docs/sdk/install.md` +- `docs/sdk/how-to-guides/README.md` +- `docs/sdk/reference/overview.md` +- `docs/sdk/reference/README.md` + +Rendered changes are limited to the overview and tutorial. The overview retains the 1 GB upload cap, distinguishes the default 1 GB whole-file download memory budget from streaming, and names the released bounded-memory APIs: `client.streamAndSave(source, options)`, `client.openFile(file, options)`, `reader.stream(options)` and `reader.pipeTo(destination, options)`. It records that streaming downloads and media no longer have a fixed 1 GB cap and updates release-specific links. The tutorial pins package `0.1.3` and links to that release; its HTML and JavaScript are unchanged. + +## Tutorial exercise + +The tutorial was run as a new disposable project under `/var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode` with Node.js `22.22.3`, npm `10.9.8`, `@withautonomi/ant-browser-sdk@0.1.3` and Vite `8.2.0`. The literal setup, build and serving commands were: + +```bash +mkdir autonomi-browser-demo +cd autonomi-browser-demo +npm init -y +npm install --save-exact @withautonomi/ant-browser-sdk@0.1.3 +npm install --save-dev --save-exact vite@8.2.0 +npx vite --host 127.0.0.1 --port 5179 --strictPort +npx vite build +npx vite preview --host 127.0.0.1 --port 5180 --strictPort +``` + +The production build completed with 29 transformed modules and emitted the JavaScript, upload-worker and WASM assets. Fresh Playwright Chromium `141.0.7390.37` on macOS ARM64 exercised both the development server and production preview through the documented public read. Each returned 138931 bytes, decoded a 782 by 1600 image, matched SHA-256 `98f657d987d339c302295e79907e7a4abc1564bd6b42300ea8d59ccd2148fd17`, received HTTP 200 for WASM, produced no uncaught page errors and restored the download button. + +A focused development-server exercise returned HTTP 503 for the first WASM request. The page reported `Download failed: Could not initialize the Autonomi WASM core` and restored the button. Removing the interception and retrying in the same page then produced the verified successful read above, with the second WASM request returning HTTP 200. + +These are new 0.1.3 results, not reused 0.1.2 evidence. npm reported one high-severity dependency advisory during the Vite installation; no dependency or environment change was made to suppress it. + +## Limits and review boundary + +No wallet, payment, upload, personal browser profile, global package installation, daemon, source patch or production write was used. Uploads, paid flows, streaming of a large file, media playback, Safari, Firefox and other browser or operating-system combinations were not exercised. The successful public read used the package's bundled mainnet defaults and does not establish a browser-wide support claim. + +The source audit checked the released API names and call forms, but the runtime exercise covers only the existing public-read tutorial and focused initialization retry. The promotion mechanism validates structure, scope, tag reachability and recorded relationships; maintainer review must still compare the npm integrity, shipped WASM evidence, rendered wording and these manually gathered results with public provider truth. No CI or external review result is claimed. + +## Repository checks + +Before commit, the static release-baseline validator passed; the focused documentation-guard suite passed 41 tests; the focused release-following suite passed 35 tests; and the full repository suite passed 107 tests. ADR governance passed with no changed ADRs. A focused check confirmed the exact Browser SDK block on all six pages, byte-preserved every unrelated verification block and resolved 89 relative links. The working-tree whitespace check passed. + +The commit-range promotion validator and range whitespace check run after the complete candidate is committed; their results are retained in the execution handoff rather than back-written into this record. diff --git a/target-manifest.yml b/target-manifest.yml index 6fecd58..b1ba369 100644 --- a/target-manifest.yml +++ b/target-manifest.yml @@ -12,17 +12,17 @@ scope: sources: ant-browser-sdk: - source_ref: v0.1.2 - source_commit: a29a87cf8d8f696ae5e8b22d6ee4f91d4e7bfbb0 - release_url: https://github.com/WithAutonomi/ant-browser-sdk/releases/tag/v0.1.2 + source_ref: v0.1.3 + source_commit: 813aa1817274551e3596038ffc8d2706672eba3b + release_url: https://github.com/WithAutonomi/ant-browser-sdk/releases/tag/v0.1.3 support_status: experimental package: name: "@withautonomi/ant-browser-sdk" - version: 0.1.2 - metadata_url: https://registry.npmjs.org/@withautonomi/ant-browser-sdk/0.1.2 - integrity: sha512-uVnIVmuJjyTs1yHyRTNJof2tGIMf2STkRhi8iEGQqaNnizZFKZ6qElZlCIttGBdXwn10TRaERhniRGAeOQa3rg== + version: 0.1.3 + metadata_url: https://registry.npmjs.org/@withautonomi/ant-browser-sdk/0.1.3 + integrity: sha512-eAqVQLWNMZzaJGcuYFHT97zacz89u6qhM9lum3X8s8AY/6eIF+t2tj4WnIHxufaLchXfi6o80kmKqwrm4Jc9QQ== shipped_wasm: source_repo: ant-client - source_commit: 9858af5dbbb2caf090e20db67ac62aa4bd100c81 - sha256: ab58bd3e331436d22acfe3d08b384992be9addec52145fa0325468c27b6da70a - evidence_url: https://github.com/WithAutonomi/ant-browser-sdk/blob/a29a87cf8d8f696ae5e8b22d6ee4f91d4e7bfbb0/src/wasm/source.json + source_commit: ccd4106dd8fd60545bbd31c40d46cc041f85fb8d + sha256: 08ae5d0cc7b96458ba9899d68be0455b276848644237f42704419a2e4311fec4 + evidence_url: https://github.com/WithAutonomi/ant-browser-sdk/blob/813aa1817274551e3596038ffc8d2706672eba3b/src/wasm/source.json From 8302a6ae3bb571e350d771b5ed80891eb3f38113 Mon Sep 17 00:00:00 2001 From: Jim Collinson <13061030+JimCollinson@users.noreply.github.com> Date: Tue, 27 Oct 2026 17:42:04 +0000 Subject: [PATCH 2/8] docs(releases-browser): supersede Browser SDK 0.1.3 with 0.1.4 - Advance all scoped release identities and links to the public 0.1.4 package - Record verified package provenance and fresh browser runtime evidence --- docs/sdk/build-in-browser.md | 10 +- docs/sdk/how-to-guides/README.md | 4 +- .../how-to-guides/retrieve-data-in-browser.md | 10 +- docs/sdk/install.md | 4 +- docs/sdk/reference/README.md | 4 +- docs/sdk/reference/overview.md | 4 +- planning/sweeps/2026-10-27.md | 153 +++++++++++++++--- target-manifest.yml | 18 +-- 8 files changed, 159 insertions(+), 48 deletions(-) diff --git a/docs/sdk/build-in-browser.md b/docs/sdk/build-in-browser.md index 258d4a2..5b5e69e 100644 --- a/docs/sdk/build-in-browser.md +++ b/docs/sdk/build-in-browser.md @@ -2,8 +2,8 @@ @@ -67,17 +67,17 @@ You do not have to load every file into memory before using it. The SDK provides For seekable audio and video, the SDK provides a service worker: a browser-managed script that connects a media element's requests to the SDK's file reader. This setup requires HTTPS or localhost and the application's page to remain open. Applications with an existing service worker must integrate the media handling with it. -Browser SDK 0.1.3 accepts uploads from 3 bytes up to 1 GB (1,000,000,000 bytes). +Browser SDK 0.1.4 accepts uploads from 3 bytes up to 1 GB (1,000,000,000 bytes). `download()` and `downloadAndSave()` buffer the whole file and use a default 1 GB `maxMemoryBytes` budget. You can pass a different budget, but the returned bytes and `Blob`, the resolved DataMap, caches and transport buffers need additional memory. -Streaming downloads and media do not have a fixed 1 GB cap. For bounded-memory downloads, use `client.streamAndSave(source, options)` or `client.openFile(file, options)` followed by `reader.pipeTo(destination, options)`. Use `reader.stream(options)` to consume a bounded stream in your application. Browser memory, storage and safe-integer limits remain practical constraints. Uploads from byte arrays may run out of memory before reaching the upload cap. The [browser SDK API documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.3#stream-directly-to-disk) covers streaming saves, range reads, media setup and file-size limits. +Streaming downloads and media do not have a fixed 1 GB cap. For bounded-memory downloads, use `client.streamAndSave(source, options)` or `client.openFile(file, options)` followed by `reader.pipeTo(destination, options)`. Use `reader.stream(options)` to consume a bounded stream in your application. Browser memory, storage and safe-integer limits remain practical constraints. Uploads from byte arrays may run out of memory before reaching the upload cap. The [browser SDK API documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#stream-directly-to-disk) covers streaming saves, range reads, media setup and file-size limits. ## Uploading from a browser The SDK also accepts browser files and byte arrays for public or private uploads. Your application supplies a payment provider to authorize storage payments; supported integrations include Ethers and Wagmi/Viem. A read-only application does not need these wallet integrations. -File uploads have additional browser requirements, including a worker for file processing and IndexedDB for temporary storage. Use the [browser SDK's upload documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.3#upload-files) when adding uploads and payment handling. +File uploads have additional browser requirements, including a worker for file processing and IndexedDB for temporary storage. Use the [browser SDK's upload documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#upload-files) when adding uploads and payment handling. ## Network compatibility diff --git a/docs/sdk/how-to-guides/README.md b/docs/sdk/how-to-guides/README.md index a0a1b62..38adbc7 100644 --- a/docs/sdk/how-to-guides/README.md +++ b/docs/sdk/how-to-guides/README.md @@ -10,8 +10,8 @@ diff --git a/docs/sdk/how-to-guides/retrieve-data-in-browser.md b/docs/sdk/how-to-guides/retrieve-data-in-browser.md index 4f099c4..caf7531 100644 --- a/docs/sdk/how-to-guides/retrieve-data-in-browser.md +++ b/docs/sdk/how-to-guides/retrieve-data-in-browser.md @@ -2,8 +2,8 @@ @@ -30,7 +30,7 @@ This example only reads existing public data. It does not configure a wallet or Vite serves the JavaScript and WASM assets during development and bundles them for deployment. -This tutorial uses browser SDK 0.1.3 and Vite 8.2.0. The commands save these exact versions so reinstalling the project does not select a different version of either package. +This tutorial uses browser SDK 0.1.4 and Vite 8.2.0. The commands save these exact versions so reinstalling the project does not select a different version of either package. In a terminal, run: @@ -38,7 +38,7 @@ In a terminal, run: mkdir autonomi-browser-demo cd autonomi-browser-demo npm init -y -npm install --save-exact @withautonomi/ant-browser-sdk@0.1.3 +npm install --save-exact @withautonomi/ant-browser-sdk@0.1.4 npm install --save-dev --save-exact vite@8.2.0 ``` @@ -174,7 +174,7 @@ The browser retrieves the data directly from Autonomi nodes. Vite serves your ap ## Next steps -- [Browser SDK documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.3): upload, wallet, private-file and media APIs for the same experimental release. +- [Browser SDK documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4): upload, wallet, private-file and media APIs for the same experimental release. - [Browser SDK](../build-in-browser.md): capabilities, application ideas and how browser connections work. - [Build with the SDKs](../install.md): compare application connection options. - [Keys, Addresses, and DataMaps](../../core-concepts/keys-addresses-and-datamaps.md): understand public addresses and private-file access. diff --git a/docs/sdk/install.md b/docs/sdk/install.md index 1eff607..eb456f3 100644 --- a/docs/sdk/install.md +++ b/docs/sdk/install.md @@ -10,8 +10,8 @@ diff --git a/docs/sdk/reference/README.md b/docs/sdk/reference/README.md index 10eebb1..70ea3f9 100644 --- a/docs/sdk/reference/README.md +++ b/docs/sdk/reference/README.md @@ -10,8 +10,8 @@ diff --git a/docs/sdk/reference/overview.md b/docs/sdk/reference/overview.md index 5b30c88..e174cfc 100644 --- a/docs/sdk/reference/overview.md +++ b/docs/sdk/reference/overview.md @@ -10,8 +10,8 @@ diff --git a/planning/sweeps/2026-10-27.md b/planning/sweeps/2026-10-27.md index 96615b5..74ef87f 100644 --- a/planning/sweeps/2026-10-27.md +++ b/planning/sweeps/2026-10-27.md @@ -1,15 +1,18 @@ -# Browser SDK 0.1.3 promotion — 2026-10-27 +# Browser SDK 0.1.4 promotion — 2026-10-27 + +Browser SDK 0.1.4 was released after the unpushed 0.1.3 promotion candidate was committed. This record supersedes that candidate before push. The final `origin/main..HEAD` range therefore promotes the published documentation directly from 0.1.2 to 0.1.4; 0.1.3 is not presented as an intermediate documentation baseline. ## Release evidence -- GitHub tag `v0.1.3` resolves to source commit `813aa1817274551e3596038ffc8d2706672eba3b`. The [public release](https://github.com/WithAutonomi/ant-browser-sdk/releases/tag/v0.1.3) is neither a draft nor a prerelease. This was checked through `git ls-remote`, the GitHub release API and a detached checkout of the exact commit. -- The exact [npm metadata](https://registry.npmjs.org/@withautonomi/ant-browser-sdk/0.1.3) identifies `@withautonomi/ant-browser-sdk` version `0.1.3` with integrity `sha512-eAqVQLWNMZzaJGcuYFHT97zacz89u6qhM9lum3X8s8AY/6eIF+t2tj4WnIHxufaLchXfi6o80kmKqwrm4Jc9QQ==`. A fresh tarball download reproduced that SHA-512 value and its SHA-1 metadata value. The npm tarball and GitHub release asset both had SHA-256 `cd6db9f2d4d72e3e966663b89bc2d8465b9b7fe197ec227fa2e094d379719984`. -- The release's immutable [`src/wasm/source.json`](https://github.com/WithAutonomi/ant-browser-sdk/blob/813aa1817274551e3596038ffc8d2706672eba3b/src/wasm/source.json) records ant-client commit `ccd4106dd8fd60545bbd31c40d46cc041f85fb8d` and WASM SHA-256 `08ae5d0cc7b96458ba9899d68be0455b276848644237f42704419a2e4311fec4`. Hashing `dist/wasm/ant_core_bg.wasm` from the independently downloaded npm package reproduced that value. -- The released source and packaged README still call the SDK and direct-browser protocol experimental. This promotion does not change that status. +- GitHub tag `v0.1.4` resolves to source commit `5199100c15527bf657ae4a795c2bdf5d086981f7`. The [public release](https://github.com/WithAutonomi/ant-browser-sdk/releases/tag/v0.1.4) was published on 2026-10-27 at `2026-10-27T16:01:23Z` and is neither a draft nor a prerelease. This was checked through `git ls-remote`, the GitHub release API and a detached checkout of the exact commit. +- The exact [npm metadata](https://registry.npmjs.org/@withautonomi/ant-browser-sdk/0.1.4) identifies `@withautonomi/ant-browser-sdk` version `0.1.4`, integrity `sha512-MD/p2TctBvB1KkE6KCrxiE5m0S0il1gmGIQlRpeSEhoItkJfxO/72uxAkxUz77gCpxOwkegjb0ZbPIJgGaq66w==` and SHA-1 shasum `279652b24675a29feeefb8df0931cd6fdf0b1f1d`. Freshly downloading the npm tarball reproduced both values. +- The npm tarball and the 2,542,615-byte GitHub release asset were byte-identical. Both had SHA-256 `15d9e015929c3e59eb29bd981cb1fb2429f960be76e2c2ab169c506457c0b1fb`, matching the GitHub asset digest `sha256:15d9e015929c3e59eb29bd981cb1fb2429f960be76e2c2ab169c506457c0b1fb`. +- The release's immutable [`src/wasm/source.json`](https://github.com/WithAutonomi/ant-browser-sdk/blob/5199100c15527bf657ae4a795c2bdf5d086981f7/src/wasm/source.json) and the source record shipped in the package both identify ant-client commit `7a432e7c4442b4628872bd5cf6a3e896e7fc10ad` and WASM SHA-256 `7873c65138aa499c48a8c34d9dbaa2fdd82509ca6e981afe9a4f77331b9e4cf4`. Hashing the shipped `dist/wasm/ant_core_bg.wasm` reproduced that value. +- The released source and packaged README still call the SDK and direct-browser protocol experimental. The 0.1.3-to-0.1.4 source comparison leaves the README and public TypeScript API and limit sources byte-identical. The 0.1.4 release changes the bundled ant-client WASM for faster browser downloads; it does not change the documented SDK API or limits. ## Documentation changes -All six mapped pages advance only their Browser SDK verification block to `v0.1.3`, the exact release commit and `2026-10-27`: +All six mapped pages advance only their Browser SDK verification block to `v0.1.4`, exact release commit `5199100c15527bf657ae4a795c2bdf5d086981f7` and `2026-10-27`: - `docs/sdk/build-in-browser.md` - `docs/sdk/how-to-guides/retrieve-data-in-browser.md` @@ -18,37 +21,145 @@ All six mapped pages advance only their Browser SDK verification block to `v0.1. - `docs/sdk/reference/overview.md` - `docs/sdk/reference/README.md` -Rendered changes are limited to the overview and tutorial. The overview retains the 1 GB upload cap, distinguishes the default 1 GB whole-file download memory budget from streaming, and names the released bounded-memory APIs: `client.streamAndSave(source, options)`, `client.openFile(file, options)`, `reader.stream(options)` and `reader.pipeTo(destination, options)`. It records that streaming downloads and media no longer have a fixed 1 GB cap and updates release-specific links. The tutorial pins package `0.1.3` and links to that release; its HTML and JavaScript are unchanged. +Rendered changes remain limited to the overview and tutorial. The overview advances its version and source links to 0.1.4 while retaining the released API and limit prose: the 1 GB upload cap, the default 1 GB whole-file download memory budget and the bounded-memory streaming APIs. The tutorial pins package 0.1.4 and links to that release; its HTML and JavaScript are unchanged. + +## Fresh 0.1.4 tutorial exercise -## Tutorial exercise +The tutorial was run as a new disposable project at `/var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode/browser-sdk-014-runtime.20261027` on macOS ARM64 with Node.js `22.22.3`, npm `10.9.8`, exact `@withautonomi/ant-browser-sdk@0.1.4`, exact Vite `8.2.0`, exact `@playwright/test@1.64.1` and a freshly downloaded Playwright Chromium `156.0.8078.4`. The project files `index.html` and `main.js` were copied from the tutorial's complete code blocks. -The tutorial was run as a new disposable project under `/var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode` with Node.js `22.22.3`, npm `10.9.8`, `@withautonomi/ant-browser-sdk@0.1.3` and Vite `8.2.0`. The literal setup, build and serving commands were: +The disposable project and isolated browser were created with: ```bash -mkdir autonomi-browser-demo -cd autonomi-browser-demo +mkdir /var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode/browser-sdk-014-runtime.20261027 +cd /var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode/browser-sdk-014-runtime.20261027 npm init -y -npm install --save-exact @withautonomi/ant-browser-sdk@0.1.3 +npm install --save-exact @withautonomi/ant-browser-sdk@0.1.4 npm install --save-dev --save-exact vite@8.2.0 -npx vite --host 127.0.0.1 --port 5179 --strictPort -npx vite build -npx vite preview --host 127.0.0.1 --port 5180 --strictPort +mkdir qa +npm init -y --prefix qa +npm install --prefix qa --save-exact @playwright/test@1.64.1 +PLAYWRIGHT_BROWSERS_PATH=qa/browsers npx --prefix qa playwright install chromium +``` + +The exact Playwright procedure was saved as `qa/check.mjs` in that project: + +```javascript +import assert from "node:assert/strict"; +import { chromium } from "@playwright/test"; + +const url = process.argv[2]; +const retry = process.argv.includes("--retry"); +assert.ok(url, "usage: node qa/check.mjs [--retry]"); + +const browser = await chromium.launch(); +try { + const page = await browser.newPage(); + const pageErrors = []; + const wasmResponses = []; + page.on("pageerror", (error) => pageErrors.push(String(error))); + page.on("response", (response) => { + if (new URL(response.url()).pathname.endsWith(".wasm")) { + wasmResponses.push({ status: response.status(), url: response.url() }); + } + }); + + let failedWasmUrl; + if (retry) { + await page.route("**/*.wasm", async (route) => { + failedWasmUrl = route.request().url(); + await route.fulfill({ status: 503, body: "intentional first-WASM failure" }); + }); + } + + await page.goto(url); + const button = page.locator("#download"); + const status = page.locator("#status"); + await button.click(); + + if (retry) { + await page.waitForFunction( + () => document.querySelector("#status").textContent.startsWith("Download failed:"), + null, + { timeout: 195_000 }, + ); + assert.equal( + await status.textContent(), + "Download failed: Could not initialize the Autonomi WASM core", + ); + assert.equal(await button.isEnabled(), true); + assert.ok(failedWasmUrl?.endsWith(".wasm")); + await page.unroute("**/*.wasm"); + await button.click(); + } + + await page.waitForFunction( + () => document.querySelector("#status").textContent === "Downloaded 138931 bytes.", + null, + { timeout: 195_000 }, + ); + await page.waitForFunction(() => document.querySelector("#preview").naturalWidth > 0); + const image = await page.locator("#preview").evaluate(async (element) => { + const bytes = await (await fetch(element.src)).arrayBuffer(); + const digest = await crypto.subtle.digest("SHA-256", bytes); + return { + bytes: bytes.byteLength, + width: element.naturalWidth, + height: element.naturalHeight, + sha256: [...new Uint8Array(digest)] + .map((byte) => byte.toString(16).padStart(2, "0")) + .join(""), + }; + }); + + assert.deepEqual(image, { + bytes: 138931, + width: 782, + height: 1600, + sha256: "98f657d987d339c302295e79907e7a4abc1564bd6b42300ea8d59ccd2148fd17", + }); + assert.equal(await button.isEnabled(), true); + assert.deepEqual(pageErrors, []); + assert.equal(wasmResponses.at(-1)?.status, 200); + console.log(JSON.stringify({ + url, + retry, + browser: browser.version(), + platform: process.platform, + arch: process.arch, + failedWasmUrl, + finalStatus: await status.textContent(), + image, + wasmResponses, + pageErrors, + buttonRestored: await button.isEnabled(), + }, null, 2)); +} finally { + await browser.close(); +} ``` -The production build completed with 29 transformed modules and emitted the JavaScript, upload-worker and WASM assets. Fresh Playwright Chromium `141.0.7390.37` on macOS ARM64 exercised both the development server and production preview through the documented public read. Each returned 138931 bytes, decoded a 782 by 1600 image, matched SHA-256 `98f657d987d339c302295e79907e7a4abc1564bd6b42300ea8d59ccd2148fd17`, received HTTP 200 for WASM, produced no uncaught page errors and restored the download button. +With the matching server kept running in another terminal, the commands were: + +```bash +npm exec -- vite --host 127.0.0.1 --port 5179 --strictPort +PLAYWRIGHT_BROWSERS_PATH=qa/browsers node qa/check.mjs http://127.0.0.1:5179/ --retry +npm exec -- vite build +npm exec -- vite preview --host 127.0.0.1 --port 5180 --strictPort +PLAYWRIGHT_BROWSERS_PATH=qa/browsers node qa/check.mjs http://127.0.0.1:5180/ +``` -A focused development-server exercise returned HTTP 503 for the first WASM request. The page reported `Download failed: Could not initialize the Autonomi WASM core` and restored the button. Removing the interception and retrying in the same page then produced the verified successful read above, with the second WASM request returning HTTP 200. +The development exercise intercepted the first WASM request with HTTP 503. The page reported `Download failed: Could not initialize the Autonomi WASM core` and restored the button. Removing the interception and retrying in the same page succeeded; the next WASM request returned HTTP 200. The production build completed with 29 transformed modules and emitted the JavaScript, upload-worker and WASM assets. Its preview read also received HTTP 200 for WASM. -These are new 0.1.3 results, not reused 0.1.2 evidence. npm reported one high-severity dependency advisory during the Vite installation; no dependency or environment change was made to suppress it. +Both successful reads returned exactly 138931 bytes, decoded a 782 by 1600 image, matched SHA-256 `98f657d987d339c302295e79907e7a4abc1564bd6b42300ea8d59ccd2148fd17`, produced no uncaught page errors and restored the download button. These are fresh 0.1.4 results, not carried forward from 0.1.3 or 0.1.2. npm reported one high-severity dependency advisory during the Vite installation; no dependency or environment change was made to suppress it. ## Limits and review boundary No wallet, payment, upload, personal browser profile, global package installation, daemon, source patch or production write was used. Uploads, paid flows, streaming of a large file, media playback, Safari, Firefox and other browser or operating-system combinations were not exercised. The successful public read used the package's bundled mainnet defaults and does not establish a browser-wide support claim. -The source audit checked the released API names and call forms, but the runtime exercise covers only the existing public-read tutorial and focused initialization retry. The promotion mechanism validates structure, scope, tag reachability and recorded relationships; maintainer review must still compare the npm integrity, shipped WASM evidence, rendered wording and these manually gathered results with public provider truth. No CI or external review result is claimed. +The source audit checked the released API names and call forms, but the runtime exercise covers only the existing public-read tutorial and focused initialization retry. The promotion mechanism validates structure, scope, tag reachability and recorded relationships; maintainer review must still compare the npm integrity, shipped WASM evidence, rendered wording and manually gathered results with public provider truth. No CI or external review result is claimed. ## Repository checks -Before commit, the static release-baseline validator passed; the focused documentation-guard suite passed 41 tests; the focused release-following suite passed 35 tests; and the full repository suite passed 107 tests. ADR governance passed with no changed ADRs. A focused check confirmed the exact Browser SDK block on all six pages, byte-preserved every unrelated verification block and resolved 89 relative links. The working-tree whitespace check passed. +Before commit, the static release-baseline validator passed; the focused documentation-guard suite passed 41 tests; the focused release-following suite passed 35 tests; and the full repository suite passed 107 tests. ADR governance passed with no changed ADRs. Focused checks confirmed that the tutorial code blocks are byte-identical to the exercised project, all six Browser SDK blocks match 0.1.4, every unrelated verification block is byte-identical to `origin/main`, all 89 relative links resolve and all new external release/source links return HTTP 200. The working-tree whitespace check passed. -The commit-range promotion validator and range whitespace check run after the complete candidate is committed; their results are retained in the execution handoff rather than back-written into this record. +The exact commit-range promotion validator and range whitespace check run from `origin/main` to `HEAD` after committing; their results are retained in the execution handoff rather than back-written into this record. diff --git a/target-manifest.yml b/target-manifest.yml index b1ba369..c4bdbae 100644 --- a/target-manifest.yml +++ b/target-manifest.yml @@ -12,17 +12,17 @@ scope: sources: ant-browser-sdk: - source_ref: v0.1.3 - source_commit: 813aa1817274551e3596038ffc8d2706672eba3b - release_url: https://github.com/WithAutonomi/ant-browser-sdk/releases/tag/v0.1.3 + source_ref: v0.1.4 + source_commit: 5199100c15527bf657ae4a795c2bdf5d086981f7 + release_url: https://github.com/WithAutonomi/ant-browser-sdk/releases/tag/v0.1.4 support_status: experimental package: name: "@withautonomi/ant-browser-sdk" - version: 0.1.3 - metadata_url: https://registry.npmjs.org/@withautonomi/ant-browser-sdk/0.1.3 - integrity: sha512-eAqVQLWNMZzaJGcuYFHT97zacz89u6qhM9lum3X8s8AY/6eIF+t2tj4WnIHxufaLchXfi6o80kmKqwrm4Jc9QQ== + version: 0.1.4 + metadata_url: https://registry.npmjs.org/@withautonomi/ant-browser-sdk/0.1.4 + integrity: sha512-MD/p2TctBvB1KkE6KCrxiE5m0S0il1gmGIQlRpeSEhoItkJfxO/72uxAkxUz77gCpxOwkegjb0ZbPIJgGaq66w== shipped_wasm: source_repo: ant-client - source_commit: ccd4106dd8fd60545bbd31c40d46cc041f85fb8d - sha256: 08ae5d0cc7b96458ba9899d68be0455b276848644237f42704419a2e4311fec4 - evidence_url: https://github.com/WithAutonomi/ant-browser-sdk/blob/813aa1817274551e3596038ffc8d2706672eba3b/src/wasm/source.json + source_commit: 7a432e7c4442b4628872bd5cf6a3e896e7fc10ad + sha256: 7873c65138aa499c48a8c34d9dbaa2fdd82509ca6e981afe9a4f77331b9e4cf4 + evidence_url: https://github.com/WithAutonomi/ant-browser-sdk/blob/5199100c15527bf657ae4a795c2bdf5d086981f7/src/wasm/source.json From 3d3c3411e97e0416e33c0761c9171a3d8399cd68 Mon Sep 17 00:00:00 2001 From: Jim Collinson <13061030+JimCollinson@users.noreply.github.com> Date: Tue, 27 Oct 2026 18:03:55 +0000 Subject: [PATCH 3/8] fix(releases-browser): pin patched Vite tutorial dependency - Replace the vulnerable Vite 8.2.0 tutorial pin with 8.3.5 - Record clean audit and repeated browser runtime evidence --- .../how-to-guides/retrieve-data-in-browser.md | 4 ++-- planning/sweeps/2026-10-27.md | 19 +++++++++++-------- 2 files changed, 13 insertions(+), 10 deletions(-) diff --git a/docs/sdk/how-to-guides/retrieve-data-in-browser.md b/docs/sdk/how-to-guides/retrieve-data-in-browser.md index caf7531..d1e6f5d 100644 --- a/docs/sdk/how-to-guides/retrieve-data-in-browser.md +++ b/docs/sdk/how-to-guides/retrieve-data-in-browser.md @@ -30,7 +30,7 @@ This example only reads existing public data. It does not configure a wallet or Vite serves the JavaScript and WASM assets during development and bundles them for deployment. -This tutorial uses browser SDK 0.1.4 and Vite 8.2.0. The commands save these exact versions so reinstalling the project does not select a different version of either package. +This tutorial uses browser SDK 0.1.4 and Vite 8.3.5. The commands save these exact versions so reinstalling the project does not select a different version of either package. In a terminal, run: @@ -39,7 +39,7 @@ mkdir autonomi-browser-demo cd autonomi-browser-demo npm init -y npm install --save-exact @withautonomi/ant-browser-sdk@0.1.4 -npm install --save-dev --save-exact vite@8.2.0 +npm install --save-dev --save-exact vite@8.3.5 ``` ### 2. Add the page diff --git a/planning/sweeps/2026-10-27.md b/planning/sweeps/2026-10-27.md index 74ef87f..81e5c9e 100644 --- a/planning/sweeps/2026-10-27.md +++ b/planning/sweeps/2026-10-27.md @@ -21,20 +21,23 @@ All six mapped pages advance only their Browser SDK verification block to `v0.1. - `docs/sdk/reference/overview.md` - `docs/sdk/reference/README.md` -Rendered changes remain limited to the overview and tutorial. The overview advances its version and source links to 0.1.4 while retaining the released API and limit prose: the 1 GB upload cap, the default 1 GB whole-file download memory budget and the bounded-memory streaming APIs. The tutorial pins package 0.1.4 and links to that release; its HTML and JavaScript are unchanged. +Rendered changes remain limited to the overview and tutorial. The overview advances its version and source links to 0.1.4 while retaining the released API and limit prose: the 1 GB upload cap, the default 1 GB whole-file download memory budget and the bounded-memory streaming APIs. The tutorial pins package 0.1.4 and links to that release; its HTML and JavaScript are unchanged. Final mechanical review found that the tutorial's pre-existing Vite 8.2.0 pin was covered by a high-severity command-injection advisory, so the tutorial now pins the patched non-major Vite 8.3.5 release. ## Fresh 0.1.4 tutorial exercise -The tutorial was run as a new disposable project at `/var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode/browser-sdk-014-runtime.20261027` on macOS ARM64 with Node.js `22.22.3`, npm `10.9.8`, exact `@withautonomi/ant-browser-sdk@0.1.4`, exact Vite `8.2.0`, exact `@playwright/test@1.64.1` and a freshly downloaded Playwright Chromium `156.0.8078.4`. The project files `index.html` and `main.js` were copied from the tutorial's complete code blocks. +The corrected tutorial was run as a new disposable project at `/var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode/browser-sdk-014-vite-835-runtime.20261027` on macOS ARM64 with Node.js `22.22.3`, npm `10.9.8`, exact `@withautonomi/ant-browser-sdk@0.1.4`, exact Vite `8.3.5`, exact `@playwright/test@1.64.1` and a freshly downloaded Playwright Chromium `156.0.8078.4`. The project files `index.html` and `main.js` were copied from the tutorial's complete code blocks. + +The npm metadata for Vite 8.3.5 records integrity `sha512-z1YpjieJ9g0ebTmQpLBv/oq9E3F9EIlOe+7LahW8SrE3LTiG3udBRUXQOlYXP9b+IC2q2phHeVxj9xGlw34OEQ==`, SHA-1 shasum `9614f66026cb92fe486cb9d3c90780b2a69fc85d` and Node.js compatibility `^20.19.0 || >=22.12.0`; the exercised Node.js 22.22.3 satisfies that range. A fresh `npm audit --audit-level=low` of the exact tutorial install reported zero known vulnerabilities. Rechecking the prior exact Vite 8.2.0 project reproduced one high-severity direct Vite finding and identified 8.3.5 as the available non-major fix. The disposable project and isolated browser were created with: ```bash -mkdir /var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode/browser-sdk-014-runtime.20261027 -cd /var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode/browser-sdk-014-runtime.20261027 +mkdir /var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode/browser-sdk-014-vite-835-runtime.20261027 +cd /var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode/browser-sdk-014-vite-835-runtime.20261027 npm init -y npm install --save-exact @withautonomi/ant-browser-sdk@0.1.4 -npm install --save-dev --save-exact vite@8.2.0 +npm install --save-dev --save-exact vite@8.3.5 +npm audit --audit-level=low mkdir qa npm init -y --prefix qa npm install --prefix qa --save-exact @playwright/test@1.64.1 @@ -148,9 +151,9 @@ npm exec -- vite preview --host 127.0.0.1 --port 5180 --strictPort PLAYWRIGHT_BROWSERS_PATH=qa/browsers node qa/check.mjs http://127.0.0.1:5180/ ``` -The development exercise intercepted the first WASM request with HTTP 503. The page reported `Download failed: Could not initialize the Autonomi WASM core` and restored the button. Removing the interception and retrying in the same page succeeded; the next WASM request returned HTTP 200. The production build completed with 29 transformed modules and emitted the JavaScript, upload-worker and WASM assets. Its preview read also received HTTP 200 for WASM. +The development exercise intercepted the first WASM request with HTTP 503. The page reported `Download failed: Could not initialize the Autonomi WASM core` and restored the button. Removing the interception and retrying in the same page succeeded; the next WASM request returned HTTP 200. Vite 8.3.5 completed the production build with 29 transformed modules and emitted the JavaScript, upload-worker and WASM assets. Its preview read also received HTTP 200 for WASM. -Both successful reads returned exactly 138931 bytes, decoded a 782 by 1600 image, matched SHA-256 `98f657d987d339c302295e79907e7a4abc1564bd6b42300ea8d59ccd2148fd17`, produced no uncaught page errors and restored the download button. These are fresh 0.1.4 results, not carried forward from 0.1.3 or 0.1.2. npm reported one high-severity dependency advisory during the Vite installation; no dependency or environment change was made to suppress it. +Both successful reads returned exactly 138931 bytes, decoded a 782 by 1600 image, matched SHA-256 `98f657d987d339c302295e79907e7a4abc1564bd6b42300ea8d59ccd2148fd17`, produced no uncaught page errors and restored the download button. These are fresh Browser SDK 0.1.4 and Vite 8.3.5 results, not carried forward from the earlier Vite 8.2.0 exercise or Browser SDK 0.1.3 or 0.1.2. The dependency correction changes only the tutorial's build-tool pin; the Browser SDK release and source pins remain unchanged. ## Limits and review boundary @@ -160,6 +163,6 @@ The source audit checked the released API names and call forms, but the runtime ## Repository checks -Before commit, the static release-baseline validator passed; the focused documentation-guard suite passed 41 tests; the focused release-following suite passed 35 tests; and the full repository suite passed 107 tests. ADR governance passed with no changed ADRs. Focused checks confirmed that the tutorial code blocks are byte-identical to the exercised project, all six Browser SDK blocks match 0.1.4, every unrelated verification block is byte-identical to `origin/main`, all 89 relative links resolve and all new external release/source links return HTTP 200. The working-tree whitespace check passed. +After the Vite correction, the static release-baseline validator passed; the focused documentation-guard suite passed 41 tests; the focused release-following suite passed 35 tests; and the full repository suite passed 107 tests. ADR governance passed with no changed ADRs. Focused checks confirmed that the tutorial HTML, JavaScript and preserved Playwright procedure are byte-identical to the exercised project; the exact package pins are present; all six Browser SDK blocks match 0.1.4; every unrelated verification block is byte-identical to `origin/main`; all 89 relative links resolve; and all new external release/source links return HTTP 200. The working-tree whitespace check passed. This resolves the final mechanical review blocker without changing the Browser SDK source or release evidence. The exact commit-range promotion validator and range whitespace check run from `origin/main` to `HEAD` after committing; their results are retained in the execution handoff rather than back-written into this record. From 8fbd563b123ffbba4893cc634e376cf22d6e1330 Mon Sep 17 00:00:00 2001 From: Jim Collinson <13061030+JimCollinson@users.noreply.github.com> Date: Wed, 28 Oct 2026 09:34:34 +0000 Subject: [PATCH 4/8] fix(releases-browser): cover full release capability delta --- docs/sdk/build-in-browser.md | 39 +++++++++++++++---- docs/sdk/how-to-guides/README.md | 1 + .../how-to-guides/retrieve-data-in-browser.md | 4 +- docs/sdk/install.md | 6 +-- docs/sdk/reference/README.md | 4 +- docs/sdk/reference/overview.md | 2 +- planning/release-baseline-maintenance.md | 4 +- planning/sweeps/2026-10-27.md | 28 +++++++++---- 8 files changed, 64 insertions(+), 24 deletions(-) diff --git a/docs/sdk/build-in-browser.md b/docs/sdk/build-in-browser.md index 5b5e69e..ba2bf1b 100644 --- a/docs/sdk/build-in-browser.md +++ b/docs/sdk/build-in-browser.md @@ -26,7 +26,8 @@ The SDK gives your web application access to stored content. You choose how to p | Image gallery | Retrieve images and display them with ordinary browser elements | | Audio or video player | Read media progressively and support seeking without downloading the entire file first | | Data viewer | Retrieve a stored dataset or JSON file and present it as tables, charts or another application view | -| File-sharing application | Let users retrieve public files or authorize paid uploads from the browser | +| File-sharing application | Open or create links and portable collections, then retrieve public or shared private files | +| Updatable catalogue or profile | Keep one lasting address while the content behind it changes | These are application patterns, not ready-made interfaces included in the SDK. For example, a book reader still needs code that understands the book's format and displays its pages. The SDK supplies access to the file's data. @@ -61,23 +62,47 @@ Private files require their DataMap, the information needed to locate and decryp For a complete working example, follow [Retrieve Data in the Browser](how-to-guides/retrieve-data-in-browser.md). It downloads a public image and displays it in a small web page. -## Streaming and larger files +## Sharing files and collections + +An `ant://` link can identify one public file or describe a collection of files. The collection form carries a manifest: a portable list of file names and the information needed to retrieve each one. Your application can also open the same kind of collection from a `.ant` file. + +A manifest does not upload or publish its files. Your application can create one from files it has already uploaded, then offer the link or `.ant` file to another person. The recipient can open the manifest and choose which entries to retrieve. + +Public entries contain an address. An embedded entry contains the DataMap needed to read a private file. Anyone who receives a manifest with an embedded entry receives access to that private file, so protect that manifest as you would protect the DataMap itself. + +See the released SDK documentation for [opening manifests and `ant://` links](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#manifests-and-ant-links) and [creating manifests and share links](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#creating-manifests-and-share-links). + +## Choosing how to retrieve a file You do not have to load every file into memory before using it. The SDK provides range reads and streams, so an application can request parts of a file as it needs them. -For seekable audio and video, the SDK provides a service worker: a browser-managed script that connects a media element's requests to the SDK's file reader. This setup requires HTTPS or localhost and the application's page to remain open. Applications with an existing service worker must integrate the media handling with it. +Choose the approach that matches the file and what your application needs to do with it: -Browser SDK 0.1.4 accepts uploads from 3 bytes up to 1 GB (1,000,000,000 bytes). +- **Download it in one operation.** `download()` returns the complete file as bytes and a browser `Blob`; `downloadAndSave()` also opens a save flow for the user. Both hold the complete file in memory. They refuse files over 1 GB by default, but you can change that memory budget. The returned `Blob`, resolved DataMap, caches and network buffers need additional memory beyond the byte-array budget. +- **Save it as it arrives.** `streamAndSave()` writes directly to a destination selected by your application or the user. It does not create a complete in-memory copy, and streaming has no fixed file-size cap. The device still needs enough storage for the file. +- **Read only the parts you need.** `openFile()` provides range reads and a stream for applications such as document readers, archives and data viewers. Your application decides where those pieces go and how to present them. -`download()` and `downloadAndSave()` buffer the whole file and use a default 1 GB `maxMemoryBytes` budget. You can pass a different budget, but the returned bytes and `Blob`, the resolved DataMap, caches and transport buffers need additional memory. +For seekable audio and video, the SDK provides a service worker: a browser-managed script that connects a media element's requests to the SDK's file reader. Deploy the service worker shipped with the same SDK version as your application. This setup requires HTTPS or localhost and the application's page to remain open. Applications with an existing service worker must integrate the media handling with it. -Streaming downloads and media do not have a fixed 1 GB cap. For bounded-memory downloads, use `client.streamAndSave(source, options)` or `client.openFile(file, options)` followed by `reader.pipeTo(destination, options)`. Use `reader.stream(options)` to consume a bounded stream in your application. Browser memory, storage and safe-integer limits remain practical constraints. Uploads from byte arrays may run out of memory before reaching the upload cap. The [browser SDK API documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#stream-directly-to-disk) covers streaming saves, range reads, media setup and file-size limits. +See the released SDK documentation for [whole-file downloads and saves](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#download-and-save), [streaming saves](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#streaming-saves), [range reads](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#random-access-reads) and [seekable media](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#seekable-media). ## Uploading from a browser The SDK also accepts browser files and byte arrays for public or private uploads. Your application supplies a payment provider to authorize storage payments; supported integrations include Ethers and Wagmi/Viem. A read-only application does not need these wallet integrations. -File uploads have additional browser requirements, including a worker for file processing and IndexedDB for temporary storage. Use the [browser SDK's upload documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#upload-files) when adding uploads and payment handling. +Uploads can be from 3 bytes up to 1 GB (1,000,000,000 bytes). Uploading a browser `File` or `Blob` processes it in a background worker and stages encrypted records in browser storage. Uploading a byte array holds the complete input in memory, so it may fail before reaching the upload limit. + +If an upload stops after the wallet may have paid, do not immediately start the upload again. Keep the page open and let the user resume or discard the failed attempt. The SDK retains the prepared input and payment history, reuses confirmed payment where it can, and stops for explicit authorization if more payment is needed. This recovery state does not survive a page reload. + +Use the released SDK's [upload documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#upload-files) and [upload recovery guidance](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#resume-a-failed-upload) when adding uploads and payment handling. + +## Keeping a reference up to date + +A pointer gives your application one stable address that can refer to changing content. This is useful for a profile, catalogue or other record whose readers need a lasting address while its owner publishes updates. + +The owner's secret controls that address, so your application must protect it. Creating or updating the pointer also costs a storage payment. Before the wallet continues, save the SDK's recovery checkpoint somewhere that survives a page reload. If the page closes after payment starts, that checkpoint lets the application finish the original paid update rather than paying again. Do not start a new update while the original payment is unresolved. + +Pointer ownership can also be transferred permanently. A successful write does not by itself prove that enough responsible nodes agree on the result. Applications that depend on that agreement must check the pointer's finality status. See the released SDK's [pointer and recovery documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#pointers-and-payment-recovery) before adding pointer writes. ## Network compatibility diff --git a/docs/sdk/how-to-guides/README.md b/docs/sdk/how-to-guides/README.md index 38adbc7..3b831fc 100644 --- a/docs/sdk/how-to-guides/README.md +++ b/docs/sdk/how-to-guides/README.md @@ -23,6 +23,7 @@ If you're still deciding how your application should connect, [Build with the SD ## In a browser - [Retrieve Data in the Browser](retrieve-data-in-browser.md): display a public image using the experimental browser SDK, without a wallet or local daemon. +- [Browser SDK](../build-in-browser.md): understand direct browser connections, share links and manifests, large-file retrieval, uploads and updatable pointers before choosing how to build those features. ## Through a local daemon diff --git a/docs/sdk/how-to-guides/retrieve-data-in-browser.md b/docs/sdk/how-to-guides/retrieve-data-in-browser.md index d1e6f5d..8388be0 100644 --- a/docs/sdk/how-to-guides/retrieve-data-in-browser.md +++ b/docs/sdk/how-to-guides/retrieve-data-in-browser.md @@ -174,7 +174,7 @@ The browser retrieves the data directly from Autonomi nodes. Vite serves your ap ## Next steps -- [Browser SDK documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4): upload, wallet, private-file and media APIs for the same experimental release. -- [Browser SDK](../build-in-browser.md): capabilities, application ideas and how browser connections work. +- [Browser SDK](../build-in-browser.md): understand browser connections, share links and manifests, large-file retrieval, uploads and updatable pointers. +- [Released Browser SDK documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4): complete examples and API details for the same experimental release. - [Build with the SDKs](../install.md): compare application connection options. - [Keys, Addresses, and DataMaps](../../core-concepts/keys-addresses-and-datamaps.md): understand public addresses and private-file access. diff --git a/docs/sdk/install.md b/docs/sdk/install.md index eb456f3..87a9947 100644 --- a/docs/sdk/install.md +++ b/docs/sdk/install.md @@ -25,7 +25,7 @@ Choose based on where your application runs and whether you want it to manage it | Connection | Choose it when | Installation and usage | |------------|----------------|------------------------| | Direct from a native application | You are building in Python, Node.js or .NET and want no separate network service to start | [Native SDKs](native/README.md) | -| Direct from the browser using WebAssembly (WASM) | You are building a web application that accesses data through the experimental browser SDK | [Browser SDK](build-in-browser.md) | +| Direct from the browser using WebAssembly (WASM) | You are building a web application that reads, streams, shares or stores data through the experimental browser SDK | [Browser SDK](build-in-browser.md) | | Through a local daemon | Several applications should share one service, or you prefer a local REST or gRPC API | [Local-Daemon Clients](use-antd.md) | The packages and APIs differ. Use the package for the connection arrangement you choose; a Python or Node.js library for one is not interchangeable with the other. @@ -44,7 +44,7 @@ Each language reference covers installation and its API. Python and Node.js also ## Browser applications -Use `@withautonomi/ant-browser-sdk` to connect directly from JavaScript or TypeScript running in a browser. WebAssembly runs the network client; WebRTC carries its connections to nodes. Visitors do not need a local daemon. +Use `@withautonomi/ant-browser-sdk` to connect directly from JavaScript or TypeScript running in a browser. WebAssembly runs the network client; WebRTC carries its connections to nodes. Visitors do not need a local daemon. Applications can work with individual files, portable collections and updatable pointers, and can stream large files without holding the complete file in memory. The browser SDK is experimental. Read the [Browser SDK overview](build-in-browser.md) for capabilities and application ideas, then follow [Retrieve Data in the Browser](how-to-guides/retrieve-data-in-browser.md) for a complete public-image example. @@ -72,7 +72,7 @@ Uploads require a wallet and storage payment. Choose public storage when you wan ## Related pages -- [Browser SDK](build-in-browser.md): build web applications with direct access to stored data. +- [Browser SDK](build-in-browser.md): read, share, stream and store data directly from a web application. - [SDK How-To Guides](how-to-guides/README.md) - [SDK Reference](reference/README.md) - [Use the CLI](../cli/use-the-cli.md) for command-line access diff --git a/docs/sdk/reference/README.md b/docs/sdk/reference/README.md index 70ea3f9..a6e24d1 100644 --- a/docs/sdk/reference/README.md +++ b/docs/sdk/reference/README.md @@ -18,7 +18,7 @@ Find the methods, parameters, return values, and errors for the library or API you are using. -For native libraries that connect directly to the Autonomi Network, use the [native SDK reference](native-sdks.md). For web applications, [Browser SDK](../build-in-browser.md) introduces the separate experimental package and links to its API documentation. For client libraries that send requests to a local daemon, a separate background service called [antd](../use-antd.md), use [Language Bindings](language-bindings/README.md). The REST and gRPC references cover that service's APIs. +For native libraries that connect directly to the Autonomi Network, use the [native SDK reference](native-sdks.md). For web applications, [Browser SDK](../build-in-browser.md) introduces the separate experimental package, explains files, manifests, links, streams and pointers, and links to the released API documentation. For client libraries that send requests to a local daemon, a separate background service called [antd](../use-antd.md), use [Language Bindings](language-bindings/README.md). The REST and gRPC references cover that service's APIs. The APIs are not interchangeable. Each reference describes its own constructors, supported operations, and limits. @@ -33,7 +33,7 @@ The APIs are not interchangeable. Each reference describes its own constructors, - [Node.js SDK](../native/nodejs.md): installation, a public-read example, types, and errors. - [.NET SDK](../native/csharp.md): installation, methods, types, and errors. - [Native SDK Reference](native-sdks.md): data, file, wallet, and external-signer APIs. -- [Browser SDK](../build-in-browser.md): the experimental browser package and links to its API documentation. +- [Browser SDK](../build-in-browser.md): the experimental browser package, its major developer tasks and links to its released API documentation. ## Local service and clients diff --git a/docs/sdk/reference/overview.md b/docs/sdk/reference/overview.md index e174cfc..c799bba 100644 --- a/docs/sdk/reference/overview.md +++ b/docs/sdk/reference/overview.md @@ -46,7 +46,7 @@ The compiled library is loaded by your application, not run as a separate comman ## Connecting directly from a browser -The browser SDK includes a network client compiled to WebAssembly (WASM). Your web application calls it from JavaScript or TypeScript, and WebRTC connects it directly to nodes. There is no local daemon to start. See [Browser SDK](../build-in-browser.md) for capabilities and [Retrieve Data in the Browser](../how-to-guides/retrieve-data-in-browser.md) for a complete example. +The browser SDK includes a network client compiled to WebAssembly (WASM). Your web application calls it from JavaScript or TypeScript, and WebRTC connects it directly to nodes. There is no local daemon to start. It can retrieve and store files, open or create shareable manifests and `ant://` links, stream large files and use pointers for content that changes behind a stable address. See [Browser SDK](../build-in-browser.md) for these capabilities and [Retrieve Data in the Browser](../how-to-guides/retrieve-data-in-browser.md) for a complete public-read example. ## Connecting through a local daemon diff --git a/planning/release-baseline-maintenance.md b/planning/release-baseline-maintenance.md index 3d760e8..70c9cb1 100644 --- a/planning/release-baseline-maintenance.md +++ b/planning/release-baseline-maintenance.md @@ -14,7 +14,7 @@ These files move together. A manifest edit alone does not promote documentation. ## Promotion workflow -1. **Source audit:** confirm that the release is publicly obtainable. Record the exact tag and peeled commit, distribution metadata, integrity values, shipped dependencies, support status and known limits required by the profile. +1. **Source audit:** start from the exact release recorded on the base branch and compare it with the candidate release. Confirm that the candidate is publicly obtainable, then review the full release notes, public exports and relevant changed source across that range. Record the exact tag and peeled commit, distribution metadata, integrity values, shipped dependencies, support status and known limits required by the profile. Account for each material developer capability as documented, already covered or deliberately deferred. 2. **Atomic promotion:** update the one manifest source or baseline, every scoped page block, and one new dated promotion record in the same branch. Update rendered documentation in that branch when behavior changed. 3. **Validation:** run the commands below. Do not bypass a failing guard or move a pin to a branch such as `main`. 4. **Review:** have a maintainer review the evidence and complete diff. Human review owns pull request scope and must reject unrelated changes that the release does not justify. Merge is the promotion action; validation alone does not approve it. @@ -45,7 +45,7 @@ Run these commands after committing the candidate promotion so both refs describ The Browser SDK is the manual example. Its existing `scope.pages` contains six mapped pages, and `sources.ant-browser-sdk` records the release, npm package and shipped WebAssembly (WASM) evidence. The validator requires that source record, all six mapped blocks, one dated promotion record and the tag-to-commit relationships to advance atomically. It also keeps non-Browser verification blocks unchanged as migration debt. The broader prose branch envelope can include rendered changes to other documentation, so human review must reject anything not justified by the release. -This manual route validates recorded structure and relationships; it does not independently fetch the public npm integrity or shipped WASM evidence. Before approval, the human source audit and review must confirm those values and the promotion-record narrative against public provider truth. The package remains `experimental`; a version change cannot alter that classification. +This manual route validates recorded structure and relationships; it does not independently fetch the public npm integrity or shipped WASM evidence, or prove that the rendered documentation covers every changed capability. Before approval, the human source audit and review must confirm those values, compare the complete deployed-to-candidate source range and check the promotion-record narrative against public provider truth. The package remains `experimental`; a version change cannot alter that classification. The CLI is the automated-adapter example. `scripts/sweep_poll.py` uses the `ant-cli` release-discovery configuration to prepare evidence for a version-1 `release_baselines.entries.ant-cli/stable` record. That larger record captures GitHub assets, npm platform packages, installers and shipped `ant-core` evidence. Discovery prepares a candidate; it does not approve or merge a promotion. diff --git a/planning/sweeps/2026-10-27.md b/planning/sweeps/2026-10-27.md index 81e5c9e..ce2ff76 100644 --- a/planning/sweeps/2026-10-27.md +++ b/planning/sweeps/2026-10-27.md @@ -8,11 +8,25 @@ Browser SDK 0.1.4 was released after the unpushed 0.1.3 promotion candidate was - The exact [npm metadata](https://registry.npmjs.org/@withautonomi/ant-browser-sdk/0.1.4) identifies `@withautonomi/ant-browser-sdk` version `0.1.4`, integrity `sha512-MD/p2TctBvB1KkE6KCrxiE5m0S0il1gmGIQlRpeSEhoItkJfxO/72uxAkxUz77gCpxOwkegjb0ZbPIJgGaq66w==` and SHA-1 shasum `279652b24675a29feeefb8df0931cd6fdf0b1f1d`. Freshly downloading the npm tarball reproduced both values. - The npm tarball and the 2,542,615-byte GitHub release asset were byte-identical. Both had SHA-256 `15d9e015929c3e59eb29bd981cb1fb2429f960be76e2c2ab169c506457c0b1fb`, matching the GitHub asset digest `sha256:15d9e015929c3e59eb29bd981cb1fb2429f960be76e2c2ab169c506457c0b1fb`. - The release's immutable [`src/wasm/source.json`](https://github.com/WithAutonomi/ant-browser-sdk/blob/5199100c15527bf657ae4a795c2bdf5d086981f7/src/wasm/source.json) and the source record shipped in the package both identify ant-client commit `7a432e7c4442b4628872bd5cf6a3e896e7fc10ad` and WASM SHA-256 `7873c65138aa499c48a8c34d9dbaa2fdd82509ca6e981afe9a4f77331b9e4cf4`. Hashing the shipped `dist/wasm/ant_core_bg.wasm` reproduced that value. -- The released source and packaged README still call the SDK and direct-browser protocol experimental. The 0.1.3-to-0.1.4 source comparison leaves the README and public TypeScript API and limit sources byte-identical. The 0.1.4 release changes the bundled ant-client WASM for faster browser downloads; it does not change the documented SDK API or limits. +- The released source and packaged README still call the SDK and direct-browser protocol experimental. The final documentation baseline moves directly from 0.1.2 to 0.1.4, so the source audit uses the full [`v0.1.2...v0.1.4` comparison](https://github.com/WithAutonomi/ant-browser-sdk/compare/v0.1.2...v0.1.4), not the unpushed 0.1.3 candidate as its starting point. Version 0.1.3 adds the public capabilities described below. Version 0.1.4 changes the bundled ant-client WASM for faster browser downloads and leaves the 0.1.3 public TypeScript API and limits unchanged. + +## Capability audit from the published baseline + +The 0.1.2-to-0.1.4 review found these material developer-facing changes: + +- Applications can open `.ant` manifests, `ant://manifest/...` links and `ant://
` file links. They can also create canonical `.ant` files, manifest links and public-file links from existing upload results without uploading or publishing another object. +- Manifest entries can point to public files or embed the DataMap that grants access to a private file. Whole-file downloads check an optional manifest SHA-256 claim; streaming and media reads do not perform that whole-file check. +- Owner-signed pointers provide a stable address for changing content. Paid pointer writes require application-owned durable checkpoints, and recovery observes the original transaction or reuses its proof rather than submitting another payment. +- `streamAndSave()` and file-reader piping can write to disk or another browser destination without constructing a complete in-memory `Blob`. Streaming and media no longer have a fixed 1 GB cap; whole-file downloads keep a configurable 1 GB byte-array budget by default, and uploads remain capped at 1 GB. +- Seekable media uses the service worker shipped with the matching SDK. Applications must deploy that worker with the SDK to use the released media behavior and limits. +- Upload recovery retains prepared input and payment evidence for explicit resume or discard. Payment providers can wait until broadcast evidence is journaled, reducing the gap between submitting a transaction and retaining recovery evidence. +- The 0.1.4 WASM refresh improves Chromium download and distant-seek performance in the release's recorded comparison. It does not add another public TypeScript capability. + +The overview now explains these capabilities as developer choices and outcomes rather than presenting an API inventory. Detailed signatures, payment rules, recovery states and complete examples remain in the released SDK documentation. Dedicated task guides for manifests, streaming saves, uploads and pointers remain future documentation work; this promotion does not claim those flows were exercised in this repository. ## Documentation changes -All six mapped pages advance only their Browser SDK verification block to `v0.1.4`, exact release commit `5199100c15527bf657ae4a795c2bdf5d086981f7` and `2026-10-27`: +All six mapped pages advance their Browser SDK verification block to `v0.1.4`, exact release commit `5199100c15527bf657ae4a795c2bdf5d086981f7` and `2026-10-27`: - `docs/sdk/build-in-browser.md` - `docs/sdk/how-to-guides/retrieve-data-in-browser.md` @@ -21,19 +35,19 @@ All six mapped pages advance only their Browser SDK verification block to `v0.1. - `docs/sdk/reference/overview.md` - `docs/sdk/reference/README.md` -Rendered changes remain limited to the overview and tutorial. The overview advances its version and source links to 0.1.4 while retaining the released API and limit prose: the 1 GB upload cap, the default 1 GB whole-file download memory budget and the bounded-memory streaming APIs. The tutorial pins package 0.1.4 and links to that release; its HTML and JavaScript are unchanged. Final mechanical review found that the tutorial's pre-existing Vite 8.2.0 pin was covered by a high-severity command-injection advisory, so the tutorial now pins the patched non-major Vite 8.3.5 release. +Rendered changes cover the Browser SDK overview and concise discovery text on the five other mapped pages. The overview explains manifests and share links, private access carried by embedded DataMaps, large-file retrieval choices, upload recovery, and pointers in task-oriented language. It also records the 1 GB upload cap, the default 1 GB whole-file byte-array budget and the absence of a fixed streaming or media cap. The tutorial pins package 0.1.4 and links to that release; its HTML and JavaScript are unchanged. Final mechanical review found that the tutorial's pre-existing Vite 8.2.0 pin was covered by a high-severity command-injection advisory, so the tutorial now pins the patched non-major Vite 8.3.5 release. ## Fresh 0.1.4 tutorial exercise -The corrected tutorial was run as a new disposable project at `/var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode/browser-sdk-014-vite-835-runtime.20261027` on macOS ARM64 with Node.js `22.22.3`, npm `10.9.8`, exact `@withautonomi/ant-browser-sdk@0.1.4`, exact Vite `8.3.5`, exact `@playwright/test@1.64.1` and a freshly downloaded Playwright Chromium `156.0.8078.4`. The project files `index.html` and `main.js` were copied from the tutorial's complete code blocks. +The corrected tutorial was run in a new disposable directory on macOS ARM64 with Node.js `22.22.3`, npm `10.9.8`, exact `@withautonomi/ant-browser-sdk@0.1.4`, exact Vite `8.3.5`, exact `@playwright/test@1.64.1` and a freshly downloaded Playwright Chromium `156.0.8078.4`. The project files `index.html` and `main.js` were copied from the tutorial's complete code blocks. The npm metadata for Vite 8.3.5 records integrity `sha512-z1YpjieJ9g0ebTmQpLBv/oq9E3F9EIlOe+7LahW8SrE3LTiG3udBRUXQOlYXP9b+IC2q2phHeVxj9xGlw34OEQ==`, SHA-1 shasum `9614f66026cb92fe486cb9d3c90780b2a69fc85d` and Node.js compatibility `^20.19.0 || >=22.12.0`; the exercised Node.js 22.22.3 satisfies that range. A fresh `npm audit --audit-level=low` of the exact tutorial install reported zero known vulnerabilities. Rechecking the prior exact Vite 8.2.0 project reproduced one high-severity direct Vite finding and identified 8.3.5 as the available non-major fix. The disposable project and isolated browser were created with: ```bash -mkdir /var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode/browser-sdk-014-vite-835-runtime.20261027 -cd /var/folders/f_/j942sskj6nx67b6gk3rqgsqm0000gn/T/opencode/browser-sdk-014-vite-835-runtime.20261027 +WORKDIR="$(mktemp -d "${TMPDIR:-/tmp}/browser-sdk-014.XXXXXX")" +cd "$WORKDIR" npm init -y npm install --save-exact @withautonomi/ant-browser-sdk@0.1.4 npm install --save-dev --save-exact vite@8.3.5 @@ -159,7 +173,7 @@ Both successful reads returned exactly 138931 bytes, decoded a 782 by 1600 image No wallet, payment, upload, personal browser profile, global package installation, daemon, source patch or production write was used. Uploads, paid flows, streaming of a large file, media playback, Safari, Firefox and other browser or operating-system combinations were not exercised. The successful public read used the package's bundled mainnet defaults and does not establish a browser-wide support claim. -The source audit checked the released API names and call forms, but the runtime exercise covers only the existing public-read tutorial and focused initialization retry. The promotion mechanism validates structure, scope, tag reachability and recorded relationships; maintainer review must still compare the npm integrity, shipped WASM evidence, rendered wording and manually gathered results with public provider truth. No CI or external review result is claimed. +The source audit checked the released API names and call forms, but the runtime exercise covers only the existing public-read tutorial and focused initialization retry. The promotion mechanism validates structure, scope, tag reachability and recorded relationships; maintainer review must still compare the npm integrity, shipped WASM evidence, rendered wording and manually gathered results with public provider truth. Runtime evidence for one public read does not establish the unexercised capabilities listed above. ## Repository checks From 5b46b0936da8045b79f8af713b66232d5ee59555 Mon Sep 17 00:00:00 2001 From: Jim Collinson <13061030+JimCollinson@users.noreply.github.com> Date: Wed, 28 Oct 2026 09:45:42 +0000 Subject: [PATCH 5/8] fix(releases-browser): resolve capability review findings --- docs/sdk/build-in-browser.md | 2 +- planning/release-baseline-maintenance.md | 4 ++-- planning/sweeps/2026-10-27.md | 4 +++- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/sdk/build-in-browser.md b/docs/sdk/build-in-browser.md index ba2bf1b..c048f04 100644 --- a/docs/sdk/build-in-browser.md +++ b/docs/sdk/build-in-browser.md @@ -100,7 +100,7 @@ Use the released SDK's [upload documentation](https://github.com/WithAutonomi/an A pointer gives your application one stable address that can refer to changing content. This is useful for a profile, catalogue or other record whose readers need a lasting address while its owner publishes updates. -The owner's secret controls that address, so your application must protect it. Creating or updating the pointer also costs a storage payment. Before the wallet continues, save the SDK's recovery checkpoint somewhere that survives a page reload. If the page closes after payment starts, that checkpoint lets the application finish the original paid update rather than paying again. Do not start a new update while the original payment is unresolved. +The owner's secret controls that address, so your application must protect it. Creating or updating the pointer also costs a storage payment. Before the wallet continues, save the SDK's recovery checkpoint somewhere that survives a page reload. When that checkpoint captures the payment evidence, it can let the application finish the original paid update without paying again. It cannot recover evidence that was never saved: if the payment remains unresolved, reconcile it with the original wallet and do not start a new update. Pointer ownership can also be transferred permanently. A successful write does not by itself prove that enough responsible nodes agree on the result. Applications that depend on that agreement must check the pointer's finality status. See the released SDK's [pointer and recovery documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#pointers-and-payment-recovery) before adding pointer writes. diff --git a/planning/release-baseline-maintenance.md b/planning/release-baseline-maintenance.md index 70c9cb1..3d760e8 100644 --- a/planning/release-baseline-maintenance.md +++ b/planning/release-baseline-maintenance.md @@ -14,7 +14,7 @@ These files move together. A manifest edit alone does not promote documentation. ## Promotion workflow -1. **Source audit:** start from the exact release recorded on the base branch and compare it with the candidate release. Confirm that the candidate is publicly obtainable, then review the full release notes, public exports and relevant changed source across that range. Record the exact tag and peeled commit, distribution metadata, integrity values, shipped dependencies, support status and known limits required by the profile. Account for each material developer capability as documented, already covered or deliberately deferred. +1. **Source audit:** confirm that the release is publicly obtainable. Record the exact tag and peeled commit, distribution metadata, integrity values, shipped dependencies, support status and known limits required by the profile. 2. **Atomic promotion:** update the one manifest source or baseline, every scoped page block, and one new dated promotion record in the same branch. Update rendered documentation in that branch when behavior changed. 3. **Validation:** run the commands below. Do not bypass a failing guard or move a pin to a branch such as `main`. 4. **Review:** have a maintainer review the evidence and complete diff. Human review owns pull request scope and must reject unrelated changes that the release does not justify. Merge is the promotion action; validation alone does not approve it. @@ -45,7 +45,7 @@ Run these commands after committing the candidate promotion so both refs describ The Browser SDK is the manual example. Its existing `scope.pages` contains six mapped pages, and `sources.ant-browser-sdk` records the release, npm package and shipped WebAssembly (WASM) evidence. The validator requires that source record, all six mapped blocks, one dated promotion record and the tag-to-commit relationships to advance atomically. It also keeps non-Browser verification blocks unchanged as migration debt. The broader prose branch envelope can include rendered changes to other documentation, so human review must reject anything not justified by the release. -This manual route validates recorded structure and relationships; it does not independently fetch the public npm integrity or shipped WASM evidence, or prove that the rendered documentation covers every changed capability. Before approval, the human source audit and review must confirm those values, compare the complete deployed-to-candidate source range and check the promotion-record narrative against public provider truth. The package remains `experimental`; a version change cannot alter that classification. +This manual route validates recorded structure and relationships; it does not independently fetch the public npm integrity or shipped WASM evidence. Before approval, the human source audit and review must confirm those values and the promotion-record narrative against public provider truth. The package remains `experimental`; a version change cannot alter that classification. The CLI is the automated-adapter example. `scripts/sweep_poll.py` uses the `ant-cli` release-discovery configuration to prepare evidence for a version-1 `release_baselines.entries.ant-cli/stable` record. That larger record captures GitHub assets, npm platform packages, installers and shipped `ant-core` evidence. Discovery prepares a candidate; it does not approve or merge a promotion. diff --git a/planning/sweeps/2026-10-27.md b/planning/sweeps/2026-10-27.md index ce2ff76..41b80a4 100644 --- a/planning/sweeps/2026-10-27.md +++ b/planning/sweeps/2026-10-27.md @@ -22,6 +22,8 @@ The 0.1.2-to-0.1.4 review found these material developer-facing changes: - Upload recovery retains prepared input and payment evidence for explicit resume or discard. Payment providers can wait until broadcast evidence is journaled, reducing the gap between submitting a transaction and retaining recovery evidence. - The 0.1.4 WASM refresh improves Chromium download and distant-seek performance in the release's recorded comparison. It does not add another public TypeScript capability. +The source review also accounted for lower-level additions that do not need overview prose. Optional BitTorrent hashes are exposed as manifest metadata but the SDK does not act on them. Media priming, service-worker keep-alive, response headers and timeout behavior remain operational detail in the released media documentation. The 4 MiB range limit, 32 MiB streaming pipeline and JavaScript integer ceiling remain reference limits rather than choices most readers need when selecting a retrieval approach. The 0.1.4 tokio security update changes no Browser SDK call or documented workflow. + The overview now explains these capabilities as developer choices and outcomes rather than presenting an API inventory. Detailed signatures, payment rules, recovery states and complete examples remain in the released SDK documentation. Dedicated task guides for manifests, streaming saves, uploads and pointers remain future documentation work; this promotion does not claim those flows were exercised in this repository. ## Documentation changes @@ -177,6 +179,6 @@ The source audit checked the released API names and call forms, but the runtime ## Repository checks -After the Vite correction, the static release-baseline validator passed; the focused documentation-guard suite passed 41 tests; the focused release-following suite passed 35 tests; and the full repository suite passed 107 tests. ADR governance passed with no changed ADRs. Focused checks confirmed that the tutorial HTML, JavaScript and preserved Playwright procedure are byte-identical to the exercised project; the exact package pins are present; all six Browser SDK blocks match 0.1.4; every unrelated verification block is byte-identical to `origin/main`; all 89 relative links resolve; and all new external release/source links return HTTP 200. The working-tree whitespace check passed. This resolves the final mechanical review blocker without changing the Browser SDK source or release evidence. +After the Vite correction, the static release-baseline validator passed; the focused documentation-guard suite passed 41 tests; the focused release-following suite passed 35 tests; and the full repository suite passed 107 tests. ADR governance passed with no changed ADRs. Focused checks confirmed that the tutorial HTML, JavaScript and preserved Playwright procedure are byte-identical to the exercised project; the exact package pins are present; all six Browser SDK blocks match 0.1.4; every unrelated verification block is byte-identical to `origin/main`; all 90 relative links resolve; and all new external release/source links return HTTP 200. The working-tree whitespace check passed. This resolves the final mechanical review blocker without changing the Browser SDK source or release evidence. The exact commit-range promotion validator and range whitespace check run from `origin/main` to `HEAD` after committing; their results are retained in the execution handoff rather than back-written into this record. From 9e583fc5517f67939613a53408afde77afdf02ea Mon Sep 17 00:00:00 2001 From: Jim Collinson <13061030+JimCollinson@users.noreply.github.com> Date: Wed, 28 Oct 2026 10:37:49 +0000 Subject: [PATCH 6/8] fix(releases-browser): clarify manifests and pointer recovery --- docs/sdk/build-in-browser.md | 32 +++++++++++++++----------------- docs/sdk/how-to-guides/README.md | 2 +- docs/sdk/install.md | 2 +- planning/sweeps/2026-10-27.md | 2 +- 4 files changed, 18 insertions(+), 20 deletions(-) diff --git a/docs/sdk/build-in-browser.md b/docs/sdk/build-in-browser.md index c048f04..3f4c9da 100644 --- a/docs/sdk/build-in-browser.md +++ b/docs/sdk/build-in-browser.md @@ -26,7 +26,7 @@ The SDK gives your web application access to stored content. You choose how to p | Image gallery | Retrieve images and display them with ordinary browser elements | | Audio or video player | Read media progressively and support seeking without downloading the entire file first | | Data viewer | Retrieve a stored dataset or JSON file and present it as tables, charts or another application view | -| File-sharing application | Open or create links and portable collections, then retrieve public or shared private files | +| File-sharing application | Upload files, then share them as links or manifests that others can open | | Updatable catalogue or profile | Keep one lasting address while the content behind it changes | These are application patterns, not ready-made interfaces included in the SDK. For example, a book reader still needs code that understands the book's format and displays its pages. The SDK supplies access to the file's data. @@ -62,20 +62,8 @@ Private files require their DataMap, the information needed to locate and decryp For a complete working example, follow [Retrieve Data in the Browser](how-to-guides/retrieve-data-in-browser.md). It downloads a public image and displays it in a small web page. -## Sharing files and collections - -An `ant://` link can identify one public file or describe a collection of files. The collection form carries a manifest: a portable list of file names and the information needed to retrieve each one. Your application can also open the same kind of collection from a `.ant` file. - -A manifest does not upload or publish its files. Your application can create one from files it has already uploaded, then offer the link or `.ant` file to another person. The recipient can open the manifest and choose which entries to retrieve. - -Public entries contain an address. An embedded entry contains the DataMap needed to read a private file. Anyone who receives a manifest with an embedded entry receives access to that private file, so protect that manifest as you would protect the DataMap itself. - -See the released SDK documentation for [opening manifests and `ant://` links](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#manifests-and-ant-links) and [creating manifests and share links](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#creating-manifests-and-share-links). - ## Choosing how to retrieve a file -You do not have to load every file into memory before using it. The SDK provides range reads and streams, so an application can request parts of a file as it needs them. - Choose the approach that matches the file and what your application needs to do with it: - **Download it in one operation.** `download()` returns the complete file as bytes and a browser `Blob`; `downloadAndSave()` also opens a save flow for the user. Both hold the complete file in memory. They refuse files over 1 GB by default, but you can change that memory budget. The returned `Blob`, resolved DataMap, caches and network buffers need additional memory beyond the byte-array budget. @@ -92,17 +80,27 @@ The SDK also accepts browser files and byte arrays for public or private uploads Uploads can be from 3 bytes up to 1 GB (1,000,000,000 bytes). Uploading a browser `File` or `Blob` processes it in a background worker and stages encrypted records in browser storage. Uploading a byte array holds the complete input in memory, so it may fail before reaching the upload limit. -If an upload stops after the wallet may have paid, do not immediately start the upload again. Keep the page open and let the user resume or discard the failed attempt. The SDK retains the prepared input and payment history, reuses confirmed payment where it can, and stops for explicit authorization if more payment is needed. This recovery state does not survive a page reload. +If an upload fails partway through, the wallet may already have paid, so starting again could pay twice. Keep the page open and let the user resume or discard the failed attempt. The SDK retains the prepared input and payment history, reuses confirmed payment where it can, and stops for explicit authorization if more payment is needed. This recovery state does not survive a page reload. Use the released SDK's [upload documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#upload-files) and [upload recovery guidance](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#resume-a-failed-upload) when adding uploads and payment handling. +## Sharing files with manifests + +An `ant://` link can identify one public file or carry a manifest that describes multiple files. A `.ant` file carries the same kind of manifest: a portable list of file names and the information needed to retrieve each one. + +Creating a manifest does not upload anything. The manifest is not stored on the Autonomi Network either: the `ant://` link or `.ant` file is the manifest, and sharing it gives another person the information needed to retrieve its entries. + +Public entries contain an address. An embedded entry contains the DataMap needed to read a private file. Anyone who receives a manifest with an embedded entry receives access to that private file, so protect that manifest as you would protect the DataMap itself. + +See the released SDK documentation for [opening manifests and `ant://` links](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#manifests-and-ant-links) and [creating manifests and share links](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#creating-manifests-and-share-links). + ## Keeping a reference up to date -A pointer gives your application one stable address that can refer to changing content. This is useful for a profile, catalogue or other record whose readers need a lasting address while its owner publishes updates. +A pointer gives your application one lasting address whose content can change. This is useful for a profile, catalogue or other record people return to. -The owner's secret controls that address, so your application must protect it. Creating or updating the pointer also costs a storage payment. Before the wallet continues, save the SDK's recovery checkpoint somewhere that survives a page reload. When that checkpoint captures the payment evidence, it can let the application finish the original paid update without paying again. It cannot recover evidence that was never saved: if the payment remains unresolved, reconcile it with the original wallet and do not start a new update. +The pointer is controlled by its owner seed. Keep that seed safe and keep a durable copy: without it, you cannot update the pointer. Each create or update costs a storage payment. If a paid update is interrupted, the SDK can often finish it without charging again, but only if your application saved its recovery checkpoint first. Nodes accept the recovered payment proof only while its quotes are less than a day old; after that, the update needs a new payment. Pointer ownership can also be transferred permanently. -Pointer ownership can also be transferred permanently. A successful write does not by itself prove that enough responsible nodes agree on the result. Applications that depend on that agreement must check the pointer's finality status. See the released SDK's [pointer and recovery documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#pointers-and-payment-recovery) before adding pointer writes. +Read the released SDK's [pointer and recovery documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#pointers-and-payment-recovery) before adding pointer writes. It covers checkpoints, recovery and how to confirm that the Autonomi Network agrees on an update. ## Network compatibility diff --git a/docs/sdk/how-to-guides/README.md b/docs/sdk/how-to-guides/README.md index 3b831fc..6448bed 100644 --- a/docs/sdk/how-to-guides/README.md +++ b/docs/sdk/how-to-guides/README.md @@ -23,7 +23,6 @@ If you're still deciding how your application should connect, [Build with the SD ## In a browser - [Retrieve Data in the Browser](retrieve-data-in-browser.md): display a public image using the experimental browser SDK, without a wallet or local daemon. -- [Browser SDK](../build-in-browser.md): understand direct browser connections, share links and manifests, large-file retrieval, uploads and updatable pointers before choosing how to build those features. ## Through a local daemon @@ -38,5 +37,6 @@ These guides use [antd](../use-antd.md), the local background service. For a fir ## Next steps +- [Browser SDK](../build-in-browser.md): understand direct browser connections, share links and manifests, large-file retrieval, uploads and updatable pointers. - [Build with the SDKs](../install.md) - [SDK Reference](../reference/README.md) diff --git a/docs/sdk/install.md b/docs/sdk/install.md index 87a9947..6a3af61 100644 --- a/docs/sdk/install.md +++ b/docs/sdk/install.md @@ -44,7 +44,7 @@ Each language reference covers installation and its API. Python and Node.js also ## Browser applications -Use `@withautonomi/ant-browser-sdk` to connect directly from JavaScript or TypeScript running in a browser. WebAssembly runs the network client; WebRTC carries its connections to nodes. Visitors do not need a local daemon. Applications can work with individual files, portable collections and updatable pointers, and can stream large files without holding the complete file in memory. +Use `@withautonomi/ant-browser-sdk` to connect directly from JavaScript or TypeScript running in a browser. WebAssembly runs the network client; WebRTC carries its connections to nodes. Visitors do not need a local daemon. Applications can work with individual files, manifests and updatable pointers, and can stream large files without holding the complete file in memory. The browser SDK is experimental. Read the [Browser SDK overview](build-in-browser.md) for capabilities and application ideas, then follow [Retrieve Data in the Browser](how-to-guides/retrieve-data-in-browser.md) for a complete public-image example. diff --git a/planning/sweeps/2026-10-27.md b/planning/sweeps/2026-10-27.md index 41b80a4..0fb52f4 100644 --- a/planning/sweeps/2026-10-27.md +++ b/planning/sweeps/2026-10-27.md @@ -16,7 +16,7 @@ The 0.1.2-to-0.1.4 review found these material developer-facing changes: - Applications can open `.ant` manifests, `ant://manifest/...` links and `ant://
` file links. They can also create canonical `.ant` files, manifest links and public-file links from existing upload results without uploading or publishing another object. - Manifest entries can point to public files or embed the DataMap that grants access to a private file. Whole-file downloads check an optional manifest SHA-256 claim; streaming and media reads do not perform that whole-file check. -- Owner-signed pointers provide a stable address for changing content. Paid pointer writes require application-owned durable checkpoints, and recovery observes the original transaction or reuses its proof rather than submitting another payment. +- Owner-signed pointers provide a stable address for changing content. Paid pointer writes require application-owned durable checkpoints. Recovery can observe the original transaction or reuse its proof without another payment while its quotes are less than a day old; older proofs require a new paid write. - `streamAndSave()` and file-reader piping can write to disk or another browser destination without constructing a complete in-memory `Blob`. Streaming and media no longer have a fixed 1 GB cap; whole-file downloads keep a configurable 1 GB byte-array budget by default, and uploads remain capped at 1 GB. - Seekable media uses the service worker shipped with the matching SDK. Applications must deploy that worker with the SDK to use the released media behavior and limits. - Upload recovery retains prepared input and payment evidence for explicit resume or discard. Payment providers can wait until broadcast evidence is journaled, reducing the gap between submitting a transaction and retaining recovery evidence. From 0c1de4090d94b166bdc1570312221965a48152ce Mon Sep 17 00:00:00 2001 From: Jim Collinson <13061030+JimCollinson@users.noreply.github.com> Date: Wed, 28 Oct 2026 10:49:18 +0000 Subject: [PATCH 7/8] fix(releases-browser): preserve payment recovery safeguards --- docs/sdk/build-in-browser.md | 8 ++++---- planning/sweeps/2026-10-27.md | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/sdk/build-in-browser.md b/docs/sdk/build-in-browser.md index 3f4c9da..3a4aab6 100644 --- a/docs/sdk/build-in-browser.md +++ b/docs/sdk/build-in-browser.md @@ -80,7 +80,7 @@ The SDK also accepts browser files and byte arrays for public or private uploads Uploads can be from 3 bytes up to 1 GB (1,000,000,000 bytes). Uploading a browser `File` or `Blob` processes it in a background worker and stages encrypted records in browser storage. Uploading a byte array holds the complete input in memory, so it may fail before reaching the upload limit. -If an upload fails partway through, the wallet may already have paid, so starting again could pay twice. Keep the page open and let the user resume or discard the failed attempt. The SDK retains the prepared input and payment history, reuses confirmed payment where it can, and stops for explicit authorization if more payment is needed. This recovery state does not survive a page reload. +If an upload fails partway through, the wallet may already have paid, so starting again could pay twice. In the same page, the SDK retains the prepared input and payment history so the user can resume or discard the failed attempt. For recovery after a reload, retain or reselect the same input and resume with the durable checkpoint that the SDK saves in IndexedDB by default. Reconcile an unresolved payment with the original wallet; it never authorizes another payment. Use the released SDK's [upload documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#upload-files) and [upload recovery guidance](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#resume-a-failed-upload) when adding uploads and payment handling. @@ -88,7 +88,7 @@ Use the released SDK's [upload documentation](https://github.com/WithAutonomi/an An `ant://` link can identify one public file or carry a manifest that describes multiple files. A `.ant` file carries the same kind of manifest: a portable list of file names and the information needed to retrieve each one. -Creating a manifest does not upload anything. The manifest is not stored on the Autonomi Network either: the `ant://` link or `.ant` file is the manifest, and sharing it gives another person the information needed to retrieve its entries. +Creating a manifest does not upload anything. The manifest is not stored on the Autonomi Network either: the `ant://manifest/...` link or `.ant` file is the manifest, and sharing it gives another person the information needed to retrieve its entries. Public entries contain an address. An embedded entry contains the DataMap needed to read a private file. Anyone who receives a manifest with an embedded entry receives access to that private file, so protect that manifest as you would protect the DataMap itself. @@ -98,9 +98,9 @@ See the released SDK documentation for [opening manifests and `ant://` links](ht A pointer gives your application one lasting address whose content can change. This is useful for a profile, catalogue or other record people return to. -The pointer is controlled by its owner seed. Keep that seed safe and keep a durable copy: without it, you cannot update the pointer. Each create or update costs a storage payment. If a paid update is interrupted, the SDK can often finish it without charging again, but only if your application saved its recovery checkpoint first. Nodes accept the recovered payment proof only while its quotes are less than a day old; after that, the update needs a new payment. Pointer ownership can also be transferred permanently. +The pointer is controlled by its owner seed. Keep that seed safe and keep a durable copy: without it, you cannot update the pointer. Each create or update costs a storage payment. If a paid update is interrupted, the SDK can often finish it without charging again, but only if your application saved its recovery checkpoint first. If a crash hid the transaction identity, reconcile the original wallet and do not start a fresh write while payment is unresolved. Nodes accept a recovered payment proof only while its quotes are less than a day old; after that, the update needs a new payment. Pointer ownership can also be transferred permanently. -Read the released SDK's [pointer and recovery documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#pointers-and-payment-recovery) before adding pointer writes. It covers checkpoints, recovery and how to confirm that the Autonomi Network agrees on an update. +A successful write does not establish finality. Only a `final` result from the pointer finality check means the responsible node group agreed with every peer answering and no rival final state. Read the released SDK's [pointer and recovery documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#pointers-and-payment-recovery) before adding pointer writes. ## Network compatibility diff --git a/planning/sweeps/2026-10-27.md b/planning/sweeps/2026-10-27.md index 0fb52f4..c90b35c 100644 --- a/planning/sweeps/2026-10-27.md +++ b/planning/sweeps/2026-10-27.md @@ -16,10 +16,10 @@ The 0.1.2-to-0.1.4 review found these material developer-facing changes: - Applications can open `.ant` manifests, `ant://manifest/...` links and `ant://
` file links. They can also create canonical `.ant` files, manifest links and public-file links from existing upload results without uploading or publishing another object. - Manifest entries can point to public files or embed the DataMap that grants access to a private file. Whole-file downloads check an optional manifest SHA-256 claim; streaming and media reads do not perform that whole-file check. -- Owner-signed pointers provide a stable address for changing content. Paid pointer writes require application-owned durable checkpoints. Recovery can observe the original transaction or reuse its proof without another payment while its quotes are less than a day old; older proofs require a new paid write. +- Owner-signed pointers provide a stable address for changing content. Paid pointer writes require application-owned durable checkpoints. Recovery can observe the original transaction or reuse its proof without another payment while its quotes are less than a day old; older proofs require a new paid write. A hidden transaction must be reconciled with the original wallet, and an empty journal does not authorize another payment. - `streamAndSave()` and file-reader piping can write to disk or another browser destination without constructing a complete in-memory `Blob`. Streaming and media no longer have a fixed 1 GB cap; whole-file downloads keep a configurable 1 GB byte-array budget by default, and uploads remain capped at 1 GB. - Seekable media uses the service worker shipped with the matching SDK. Applications must deploy that worker with the SDK to use the released media behavior and limits. -- Upload recovery retains prepared input and payment evidence for explicit resume or discard. Payment providers can wait until broadcast evidence is journaled, reducing the gap between submitting a transaction and retaining recovery evidence. +- Upload recovery retains prepared input and payment evidence for explicit same-page resume or discard. Durable checkpoints persist in IndexedDB by default and can resume after a reload when the application retains or reselects the same input. Payment providers can wait until broadcast evidence is journaled, reducing the gap between submitting a transaction and retaining recovery evidence. - The 0.1.4 WASM refresh improves Chromium download and distant-seek performance in the release's recorded comparison. It does not add another public TypeScript capability. The source review also accounted for lower-level additions that do not need overview prose. Optional BitTorrent hashes are exposed as manifest metadata but the SDK does not act on them. Media priming, service-worker keep-alive, response headers and timeout behavior remain operational detail in the released media documentation. The 4 MiB range limit, 32 MiB streaming pipeline and JavaScript integer ceiling remain reference limits rather than choices most readers need when selecting a retrieval approach. The 0.1.4 tokio security update changes no Browser SDK call or documented workflow. From c8e7bcc1d2bca568d9a0d10eae7f1acbc7122d3a Mon Sep 17 00:00:00 2001 From: Jim Collinson <13061030+JimCollinson@users.noreply.github.com> Date: Wed, 28 Oct 2026 10:56:04 +0000 Subject: [PATCH 8/8] docs(releases-browser): clarify unresolved upload payments --- docs/sdk/build-in-browser.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/sdk/build-in-browser.md b/docs/sdk/build-in-browser.md index 3a4aab6..0342a22 100644 --- a/docs/sdk/build-in-browser.md +++ b/docs/sdk/build-in-browser.md @@ -80,7 +80,7 @@ The SDK also accepts browser files and byte arrays for public or private uploads Uploads can be from 3 bytes up to 1 GB (1,000,000,000 bytes). Uploading a browser `File` or `Blob` processes it in a background worker and stages encrypted records in browser storage. Uploading a byte array holds the complete input in memory, so it may fail before reaching the upload limit. -If an upload fails partway through, the wallet may already have paid, so starting again could pay twice. In the same page, the SDK retains the prepared input and payment history so the user can resume or discard the failed attempt. For recovery after a reload, retain or reselect the same input and resume with the durable checkpoint that the SDK saves in IndexedDB by default. Reconcile an unresolved payment with the original wallet; it never authorizes another payment. +If an upload fails partway through, the wallet may already have paid, so starting again could pay twice. In the same page, the SDK retains the prepared input and payment history so the user can resume or discard the failed attempt. For recovery after a reload, retain or reselect the same input and resume with the durable checkpoint that the SDK saves in IndexedDB by default. Check the original wallet to determine whether an unresolved payment went through. This check never authorizes another payment. Use the released SDK's [upload documentation](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#upload-files) and [upload recovery guidance](https://github.com/WithAutonomi/ant-browser-sdk/tree/v0.1.4#resume-a-failed-upload) when adding uploads and payment handling.