An app must be defined with the resource before it can be used. Create a resource with type set to App.

Then: create tools, custom html pages, and triggers for that app. Then embed those into the app.

A tool is a resource which contains some code, an input schema, output schema, description, and specifies which other tools it needs.

A custom html page is a full-screen UI which defines an input schema, and a HTML+CSS+JS bundle to run the page.

A trigger is a condition when something should happen, a result of a cron job, a one-time scheduled job, an event matcher where something should happen as a result of an event, or a webhook

The "something that happens" is a tool call

The trigger defines custom mapping from the trigger metadata (like time, webhook, event metadata), mapped to the input schema of the tool

A service is a long-running program that is meant to stay running as long as the app is launched. (services aren't fully designed yet).

In addition to the children, the app resource has extra metadata:

Schema for public configuration (like, specifying a URL of what the app is referencing). Anybody who can read the app can read the public configuration

For example if the app is meant to integrate with a GH repository, then the public config would contain the Github org name and repo name.

Schema for private configuration (like API key). This will be held on the server who mounts/runs the app

Mount URL of the app (will explain this as part of "Launching")

To launch an app, you will call an API on a server. TBD: how do you authenticate to that server, when does a server allow you to launch? If the server is the same server as the space-defined server (siteURL), then you are done. If this is a standalone server, you need to update the mount URL of the app. With these two rules, anybody can see how they will reach the server where the app is running.

When an app is running, you can call APIs on that server for each tool, and the server will run the latest code for that tool.

Also, that server will perform triggers and will run the services.

To use an app you must talk to the server where it is hosted. Use the resource data to figure out the server. First, check if the app resource references an app server. Otherwise use the server URL defined by the space's siteURL.

If you cannot find a server, or if the server refuses to acknowledge the app, it is not launched.

Then, you can start interacting with that server by signing messages and referencing the app through its HM ID.

An app is just a document, regardless if is launched or not. That means that if I can read an app, I can fork it and run it myself.

All resource/document semantics follow documents. For example, AppA embeds Tool1@latest. Then I want to run AppA, so I fork it, and my fork still references Tool1@latest. That means that my app is using the tool code defined by somebody else. When the owner of Tool1 changes the code, the behavior of my app will change.