mesh: a cut journal is caught by the receipts the steward handed out, and the receipt chain survives a restart #306

Merged

dcharlot merged 1 commit from feat/mesh-journal-witness into main 2026-10-18 00:42:33 -04:00

Conversation 0 Commits 1 Files changed 4 +341 -72

dcharlot commented 2026-10-17 11:57:22 -04:00

Owner

Copy link

Stacked on #301 (itself on #294 and #300). Merge those first. This branch is #301's exact head plus one commit.

What was left open after #301

The journal re-established a grant's spend on restart, but nothing could tell whether records had been cut from its end. Removing a serve's records gave the grant its spend back and unspent its presentation, so a captured presentation could be replayed.

Separately, a restarted steward began a new receipt chain at sequence 0, so a restart looked the same as a log that had lost its history.

The fix

• The journal is one chain: each record is {seq, prev, entry}, where prev is the BLAKE3 hash of the previous record's encoding. A record removed from the middle, edited or moved fails the replay. Only a cut from the end leaves a whole chain.
• Every receipt is recorded before it is handed out: granted or not, each receipt gets a Sealed record holding its sequence and envelope id. ReceiptLog::seal_next / advance split sealing from advancing, so a receipt that cannot be recorded is not handed out and the chain does not pass it.
• The receipt chain continues across a restart, from the last Sealed record (ReceiptLog::resume), instead of starting over at 0.
• Mesh::witness(receipt, envelope): anyone holding a receipt this steward sealed can show it. If the journal does not hold it, records were cut after that receipt left, and the spend the steward replayed is less than it signed for. The steward returns JournalCut and refuses every grant from then on. Ungranted serves are unaffected. A witness that is not the steward's own unaltered receipt is WitnessInvalid.
• SPEC §2.2, §6.3, §7 and §8 describe it, including what remains. A cut that removes only an in-flight serve, which produced no receipt, leaves no evidence outside the steward. A caller SHOULD show its latest receipt after the steward restarts.

Checked

On the build host:

• mesh-rs: 77 tests pass, four of them new. They cover a receipt proving a cut, chain continuity across a restart, a record removed from the middle or edited, and a foreign or altered witness. The existing journal tests now count seal records.
• Vectors: every mesh/1 vector is byte-identical.
• Lockfiles and clippy: every Cargo.lock in the repo is current (--locked), and clippy is clean on mesh-core and mesh-receipt.
• Mutations: each fails tests:
  • a witness that always passes
  • a detected cut that is ignored
  • seals not recorded
  • no chain check
  • a chain not resumed
• Repository checks: spec references, tests-in-CI, vanity metrics and orphan sources all pass locally.

🤖 Generated with Claude Code

> **Stacked on #301** (itself on #294 and #300). Merge those first. This branch is #301's exact head plus one commit. ## What was left open after #301 The journal re-established a grant's spend on restart, but nothing could tell whether records had been **cut from its end**. Removing a serve's records gave the grant its spend back and unspent its presentation, so a captured presentation could be replayed. Separately, a restarted steward began a **new receipt chain at sequence 0**, so a restart looked the same as a log that had lost its history. ## The fix - **The journal is one chain:** each record is `{seq, prev, entry}`, where `prev` is the BLAKE3 hash of the previous record's encoding. A record removed from the middle, edited or moved fails the replay. Only a cut from the end leaves a whole chain. - **Every receipt is recorded before it is handed out:** granted or not, each receipt gets a `Sealed` record holding its sequence and envelope id. `ReceiptLog::seal_next` / `advance` split sealing from advancing, so a receipt that cannot be recorded is not handed out and the chain does not pass it. - **The receipt chain continues across a restart,** from the last `Sealed` record (`ReceiptLog::resume`), instead of starting over at 0. - **`Mesh::witness(receipt, envelope)`:** anyone holding a receipt this steward sealed can show it. If the journal does not hold it, records were cut after that receipt left, and the spend the steward replayed is less than it signed for. The steward returns `JournalCut` and refuses every grant from then on. Ungranted serves are unaffected. A witness that is not the steward's own unaltered receipt is `WitnessInvalid`. - **SPEC** §2.2, §6.3, §7 and §8 describe it, including what remains. A cut that removes only an in-flight serve, which produced no receipt, leaves no evidence outside the steward. A caller SHOULD show its latest receipt after the steward restarts. ## Checked On the build host: - **mesh-rs:** 77 tests pass, four of them new. They cover a receipt proving a cut, chain continuity across a restart, a record removed from the middle or edited, and a foreign or altered witness. The existing journal tests now count seal records. - **Vectors:** every `mesh/1` vector is byte-identical. - **Lockfiles and clippy:** every `Cargo.lock` in the repo is current (`--locked`), and clippy is clean on mesh-core and mesh-receipt. - **Mutations:** each fails tests: - a witness that always passes - a detected cut that is ignored - seals not recorded - no chain check - a chain not resumed - **Repository checks:** spec references, tests-in-CI, vanity metrics and orphan sources all pass locally. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 3 commits 2026-10-17 11:57:23 -04:00

mesh: a grant is decided by JCP's runtime, so expiry, caveats, the model and spend bind ... afde4f18ec

