Skip to main content
In progress. Mzizi Roots is a conversion with its first batch done, not a finished library. The first batch is twelve brand components; most of the registry’s 434 branded items are still React only. The design is docs/roots/RFC-roots.md in the registry, merged with the status “proposed, 2026-09-29”. Where this page and that RFC disagree, the RFC is right.
Mzizi Roots is the name for Mzizi’s own branded components rebuilt in Rust: UI and server components, built for the agentic web. It is where new component work goes.

​
Rust first

  • Rust is the lead. Where a Rust implementation of a component exists, it is the one to use, and these docs present it first.
  • The React build keeps working. The React and TypeScript (.tsx) components stay in the registry and stay installable. They are deprioritised: not the lead, and not where new work goes. These docs call them the React build.
  • UI and server. Roots covers the handlers that serve a component as well as the component, which is the charter’s full-stack shape for Phase 1.
This follows from the owner’s direction for Mzizi as a whole: the frontend is either Astro with Mzizi UI (Roots) underneath, or pure Rust end to end, and everything built carries a contract. See the roadmap.

​
How Roots relates to the language

Roots components are written in Rust today, not in Mzizi. The language cannot produce them yet: no component lowers to Rust (only a service does, to a local axum package), and Phase 1 waits on the benchmark (Status). Roots is built to support the language: it is meant to be the language’s component model, the way React is JavaScript’s, with Rust as the platform underneath. When the language lowers components to Rust, Roots is its target: the RFC writes every Roots contract in the language’s contract … end grammar. That is a design intention, gated on the benchmark like the rest of Phase 1. Until then, the components also do a second job. The registry’s components, React and Rust together, are the ground truth for the benchmark’s UI tasks. The nine primitives are hand ports of registry components, and the benchmark scores a candidate against a component’s Rust reference. That is one of the components’ jobs, not what they are, and not the benchmark’s goal, which is Mzizi against the best existing language for each kind of task (the benchmark).

​
What exists today

The Rust half of the registry lives in mzizi-rs/ in mzizi-dev/mzizi-registry, a Cargo workspace. All ten of its crates are on crates.io at 0.1.0 (checked 30 September 2026): eight node crates, one per node that has Rust, and two umbrella crates that re-export them.

​
Install

Each umbrella turns every feature on by default. mzizi-roots has the features ui, brand and shell, and always includes mzizi-tokens. mzizi-roots-server has assurance, fundi, docs and discovery; docs brings in Dioxus, because mzizi-docs also carries two documentation renderers. To take less, turn the defaults off and name what you need, or depend on a single node crate:
The node crates are the ones that compile each component, and they keep their names.

​
The first batch: twelve brand components

The first Roots batch converts twelve N3 brand components, where there was no Rust at all before: mzizi-alert-banner, mzizi-avatar-stack, mzizi-cover-header, mzizi-empty-state, mzizi-escalation-card, mzizi-gauge-card, mzizi-hero-stat, mzizi-meta-tile, mzizi-stats-row, mzizi-success-screen, mzizi-suitability-card and mzizi-user-card. They ship in mzizi-brand. Each one carries a contract, checked against its rendered output. The contract has two parts. The registry contract is the one every component has: one name, one set of variants, the same data-slot, data-portal and tokens as the React build, asserted against the .tsx sibling. On top of that, each module exports clauses in the language’s contract … end grammar, three to eight per component and 65 in all. The crate’s contract suite renders each component with dioxus-ssr and evaluates every clause against the markup it emits. A clause it cannot evaluate fails. For example, from mzizi-alert-banner:
These clauses are evaluated by Rust tests in the registry, not by mz contract. The language’s own evaluator checks a .mz component against itself and cannot read Rust. The ports also fix six defects the React build still has, such as a 40px button under the 48px touch floor and an unclamped aria-valuenow. Each fix has a test.

​
Reading the Rust source

You can read a component’s Rust source over the API:
That route is a read surface, not an install path: depend on the crate instead. Each document’s crate field names the crate its component ships in, so it answers which one to depend on:
From registry commit 9b86e03 on, /v1/rs/{name} serves all twelve brand components, each naming mzizi-brand, alongside the primitives in mzizi-ui, the app chrome in mzizi-shell and the server rungs in their own crates. On 30 September 2026 the API was built from that commit, and so was the MCP server. Both pins move, so read the live one from the source: the API’s x-mzizi-source header, or the MCP server’s catalogue.json. The MCP server is Rust first too: mzizi_get_component leads with the component’s crate, its cargo add line, its contract and its .rs source, and gives the React build second.

​
Where to go next

The registry

How the registry works, and how to install from it today.

The helix

The DNA-helix architecture every component, Rust or React, is placed on.

Browse the components

Every component, grouped by node, at mzizi.dev/components.

The MCP server

Read any component, its tokens and its doctrine from an agent.