Config, manifests, and capabilities

A provider has Rust config and manifest metadata. They serve different purposes.

Rust config

Use #[omnifs_sdk::config] for the config type the provider receives at startup:

#[omnifs_sdk::config]
struct Config {
    endpoint: String,
}

The macro wires JSON deserialization for provider initialization. It does not replace the public manifest schema.

Manifest

omnifs.provider.json declares provider metadata, default mount name, auth schemes, config schema, and requested capabilities.

{
  "id": "example",
  "displayName": "Example",
  "provider": "omnifs_provider_example.wasm",
  "defaultMount": "example",
  "capabilities": [
    {
      "kind": "domain",
      "value": "api.example.com",
      "why": "Fetch Example API resources."
    }
  ]
}

The provider macro embeds this metadata in the component.

Mount config

Mount specs are JSON. A mount selects a provider, a mount name, optional auth, optional config, and optional runtime capability overrides. The host resolves raw mount config into runtime-ready mounts by applying provider metadata and defaults.

Capabilities

Provider authors declare what they need. The host decides what is granted.

Use narrow capabilities:

• exact domains for HTTP callouts,
• exact Unix socket needs,
• explicit WASI preopens,
• Git repo patterns only when tree handoff is required,
• blob fetch/read byte limits when the provider works with large host-managed bytes,
• auth injection only for domains that need credentials.

Do not treat a manifest memoryMb declaration as proof that long-lived provider memory is enforced. Document it as requested or declared memory unless runtime enforcement changes.

Auth schemes

Add auth only when the provider needs credentials. Auth schemes describe how the host obtains credentials and where it may inject them. Providers should not parse tokens out of config or logs.