jerry/buzz

mirror of https://github.com/block/buzz.git synced 2026-11-06 09:21:45 +00:00

Files

ss-dev-00 b173f46e75 broker: add host authority pipeline, execution log, and agents policy

The trusted path lives in one Rust function:

verified frame -> authorize -> validate -> claim -> dispatch -> complete

It is a single function rather than coordinated steps because every stage
boundary is somewhere a caller could otherwise substitute its own answer
for "who is asking" or "has this already run", and a crash between two
coordinated steps is a side effect nobody recorded.

Identity arrives as VerifiedRequest, whose construction asserts that
owner, requester, and relay scope came from the verified transport.
Nothing in the request body can influence them, so a signer cannot name
someone else as owner. A payload that tries fails to deserialize.

The digest is computed here, over the exact decrypted bytes, after a size
bound. No canonical encoding has to be agreed on and no second
implementation can drift from this one.

The execution log is keyed by
(relay_scope, owner, requester, capability, request_id) and inserts
`executing` before the first side effect. Terminal rows replay; a
digest mismatch is a conflict, checked before state so a conflicting
retry can never be answered with the first request's result; an existing
`executing` row becomes `indeterminate` and is never blindly re-executed.
Claim runs in an IMMEDIATE transaction -- a test races eight threads to
show exactly one winner.

This guarantees at-most-once plus indeterminate. Not exactly-once, and
not durable completion: the log can prove execution started, never how
far it got. Reconciling partial effects belongs to the capability that
knows its own phases.

Authorization is split from authentication. The broker proves who signed;
whether that signer may manage agents is an agents.* scope rule, so a
future capability cannot inherit it. The rule is that the requester must
be one of this owner's managed agents, read from the authoritative Rust
roster. It fails closed when the roster cannot be read, and refuses the
owner key itself as a requester.

Per the approved design, there is no channel restriction on the target of
an update or delete: an owner's agent is theirs regardless of channel,
and requiring co-membership would look tighter than it is while adding no
real constraint. Channel appears only on create, where attachment needs
it.

Signed-off-by: ss-dev-00 <a02c4e0850e5e612b4ddf95dbe2f5c56467cf27c6552203bc833ff438fb31971@buzz.block.builderlab.xyz>
Co-authored-by: Bradley Axen <baxen@squareup.com>
Signed-off-by: Bradley Axen <baxen@squareup.com>

2026-08-21 19:55:22 -07:00