The MZI application platform

Application responsibility and host responsibility

Your application defines its domain behavior, data and semantic interface. The host maps that intent to its platform, enforces permissions and manages execution and local state. SDK and CLI provide the authoring and packaging workflow. Platform compatibility depends on the versioned contract and required capabilities.

The distinction is observable: field-notes.mzi is around 34 KB and contains a platform-neutral component, WIT, interface description and data schema. It contains no browser, desktop or mobile build.

Platform hosts

Each host implements the package contract, signature verification, capability checks and local data behavior for its platform. Native hosts have independent implementations; matching semantics must be verified with conformance tests. Each operating system still needs a platform implementation even when the application package stays unchanged.

Both mobile hosts prove native touch rendering, private state and typed Component actions without an application-specific platform build. Their current Component profile remains Application 0.3 and applies a 10 million instruction budget to each call; capability imports and arbitrary multi-module composition remain future mobile work. The iOS device artifact proves the correct target and architecture, not installation on an iPhone. Apple App Review guideline 2.5.2 makes arbitrary downloaded executable behavior a separate distribution-policy problem.

Build your first application

The recommended beta starter uses AssemblyScript, a statically typed TypeScript-like language designed for WebAssembly. It is deliberately not described as full TypeScript: browser and Node APIs are not part of the portable application sandbox.

hello-mzi/
├── manifest.toml          # identity and authority
├── assembly/index.ts      # editable typed logic
├── package.json           # pinned compiler dependency
├── asconfig.json          # reproducible Wasm target
├── interface.mzi.json     # semantic native controls
├── data.schema.json       # host-owned local state
└── wit/mzi.wit            # versioned contract

curl -fsS https://mzi.app/downloads/mzi-cli.mjs -o mzi.mjs
node mzi.mjs init hello-mzi --language assemblyscript
cd hello-mzi && npm install
node ../mzi.mjs dev . --launch

Edit assembly/index.ts to change increment, decrement and reset. mzi dev watches typed source, WAT, manifests, interface definitions, schemas and WIT contracts; it debounces editor writes, rebuilds the deterministic package and keeps watching after a compiler error. Windows Host 0.8 and Linux/macOS Host 0.7 previews negotiate mzi-dev-reload/0.1; valid revisions replace the runtime and semantic UI inside one native process while persisted state remains host-owned. A revision that changes publisher, storage, WASI or capabilities is refused until it receives a new authority review. Older hosts do not acknowledge the session, so CLI safely falls back to reopening the package. Omit --launch for a quiet continuous build. Use mzi run . --no-launch for one CI build.

Package signing

mzi keygen creates an Ed25519 publisher key and mzi sign adds a verifiable SIGNATURE entry. The signature covers a domain-separated SHA-256 digest of every sorted path and its exact bytes except the signature entry itself.

Package SHA-256 still identifies one exact archive. The publisher key instead connects different signed versions. On first approval the host binds that key to storage_key; later packages signed by another key are refused before state is read.

Distribution catalog

mzi.app/apps is the first distribution surface. On Windows x64, the per-user setup installs MZI Host, creates a Start menu shortcut and associates .mzi files without requesting administrator access. A user then downloads small signed application packages from the catalog or opens the same package in Browser Host.

The setup itself is currently unsigned beta software, so SmartScreen may warn; its SHA-256 is published beside the download and the portable ZIP remains available. GET /api/host-updates implements mzi-host-update/0.2. Its release payload is signed offline with a dedicated Ed25519 key whose public half is embedded in Windows Host. Both the API and host verify that signature, while the API also matches the setup's PE header, exact byte length and SHA-256.

The Windows host checks this feed on demand, but refuses automatic installation while the EXE remains unsigned. GET /api/catalog implements the preview mzi-catalog/0.1 application feed. Production distribution still requires publisher enrollment, key revocation and recovery, protected signing-key operations, Windows installer signing and Apple notarization.

Application 0.2

The semantic vocabulary now includes forms, inputs, statistics, record collections, item templates and contextual actions in addition to the 0.1 nodes. Hosts choose their own controls and layout while preserving bindings and meaning.

Field Notes proves add, toggle, remove, clear and reload behavior without application access to browser storage or native files. Collection effects are applied and persisted by the host after a Wasm decision.

WIT contract and runtime

Versioned-state packages declare and embed mzi:[email protected]. Application 0.4 adds the host-provided clock.now-ms import. Application 0.5 adds http-get and complete-http, a two-stage contract for asynchronous host work.

Capability HTTP returns a typed task instead of importing fetch. Browser Host or the shared Windows/Linux/macOS host core validates its destination, performs the request outside the Component, then resumes it with bounded response bytes. This avoids depending on experimental async Component bindings while preserving one contract and authority boundary across independent runtimes.

State migration

A stable storage_key separates application data from the changing package SHA-256 identity. The data schema declares directed migration edges; the host rejects missing, ambiguous, cyclic and downgrade paths.

Before migration the host stores a schema-versioned backup. It executes each edge inside the sandboxed component with a two-second deadline and a 4 MB state limit. Only valid JSON object output is committed in an mzi-state envelope. A trap, timeout or invalid result leaves the prior state untouched.

Capabilities

Capabilities describe authority, not dependencies. Browser Host 0.7, Windows Host 0.8 and the 0.7 Linux/macOS previews compare Component work with the reviewed signed manifest. A missing declaration, unsupported import or unauthorized task stops the operation.

self is resolved against the signed distribution.origin; other grants are exact HTTPS origins. Requests carry no application cookies or referrer, cannot follow redirects, use URLs of at most 2,048 characters and return at most 256 KiB within five seconds. Application 0.5 currently supports one GET task per action; headers, request bodies and streaming remain outside the profile.

Host lifecycle

All current hosts expose an inspectable four-step path. Rejection is possible before execution. Runtime calls are bounded; Android and iOS enforce 10 million interpreted instructions and permanently lock an instance after budget exhaustion or another trap.