Install moxzialpha

How do I get the toolchain onto my machine and confirm it works?

curl -fsSL https://moxzi.ai/install.sh | sh

That is the whole thing on macOS and Linux. The script picks the build for your platform, verifies its SHA-256 against the release's SHA256SUMS before unpacking anything, and installs to ~/.local — binaries in bin/, the two wasm files in lib/moxzi/. It refuses to install on a checksum mismatch, and refuses to install at all if it cannot fetch the checksums: this project's whole argument is that you can check bytes instead of trusting them, and an installer that skipped that would be arguing the other side. Set MOXZI_PREFIX to install elsewhere, MOXZI_VERSION to pin a version.

Where the bytes come from. Releases are served by moxzi's own site, which is a canister on the Internet Computer — the same platform the compiler targets. The script reads /releases/latest for the current version and fetches the tarball and SHA256SUMS from /releases/v<version>/. There is no release API, no account, and no third party between you and the artifact; MOXZI_RELEASE_BASE points the whole lookup somewhere else if you would rather mirror it, and MOXZI_BASE_URL names an exact directory (a local dist/, or a GitHub release's download directory) when you want to bypass the version lookup.

There is no separate compiler package, because the compiler is one of the wasm files — and those two files are the same bytes on every platform. Only the native binaries differ, which is why releases are per-target (the release script refuses to cross-compile: shipping an untested cross-build is worse than not shipping one).

If you would rather do it by hand, or you are on a platform without a build, the tarball is below.

What is in the release#

Both binaries look for the two wasm files beside themselves, so the unpacked directory works with no environment set up at all.

By hand, from the tarball#

shasum -a 256 -c SHA256SUMS --ignore-missing   # check it first
tar -xzf moxzi-0.1.0-alpha.1-aarch64-apple-darwin.tar.gz
cd moxzi-0.1.0-alpha.1-aarch64-apple-darwin
./moxzi info

Everything in the unpacked directory works with no environment set up, because both binaries look for the wasm files beside themselves. (They also look in ../lib/moxzi/, which is what lets the install script put moxzi on your PATH while keeping the wasm files out of it.)

moxzi info is the confirmation step, and it prints the two things that matter — which wasm files were found and their SHA-256 hashes:

compiler : /…/moxzi-0.1.0-alpha.1-aarch64-apple-darwin/compiler.wasm
sha256   : 86ea6a0c26965691715a31ffa4c4d4280d60aab8cb8ac1a385e783b49371c193
size     : 7.8 MB
linker   : /…/moxzi-0.1.0-alpha.1-aarch64-apple-darwin/linker.wasm
sha256   : 64a110c3430af78f7d0ac8828706fcbe22fbd4c18d9c000a9b06cd6e82800744
module   : loaded from AOT cache in 0.038s
updates  : 42
queries  : 34
  write      present
  start      present
  step       present
  jobWasmSize present
  jobWasmChunk present

Those hashes are published in the release's SHA256SUMS, and they are the same hashes every build prints as its provenance line. Check them against the release notes before trusting an artifact you did not build yourself.

Then compile something:

cat > hello.mo <<'EOF'
persistent actor {
  public query func greet(name : Text) : async Text { "Hello, " # name # "!" };
};
EOF
./moxzi build hello.mo -o hello.wasm

If that prints hello.mo -> hello.wasm + hello.did (220356 bytes, …), the install is finished. The release script runs exactly this check on the staged directory with the environment scrubbed, so a tarball that reaches you has already built a hello world once.

Putting it on PATH#

Copy both binaries and both wasm files into the same directory, and discovery keeps working. The search order is fixed, and --compiler / --linker always win:

If none of those hit, moxzi fails with the list of every path it tried, rather than a confusing trap inside the compiler.

Docker#

The repo's Dockerfile produces one image carrying both binaries and both wasm files in /usr/local/bin, so beside-the-binary discovery works inside the container:

docker build -t moxzi/moxzid .
docker run --rm -p 7000:7000 -v moxzi-state:/state -e MOXZID_TOKEN=change-me moxzi/moxzid

The wasm artifacts are copied in, not built: building compiler.wasm needs the reference moc toolchain, which does not belong in a release image. Run make compiler-canister-wasm and make moxzi-linker, or unpack a release tarball into bin/, before docker build.

From a source checkout#

cd moxzi && cargo build --release --workspace

That produces moxzi/target/release/moxzi and moxzid. It does not produce the two wasm files: those are built by the reference moc toolchain that mops toolchain manages (make compiler-canister-wasm, make moxzi-linker), which is a dev-machine dependency. CI restores them from cache for the same reason. A source build with no wasm files will compile fine and then fail at moxzi build with the search-path error above.

Things you cannot do#

moxzi-web, the browser runtime, is the one piece that is an npm package (npm install moxzi-web) and is packed alongside the tarball as moxzi-web-<version>.tgz.

Next#

• Your first compile — turn hello.mo into a wasm and read what the build printed.
• Choosing a runtime — decide whether you need the CLI, the server, the browser, or the on-chain builder.
• CLI quickstart — the shortest path from an empty directory to an installable wasm.