# Ecosystem gap and non-overlap check (rechecked 2026-09-26)

## Method and strength of evidence

The 2026-09-25 investigation queried Mooncakes' public search endpoint for
[`tuf`](https://mooncakes.io/api/v0/search?kw=tuf&limit=20) and
[`tuf client`](https://mooncakes.io/api/v0/search?kw=tuf%20client&limit=20);
both returned empty results **at that time**. On 2026-09-26, indexed searches
for `TUF`, `MoonTUF`, `The Update Framework`, and combinations of
`root.json`, `timestamp.json`, `snapshot.json`, and `targets.json` with
Mooncakes/MoonBit did not surface a direct four-role TUF client. The search API
could not be fetched again from this environment, so the earlier empty result
is **not** asserted as a fresh complete-registry result. Search indexing,
package names, and publication state can all change. These observations cannot
prove universal absence or exclusive novelty; repeat a live registry search
and inspect new near matches immediately before publication.

## Nearest published or visible adjacent work

| Package or source | Verified boundary | Difference from MoonTUF |
| --- | --- | --- |
| [`moonbit-community/proton_updater`](https://github.com/moonbit-community/proton/blob/main/updater/README.mbt.md) | Its current first-party README calls it the shared Proton update-manifest schema: decoding and ordering, **without cryptography, network, or filesystem**; signature verification is the caller's responsibility. Proton's [runtime facade in the published 0.1.15 source](https://assets.mooncakes.io/assets/moonbit-community/proton%400.1.15/facade_updater.mbt.html) separately exposes signed-offer checking and native installation. | Proton's overall desktop updater is a genuine adjacent signed-update solution, but its schema module is not a TUF four-role verifier. MoonTUF verifies root/timestamp/snapshot/targets trust and delegated target paths without owning a particular desktop runtime, transport, or installer. |
| [`xiguaAp6y3/moon-httpsig`](https://mooncakes.io/docs/xiguaAp6y3/moon-httpsig) | RFC 9421 HTTP message-signature canonicalization, HMAC signing/verification, and policy. | Authenticates HTTP messages, not TUF repository metadata, role rotation, snapshot pinning, or target-file admission. |
| [`cogna-dev/sbom`](https://mooncakes.io/docs/cogna-dev/sbom) | Software-composition analysis and SPDX/CycloneDX SBOM generation from dependency manifests. | Describes components and dependencies; it does not decide whether a time-evolving update repository or downloaded artifact is trusted. |
| [`python123/moondepsolve`](https://mooncakes.io/docs/python123/moondepsolve) | Semantic-version parsing and dependency resolution for package tooling. | Selects compatible versions; MoonTUF intentionally excludes dependency solving and installation. |

The previous investigation also recorded Mooncakes entries for
[`starlittle/MoonEvidence`](https://mooncakes.io/api/v0/modules/starlittle/MoonEvidence)
and [`liyun/moonseal`](https://mooncakes.io/api/v0/modules/liyun/moonseal)
as provenance/release-audit neighbors. Their module records were not
independently retrievable in this recheck; those earlier classifications are
retained as leads, **not** as freshly verified descriptions. The direct-source
comparisons above carry the current non-overlap argument.

The local MoonBit workspace inventory at project selection contained MoonBDD,
MoonCurveFit, MoonExternalSort, MoonGrammata, MoonHttpCache, MoonIPFIX,
MoonLab, MoonMIME, MoonMVT, MoonOCL, MoonSCIM, MoonSuccinct and MoonTusCore.
Their primary subjects differed from a TUF client. MoonTUF was therefore
created as an independent local repository, not an extension of those projects.
This inventory is historical and must also be refreshed before release.

## Why the reusable boundary matters

The [TUF 1.0.36 specification](https://theupdateframework.github.io/specification/latest/)
defines four fundamental top-level roles and explicitly distinguishes its
security framework from package formats and actual installation. It names
package managers, individual application updaters, and plugin/library managers
as examples of software-update systems. This supports a transport- and
installer-independent trust core that can also be embedded in firmware, model,
rule, and internal-artifact distribution hosts. These latter scenarios are
**integration inferences**, not claims that MoonTUF itself provides a firmware
installer, model registry, or policy engine.

MoonTUF is an original MoonBit implementation with a deliberately narrower
Ed25519/SHA-256 JSON profile; it does **not** claim independent TUF conformance
or a security audit. [Python-TUF](https://github.com/theupdateframework/python-tuf)
and the [TUF conformance suite](https://github.com/theupdateframework/tuf-conformance)
were consulted as behavioral references, not copied into the implementation.