Stream: git-wasmtime

Topic: wasmtime / issue #10725 Guidance for a minimal, long‑term...

Wasmtime GitHub notifications bot (May 04 2025 at 13:00):

Kyoya67 opened issue #10725:

Thanks for filing a feature request! Please fill out the TODOs below.

Feature <!-- what I’m looking for -->

I would like official guidance (or a dedicated build profile) that lets me
run the same .wasm binary unchanged 10 + years from now with Wasmtime.

Concretely, I’d like to know:

1. Whether locking to WASI preview 1 and relying on the
   wasi-preview1-component-adapter will remain a supported path.

2. How to build a static, no_std, “smallest‑possible” Wasmtime that links
   only the required WASI snapshot.

3. The recommended migration path once **WASI preview 2 /
   Component Model** stabilises.

Benefit <!-- why this matters -->

Most generative‑art projects today rely on WebGL, Canvas, or other host‑specific
graphics APIs that could disappear or break in the future.
By rendering purely in software inside a .wasm module
and embedding a minimal, stable Wasmtime instance, the artwork can stay
re‑playable long after those APIs are gone.

Having an upstream‑blessed “long‑term reproducible” profile would

• guarantee that archived .wasm art (and other scientific artefacts) stays runnable,
• help embedders keep binary size and attack surface small,
• provide clear guidance to anyone who needs strong forward‑compatibility.

Implementation ideas <!-- rough sketch -->

• A Cargo feature such as reproducible-preview1 that
  • strips non‑deterministic / experimental functionality,
  • links only the chosen WASI snapshot symbols.

• Later, convert the module to .component.wasm and use
  WASI preview 2 once that toolchain is considered stable.

• Always build with no_std and static linking to minimise size.

I’m happy to prototype and contribute patches once the recommended direction is clear.

Alternatives

• Fork and freeze an old Wasmtime commit & WASI version
  → difficult to track security updates.

• Switch to another runtime (e.g. Wasmer)
  → today Wasmtime still has the richest docs and tooling for this use‑case.

• Wait until preview 2 is fully settled before starting
  → would delay any practical demo for years.

---

Wasmtime GitHub notifications bot (May 05 2025 at 14:44):

alexcrichton commented on issue #10725:

Wasmtime's release process, including an LTS release, is documented here. Our tiers of support are documented here. The process for making major breaking changes to Wasmtime is documented here.

In effect I think you're going to have to decide whethe Wasmtime is right for you in the end. Wasmtime releases a new major version every month and does not guarantee API-stable major-version compatbility between versions. Put another way -- the same wasm module will still be able to run but you may have to adjust host bindings every so often to keep up-to-date. You can perform this update once-a-year with an LTS release.

Whether or not that's suitable for your use case is up to you to decide. WebAssembly, much less Wasmtime, has not even existed for 10 years. Asking for something to stay unchanging for a decade is a big ask and is not something we can reasonably satisfy at this time (IMO at least). We can probably guarantee that modules from long ago will still be able to run, but guaranteeing that the exact same host code from a decade ago can still be used is not something we can commit to.

Wasmtime GitHub notifications bot (May 05 2025 at 15:25):

cfallin commented on issue #10725:

To add a few more thoughts:

• We just recently instituted the LTS process (maintained/backported-fixes version of Wasmtime for two years, with a new one each year), after much debate, and the major -- quite reasonable -- concern was the additional burden it would place on us, the maintainers. None of us has a bunch of free time -- we all have duties aside from maintaining Wasmtime -- and felt that we were stretching a bit, but could manage an LTS because it's important for many use-cases. That was a tradeoff informed by the importance of the use-case. Asking for a five-times-longer stretch of that for a demoscene is, IMHO, not a reasonable use of resources. At that timescale we're also looking at shifting OS support and even hardware support -- who knows what major ISA(s) will be common in ten years, for example? If a new one appears and we port to it, do we need to backport that entire compiler backend to the old Wasmtime?
• Given that reality of resources, a request like this could plausibly come from an entity with a need and corresponding engineering effort commitment: "we want to keep Wasmtime v24 alive until 2034 and we have a fulltime engineer to do it". Anything less than that is asking for large and unknowable work for free from people with many other priorities.

You're of course welcome to fork Wasmtime (open-source!) but I would agree with Alex that maintaining any restrictions related to this in-tree is far too large a burden for our current state.

