mesh: a grant is spent only by its issuer, at the steward it names, and its spend survives a restart #301

Merged

dcharlot merged 1 commit from feat/mesh-caller-auth-durable-spend into main 2026-10-18 00:42:18 -04:00

Conversation 0 Commits 1 Files changed 12 +757 -104

2026-10-17

Transaction Science

mesh: a grant is spent only by its issuer, at the steward it names, and its spend survives a restart ...

After #294, mesh decided a grant with JCP's runtime but honoured it as a
bearer token. Whoever presented a grant was taken to be its subject, and
the steward's spend lived in memory. Three consequences:
- Anyone who obtained a grant could spend it and receive the output.
- The same grant spent its full budget again at every steward it was
  shown to.
- A restart gave every grant its budget back.

**Caller authentication (SPEC §2.1).** A grant is now presented as a
`Presentation`: the delegation chain, root first, plus a caller, a nonce
and an Ed25519 signature over the request id, the leaf's id, the caller
and the nonce.
- The steward refuses a presentation whose caller is not the leaf's
  issuer, or whose signature is not for this request.
- The steward refuses a presentation it has already spent, keyed by leaf
  and nonce, so a captured one cannot be replayed.

**Steward-held grants (SPEC §2.1).** The steward decides the chain as its
holder, under its sealing key's identity, so the leaf's subject must be
this steward. A grant shown to another steward is refused
`NotThisSteward`. One budget over several stewards is sharded with
`jcp_grant::shard` (JCP §4.5): one shard held by each steward, summing to
no more than the parent. Chains are decided with jcp-runtime's new
`authorize_chained` / `charge_chained` (#300), which check every link and
debit every link.

**Durable spend (SPEC §2.2, JCP §4.11).** The decision journal:
- **Before the engine runs,** each decision is recorded as an
  `Authorised` entry. A decision that cannot be recorded is refused.
- **After the debit,** a `Debited` entry is recorded.
- **On restart,** `Mesh::with_journal` replays the journal through the
  gate. Each authorisation is verified and decided again at its recorded
  time, and each debit is applied to its serve.
- **Inconsistent journals** fail with `JournalInconsistent`: a replay the
  gate refuses, a debit with no authorisation, or a presentation spent
  twice.
- **In-flight serves** (authorised, never debited) stay debited at their
  ceiling. They are listed in `unresolved()` with the caller and backend,
  and never retried.
- **The reference `FileJournal`** is append-only JSON lines, synced per
  append. A torn final line is dropped and cut from the file.

`Mesh::serve` and mesh-openai's `complete_chat` / `complete_responses`
take `Option<&Presentation>`. The demo and the falcon binary present
their grants. The HTTP server presents none, as before. SPEC §2, §2.1,
§2.2, §7 and §8 and the README describe all of it.
joulehook-rs locks mesh-core through a path dependency, so its Cargo.lock
is updated too.

Checked on the build host:
- mesh-rs: 73 tests pass, eight of them new. They cover a grant held
  elsewhere, a wrong or misdirected caller, replay, shards across two
  stewards, restart resumption, an in-flight serve, a forged journal and a
  torn file line.
- Every `mesh/1` vector is byte-identical, and the lockfile is current.
- The gguf and openai server features build, the demo runs, and clippy is
  clean on mesh-core and mesh-openai.
- Mutations each fail tests: no caller check, no replay check, bearer
  subject, replay dropping debits, in-flight not debited, and replay
  trusting the journal.

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

f79fffd9fa

• View at this point in history

2026-10-17 17:13:42 -04:00