Remote component sources from the registry

Background

Referencing a Wasm module from a remote bindle has been possible since #456. However, because of the infrastructure requirements for running Bindle, #890 introduced support for referencing a remote component source from an HTTP URL to simplify this scenario.

This made possible things like templates for the static fileserver and redirect components (#898), since all you need is to publish a Wasm module to a URL.

However, because the URL source points to a single file (similarly, you reference a single parcel from the remote bindle), this means you cannot use a component that requires additional assets or configuration in order to function properly. (examples for this could include components with static assets, ML models, logos, or https://github.com/radu-matei/spin-kv-explorer)

With spin registry publish, you can distribute an application to a remote registry service. spin registry publish also adds any asset referenced by the component in the distributed package.

Proposal

I would like to propose expanding the options for the module source to allow referencing a remote component from the registry. There are two (non-mutually exclusive) ways in which we could address this:

• reference a single Wasm module from a remote registry reference — this would bring feature parity with the existing functionality. :

source = { reference = "ghcr.io/radu-matei/my-spin-app:v1", digest = "sha256:aaa" }

Note that digest here would require a user to either calculate the digest of the Wasm module locally, or inspect the generated manifest or lockfile, neither of which would be ideal. Alternatively, this could allow referencing the Wasm source of a given component ID instead — see next option.

• reference an entire Spin component from a remote registry reference:

source = { reference = "ghcr.io/radu-matei/my-spin-app:v1", id = "my-spin-component" }

A component in Spin is a Wasm module together with configuration and assets. A user would choose to reference an entire component because its functionality is something they would like to reuse in their application. This raises the following question: what should be the bahavior for handling configuration, considering there are two sources of configuration for the new component — the component configuration in the registry, and potentially user-defined configuration in the current spin.toml.

There are two things to consider here:

• the referenced component might not function at all without its default configuration it was distributed with
• the referenced component is potentially a third party extension and it should not be implicitly granted access to resources (allowed hosts, KV stores, current files or configuration)

Given that the immediate value we get out of referencing an entire component is distributing other assets together with the Wasm module, we could treat files that were part of the component specially and use those (and potentially allow a user to override them with other files). Everything else in the component configuration must be defined by the user importing the component.

We could introduce a new component type (in preparation of eventually having "library components" as opposed to "executable components"), but how we handle configuration would still need to be carefully assessed.

Is supporting components from the registry something we want to enable?

Start by reviewing the existing remote HTTP component-source support from #890 and the spin registry publish behavior described here. Define whether registry references target a Wasm module or an entire component, then resolve how registry configuration, user configuration, assets, and resource access should interact; the issue is done when that behavior is specified clearly enough to implement.