Wasmtime GitHub notifications bot (May 05 2025 at 15:31):

cfallin closed issue #10725:

Thanks for filing a feature request! Please fill out the TODOs below.

Feature <!-- what I’m looking for -->

I would like official guidance (or a dedicated build profile) that lets me
run the same .wasm binary unchanged 10 + years from now with Wasmtime.

Concretely, I’d like to know:

1. Whether locking to WASI preview 1 and relying on the
   wasi-preview1-component-adapter will remain a supported path.

2. How to build a static, no_std, “smallest‑possible” Wasmtime that links
   only the required WASI snapshot.

3. The recommended migration path once **WASI preview 2 /
   Component Model** stabilises.

Benefit <!-- why this matters -->

Most generative‑art projects today rely on WebGL, Canvas, or other host‑specific
graphics APIs that could disappear or break in the future.
By rendering purely in software inside a .wasm module
and embedding a minimal, stable Wasmtime instance, the artwork can stay
re‑playable long after those APIs are gone.

Having an upstream‑blessed “long‑term reproducible” profile would

• guarantee that archived .wasm art (and other scientific artefacts) stays runnable,
• help embedders keep binary size and attack surface small,
• provide clear guidance to anyone who needs strong forward‑compatibility.

Implementation ideas <!-- rough sketch -->

• A Cargo feature such as reproducible-preview1 that
  • strips non‑deterministic / experimental functionality,
  • links only the chosen WASI snapshot symbols.

• Later, convert the module to .component.wasm and use
  WASI preview 2 once that toolchain is considered stable.

• Always build with no_std and static linking to minimise size.

I’m happy to prototype and contribute patches once the recommended direction is clear.

Alternatives

• Fork and freeze an old Wasmtime commit & WASI version
  → difficult to track security updates.

• Switch to another runtime (e.g. Wasmer)
  → today Wasmtime still has the richest docs and tooling for this use‑case.

• Wait until preview 2 is fully settled before starting
  → would delay any practical demo for years.

---

Wasmtime GitHub notifications bot (May 05 2025 at 15:31):

cfallin commented on issue #10725:

(I'll go ahead and close this because it seems clear to me we aren't going to be able to do anything about it, but please do feel free to file other issues as you have them if you choose to use Wasmtime!)

Wasmtime GitHub notifications bot (May 05 2025 at 15:32):

cfallin closed issue #10725:

Thanks for filing a feature request! Please fill out the TODOs below.

Feature <!-- what I’m looking for -->

I would like official guidance (or a dedicated build profile) that lets me
run the same .wasm binary unchanged 10 + years from now with Wasmtime.

Concretely, I’d like to know:

1. Whether locking to WASI preview 1 and relying on the
   wasi-preview1-component-adapter will remain a supported path.

2. How to build a static, no_std, “smallest‑possible” Wasmtime that links
   only the required WASI snapshot.

3. The recommended migration path once **WASI preview 2 /
   Component Model** stabilises.

Benefit <!-- why this matters -->

Most generative‑art projects today rely on WebGL, Canvas, or other host‑specific
graphics APIs that could disappear or break in the future.
By rendering purely in software inside a .wasm module
and embedding a minimal, stable Wasmtime instance, the artwork can stay
re‑playable long after those APIs are gone.

Having an upstream‑blessed “long‑term reproducible” profile would

• guarantee that archived .wasm art (and other scientific artefacts) stays runnable,
• help embedders keep binary size and attack surface small,
• provide clear guidance to anyone who needs strong forward‑compatibility.

Implementation ideas <!-- rough sketch -->

• A Cargo feature such as reproducible-preview1 that
  • strips non‑deterministic / experimental functionality,
  • links only the chosen WASI snapshot symbols.

• Later, convert the module to .component.wasm and use
  WASI preview 2 once that toolchain is considered stable.

• Always build with no_std and static linking to minimise size.

I’m happy to prototype and contribute patches once the recommended direction is clear.

Alternatives

• Fork and freeze an old Wasmtime commit & WASI version
  → difficult to track security updates.

• Switch to another runtime (e.g. Wasmer)
  → today Wasmtime still has the richest docs and tooling for this use‑case.

• Wait until preview 2 is fully settled before starting
  → would delay any practical demo for years.

---

Last updated: Dec 06 2025 at 06:05 UTC