Skip to content

MALT v0.0.5 — Resolve/Read Client Boundary

Choose a tag to compare

@BernardLowe BernardLowe released this 13 Jul 12:07
fd7dd54

MALT v0.0.5

Status: released on 2026-07-13

MALT v0.0.5 tightens the boundary between the portable authentication core,
trusted clients, untrusted gateway/executor work, immutable CAS payloads, and
application models such as UnixFS. It is an experimental source release, not a
stable API line or production managed service.

Release Contract

  • Go module: github.com/dewebprotocol/malt@v0.0.5
  • resolve profile: malt.resolve/v0alpha1
  • primitive-read profile: malt.read/v0alpha1
  • frozen compatibility profile: malt.artifact/v0alpha2
  • schemas: protocol/schemas/*.schema.json
  • reference routes:
    • POST /v1/resolve
    • POST /v1/read
    • POST /v1/verify/resolve (diagnostic only)
    • POST /v1/verify/read (diagnostic only)

Highlights

  • The module-root malt package exposes application-neutral
    ResolveRequest/ResolveResult and typed primitive-read contracts together
    with portable VerifyResolve and VerifyRead functions.
  • execution.Executor performs untrusted resolve/read/apply work over injected
    resolver, semantic prover, and mutation-applier capabilities. It never makes
    the client trust decision.
  • protocol publishes operation-specific request, result, verification, and
    JSON Schema contracts. ProofList is evidence carried by those results, not a
    generic operation envelope.
  • mutation owns namespace-free semantic mutation, delta, commit-descriptor,
    and write-receipt values. Receipts and candidate roots are not cryptographic
    state-transition proofs.
  • UnixFS is split across model/unixfs, sdk/unixfs, and runtime/unixfs so
    application semantics, client planning/body verification, and reference
    execution are not treated as MALT core.
  • sdk/verifier, malt verify, and the browser/WASM build bind a
    caller-selected request to an untrusted result before portable ProofList
    verification.
  • The process managed by malt start is documented as an all-in-one reference
    executor. Remote verify routes are diagnostic/conformance helpers, not trust
    authorities.

Resolution And Payload Semantics

Clients submit canonical segment arrays without discovering authenticated arc
boundaries. Resolution authenticates one complete returned derivation and does
not claim longest-prefix maximality, uniqueness, or application preference.

An empty segment array is strict root identity. Payload selection uses the
explicit reserved @payload segment. A verified payload resolve authenticates
a CID; clients must additionally bind returned full or ranged bytes to that CID
using ordinary CID verification or sdk/unixfs.VerifyRangeBody as appropriate.

Compatibility

The v0.0.4 malt.artifact/v0alpha2 resolve/prove/verify operation set remains
frozen. New integrations should use malt.resolve/v0alpha1 and
malt.read/v0alpha1 rather than adding operations to that compatibility
profile.

This release intentionally removes the former layout/unixfs Go package path.
Consumers should import the model, SDK, or runtime package matching their role.
All current profiles and Go APIs remain experimental before v1.0.0.

Security Boundary

Resolvers, ArcTable indexes, gateways, caches, CAS availability, and reference
execution are untrusted for correctness. Clients accept results only after
local verification against an explicit trusted root and caller-constructed
request. Root freshness, authority, rollback prevention, tenant policy, and
multi-writer arbitration remain application or managed-gateway concerns.

Validation Gate

The release commit is validated with:

git diff --check
gofmt -l .
go test ./...
go vet ./...
go build -buildvcs=false ./...
scripts/build-verifier-wasm.sh dist/verifier
bin/malt-eval run --plan examples/eval-smoke-plan.json --run-id v0.0.5-smoke

Additional gates cover an external consumer of the root facade and protocol
schemas, native and WASM builds, local verifier accept/tamper rejection, and
gateway/Web integration against the exact release source.

Published Tags

  • v0.0.5-rc.1: validated candidate source tag
  • v0.0.5: final experimental source release

Both tags identify the same approved source tree. Source tags are authoritative;
native binaries remain build-from-source. Published browser verifier artifacts
must identify their exact MALT source commit and SHA-256 checksum.

Related Documents