@network-harness/artifacts-git
v0.2.0
Published
Part of the network harness: @network-harness/artifacts-git.
Downloads
293
Readme
@network-harness/artifacts-git
The artifact store two peers negotiate over, claiming ctx.artifacts: one
history per resource, each revision attributed to the node that authored it, and
agreement recorded as a mark on a revision.
git is used for what it is good at -- content-addressed history, a diff, and a bundle that moves a revision between two repositories that share no remote -- and trusted for nothing else:
- Authorship is recorded here, not read from git. A commit is authored as this node; an import is authored as the peer on the session the caller named, read from the adapter's session record. The author field inside a peer's bundle is not evidence, so the store keeps its own record beside the repository, where a commit cannot rewrite it and a bundle cannot reach it.
- The session is read through the caller's own context, so the store holds no ambient access to sessions -- only to the ones the protocol calling it already owns. A protocol cannot attribute a revision to a peer it is not talking to.
- Verify before applying. A bundle's size and hash are checked, then git's
own
bundle verify, and only then may it near a ref. It must also continue the history it claims to: the head it names has to be the current head, and the revision has to descend from it. - A workspace is a copy, not a checkout. A run writes into a plain directory, so nothing it does can reach the repository's objects, and it is bounded by file size, file count, total size, and count per protocol, with a TTL: it is scratch space, not storage.
Resources are scoped to the calling protocol, which is half of the path they live under, so one protocol cannot reach another's by name.
The conformance suite both this and @network-harness/artifacts-memory must satisfy lives in core/network/tests/artifactSuite.ts.
