1. Motivations
1. Type sharing
1. Link relevant to wit-bindgen issues
2. Why WASM outside the browser wants *multiple* Worlds
1. Hosts provide different capabilities to their guests
1. (For non-accidental reasons: have network or not, have GPU or not, have storage or not...)
2. Examples: client (UI), SaaS plugin, HTTP Proxy, DB UDF, ...
2. How do we still share tooling?
1. Want: given a World, I'm ready to rock (generate all necessary guest or host code)
2. Show hypothetical syntax
1. What we could write today
2. If we wanted multiple interface definitions in one file, we'd extend like this...
3. Now, we add a new kind of definition: "world"
4. Example (HttpProxy) Several of us are interested in an interoperable HttpProxy, how might this look as a World.
> Stub out HttpProxy (https://docs.google.com/presentation/d/11lY9GBghZJ5nCFrf4MKWVrecQude0xy_buE--tnO9kQ/edit#slide=id.gef8ed7fdec_0_138)

4. Hermetically-sealedness of a world
1. It's *all* the *possible* imports/exports
2. From a component-model POV, a world = component type, subtyping says whether your host world can run a given component
5. Two perspectives on a world: Guest and Host

Today I want to introduce a new `WIT` construct called "Worlds". A world is a collection of "imports" and "exports". From the component-model POV, a world is a a component type and subtyping says whether your host world can run a given component.

> Guests may require certain capabilities from a host

Said another way, guests can import capabilities from the host.

> Guests may target any number of hosts.

* Guest may import/export capabilities from/to the host or other components
* Hosts may export/import capabilities from/to guests

Historically, we used the term "profiles" to refer to this contract between guest and hosts.