# Bytecode Alliance Components Registry — MVP Product definition The purpose of this document is to collaborate on and produce a specification for a registry for publishing, consuming, storing, and sharing Web Assembly components. This includes a set of user stories, requirements, non goals, and the HTTP API for the registry. ## Requirement categories ### Authoring components (A, B, C, I) - Must be able to author a component in Rust, JavaScript, C/C++ - Must be able to import other components and interfaces - Must be able to bootstrap a component from a template - Must be able to add a cryptographic signature ### Publishing components (G, N, P) - Must be able to cryptographically sign artifacts - Must be able to distribute components separately - Must be able to yank components ### Discovering components (D, E, T) - Must be able to search for interfaces and components - Must be able to search for components that implement an interface - Must be able to view dependencies of a component - Must be able to view the cryptographic signature of a component. - Must be able to list authors of component - Must be able to view LICENSE of component - Must be able to view what system capabilities a component will require - Must be able to get the name and version of a component - Must be able to see available versions of a component given the component name ### Fetching components (H, R, S) - Must be able to fetch a component by name and version - Must be able to cryptographically validate components prior to installing them (though perhaps after downloading them) - Must be able to cache components and compare cached component to component in registry to know if they are the same (e.g. avoid re-downloading the same components) ### Inspecting components (K, M) - Must be able to list signatures on a component prior to installing - Must be able to see LICENSE (and maybe README) of component without installing - Must be able to determine size of component prior to installing ### Deploying components (F, L, O, Q) - It must be easy to run your own [Deployable Registry](https://docs.google.com/document/d/1FxSuSYL0LkGb2jueUAcUu-h4sKEsdiWgMd4axsR95F8/edit#heading=h.hibsxupp1y4n) - We must have implemented the Registry Spec except for the provenance parts ### Running components (J) - Must be able to have tooling to dynamically link and instantiate components - Must be able to reject components that don’t cryptographically verify ## User stories A. As a Rust developer, I want to be able to use cargo-based tooling to develop a WebAssembly Component that consumes Components and Interfaces from the registry through auto-generated Rust APIs, and publish the resulting Component to the registry. B. As a JS developer, I want to be able to use npm-based tooling to develop a WebAssembly Component that consumes Components and Interfaces from the registry through auto-generated TypeScript type definitions, and publish the resulting Component to the registry. C. As a JS or Rust developer, I want to target a Profile published to the registry to ensure that the resulting component will work in a runtime environment implementing that Profile. D. As a developer, I want to be able to search the registry by component / interface name or description contents with an optional version constraint. E. As a developer, I want to be able to search the registry for Components implementing a specific Interface with an optional version constraint. F. As a system administrator or platform operator, I want to be able to run an instance of the registry implementation, and have the ability to make a filtered subset of other registries available, either their live contents, or a mirrored snapshot. G. As a package author, I want to be able to associate sets of structured, but open-ended metadata with the package when uploading it to the registry along with signatures proving authenticity. H. As a package consumer, I want to be able to retrieve the metadata sets associated with a package as well as their signatures. I. As a component developer, I want to be able to package my component along with a set of hierarchical static contents from a local directory into my component as an encapsulated implementation detail not visible to my clients or other components my client is using. J. As an application deployer, I want to be able to deploy (or know how to unpack) a wasm component with my mounted static assets from a package in a registry. K. As a forensic analyst or auditor, I want to re-compose the full execution environment for a past job and reconstruct the source code used for all compiled artifacts. L. As an individual or organization, I want to collect my components/interfaces/profiles into a namespace grouping. M. As a host environment provider, I want to have the APIs exposed necessary to analyze whether I can run a specific component purely based on statically analyzing its interface. N. As a package owner, I can mark a package as “yanked” to indicate it should not be used O. As a repository owner, I can “delete” a package that is deemed in violation of registries practices. P. As a developer, I want to be able to satisfy licenses that require making source code and/or other information available for binaries. Q. As a registry owner, I can enable a requirement that all packages must have a license field/annotation that contains a valid [SPDX identifier](https://spdx.org/licenses/). R. As a registry client, I want to have reproducible version resolution of my version-constrained dependencies to the same contents over time (or a failure in case a dependency was deleted). S. As a registry client, I want to have a way to update the reproducible version resolution of my version-constrained dependencies. T. As a registry client, I want to be able to look up and retrieve a package in a registry based on its content hash. ### References - [original user stories document](https://docs.google.com/document/d/1QV0iXQBEqnE9CtNAhwH-oD7PBRnfeREj2nWZmw_zO8M/edit#) - [registry architecture requirements](https://docs.google.com/document/d/1jv4Vh9o4LNT_XV9sklY1N840vElSI_dilnenzuwkraM/edit#heading=h.s6m06pefqgfb)