Mesh honoured a JCP grant by checking three things: the issuer signature,
that the capability permits `infer` on the request, and that the budget
covered the request's ceiling. Nothing else was checked:
- An expired grant was served.
- No caveat was evaluated, so `NotAfter`, `NotBefore`, `PayloadIs`,
  `MaxCostUj` and `ModelIn` were ignored.
- Nothing was ever debited, so one grant paid for any number of serves.
mesh-core had no unit test of the grant path.

The steward now holds a jcp-runtime `Runtime` and decides every grant in
JCP's two-phase metered path:
- **Route.** With a grant, a backend whose model the grant's `ModelIn`
  does not permit is inadmissible, and so is one that names no model. The
  route is the cheapest permitted backend, and the candidates record why
  the others were refused (`Router::route_where`).
- **Authorise,** before any work. The frame names `infer` on the request,
  the prompt hash as payload, and the chosen backend's weights as `model`.
  Signature, expiry, revocation and every cost-independent caveat apply,
  and what the grant has left must cover the request's ceiling.
- **Debit,** after metering. The metered joules are charged whatever
  happens next. A per-call cost caveat binds here, and a breach is sealed on
  the receipt as `grant_breach`.
- **Model check.** An engine that runs other weights than the ones it named
  before serving is refused a receipt.

Engines name their weights before serving through a new
`ServingEngine::weights_digest()`, which defaults to `None`.

The refusals that existed keep their errors (`GrantInvalid`,
`Unauthorized`, `BudgetTooLow`). `BudgetTooLow` now reports what the grant
has left. SPEC §2, §6.1, §7 and §8 and the README describe the new order.
§8 states that Mesh does not authenticate the caller, honouring a grant
as a bearer token of its subject, and that spend is per steward.

Checked on the build host:
- mesh-rs: 65 tests pass, six of them new, and every regenerated `mesh/1`
  vector is byte-identical.
- The gguf and openai server features build.
- clippy is clean on the changed crates.
- Mutations: no debit, a router that ignores the filter, ignoring other
  denials, and skipping the model check each fail tests.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

jcp: a chained decision enforces caveats, and a chain cannot drop one ... f0952309c1

`decide_chained` evaluated no caveat at all: not the leaf's, not any
ancestor's. It is the decision path behind jcp-wire's endpoint (§11),
jcp-channel, jouleclaw-jcp and joule-code-jcp. Those always present a
chain, even a one-link chain for an undelegated grant. So `PayloadIs`,
`NotBefore`, `NotAfter`, `CallerIs`, `ActionIn`, `MaxCostUj` and
`ModelIn` were enforced only on the single-grant `decide`/`authorize`
path, which the conformance suite exercises.

Separately, `verify_chain` checked capability, budget, expiry and depth
at each hop, but not that a child carries its parent's caveats or no
wider money ceiling. `attenuate` refuses both when it mints. A chain
minted by hand verified anyway and conveyed the authority the caveat
withheld.

- `verify_chain` refuses a hop that drops a parent caveat
  (`caveats_narrow`) or widens or drops its money ceiling
  (`funds_narrows`). Both are denied `attenuation-violation`.
- The chained decision's checks move into `check_chained`, which now
  evaluates every link's caveats. Cost-dependent ones are evaluated when
  the cost is known.
- `authorize_chained` / `charge_chained` add the two-phase metered path
  for a chain. Authorize debits nothing and reports the least any link
  has left. Charge debits every link, so siblings share their parent as
  in `decide_chained`, and a per-call breach is reported with the joules
  still debited.
- SPEC §4.2 states both rules and the chained metered path. C7's
  conformance check covers an inherited caveat and a dropped one.

Checked on the build host:
- jcp-rs: 501 tests pass, and the conformance suite passes all checks.
- Every vector gen-vectors writes is byte-identical.
- jouleclaw-jcp, joule-code-jcp and sandbox-jcp pass their tests.
- mesh, joule-ui, joulehook and jouledesk compile.
- Mutations each fail tests: chains ignoring caveats, `verify_chain`
  allowing a dropped caveat, and a charge debiting only the leaf.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

joulehook-rs: lock mesh-core's new dependency on jcp-runtime ... 3e2e3f85f3

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot force-pushed feat/mesh-journal-witness from 9eb217be9f to 29ee437557 2026-10-17 17:14:50 -04:00 Compare

dcharlot merged commit f26f088ebe into main 2026-10-18 00:42:33 -04:00

dcharlot referenced this pull request from a commit 2026-10-18 00:42:34 -04:00

Merge pull request 'mesh: a cut journal is caught by the receipts the steward handed out, and the receipt chain survives a restart' (#306) from feat/mesh-journal-witness into main

dcharlot referenced this pull request from a commit 2026-10-18 02:21:12 -04:00

mesh: a grant rides over the OpenAI-compatible HTTP binding, and a receipt can be shown back as a witness

dcharlot referenced this pull request 2026-10-18 02:21:14 -04:00

mesh: a grant rides over the OpenAI-compatible HTTP binding, and a receipt can be shown back as a witness #312

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!306

No description provided.