There is no DreamWeave server in the middle of this. A mod’s own site says what the mod is, and anything else is a reader.
Truth at the origin, everyone else reads it
The project's own site is the only authority. Clients, indexes and mirrors are readers.
-
source
Project repository
index.md, mod.toml, mod.lock and the mod's files, reviewed in git.
-
result
Static mod site
The page people read, plus dreamweave.json and one manifest per project.
Clients
CHIMERA or anything else: discover, pick a release, verify, install.
Indexes
St4sh or a community list: crawl, cache, search. Never the only copy.
Mirrors and caches
Serve bytes by SHA-256. Never trusted, always verified.
How the pieces relate
- Project repository CI builds it with Zola Static mod site
- Static mod site direct discovery Clients
- Static mod site crawl dreamweave.json Indexes
- Clients download by digest Mirrors and caches
Is this mod ready?#
Every site built from the template has a Network page. For each project it shows the
id, the manifest URL and digest, and a list of checks: discovery, published releases, channel heads,
content hashes, resolvable relationships, signatures, source revisions, mirrors, and any content file
in the payload that mod.toml does not mention. They are computed when the site is built and cover
structure, not taste.
“Ready” means a client starting from your page can find the manifest, pick a release for its channel, download it from a listed source, and verify it. A project with only a development channel is on the network; a project with a recorded stable release is on it properly.
CHIMERA and other clients#
A client never needs to know this template exists. Given any URL on the site it:
- finds
dreamweave.jsonthrough the page’s<link>or by walking up the path; - reads the project manifest and checks
project.id; - picks the head of the channel the player follows and checks runtimes, platforms and critical extensions;
- resolves
requiresby id or capability, checksconflicts; - downloads an artifact from any source and verifies size and SHA-256, falling back to the next source on mismatch;
- optionally verifies a Sigstore bundle against the identity the manifest names;
- applies the declarative install data: data directories, content files in order, fallback entries, settings the player agrees to.
Everything in that list is in the protocol. None of it involves HTML, JavaScript, GitHub’s API or DreamWeave infrastructure.
St4sh and other indexes#
An index crawls sites it knows about, reads dreamweave.json, and fetches a manifest when its
manifest_sha256 changes. It can search, categorize, rank, cache manifests and mirror artifacts. It
should show which origin every manifest came from, and it must not become the only copy of a
project’s identity or releases: when the index is gone, the project’s own site still says everything.
Mirrors and caches#
A mirror stores artifacts by SHA-256 and serves them to anyone who asks for that digest. It does not
need permission, because it is never trusted: a client already knows the digest from the project’s
manifest and rejects anything else. Authors can list mirrors in mod.toml (Distribution);
clients can also use caches nobody listed. Nothing about this depends on the transport, so a LAN
cache, an archive service, or peer-to-peer transfer later all fit without a protocol change.
Existing channels#
Nothing here replaces GitHub Releases, Nexus Mods or anywhere else a mod is already published. Those become sources and integrations in the manifest. Players who never touch a DreamWeave client see an ordinary mod page with ordinary download buttons.