Idea: Content-Addressed Interface Verification for WASI (Hybrid Named/Anonymous Model)

[const]

Hi WASI community,

I'm sharing a research-level proposal exploring content-addressed verification as an opt-in extension to the current WASI interface model.

Disclaimer: This is a conceptual exploration. I do not have resources to implement, maintain, or champion this proposal. However, I still think that the idea is interesting enough and worth sharing.

🔍 Core Idea

• Problem: Current WASI relies on named interfaces + central registries, causing naming fatigue, version drift, offline deployment friction, and complex dependency graphs.
• Propsed Solution: Opt-in content-addressed verification using structural hashes alongside existing names. Introduces @anonymous interfaces for ephemeral/CLI contracts and a configurable wit-sources.toml fetch model (git/maven/file/nexus) for offline/enterprise use.
• Key Mechanism: @version(hash=...) + @available(version=...) enable deterministic runtime projection and instant drift detection. Hash mismatches flag forks/vendor modifications before deployment.
• Scope: Looks like backwards compatible. Canonicalization v1 intentionally limited to avoid ABI risks. Missing @available = member exists in all versions. Hashes verify integrity, not authenticity.
• Open Questions: Formal canonicalization rules for complex types? Transitive dependency resolution strategy? Feasibility as a wasm-tools extension? Community interest level?

interface-publishing-improvement.md

[yoshuawuyts]

@const hi, thanks for opening this issue! Could I ask you to please provide a link to your proposal in gist format rather than as a downloadable file? Thanks!

[const]

done

[const]

I've added some clarifications and appendix on decentralization to gist with proposal, also added developer's workflow section

[yoshuawuyts]

@const thanks for updating the link! Before proceeding I just wanted to quickly check: did you use an AI tool to generate that document?

[const]

I used AI to help to verify idea problems, missing pieces, possible counter arguments and questions, also to smothen narrative, and check for spelling and grammar errors. The core idea is mine, and it is based on my old non-accepted proposal for Kotlin suport for multi-release jars: https://discuss.kotlinlang.org/t/proposal-kotlin-multi-release-jar-support/21386