Implementing Short Aliases

[calvinrp]

Primarily, two use cases:

1. In Wit, short aliases that map to a Registry's domain name. Examples: wasi: mapping to registry.wasi.dev: or ba: mapping to registry.bytecodealliance.org:;
2. Easily remapping imports to substitutes locally or remotely;

There are a few different ways to implement. Key questions:

1. What should be in the Component binary? The short alias or the Registry's domain name?
2. Should short aliases be local development concern? Or something aliased in Wit?
3. Or should a Registry maintain an alias table mapping to Registry domain names? If so, should that alias table be global to the Registry or package specific?

[lukewagner]

Great to see this being brought up! Regarding the question about what's in the published component binary:

With the component format changes in component-model/#198, the names of interface imports and exports will have the form (interface "foo:bar/baz"). Ideally, we could simply publish these components to the registry as-is, using this alias mechanism to map foo to the registry defining the foo namespace, with bar as the Wit package name and baz as the name of the Wit interface in that Wit package. Then I think it would make sense to do symmetrically for implementation imports, although there is more work to do to define precisely how implementation imports are represented in the component binary format.

Note that, when a component containing aliases is published, the publish event can record precisely the state of the registry (and all aliased registries) as observed by the developer at the time publication. Thus, there should be zero loss of information or addition of ambiguity with having the published contents of a component use aliases. And then if a downstream use of this published component wants to map the alias to something else (for which I think there are a number of use cases, local development being one), the downstream doesn't need to rewrite the binary (thereby changing the content hash) or map from one domain to another (making the domain an alias after all, which seems likely to trip up anyone along the way who thinks domains are domains). There is a time and place for domains, of course, but I think it's when you ship a component to a browser that is going to live-fetch the component's imports and in this case the domain isn't that of the registry, it's that of a CDN or production server.

[esoterra]

You and @peterhuene seem to be thinking about this in similar terms, so I'll reply here to both. This is an appealing way to think about namespaces and has some benefits that you've both pointed out. In addition, representing namespaces using the identity of the owning registry is lossy if registries ever contain multiple namespaces.

The one hazard I want to be aware of is that this makes context very important when evaluating warg references. As long as we think we can communicate this complexity with registry implementers and it doesn't make it easy for users to do something insecure I think this is a good way forward.

[lukewagner]

You're right; having a clear registry context established for all the primary developer workflow operations like building, publishing, dep-solving and deploying seems essential to this approach. I get the impression that we need and want to have this context clearly establish in general (along with a clear way for the developer to know and set it), so hopefully there aren't cases where the context would otherwise be ambiguous, but I'm definitely interested to talk through any challenging scenarios with folks.

[peterhuene]

In Wit, short aliases that map to a Registry's domain name.

I haven't thought about it like this.

To me, wasi and ba are just namespaces and nothing more; that is to say I don't believe they should be indicative of which registry you should talk to for those packages.

If I, a client, ask a registry for wasi:http, it might have no idea what that name is, it might have its own concept of what the name refers to, it might be replicating a package of that name from an upstream registry (e.g. registry.wasi.dev), or it might simply redirect the request for that package to the upstream registry directly.

Thus, I consider this more of a problem to solve for how a registry maps namespaces in the context of replication/redirecting.

What should be in the Component binary? The short alias or the Registry's domain name?

I think we'd have the <ns>:<name> in the binary encoding (which we'll have shortly with Alex's changes), but we wouldn't want any references to domains.

Should short aliases be local development concern? Or something aliased in Wit?

I don't think it'd be a concern for local development at all. The developer simply configures their tooling regarding which registries it wants to source packages from. It could be a single registry for every package or particular registries for specific packages.

Take for example a hypothetical Fastly registry one day. The Fastly developer SDKs would be configured to use a hypothetical registry at registry.fastly.com. The registry client may request packages such as wasi:http and ba:wasm-tools and Fastly may choose to replicate/redirect the wasi and ba namespaces to upstream WASI/BA registries. In addition, the Fastly registry might define its own packages at fastly:xyz or allow users to have a private namespace for their own packages.

Or should a Registry maintain an alias table mapping to Registry domain names? If so, should that alias table be global to the Registry or package specific?

This sound more of what I was thinking. The registry would maintain a set of namespaces or full package names it is either redirecting to or fully replicating the logs for. I think that'd be under the purview of the registry's implementation to determine at what scope it does the mapping.

[calvinrp]

Does this reflect how you guys are thinking about it?

Namespaces are some valid name ending with : that act as a prefix for package names. Each Registry would declare a namespace that refers to self. Registries can have their own policies for controlling namespace usage, including restricting who can use a namespace.

When a Registry is setup to mirror another Registry, an alias namespace is declared as a prefix for the mirrored package names. That alias namespace would map to the mirrored Registry's domain name. For the moment, let's call this a "Namespace Import Map". The "Namespace Import Map" would also need to be mirrored (recursively) to resolve mirrored package imports.

Can a namespace be deleted or renamed? Probably not.
Are nested namespaces valid? For referencing, a mirrored Registry's namespaces, potentially recursively.

[calvinrp]

Closing this discussion since it is outdated and could cause confusion. But happy to reopen if others feel otherwise.