Skip to main content

MEP-57 research bundle: Mochi module and package system

Author: research pass for MEP-57 (Mochi module and package system). Date: 2026-05-29 (GMT+7).

This bundle contains the twelve research notes that informed MEP-57, the Mochi module and package system. The notes are informative; the normative spec is in the MEP body.

#TitleTopic
01Language surfaceHow the existing import statement extends to manifest-resolved packages, workspaces, capabilities, polyglot target opt-in, while keeping path-form imports intact
02Design philosophyWhy TOML, why PubGrub, why sparse index, why content-addressed objects, why Sigstore + OIDC, why capabilities at the package boundary, why polyglot fan-out is mandatory, framed against 2024-2026 research
03Prior art: registries and package managersSurvey of modern (2024-2026) systems: Cargo, Go modules, npm, JSR, Bun, uv + PEP 751 / 723 / 735, Bazel bzlmod, Nix flakes, SwiftPM, Hex, NuGet, Pixi, Spack, Pkl
04Manifest formatmochi.toml schema deep dive, key set comparison with Cargo / uv / pyproject / package.json, validation rules, three Mochi-only sections, manifest evolution
05Solver designPubGrub algorithm walk, derivation of incompatibilities, decision levels, conflict-driven backtracking, "why" explanation generation, rejection of MVS / SAT / ASP for Mochi's polyglot surface
06Lockfile formatmochi.lock canonical TOML serialisation, per-platform sections, version envelope, lessons from Bun's bun.lockb reversal, PEP 751, Cargo.lock, package-lock.json v3
07Registry indexSparse HTTPS index protocol, ETag and cache semantics, retry strategy, mirror discovery, version yank flow, deletion policy, comparison with Cargo's GA March 2023 migration
08Content-addressed object storeBLAKE3-256 primary + SHA-256 secondary, blob fetch protocol, cache layout, deduplication, integrity verification, why dual hashing matches SLSA + Sigstore + npm requirements
09Trusted publishingSigstore + OIDC keyless flow, Fulcio certificate request, signature bundle, Rekor transparency log, verification, comparison with npm Trusted Publishing (April 2024), Maven Central (October 2024), PyPI PEP 740 (Nov 2024), Cargo RFC #3724
10Capability modelClosed capability set, declaration syntax, lockfile annotation, enforcement per target (Deno permissions, Python runtime checks, Wasm component imports), lessons from Roc platforms, Pony reference capabilities, Wasm Component Model, Lavamoat / NodeShield
11Polyglot fan-outOne source manifest, eight artifact pipelines, per-target overrides, FFI lowering hand-off, target-specific gates, version mapping across ecosystems with incompatible semver semantics
12Risks and alternatives16 risks (typosquatting, registry compromise, solver loops, capability creep, sigstore root rotation, polyglot drift, ...) + 12 rejected alternatives (Unison hash-as-name, git-based registry, Mochi-DSL manifest, monorepo-only, vendoring-only, MVS, SAT, ASP, binary lockfile, long-lived tokens, open capability vocabulary, no capabilities at all) + 7 v2 candidates (federated discovery, index transparency log, cargo-vet attestations, effect-system capabilities, path-scoped capabilities, PEP 723 inline-script deps, Wasm component model)

Cross-references